Lessons from a successful modern PKI Design

When a PKI has sat untouched for more than a decade, the question is rarely whether improvements are needed. It is where to begin. That was the situation facing one of the largest rural lifestyle retailers in the United States, founded in 1938 and now operating more than 2,000 stores across 49 states. The company serves millions of customers with everyday products for home, land, pet, and animal care, and it depends on a resilient digital backbone to keep that trust and service consistent.

What is a modern PKI design? A modern PKI design replaces a single aging Certificate Authority with an HSM-backed root and issuing CA hierarchy, defined certificate validity periods, consistent CRL and OCSP publication, and centralized governance. This case study shows how a 2,000-store U.S. retailer used that approach to close key storage, revocation, and access control gaps in a decade-old PKI.

Executive Summary

• A 2,000-store U.S. retailer redesigned a Public Key Infrastructure that had gone largely unchanged for more than a decade.
• The redesign replaced unprotected, software-based private keys with HSM-backed storage for the Root and Issuing CAs.
• Certificate and CRL lifetimes were standardized, and dedicated disaster recovery CAs were introduced for the first time.
• Governance was rebuilt around documented certificate templates and role-based issuance rights.
• The result is a scalable, auditable PKI built to support automation and crypto-agility going forward.

Why This Enterprise Needed a Modern PKI Design

As part of a broader initiative to strengthen its IT security posture, the organization launched a detailed assessment of its Public Key Infrastructure (PKI). The assessment quickly revealed that the existing infrastructure carried several risks, including unchecked CA validity periods, irregular CRL publication intervals, and private keys stored on software-based machines. These findings pointed to the need for a structured approach rather than a series of one-off fixes.

Instead of patching issues reactively, the team built a custom roadmap to address the core risks and reduce the overall attack surface of the existing PKI environment. Rather than moving straight into implementation, the organization chose the more deliberate step of designing the PKI first. This let them lay out the architecture of the new environment, define the role of the existing PKI during the transition, identify the right starting point, and establish a structured migration plan. The goal was to bring clarity, simplify management, and build a sustainable PKI equipped with modern technologies and aligned with current security standards.

After all, you do not build a bank vault without blueprints, so why build a PKI without a design for it first?

The PKI design took shape through multiple in-depth working sessions and technical discussions with stakeholders from across the organization. These sessions established a clear trust hierarchy of Root and Issuing CAs, aligned the architecture with the Active Directory Forest design, and streamlined certificate lifecycle management for the organization’s users, devices, and application scenarios. The resulting architecture was customized to support the company’s distributed AD domain structure, so that each domain’s use cases and operational workflows were reflected in the final design.

Common Challenges in Legacy PKI Environments

Before looking at what the new design fixed, it helps to understand why a fix was needed at all. The organization’s Public Key Infrastructure (PKI) was running on aging infrastructure, hosted primarily on Windows Server 2012 R2. A detailed workshop review of existing PKI policies, procedures, and standards surfaced the following architectural and operational weaknesses.

Trust Chain and Disaster Recovery Gaps

• The PKI trust chain was built around a single Root Certification Authority (CA) and multiple Issuing CAs, but no formal backup or disaster recovery strategy existed for any of them. A CA failure or data center outage would have left the organization with no reliable path to restore certificate issuance.

Private Key Storage and Certificate Lifetime Risks

• The Root CA and Issuing CA private keys were stored without the protection of a Hardware Security Module (HSM). As one senior security engineer on the project put it, “that is like locking the crown jewels in a filing cabinet.” The absence of HSM protection significantly raised the risk of key theft or compromise.
• The Root CA certificate carried a validity period of more than 20 years, well beyond CA/B Forum recommendations. Certificates with such long lifespans widen the potential blast radius if a key is ever compromised and limit the organization’s ability to adapt cryptographically over time.

Infrastructure, CRL, and Endpoint Management Gaps

• The Active Directory Forest was still running a legacy Windows Server version that had reached End of Life (EOL) and End of Support (EOS), which blocked integration with newer PKI capabilities such as certificate auto-enrollment, modern cryptographic templates, and policy-based issuance controls.
• CRL validity periods were configured inconsistently across the three Issuing CAs, ranging beyond 7 days for base CRLs and beyond 24 hours for delta CRLs. This inconsistency created operational overhead and increased the risk of revocation-related errors going unnoticed without constant manual oversight.
• Multiple mobile device management (MDM) platforms were in use to manage different device types, with Android, macOS, and iOS devices spread across separate systems. This fragmented MDM setup added unnecessary complexity and inefficiency to certificate deployment and endpoint trust.

Governance, Access Control, and Template Sprawl

• Within the security settings of all three Issuing CAs, multiple user accounts and groups had been granted certificate issuance and management rights without clear role mapping or justification, a governance gap that raised the risk of misuse or misconfiguration.
• The PKI environment showed a weak governance framework overall. Certificate templates lacked documentation, defined ownership, and clear purpose mapping. Without centralized oversight, the environment had accumulated redundant, outdated, and unused templates, which raised the likelihood of issuing misconfigured certificates.

Modern PKI Design and Solution Architecture

A series of whiteboarding sessions and technical workshops with key stakeholders produced a new PKI architecture built to address the core challenges above and establish a stronger foundation for security, scalability, and operational efficiency. The decisions below reflect the outcomes of those sessions and collectively form the organization’s PKI modernization strategy.

Infrastructure and Certificate Authority Structure

• To move away from outdated infrastructure, the team chose Windows Server 2022 or higher to pilot the new PKI setup, allowing compatibility with modern security features to be evaluated and the architecture validated in a controlled environment before full-scale implementation.
• Two dedicated Issuing CAs, each aligned to a distinct use case, were planned for the data center. This structure provided logical segmentation and supported tailored certificate issuance policies.
• Corresponding Issuing CAs were also planned for a Disaster Recovery (DR) environment to ensure high availability. These DR CAs were built for failover scenarios, were not used to issue certificates during normal operations, and would be tested regularly and kept synchronized through manual configuration replication.

Certificate Validity, CRL, and OCSP Configuration

• The Root CA certificate validity was reduced to 10 years, and Issuing CAs were assigned a 5-year validity. End-entity certificates were configured according to industry best practices.
• Industry best practices shaped the configuration of Certificate Revocation List (CRL) publication and certificate status checking. Subordinate CAs were set to publish base CRLs every 7 days and delta CRLs every 24 hours, with a 2-day overlap period to limit revocation-related disruption during outages. CRL and AIA extensions were distributed over HTTP as the primary path, LDAP as a secondary path, and OCSP, to keep certificate status checks fast and reliable.

Governance, Templates, and Cloud PKI Integration

• A full overhaul of certificate templates removed redundancy, assigned clear ownership, and mapped each template to its intended use, enabling stricter issuance policies and reducing operational ambiguity. Access to the Issuing CAs was restructured so only authorized roles could issue or manage certificates, closing the gaps left by undocumented or excessive user and group permissions.
• To address fragmentation and simplify certificate lifecycle management, the design recommended Microsoft Cloud PKI. This allowed seamless integration with the existing MDM platforms while reducing dependence on on-premises infrastructure, giving the organization a unified, scalable trust model anchored by a single source of truth.

The table below summarizes how the redesign changed each area of the PKI.

Area	Legacy PKI	Modernized PKI Design
Root and Issuing CA key storage	Software-based, no HSM	HSM-backed key storage
Root CA certificate validity	20+ years	10 years (5 years for Issuing CAs)
CRL and delta CRL schedule	Inconsistent across 3 Issuing CAs	Standardized: 7-day base CRL, 24-hour delta CRL, 2-day overlap
Disaster recovery	No formal DR or backup strategy	Dedicated DR Issuing CAs, tested regularly
Certificate templates and access	Undocumented, redundant, broad permissions	Documented ownership, mapped use cases, role-based access
Device management	Fragmented across multiple MDM platforms	Unified through Microsoft Cloud PKI integration

How to Apply This PKI Design Approach: Step-by-Step Playbook

Enterprise PKI teams facing a similarly aging environment can adapt the same sequence used in this case study. The steps below generalize that process into a repeatable playbook, along with the checks, common errors, and rollback options a team should plan for.

Prerequisites

• A completed PKI health assessment identifying Root and Issuing CA risks.
• Executive and stakeholder alignment on scope, budget, and timeline.
• A lab or pilot environment running Windows Server 2022 or later.
• HSM access, whether on-premises hardware or HSM as a service.
• An Active Directory Forest running a currently supported Windows Server version.
• A full backup of the existing CA database, private keys, and CAPolicy.inf file.
• A documented inventory of current certificate templates and their consumers.
• A defined maintenance window and communication plan for certificate holders.

Step-by-Step Implementation Procedure

1. Assess the existing PKI environment. Review CA validity periods, CRL and OCSP configuration, private key storage, and certificate templates against current best practices before changing anything.
2. Design the trust hierarchy. Define the Root CA and Issuing CA structure, align it with the Active Directory Forest design, and document how each domain’s use cases map to the new hierarchy.
3. Pilot the new CA infrastructure. Stand up the Root and Issuing CAs on a current, supported operating system such as Windows Server 2022 or later in an isolated lab before touching production. Example command to confirm the CA type on a pilot server: certutil -getreg CA\CAType
4. Configure HSM-backed key storage. Generate and store the Root and Issuing CA private keys inside a Hardware Security Module using the vendor’s Key Storage Provider, following the vendor’s key ceremony procedure.
5. Set certificate validity periods. Configure Root CA, Issuing CA, and end-entity validity to match policy, for example: certutil -setreg CA\ValidityPeriod "Years" and certutil -setreg CA\ValidityPeriodUnits 5
6. Configure CRL, delta CRL, and OCSP publication. Set consistent base and delta CRL schedules with an overlap period, then publish CRL and AIA information over HTTP, LDAP, and OCSP, for example: certutil -setreg CA\CRLPeriod "Days", certutil -setreg CA\CRLPeriodUnits 7, certutil -setreg CA\CRLDeltaPeriod "Hours", certutil -setreg CA\CRLDeltaPeriodUnits 24, certutil -setreg CA\CRLOverlapPeriodUnits 2, then restart the CA service and republish: net stop certsvc && net start certsvc followed by certutil -crl
7. Rebuild certificate templates and access controls. Retire redundant templates, document an owner and purpose for each remaining template, and restrict issuance and management rights to named roles instead of broad groups.
8. Stand up disaster recovery CAs. Configure Issuing CAs in a Disaster Recovery environment, replicate configuration on a defined schedule, and test failover without issuing production certificates from the DR CAs during normal operations.
9. Integrate cloud PKI where it reduces fragmentation. Where multiple MDM platforms manage different device types, evaluate a cloud-managed CA, such as Microsoft Cloud PKI, to unify issuance and reduce on-premises dependency.
10. Migrate endpoints and decommission legacy trust. Roll out the new chain through Group Policy or MDM, confirm client trust and enrollment, then retire the legacy CA hierarchy only after every consumer has moved to the new PKI.

Validation Checks

• Confirm the certificate chain builds cleanly to the new Root CA using certutil -verify or a client-side chain check.
• Confirm CRL and OCSP endpoints return current, unexpired revocation data from an external network path.
• Issue a test certificate from each rebuilt template and confirm the validity period, key usage, and subject fields are correct.
• Confirm HSM-backed signing succeeds and audit logs show the HSM as the key store of record.
• Confirm the Disaster Recovery CA can process a failover request and that templates are replicated correctly.

Common Errors and Troubleshooting

Error or Symptom	Likely Cause	Recommended Fix
0x80070005 (ACCESS_DENIED) on certutil -setreg	Command run without CA administrator rights or an elevated prompt	Run certutil from an elevated prompt as a member of the CA Administrators group, then restart Certificate Services.
Clients fail revocation checks with 0x80092013	CDP or AIA HTTP location unreachable, or the OCSP responder is down	Confirm CDP and AIA URLs resolve externally and the OCSP responder service is running.
New CRL not visible to clients after a change	CRL not republished after the CA service restart	Run certutil -crl and confirm the file is published to every CDP location before enabling the new schedule.
HSM operations fail with 0x800706BA (RPC server unavailable)	Network path to a networked HSM is blocked, or the HSM client service is not running	Verify firewall rules and confirm the HSM client or PKCS#11 provider service is active on the CA host.
Certificate request denied, policy module error 0x80094800	Template was retired, renamed, or the requester lacks Enroll permission	Confirm the template is published on the Issuing CA and the requester’s security group has Enroll rights.

Rollback Steps

• Revert changed registry values with certutil -setreg using the previously recorded settings, then restart Certificate Services.
• Restore the CA database and private key from the pre-change backup using certutil -restoredb and certutil -restorekey if a validity or key change was already applied.
• Republish the previous CRL with certutil -crl so relying parties see valid revocation data again immediately.
• Fail enrollment back to the legacy Issuing CA through Group Policy until the new CA passes every validation check.
• Leave the Disaster Recovery CA untouched during rollback testing so a validated fallback path stays available.

Business Impact and Results

By closing longstanding architectural gaps and operational inefficiencies, the organization strengthened its digital trust foundation and aligned it with modern security standards. The key business outcomes included the following.

• With private keys now secured in hardware security modules (HSMs), the risk of compromise dropped significantly. The environment moved away from outdated infrastructure and legacy dependencies, enabling smoother integration with modern platforms and cloud-native services.
• Operational clarity improved through tighter governance: certificate templates were streamlined, access controls were properly mapped, and issuance processes became far more predictable and auditable. This reduced administrative overhead and cut the likelihood of errors or misconfigurations.
• Business continuity improved with the introduction of disaster recovery CAs, so critical certificate issuance could continue even during outages. The trust model became more scalable, resilient, and easier to manage, freeing IT and security teams to focus on proactive improvements instead of firefighting a fragmented setup.
• Most importantly, the organization established a future-ready PKI framework capable of supporting growing numbers of users, devices, and applications, while meeting its requirements for crypto-agility and automation across use cases.

Expert Recommendations for Enterprise PKI Teams

• Design before you build. Map the trust hierarchy, ownership, and lifecycle policy on paper before touching production CAs.
• Treat HSM-backed key storage as a baseline requirement for Root and Issuing CAs, not an optional upgrade.
• Right-size certificate and CA validity periods to current best practices instead of carrying forward defaults set a decade earlier.
• Build disaster recovery into the design from day one rather than adding it after an outage exposes the gap.

Conclusion

This modernization journey underscores a simple reality: secure PKI begins with smart design, not reactive fixes. By prioritizing architecture, enforcing access controls, adopting HSM-backed key storage, and streamlining certificate governance, the organization built a scalable, resilient trust foundation. Most importantly, it positioned itself to support future growth, automation, and crypto-agility, proving that a well-planned PKI is not just a security upgrade but a strategic enabler for the digital enterprise.

Frequently Asked Questions

What is the main takeaway from Lessons from a Successful Modern PKI Design?

The main takeaway is that a secure, scalable PKI starts with deliberate design, not reactive patching. By designing a new trust hierarchy before touching production, this retailer fixed root causes such as unprotected private keys, inconsistent CRL periods, and unmapped issuance rights, instead of treating each one as an isolated ticket.

Why does this matter for enterprise PKI teams?

Enterprise PKI teams often inherit infrastructure built years earlier by people who have since left the organization. This case matters because it shows a repeatable way to assess, redesign, and modernize inherited trust infrastructure without disrupting certificate issuance for the users, devices, and applications that depend on it.

What risks increase if this topic is handled manually?

Left to manual, undocumented management, PKI risk increases on several fronts: key compromise from unprotected private keys, revocation failures from inconsistent CRL publication, outages with no disaster recovery path, and misissued certificates from undocumented templates and excessive user permissions.

Which teams should own this change?

Ownership typically spans the identity and access management or security engineering team that runs certificate services, the Active Directory and infrastructure team that maintains the underlying domain, and IT security leadership that signs off on the trust hierarchy, HSM investment, and governance policy.

How does this connect to certificate lifecycle management?

PKI design sets the rules that certificate lifecycle management runs on: how long certificates and CA certificates stay valid, which templates issue them, how revocation is checked, and who can request or approve issuance. Fixing the design first makes day-to-day lifecycle management predictable instead of ad hoc.

How should organizations measure success?

Success shows up as fewer unplanned certificate outages, faster and auditable issuance requests, private keys demonstrably protected in an HSM, CRL and OCSP responses returned reliably within their published windows, and a documented mapping between every certificate template and its business owner.

What should be audited or monitored regularly?

Teams should regularly audit CA and end-entity certificate validity periods, CRL and delta CRL publication times, HSM key usage logs, certificate template permissions and ownership, and the health of disaster recovery CAs to confirm they stay synchronized and ready for failover.

How does this topic affect cloud, hybrid, or multi-CA PKI?

In hybrid and multi-CA environments, inconsistent validity periods, CRL schedules, and access controls compound quickly across CAs. This case study’s move toward Microsoft Cloud PKI shows how centralizing policy across on-premises and cloud-managed CAs reduces fragmentation while still supporting multiple MDM platforms and device types.

What prerequisites are required before implementation?

Before implementation, teams need a completed PKI assessment, executive and stakeholder alignment, a lab environment on a current server OS, HSM access or procurement, an Active Directory Forest on a supported version, a full backup of the existing CA database and private keys, and a documented inventory of current certificate templates.

What common errors should administrators watch for?

Administrators should watch for access-denied errors when changing CA registry settings without elevated CA administrator rights, expired or unreachable CRL and OCSP endpoints after a configuration change, HSM connectivity failures over the network, and certificate requests denied because a template was retired or renamed without updating enrollment permissions.