PKI becomes difficult to sustain because it demands specialized expertise, careful lifecycle management, and consistent operational discipline across many certificate use cases. When original architects leave and teams rely on consultants or disconnected tools, governance fragments. The result is higher cost, weaker standardization, and less confidence that machine and payload certificates are being issued and maintained correctly.
Why PKI Gets Harder to Run at Scale
PKI is manageable when the certificate estate is small, the issuing model is simple, and the people who designed it still understand every dependency. It becomes difficult to sustain as organisations grow because certificate ownership, policy enforcement, renewal timing, trust-anchor decisions, and revocation handling all expand faster than the team’s ability to keep them consistent. A single broken assumption can affect many applications at once, especially where certificates are embedded in infrastructure, applications, and automation pipelines.
The practical problem is not just volume. It is also variation. Different business units adopt different tooling, different expiry windows, and different exception habits, which makes the PKI no longer behave like one governed system. At that point, certificate management turns into a coordination problem across security, platform, application, and operations teams. The NHIMG Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a useful reminder that weak visibility often becomes the hidden scaling constraint around machine trust. In practice, many teams discover PKI fragility only after a renewal failure, an expired certificate, or a trust change has already disrupted production.
How PKI Breaks Down in Real Operations
At small scale, PKI can be run with manual approval, a central CA team, and clear knowledge of where certificates live. At larger scale, that model fails because certificate issuance becomes distributed across cloud platforms, containers, service meshes, endpoint tools, CI/CD systems, and internal applications. Each environment adds different lifecycle demands, and each dependency increases the chance that issuance, renewal, revocation, or trust distribution will drift away from policy.
Operationally, the hardest part is keeping the lifecycle intact. Certificates have to be issued to the right subject, with the right validity period, for the right purpose, and with the right revocation path. If teams rely on ad hoc scripts, disconnected inventories, or inherited consultant knowledge, they may still issue certificates successfully while losing the ability to prove what was issued, where it is used, or who is responsible for renewal. That is why PKI often degrades from a trust system into a collection of exceptions.
The issue is compounded when private keys, intermediate CAs, and trust stores are managed separately. A certificate can be technically valid while the surrounding operational process is no longer trustworthy. Current guidance suggests that organisations should treat certificate inventory and ownership as first-class governance objects, not as a side effect of infrastructure management. The OWASP Non-Human Identity Top 10 is relevant here because the same scaling pressure appears in machine authentication: once workloads, services, and automation depend on opaque credentials, lifecycle discipline becomes the real control boundary.
- Certificate sprawl makes expiry monitoring harder because not every certificate is issued through the same workflow.
- Ownership gaps create renewal failures because no team clearly accepts accountability for the asset.
- Inconsistent policy creates trust drift because different applications tolerate different issuers, lengths, or key types.
- Manual revocation paths become unreliable because emergency response depends on human coordination under time pressure.
These controls tend to break down in multi-cloud and hybrid environments because trust chains, automation methods, and operational ownership are all different enough that a single governance model is difficult to enforce consistently.
What Usually Fails First as Environments Multiply
Tighter certificate governance often increases administrative overhead, so organisations have to balance standardisation against deployment speed. The first thing to fail is usually not the cryptography itself but the operating model around it: inventory accuracy, expiry tracking, and responsibility assignment. When that happens, teams still believe the PKI is functioning because certificates continue to exist, but they no longer have reliable evidence that the estate is controlled.
Another common edge case is the long-lived certificate buried inside an application or embedded device. Those certificates are hard to rotate, hard to attribute, and sometimes impossible to replace without maintenance windows or code changes. Best practice is evolving toward shorter-lived credentials and automated issuance, but there is no universal standard for how quickly every environment can make that transition. The practical rule is to treat any certificate that cannot be renewed automatically as a higher-risk dependency, even if it has not yet caused an incident.
Large estates also expose a tradeoff between central trust and local autonomy. Central teams want consistency, but platform teams often need speed and local control to support release pipelines. The more the organisation relies on delegated issuance, the more it needs robust policy checks, inventory reconciliation, and exception review. This is where PKI maturity is usually measured: not by whether certificates can be issued, but by whether they can be governed across change, scale, and staff turnover. In many organisations, the breakdown is visible only when an expired certificate or abandoned issuing path interrupts a critical service.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | Secrets and Credential Lifecycle — Secrets and Credential Lifecycle | PKI certificates are machine credentials that need governed lifecycle control. |
| Recommendation — Automate certificate inventory, renewal, and revocation for every non-human identity. | ||
| CIS Controls v8 | 6 — Access Control Management | Certificate sprawl and ownership gaps are access-control governance problems. |
| Recommendation — Standardise certificate ownership and remove unmanaged access paths. | ||
| NIST CSF 2.0 | ID.AM — Asset Management | Scaling PKI depends on knowing where certificates and trust anchors exist. |
| PR.AA — Identity Management, Authentication, and Access Control | PKI is the authentication backbone for many machine and application trust flows. | |
| Recommendation — Maintain a complete certificate inventory with accountable owners. Align certificate policy to authentication requirements and enforce renewal controls. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Leaked or unmanaged certificates function as credentials attackers can abuse. |
| Recommendation — Monitor for exposed certificates and remove unmanaged credential copies. | ||
Practitioner Guidance
What to prioritise: Treat inventory, ownership, and renewal automation as the core PKI controls. If a certificate cannot be tied to a named owner and a known renewal path, classify it as operationally fragile even if it is currently valid.
What to verify: Confirm that every issuing path has a documented policy, every intermediate CA is accounted for, and every certificate class has an expiry alert that reaches the team able to act on it. Verification should include the hard cases, not just the certificates already managed by the central team.
What practitioners underestimate: Scale usually breaks PKI through governance drift, not through a single cryptographic flaw. The warning sign is fragmented responsibility: once platform, security, and application teams each assume someone else owns lifecycle management, certificate trust becomes harder to sustain than the technology itself.
Practitioner takeaway: The decisive question is not whether the PKI can issue certificates, but whether the organisation can still prove control over issuance, renewal, and revocation after growth, turnover, and tooling drift.
