What Makes It Hard to Modernise Legacy PKI Securely

The short answer

Modernising legacy Public Key Infrastructure is difficult because PKI is load-bearing and largely invisible. It underpins authentication, encryption and code integrity across the estate, yet most organisations hold no reliable record of which systems depend on it. When trust relationships change, failures are immediate, widespread and difficult to reverse, because certificates that have been distributed across thousands of endpoints cannot simply be recalled.

Five specific barriers make secure modernisation hard:

1. No reliable inventory. Organisations know where their certificate authorities are, but not the full population of certificates or the systems that depend on them.
2. Undocumented dependencies. Trust chains, revocation paths, pinned certificates and hardcoded trust stores fail in ways that are difficult to predict before change.
3. Inherited security weaknesses. Software-held CA keys, deprecated algorithms and permissive certificate templates determine what can safely be carried forward.
4. Constrained rollback. Once certificates are reissued and distributed, reversal means reversing every distribution, so migration must be designed around parallel operation.
5. An operating model that cannot scale. Manual processes built for three-year certificates will not survive shortening lifetimes and growing machine identity populations.

Unsung describes these collectively as trust debt, the accumulated gap between what a PKI was designed to do and what the organisation now requires of it. The rest of this article sets out each form of trust debt, and the sequence of work that clears it safely.

Why legacy PKI persists longer than it should

Most enterprise PKI was not designed. It accumulated.

A certificate authority was stood up for a specific project, often more than a decade ago. Another arrived with an acquisition. A third came with a cloud migration. Templates were duplicated and adjusted. Exceptions became permanent. Over time, the infrastructure underpinning authentication across the organisation became something no single person fully understands, and something no one is comfortable changing.

It survives for reasons that are organisational as much as technical. It usually works, and a certificate authority issuing certificates without incident generates none of the operational noise that drives investment. Ownership sits between infrastructure, identity, security operations and application teams, with each holding a dependency and none holding the whole. The people who designed it have frequently moved on, taking the reasoning behind still-active decisions with them.

Above all, the perceived cost of change is high and the perceived cost of inaction is low. That calculation holds until a root approaches expiry, an audit finding lands, or an automation requirement arrives that the platform cannot meet. At that point the work becomes urgent, and urgent PKI change is where the risk concentrates.

Our article on the real cost of expired certificates sets out how the operating cost of an ageing estate typically presents itself in a business case.

Trust debt one: visibility

The client position. The organisation can name its certificate authorities. It cannot say with confidence how many certificates are in issue, where they are installed, which services depend on them, or who is responsible for renewing them.

This is the single most common obstacle to secure modernisation, because every subsequent activity depends on the dependency graph. Retiring an issuing CA requires knowing every system that validates a chain terminating at it. Changing a root requires knowing every trust store that would need updating. Introducing automation requires knowing which endpoints can accept it.

Discovery in a legacy environment is more involved than a network scan. Scans find what is listening on standard ports. They do not find certificates held in application configuration files, keystores, secrets managers, device firmware, or systems behind segmentation boundaries. A defensible inventory combines network discovery, certificate authority database extraction, cloud provider APIs, configuration management data and structured conversations with application owners.

The value of that work outlasts the programme. A maintained cryptographic inventory is the foundation for crypto agility, post-quantum planning and regulatory evidence. Our guidance on building a cryptographic inventory covers where to begin, and our Cryptographic Bill of Materials service provides a structured route to a complete view.

Trust debt two: architecture

The client position. The hierarchy in place was designed for a different organisation, with different boundaries, different regulatory obligations and different technology. It now constrains decisions rather than supporting them.

Legacy hierarchies commonly show the same patterns. A single tier where the root also issues end-entity certificates, which means the most sensitive key in the estate is online and in routine use. Validity periods measured in decades, which defer risk rather than removing it. Issuing CAs aligned to organisational structures that no longer exist. Certificate profiles that grant broader capability than the use case requires.

The practical consequence is that ordinary requirements become difficult. Segregating trust between production and development, supporting an acquired business, meeting a regulator's expectation of separation, or issuing to a cloud platform each require changes the existing hierarchy cannot accommodate cleanly.

This category also determines where public and private PKI boundaries sit. Public certificate authorities are progressively withdrawing support for use cases that many organisations still depend on, and the resulting decisions about hierarchy design carry long-lived consequences. Our article on choosing the right PKI hierarchy as public TLS certificates withdraw from mTLS examines that question in detail.

Trust debt three: assurance

The client position. The environment would not pass a rigorous assessment against the standards the organisation now claims to meet, and no one is certain how large the gap is.

Three findings recur.

Key protection. Certificate authority private keys in older environments are frequently held in software, on operating systems, sometimes on virtual machines backed up to general purpose storage. A root key that has existed in software for a decade cannot be assumed uncompromised, and its integrity cannot be proven retrospectively. This is a material finding, because it determines whether the existing root can be migrated or whether a new one must be established. Where keys sit in hardware security modules, the position is considerably stronger, though firmware currency, certification status and quorum controls all warrant review.

Enrolment and template configuration. Active Directory Certificate Services environments in particular accumulate template misconfigurations that permit privilege escalation. Templates allowing requesters to supply their own subject, granting enrolment rights too broadly, or permitting client authentication where it was never intended, each represent a path from ordinary user to domain compromise. These issues are well documented, actively exploited, and frequently present in environments never formally reviewed. Our article on Active Directory Certificate Services in modern IT covers the operational and security considerations.

Governance drift. Certificate Policy and Certificate Practice Statement documents are typically written at build time and rarely revised. Where practice has moved away from policy, the organisation is operating outside its own stated controls, which is a finding in any audit and a significant issue in regulated sectors.

The point for planning is that these findings determine what can be carried forward. A programme that migrates a compromised hierarchy onto a modern platform has relocated its problems. A structured PKI health check establishes which elements are sound enough to retain before design decisions are taken.

Trust debt four: operations

The client position. Certificates are requested by ticket, issued by a handful of administrators, installed by application teams and tracked in a spreadsheet. The process depends on individuals rather than systems, and it is already under strain.

This model was viable when certificates lasted three years and the population numbered in the hundreds. It is becoming unviable for reasons entirely outside the organisation's control. Public TLS certificate lifetimes are contracting under the CA/Browser Forum schedule towards a maximum validity of 47 days by March 2029, with domain validation reuse reducing to ten days over the same period. Internal populations are growing rapidly as containerised workloads, service meshes and machine identities multiply.

The combination produces renewal volumes manual processes cannot absorb. Our article on the reduction of public TLS certificate lifetimes sets out the timeline and its practical effect.

Modernisation therefore has to include the operating model. That means automated enrolment through ACME, SCEP, EST or CMP where endpoints support it, certificate lifecycle management tooling for discovery, ownership and renewal orchestration, and explicit accountability for the certificates automation cannot reach. It also means engaging with the cultural position, since resistance to automation is common and usually rooted in reasonable concerns about control. Our article on overcoming resistance to automation addresses how those concerns are best handled.

Skills are the related constraint. Organisations that have operated a stable environment for years have rarely had cause to build deep PKI capability internally. Modernisation asks a team to design a hierarchy, execute key ceremonies, plan a migration and adopt new tooling, frequently for the first time. Where that gap is not addressed, through knowledge transfer or through a managed PKI service, the new environment begins accumulating the same undocumented decisions that made the old one difficult.

Trust debt five: agility

The client position. Changing an algorithm, a key size or a certificate profile would require a project. That is a problem, because the organisation will need to change all three within the decade.

Any PKI designed today will be in service when post-quantum migration becomes mandatory. The NCSC timeline expects UK organisations to complete discovery and planning by 2028, high-priority migration by 2031, and full migration by 2035. NIST has published the initial post-quantum standards, and NIST Internal Report 8547 proposes deprecating RSA and elliptic curve cryptography from 2030 and disallowing them from 2035. Vendor support is arriving across certificate authority platforms, hardware security modules and lifecycle tooling at varying levels of maturity.

Crypto agility in practice means the ability to change cryptographic primitives without redesigning the infrastructure. It rests on a maintained inventory, abstraction between applications and the cryptography they consume, lifecycle automation short enough to permit rapid reissuance, and a hierarchy able to run parallel algorithm families during transition. Our article on what crypto agility actually means in practice examines the operational detail, and our overview of the NIST post-quantum roadmap covers the standards position.

Organisations modernising now hold an advantage that will not be available later, which is the opportunity to build agility into the foundations rather than retrofit it. Vendor claims in this area warrant scrutiny, since support for a post-quantum algorithm and usable performance under production load are separate questions.

Why migration is the moment of greatest exposure

Clearing trust debt requires change, and change in PKI is unusually unforgiving.

Failure is immediate and broad. When a trust relationship breaks, authentication fails and services become unavailable across every dependent system simultaneously. There is no gradual degradation to give teams time to respond, and failures frequently present as application faults rather than certificate faults, which slows diagnosis considerably.

Rollback is constrained. Once certificates have been reissued and distributed across an estate, reversing the change means reversing every distribution. Practical rollback planning is therefore built around parallel operation, with old and new hierarchies coexisting while trust transfers gradually, rather than around a cutover that can be undone.

Vendor support is inconsistent. Migration between platforms is not a scenario most vendors document, and in some cases it is one they advise against. When Unsung re-platformed twenty root certificate authorities for a large public sector organisation, moving from an end-of-life vendor platform to EJBCA, the migration was one the vendor considered unfeasible. Delivering it required building a repeatable methodology from first principles, grounded in certificate authority architecture and cryptographic operations, and verifying precise structural parity between source and target so downstream systems continued validating chains without change. That programme completed with no operational impact to business services, alongside a substantial reduction in operational and licensing cost. The full account is in our Entrust to EJBCA migration case study.

Sequencing separates a controlled migration from a disruptive one. Parallel hierarchies, staged trust distribution, pilot cohorts chosen for representativeness rather than convenience, and defined rollback positions at each stage all reduce exposure. So does timing, since migrations executed under expiry pressure compress every one of those safeguards. Our migration de-risking and issuing CA expiry engagements illustrate how that pressure changes the shape of a programme.

How Unsung approaches legacy PKI modernisation

Unsung works exclusively on Public Key Infrastructure. Our consultants have delivered PKI programmes across central government, defence, financial services, healthcare, transport and critical national infrastructure, and many hold SC or DV clearance. We hold no reseller allegiance, so recommendations reflect the requirement rather than a platform preference.

Our approach follows a consistent sequence.

Establish the current state. A PKI health check produces a documented baseline covering certificate authority configuration, hierarchy structure, key protection, revocation infrastructure, template and enrolment configuration, governance documentation and operational process. Findings are categorised by risk with context, impact and recommended mitigation, so remediation can be prioritised against risk appetite and available resource. The report is written for both technical and executive audiences, because modernisation requires agreement at both levels.

Quantify the debt. Discovery across networks, CA databases, cloud platforms, secrets stores and application configurations produces the dependency view migration planning depends on, extending into a Cryptographic Bill of Materials where a broader cryptographic position is required.

Define the target. PKI consultancy and PKI design and build engagements determine hierarchy design, key protection strategy, certificate profiles, enrolment protocols and governance framework, aligned to regulatory obligations and technology roadmap. Decisions are documented with their reasoning, which is what prevents the new environment becoming the next legacy estate.

Plan the transition. Migration planning covers parallel operation, trust distribution, pilot selection, cutover sequencing, rollback positions and communication with application owners. This is where most risk is removed, and it is the stage most often compressed when programmes run late.

Execute with control. Key ceremonies are conducted under witnessed and documented procedure. Migration proceeds in stages with defined verification at each point. Where a vendor offers no migration path, we develop and test a methodology before it touches production.

Sustain the position. Certificate lifecycle management delivers the automation, visibility and ownership model that keeps the environment current. Where the capability sits better outside the organisation, our PKI management and hosting service operates it under agreed service levels.

A practical starting sequence

For organisations at the beginning of this work, the first ninety days can be structured without significant investment.

Confirm ownership of the PKI estate and name an accountable individual. Locate every certificate authority, including those operated outside central IT, and record expiry dates. Establish how certificates are currently requested, issued, tracked and renewed, and identify where that process depends on individuals rather than systems. Commission an independent assessment to produce a documented baseline. Use the findings to set remediation cost against the operational and regulatory exposure of the present position.

That sequence produces the two things a modernisation programme needs before design begins, which are an accurate picture of the estate and an agreed understanding of the risk it carries.

‍