How to Modernise Legacy PKI Securely in 2026

How to Modernise Legacy PKI Securely in 2026

Public Key Infrastructure rarely appears at the top of a transformation roadmap. It sits underneath everything else, quietly authenticating devices, securing machine-to-machine traffic, signing code and underpinning identity. That invisibility is precisely why so many organisations are now working with certificate authorities designed for a world of domain-joined desktops and annual renewal cycles, while supporting cloud-native workloads, ephemeral containers and supply chains that expect certificates to be issued in seconds.

Modernisation is no longer a matter of preference. Shortening certificate lifetimes, the migration to post-quantum cryptography and increasing regulatory scrutiny of cryptographic governance have combined to put a firm timescale on the work. The difficulty is that PKI is one of the least forgiving systems to change. A misconfigured migration does not degrade gracefully. It takes services offline.

This guide sets out what makes legacy PKI modernisation genuinely hard, covering the security, operational and migration barriers organisations encounter, and describes a structured approach to reducing risk while upgrading certificate management.

What legacy PKI actually looks like

Legacy PKI is seldom a single ageing server. In most enterprises it is an accumulation of decisions made by different teams over fifteen or twenty years, each reasonable at the time.

Typical characteristics include a Microsoft Active Directory Certificate Services deployment that has grown organically, with certificate templates configured by administrators who have long since moved on. Alongside it there may be an end-of-life commercial CA platform retained because one critical application depends on it, a set of departmental or project-level certificate authorities established outside central governance, and one or more offline root CAs whose key ceremony documentation is incomplete.

Certificate issuance is often split between this private estate and multiple public certificate authorities, procured independently by different business units. Hardware security modules may be present, though frequently they are past their firmware support window or configured in a manner that no longer reflects current assurance requirements. Inventory, where it exists, lives in a spreadsheet that was accurate at the point it was created.

The defining feature of legacy PKI is the absence of a reliable, current picture of what exists, what depends on it and who is accountable for it. Every subsequent difficulty follows from that.

Why modernising legacy PKI is difficult

Organisations that have attempted PKI modernisation and stalled usually did so for one of three reasons. Understanding all three before starting is the single most effective way of avoiding the same outcome.

Security barriers

The first barrier is that legacy PKI often carries risks that are only discovered once the environment is examined properly.

Certificate template misconfiguration in AD CS remains one of the most consistently exploited weaknesses in enterprise environments. Templates that permit requesters to supply their own subject alternative name, combined with enrolment permissions granted to broad domain groups, create straightforward paths to privilege escalation. These conditions have often existed for years without detection, because certificate issuance is rarely covered by conventional vulnerability management.

Key material presents a related problem. Where private keys for issuing CAs have been generated or stored in software rather than within a hardware security module, the assurance level of every certificate beneath them is limited accordingly. Establishing whether keys were generated under adequate controls, and whether the ceremony was witnessed and evidenced, is frequently impossible for older infrastructure.

Cryptographic algorithm inventory is a third concern. Estates still contain SHA-1 signatures, 1024-bit RSA keys and certificate profiles that were compliant when issued and are no longer defensible. Because these certificates continue to validate within closed environments, they persist without generating alerts.

Finally, revocation infrastructure is often the weakest link. Certificate revocation lists published to endpoints no longer monitored, OCSP responders without adequate redundancy, and validity periods that make revocation practically irrelevant all undermine the trust model the PKI is supposed to provide.

A modernisation programme that begins with design rather than assessment will carry these issues into the target state.

Operational barriers

The second barrier concerns how the estate is run day to day.

Certificate management in legacy environments depends heavily on individual knowledge. A small number of people understand which applications consume which certificates, which renewals require manual intervention and which systems will fail silently if a chain changes. That knowledge is rarely documented and represents a substantial concentration of risk.

Manual renewal processes do not scale to shortened lifetimes. Under the CA/Browser Forum timeline agreed in 2025, maximum public TLS certificate validity reduces to 200 days from March 2026, to 100 days from March 2027 and to 47 days from March 2029. An organisation renewing several hundred public certificates manually on an annual cycle will be performing that work roughly eight times more often by the end of the decade. Private PKI is not directly bound by these limits, though internal policy and audit expectations tend to follow the public trend. This is examined further in Reduction of Public TLS Certificate Lifetimes.

Visibility is the connected problem. Most organisations discover during assessment that their certificate estate is materially larger than their records suggest, with the difference accounted for by self-signed certificates in development environments, certificates embedded in appliances, and certificates issued by cloud platform services outside central procurement. Automation cannot be applied to assets that have not been identified, as set out in What is Certificate Lifecycle Management.

Ownership creates a further constraint. PKI typically sits across security, infrastructure and application teams without a single accountable owner. Modernisation requires decisions about policy, architecture and funding that no individual team is positioned to make alone.

Migration barriers

The third barrier is the migration itself, and it is where most technical risk concentrates.

Trust chain continuity is the central challenge. Every certificate issued by a legacy CA remains valid until it expires, and every system that validates those certificates must continue to trust the issuing hierarchy throughout the transition. Introducing a new root or issuing CA therefore requires trust store distribution across the entire consuming estate, including systems that are difficult to reach, embedded devices with static trust stores and third-party platforms outside direct control.

Certificate profile parity is more demanding than it first appears. Subject naming conventions, extended key usage values, certificate policy object identifiers, CRL distribution points and authority information access extensions must be replicated accurately on the target platform. Consuming applications frequently depend on specific extension values in ways that are not documented. Minor differences in profile construction can cause validation failures that surface only under particular conditions.

Application dependencies compound this. Applications that pin certificates or public keys, validate against a hardcoded issuer, or rely on a specific certificate chain order will break when the issuing hierarchy changes. Identifying these dependencies requires application-level engagement rather than infrastructure-level analysis alone. Our view on pinning is set out in Certificate Pinning: Why a Once Sensible Practice Has Become a Liability.

Vendor support is often limited. Where an organisation is migrating away from an end-of-life platform, the outgoing vendor has little commercial interest in assisting, and the incoming vendor may consider the migration path unsupported. In one public sector engagement, Unsung developed a repeatable migration methodology for re-platforming twenty root certificate authorities from Entrust to EJBCA after the vendor assessed the migration as unfeasible, completing it with no operational impact to business services. The detail is available in the Entrust to EJBCA migration case study.

Rollback is the final consideration. Unlike most infrastructure changes, PKI migration cannot always be reversed cleanly once certificates have been issued from a new hierarchy and distributed. Migration planning must therefore establish decision points at which a change can still be withdrawn, and design forward paths for the stages where it cannot.

The pressures shaping the 2026 decision

Several developments have converged to make modernisation time-bound rather than discretionary.

Certificate lifetime reduction is the most immediate. The phased reduction to 47-day public TLS certificates makes manual certificate management operationally unsustainable and removes automation from the category of optional improvement. Code signing certificate validity is being reduced on a similar trajectory, affecting software release processes and CI/CD pipelines, as covered in Code Signing Certificates Move to 460 Days.

Post-quantum cryptography sets the longer horizon. NIST published its first post-quantum standards in 2024, covering ML-KEM, ML-DSA and SLH-DSA, and has signalled that RSA and elliptic curve cryptography at current strengths should be deprecated from 2030 and disallowed by 2035. The UK National Cyber Security Centre has published a corresponding migration timeline, expecting organisations to complete discovery and produce a migration plan by 2028, deliver highest-priority migration activity by 2031 and complete migration by 2035. Legacy CA platforms that cannot issue certificates using post-quantum algorithms, or support hybrid certificate constructions, will require replacement regardless of any other consideration. Further detail is available in Navigating the NIST Post-Quantum Cryptography (PQC) Roadmap.

Regulatory expectation has also increased. The EU Cyber Resilience Act, NIS2 and DORA each place obligations on cryptographic governance, supply chain assurance and demonstrable control of digital trust infrastructure. Organisations supplying into regulated sectors are increasingly asked to evidence cryptographic inventory and lifecycle governance as part of assurance processes.

Zero Trust architecture provides the fourth driver. Zero Trust depends on strong, verifiable identity for every workload, device and service, and certificate-based identity is the practical mechanism for delivering it. A PKI that cannot issue at machine speed, across cloud and on-premises environments, constrains the wider security strategy. The relationship is explored in The Role of PKI in Zero Trust Security Strategies.

A structured approach to secure modernisation

The approach below reflects how Unsung delivers PKI modernisation for central government, defence, financial services, healthcare, transport and critical national infrastructure clients. It is deliberately sequential, because each phase produces the evidence required to make the next set of decisions safely.

Phase one: establish the facts

Modernisation begins with discovery rather than design. The objective is a complete and current picture of the cryptographic estate, covering certificate authorities and their hierarchies, issued certificates across private and public sources, key material and its storage, hardware security modules and their configuration, algorithms and key lengths in use, and the applications and services that consume each element.

Network-based discovery identifies certificates in use. Interrogation of CA databases identifies certificates issued. Configuration review of application and platform inventories identifies certificates embedded where neither method reaches. All three are required, because each finds assets the others miss.

This phase also produces the foundation for a Cryptographic Bill of Materials, which is becoming the accepted structure for recording cryptographic dependencies and will underpin post-quantum planning.

Phase two: assess against best practice

With the estate documented, the next step is to assess it against security best practice, relevant compliance frameworks and the organisation's own certificate policy and certification practice statement, where these exist.

A PKI Health Check examines hierarchy design, CA configuration, template and profile security, key management and HSM configuration, revocation infrastructure, operational process, governance documentation and cryptographic agility. The output is a prioritised set of findings distinguishing issues requiring immediate remediation from those that should be addressed through the modernisation programme itself.

This distinction matters. Some findings, such as an over-permissive certificate template, should be corrected within days and independently of any migration. Others, such as a hierarchy design that cannot support the required segregation, are properly resolved by the target architecture.

Phase three: design the target architecture

Target state design should be driven by the organisation's requirements rather than by any particular vendor's capability. Vendor-neutral assessment matters here because the correct answer varies considerably. Some organisations are well served by a modern commercial CA platform with strong automation interfaces. Others require an open-source-derived platform for licensing or sovereignty reasons. Many benefit from a managed service that removes the operational burden entirely. Our PKI Design and Build service covers this stage through to delivery.

Design decisions to be resolved at this stage include:

• Hierarchy structure and the degree of segregation between use cases.
• Root CA custody, ceremony requirements and evidence standards.
• HSM strategy across on-premises, cloud and hybrid environments.
• Enrolment protocol support covering ACME, EST, SCEP and CMP.
• Integration with identity, configuration management and orchestration platforms.
• The certificate policy framework that will govern issuance.

Crypto-agility should be treated as an architectural requirement rather than a future enhancement. The practical test is whether the target design allows an algorithm, key length or certificate profile to be changed without redesigning the hierarchy or rebuilding integrations. Designs that pass that test will accommodate the post-quantum transition. Designs that do not will require a further modernisation programme within five years.

Guidance on platform selection is set out in How to Evaluate CLM Vendors and Licensing Models and What Does Crypto-Agility Actually Mean in Practice.

Phase four: plan and de-risk the migration

Migration planning translates the target architecture into a sequence of changes that can be delivered without service disruption.

The core principle is parallel operation. The new hierarchy is established, its trust anchors are distributed and verified across the consuming estate, and issuance is transitioned progressively by service or business unit. The legacy hierarchy continues to operate until every certificate it issued has expired or been replaced, at which point it is formally decommissioned under controlled conditions.

Effective plans sequence migration by dependency and risk, beginning with services that are well understood and lower in criticality, and using them to validate profile parity and trust distribution before higher-consequence services are addressed. Each stage should have defined success criteria, a validation method and, wherever the stage permits it, a rollback position.

Trust store distribution deserves particular attention, because it is usually the longest lead time item and the one most likely to be underestimated. Endpoints managed by configuration management tooling are straightforward. Appliances, embedded devices, third-party platforms and systems in isolated network segments are not, and identifying them early determines the overall programme timeline.

Unsung's migration de-risking engagements exist specifically to address this phase, providing independent validation of migration design and identifying failure modes before they are encountered in production.

Phase five: automate certificate lifecycle management

Modernising the certificate authority without modernising certificate management addresses only part of the problem. A Certificate Lifecycle Management capability provides continuous discovery, centralised inventory, policy enforcement at issuance, automated renewal and installation, expiry alerting and reporting for audit purposes.

Automation should be introduced progressively. Beginning with discovery and alerting delivers immediate risk reduction and builds confidence. Automated renewal for well-understood, standardised workloads follows. Complex or bespoke integrations are addressed last, once the operating model is established.

Resistance to automation is common and usually reflects reasonable concern about losing control of a critical process rather than reluctance to change. Addressing it requires demonstrating the control model, showing how exceptions are handled and providing visibility of what the automation is doing. This is examined in Overcoming Resistance to Automation in Certificate Management.

Phase six: establish the operating model

The final phase determines whether the modernised environment remains modern. It covers:

• Accountable ownership for PKI as a service rather than as an infrastructure component.
• Certificate policy and certification practice statements maintained as living documents.
• Key ceremony procedures with defined witness and evidence requirements.
• Monitoring and alerting integrated with existing operational tooling.
• Defined review cycles for algorithms, certificate profiles and hierarchy design.
• Access to specialist expertise when required.

Organisations without the internal capacity to sustain this often adopt a PKI Management and Hosting arrangement, retaining policy ownership while transferring operational delivery to a specialist provider.

Common mistakes in PKI modernisation

Several patterns recur across stalled or troubled programmes.

Treating modernisation as a platform replacement is the most frequent. Replacing the certificate authority without addressing inventory, policy, automation and operating model reproduces the original position on newer software.

Designing before discovering is closely related. Target architectures built on assumed requirements consistently fail to accommodate the use cases discovery would have identified.

Underestimating trust distribution timelines causes more schedule slippage than any other factor, because it depends on parties outside the programme team.

Migrating without profile validation produces intermittent failures that are difficult to diagnose and undermine confidence in the programme.

Omitting crypto-agility from the design creates a modernised estate that will require modernising again before the post-quantum deadline.

Finally, deferring the work until a certificate authority approaches expiry converts a planned programme into an emergency one. Unsung is frequently engaged at this point, and while these engagements succeed, they cost more and constrain the options available. The issuing CA expiry case study illustrates what that situation looks like in practice.

What a realistic 2026 programme looks like

For an organisation starting from a legacy position, a twelve-month programme is achievable and typically follows this shape.

• Quarter one: discovery, health check and cryptographic inventory, alongside immediate remediation of any critical findings.
• Quarter two: target architecture design, platform selection and migration planning, including the trust distribution assessment.
• Quarters three and four: phased migration with parallel running, progressive introduction of certificate lifecycle automation, and establishment of the operating model.
• Following completion: legacy decommissioning once all certificates issued by the outgoing hierarchy have been retired.

Post-quantum readiness is embedded throughout rather than treated as a separate workstream. The cryptographic inventory produced in the first quarter is the same inventory required for post-quantum planning, and the agility built into the target architecture is what makes the eventual algorithm transition a configuration exercise rather than a further programme.

How Unsung supports PKI modernisation

Unsung is a UK-based consultancy specialising exclusively in Public Key Infrastructure, with a team of more than twenty dedicated PKI experts working across central government, defence, financial services, healthcare, transport and critical national infrastructure.

We are vendor-neutral by design. We hold partnerships across the major certificate authority, hardware security module and certificate lifecycle management vendors, which gives us practical delivery experience on each platform without commercial pressure to recommend any of them. The recommendation follows the requirement.

Our support spans the full modernisation lifecycle, from PKI Consultancy and health assessment through PKI Design and Build, migration delivery and ongoing managed service. Our case studies set out how this has been applied to root CA re-platforming, issuing CA expiry remediation, greenfield design and health check engagements across regulated sectors.

A PKI Health Check is the usual starting point. It establishes what exists, what risk it carries and what the modernisation path should be, and it produces the evidence base every subsequent decision depends on. You can discuss scope with our team through the contact page.

‍