Every organisation has technical debt it knows about. The database that should have been migrated, the service nobody wants to touch, the integration held together by one person's memory.
There is a category most organisations do not have on the register at all, and it sits underneath everything else.
How it accumulates
Most enterprise public key infrastructure 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 nobody is comfortable changing.
It survives for reasons that are organisational as much as technical. It usually works, and infrastructure that works quietly generates none of the operational noise that drives investment. Ownership sits between infrastructure, identity, security operations and application teams, 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 right up until a root certificate approaches expiry, an audit finding lands, or an automation requirement arrives that the platform cannot meet.
The five forms it takes
We describe the accumulated gap between what a PKI was designed to do and what the organisation now needs from it as trust debt. It shows up in five places.
- No reliable inventory. Organisations know where their certificate authorities are. They rarely know the full population of certificates or the systems depending on them.
- Undocumented dependencies. Trust chains, revocation paths, pinned certificates and hardcoded trust stores fail in ways that are difficult to predict before a change is made.
- Inherited security weaknesses. Software-held CA keys, deprecated algorithms and over-permissive certificate templates. These determine what can safely be carried forward and what cannot.
- Constrained rollback. Once certificates have been reissued and distributed across an estate, reversing the change means reversing every distribution.
- An operating model that cannot scale. Manual processes built for three-year certificates will not survive shortening lifetimes and growing machine identity populations.
Why it is unusually unforgiving
Most infrastructure degrades gracefully. Trust does not.
When a trust relationship breaks, authentication fails across every dependent system simultaneously. There is no gradual degradation to give teams time to respond. Worse, the failures frequently present as application faults rather than certificate faults, which means diagnosis starts in the wrong place and takes considerably longer.
Rollback is also constrained in a way most changes are not. Certificates distributed across thousands of endpoints cannot simply be recalled. Practical planning is therefore built around parallel operation — old and new hierarchies coexisting while trust transfers gradually — rather than a cutover that can be undone.
What to do about it
The first ninety days can be structured without any significant investment.
- Name an accountable owner for the estate. Most trust debt accumulates in the absence of one, and no amount of tooling substitutes for it.
- Locate every certificate authority, including any operated outside central IT, and record expiry dates. Root and issuing CA expiry is the constraint most likely to dictate your timeline, and it is not negotiable.
- Document how certificates are actually requested, issued, tracked and renewed today. Identify where that process depends on individuals rather than systems.
- Set the cost of remediation against the cost of the present position, including operational risk, regulatory exposure and the renewal volumes arriving with shorter certificate lifetimes.
That produces the two things any remediation programme needs before design begins: an accurate picture of the estate, and an agreed understanding of what the current position is costing.
Organisations that skip those steps do not avoid the work. They carry it into a programme where it sits on the critical path, gets discovered late, and gets priced under pressure. We have written in more detail on what makes legacy PKI difficult to replace safely, and on what PKI is and where it sits for anyone coming to this cold.
Unsung works exclusively on public key infrastructure, across central government, defence, financial services, healthcare and transport. More at unsungltd.com
