Start with the certificate lifecycle, policy needs, revocation model, and operational workload before adding more CAs. A simple CA hierarchy is often easier to secure, monitor, and sustain than a layered design that looks tidy on paper but creates cost and complexity. The right design balances assurance, availability, and long term operability, not just architectural symmetry.
How to size a PKI hierarchy without multiplying certificate authorities
The right question is not how many CA layers look elegant, but what the hierarchy has to support in practice. A compact design usually works best when trust boundaries are clear, certificate policy is simple, and revocation, renewal, and audit obligations can be operated reliably without adding administrative fragility.
A CA hierarchy should express governance, not decoration. Each additional tier or subordinate CA creates another policy boundary, another root of operational failure, and another set of keys, procedures, and monitoring obligations that security teams must sustain over time.
When the hierarchy is designed around actual lifecycle needs, most environments need fewer CAs than their first draft suggests. Separate only when you need materially different trust domains, issuance rules, algorithm choices, revocation exposure, or organizational ownership, not merely to mirror a chart or anticipate hypothetical future complexity.
What should drive CA separation in the first place?
Start with the certificate lifecycle and the way certificates will be used. If issuance, renewal, rotation, and revocation can be governed under one policy set, a single subordinate or small set of subordinates is often enough. More CAs become justified when different classes of identities, applications, or trust domains require genuinely different controls or operational handling.
Policy needs are usually the clearest divider. For example, public TLS certificates, internal server certificates, code-signing, client authentication, and partner-issued credentials may deserve different issuance rules, validity periods, or approval paths. The hierarchy should reflect those differences only when the resulting control separation is operationally meaningful.
Operational workload matters as much as cryptographic design. Every CA increases the burden on key protection, ceremony, renewal, revocation publication, audit evidence, and incident response. A structure that looks rigorous on paper can become brittle if the team cannot monitor it continuously or exercise recovery procedures regularly.
Where overengineering usually starts
Overengineering begins when teams add CAs to satisfy symmetry, organizational politics, or theoretical separation that never appears in actual certificate use. That often leads to duplicated policy documents, inconsistent approval paths, and revocation procedures that are harder to test than the services they are meant to protect.
It also shows up when teams confuse architectural purity with security benefit. A deep hierarchy does not automatically improve assurance if the same operators control every layer, the same automation issues every certificate, and the same monitoring gaps exist across the whole chain.
A simpler structure can actually improve security because it narrows the number of highly sensitive components that must remain trustworthy. Fewer CAs usually means fewer keys to guard, fewer places for misissuance to occur, and fewer opportunities for configuration drift across subordinate issuers.
What balance should security teams aim for?
The best design balances assurance, availability, and long term operability. High assurance comes from strong key protection, clear policy, and disciplined issuance, not from a large CA count by itself. Availability comes from resilient operational processes and recovery planning, not from assuming that one more layer will absorb failure.
In practice, teams should size the hierarchy around the smallest number of issuers that still allows clean policy separation and manageable operations. If a proposed CA does not reduce a real risk, simplify a workflow, or improve recovery, it is usually adding structure without adding value.
For public trust use cases, external baseline requirements also matter, including certificate issuance and revocation expectations defined by the CA/Browser Forum. For key lifecycle design, the most useful external anchor is NIST SP 800-57 Key Management, which reinforces that key lifecycle and cryptoperiod decisions should shape the hierarchy.
Security teams should also treat certificate handling as part of broader secret and credential hygiene. A breach that exposes certificates, tokens, or API keys can turn a clean hierarchy into an access problem very quickly, as seen in the Sisense breach, where access material included certificates alongside other secrets.
Risk and Threat Considerations
Overbuilding the CA structure can create a larger attack surface and a harder recovery problem. If subordinate CA keys, publishing points, or revocation workflows are fragmented across too many layers, compromise or operational failure in one part of the hierarchy can be harder to detect, isolate, and remediate.
Failure mechanism: Excess CA layers increase key custody points, ceremony complexity, and revocation dependencies, which makes misissuance, stale trust, and recovery gaps more likely when processes are not rehearsed.
Impact: The result can be broader trust erosion, slower revocation, and higher operational fragility, especially when certificates support production systems or external trust relationships.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | CA hierarchy design depends on key lifecycle, cryptoperiods, and recovery discipline. |
| Recommendation — Align CA tiers to key lifecycle and cryptoperiod requirements before adding hierarchy layers. | ||
| CIS Controls v8 | CIS-3 — Data Protection | PKI hierarchy affects certificate and key protection across the environment. |
| Recommendation — Protect private keys and certificate material with tightly controlled storage and handling. | ||
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | CA hierarchy is a key-management structure that governs certificate trust and lifecycle. |
| Recommendation — Define CA tiers around key establishment, rotation, and protection requirements. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | PKI hierarchy is part of cryptographic control design and operational governance. |
| Recommendation — Document and operate CA hierarchy choices as part of cryptographic control design. | ||
Practitioner Guidance
What to prioritise: Decide the hierarchy from lifecycle and policy requirements first, then add CA tiers only when a new trust domain or materially different issuance rule cannot be handled cleanly inside the existing structure.
What to verify: Confirm that each CA has a distinct purpose, a defined owner, a tested revocation path, and a recovery plan. If you cannot explain why a CA exists in operational terms, it is probably unnecessary.
Common mistake: Teams often optimise for architectural neatness and end up with a CA tree that is harder to monitor, harder to rotate, and harder to explain during audit or incident response.
Practitioner takeaway: The safest pki hierarchy is usually the one with the fewest moving parts that still enforces the real policy boundaries, because simplicity improves both security and survivability.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams design OAuth scopes without creating consent confusion?
- How should security teams design self-service identity workflows without creating standing privilege?
- How should security teams combine FIDO2 and PKI without creating overlap?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
