Should organisations consolidate PKI infrastructure or keep it distributed?

Organisations should decide based on control preservation, not server count alone. Consolidation can reduce maintenance overhead, but only if policy separation, logging, and revocation speed remain strong across every certificate population. If those controls weaken, the organisation has reduced infrastructure cost at the expense of trust governance.

Why This Matters for Security Teams

PKI design is not just an infrastructure preference. It shapes who can issue certificates, how quickly compromise is contained, and whether revocation decisions can be enforced without cross-team bottlenecks. Centralisation can improve standardisation, but it can also concentrate failure and create approval queues that slow incident response. Distributed PKI can preserve local control, but only if governance remains consistent across business units, cloud estates, and third parties. The practical question is whether certificate authority design supports policy separation and trustworthy revocation under pressure, not whether one model is simpler to diagram.

That is why PKI choices should be evaluated alongside broader identity controls described in the Ultimate Guide to NHIs and the control objectives in NIST Cybersecurity Framework 2.0. NHI governance now affects far more than human login flows: certificates often anchor service accounts, automation, CI/CD pipelines, and machine-to-machine trust. When those identities are over-privileged or poorly tracked, the blast radius expands quickly. In the NHI Mgmt Group research, 97% of NHIs carry excessive privileges, which makes weak certificate governance especially dangerous when PKI is treated as a back-office utility rather than a security control.

In practice, many security teams encounter certificate sprawl only after revocation delays have already slowed containment during an active incident.

How It Works in Practice

A useful decision model starts with three questions: who owns issuance policy, how is trust segmented, and how fast can compromise be revoked. A consolidated model works best when a central PKI can enforce common templates, audit logging, key protection, and renewal automation across all populations. A distributed model works best when different environments need hard separation, such as regulated subsidiaries, sovereign cloud boundaries, or distinct operational domains that must not share an issuance path. Current guidance suggests that the right answer is usually hybrid: central standards, local issuance where isolation matters.

Operationally, teams should map certificate populations by business criticality and trust boundary. Service-to-service certificates, workload identities, and administrator certificates should not all follow the same lifecycle. The Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and revocation processes for API keys, and the same governance gap often appears with certificates. If certificate revocation is slow, the architecture is already too centralised for its own good. Where certificate use supports Zero Trust goals, teams should align design with NIST Cybersecurity Framework 2.0 and ensure logging, ownership, and renewal are visible to security operations.

• Use central policy standards, even if issuance is delegated.
• Keep revocation authority close to the environments that can be compromised fastest.
• Separate CA roles, audit trails, and approval paths by certificate population.
• Test renewal and revocation under incident conditions, not just during steady state.

These controls tend to break down when mergers, multi-cloud estates, or third-party integrations force mixed trust domains into a single CA hierarchy because governance slows down faster than the infrastructure team can standardise it.

Common Variations and Edge Cases

Tighter central control often increases operational overhead, requiring organisations to balance efficiency against resilience and separation of duties. There is no universal standard for this yet. Some environments need strict consolidation because auditability matters more than local autonomy, while others need distributed PKI because blast-radius containment is the higher-order risk. The correct answer can also differ by certificate class: internal service certificates may tolerate central management, while externally facing or regulated workloads may need independent trust anchors.

One common edge case is a hybrid estate where cloud-native workloads, on-prem systems, and partner integrations all rely on different renewal patterns. In that setting, the issue is not simply where the CA lives, but whether policy can remain consistent across every trust domain. Another edge case is delegated PKI for subsidiaries or acquired businesses. Consolidation can look efficient on paper, yet inherited systems often have their own lifecycles, logging conventions, and emergency procedures. If those are forced into a single operational model too quickly, revocation speed and evidence quality usually suffer. For a broader governance lens on machine identities, the Ultimate Guide to NHIs remains the most practical baseline reference.

Best practice is evolving toward central policy with distributed enforcement where trust boundaries demand it, rather than a binary choice between one PKI and many. That is especially true when certificate consumers are automated systems that renew quickly and fail closed when authority is ambiguous.

Related resources from NHI Mgmt Group

• Should organisations consolidate infrastructure access tooling or keep separate point solutions?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?