Why do fragmented certificate authorities create more identity risk than cost risk?

Why This Matters for Security Teams

Fragmented certificate authorities are usually discussed as a procurement or platform sprawl problem, but the operational risk sits in identity governance. When certificate issuance, approval, renewal, and revocation are split across teams or tooling, no single control plane can answer a simple question: which secrets are trusted, where, and for how long? That blind spot turns certificates into unmanaged machine identities, especially when inventory is incomplete and ownership is unclear, a pattern reflected in SailPoint research on machine identity management gaps.

The issue is not only expiry outages. It is also compromised certificates that remain valid long enough to enable lateral movement, service impersonation, or unauthorized API access. NIST’s Cybersecurity Framework 2.0 treats asset visibility and governance as core risk reducers, and certificate authorities are no exception. In practice, many security teams encounter certificate sprawl only after a renewal failure or a revoked credential is still trusted in production.

How It Works in Practice

A fragmented CA environment creates identity risk because trust is enforced by cryptographic proof, but governed through inconsistent process. One business unit may issue internal certificates for workloads, another may rely on a public CA for customer-facing services, and a third may run a local CA for test systems. Each can be technically valid, yet none may be consistently inventoried, rotated, or revoked at the enterprise level.

Practitioners reduce this risk by treating certificates as non-human identities, not just TLS plumbing. That means mapping each CA to an owner, a scope, and a revocation path, then enforcing lifecycle controls across the full chain:

• Discovery of issued certificates and intermediates across all environments.
• Central policy for issuance, including key length, subject naming, and approved use cases.
• Automated renewal and revocation with short TTLs where possible.
• Continuous monitoring for orphaned, duplicated, or shadow certificates.
• Audit evidence that shows who issued what, when, and under which policy.

Current guidance suggests pairing certificate governance with workload identity controls rather than relying on static trust chains alone. In more mature environments, teams also align CA policy with common NHI issues such as overextended lifetimes, manual renewal, and poor ownership hygiene. For implementation detail, SPIFFE-style workload identity and policy-as-code approaches are often used to make issuance and trust decisions machine-readable at runtime. These controls tend to break down when legacy applications hardcode certificate paths and cannot support automated rotation without downtime.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance security gains against migration cost and uptime constraints. That tradeoff is most visible in mixed estates where public PKI, private PKI, and embedded device certificates coexist. There is no universal standard for this yet, so best practice is evolving: some teams centralize CA policy while allowing delegated issuance, while others keep separate CAs but impose a shared inventory, revocation service, and evidence model.

The hardest edge cases are service meshes, legacy appliances, and acquisitions. Service meshes can reduce risk by making identity issuance ephemeral, but they still need authoritative policy and inventory. Legacy appliances may not support automated renewal, which forces exception handling and compensating controls. Acquired environments often create the worst fragmentation because inherited CAs continue to issue trusted credentials long after the original operators are gone.

That is why NHIMG guidance on key NHI challenges and risks matters here: the security problem is governance fragmentation, not certificate purchase price. If an organisation cannot prove which CA issued which credential, and cannot revoke it everywhere it is trusted, the trust model is already weak even if renewal costs are low.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?