Organisations should place the Root CA in an offline or tightly restricted trust role and use Intermediate CAs for routine issuance and lifecycle operations. This separation reduces blast radius, supports multiple use cases, and makes certificate management more scalable. The right hierarchy aligns with business needs, clear policy boundaries, and the level of operational risk each certificate class carries.
How to design the hierarchy around trust boundaries, not just certificate volume
A multi-tier PKI works best when each layer has a distinct security role. The Root CA should be treated as a trust anchor with minimal exposure, while one or more Intermediate CAs handle day-to-day issuance, renewal, revocation, and policy enforcement. That separation lets you scale issuance without turning the highest-trust key into an operational dependency.
The practical design question is how much authority each tier should hold. If one hierarchy serves multiple business units, certificate types, or environments, intermediate separation helps prevent policy sprawl and keeps operational mistakes from affecting the entire trust tree. The hierarchy should reflect real trust domains, not just an abstract diagram.
For certificate-lifecycle decisions, the strongest reference point is NIST SP 800-57 Key Management, which ties cryptoperiods and key handling to operational control. In the same way, a well-structured PKI makes certificate issuance a controlled service rather than an ad hoc administrative action.
Where to place the Root CA, and why intermediates do the real work
The Root CA should rarely be used directly for routine issuance. In a secure design it is offline, or at least tightly restricted, so compromise of everyday operations does not expose the root trust anchor. Intermediate CAs then absorb the operational load: issuing leaf certificates, enforcing name constraints or policy boundaries, and supporting revocation and replacement workflows.
This is what gives the hierarchy resilience. If an intermediate is misconfigured, compromised, or simply retired, the blast radius is narrower than if every certificate chains directly to the root. It also makes migration easier, because you can introduce a new intermediate for a business line, environment, or application class without rebuilding the entire PKI.
That control boundary is why certificate governance maps naturally to the CA/Browser Forum model for public trust and issuance discipline. Even in private PKI, the same principle applies: keep high-trust keys offline or heavily restricted, and use intermediates for scalable operational issuance.
How to balance scale, policy separation, and operational control
Most organisations eventually need more than one intermediate. Separate intermediates can serve production and non-production workloads, different application owners, different subject formats, or different risk classes. That lets you apply different validity periods, issuance approvals, revocation expectations, and key protection requirements without overloading one catch-all hierarchy.
Multi-tier design also improves operational control when you need delegation. Teams can be allowed to request or automate issuance through intermediates while a central security or PKI function retains authority over root policy, intermediate policy, key ceremonies, and lifecycle changes. The result is not less control, but better control placement.
For certificate-heavy environments, Machine Identity, PKI and Certificate Lifecycle Guide is a useful way to think about the operational side of the hierarchy: certificate renewal, automation, key protection, and the practical need to keep the trust anchor separate from routine issuance.
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, NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | key lifecycle — Recommendation for Key Management | PKI hierarchy design depends on key lifecycle and cryptoperiod control. |
| Recommendation — Apply key lifecycle discipline so root and intermediate keys have distinct protection and rotation rules. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate issuance and renewal are governed by credential lifecycle controls. |
| Recommendation — Manage certificate-related credentials with defined issuance, renewal, and revocation processes. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | PKI hierarchy is a cryptographic control design issue with trust-anchor protection needs. |
| Recommendation — Protect the root trust anchor and document intermediate key handling requirements. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certificate authorities require controlled lifecycle and delegated administration. |
| Recommendation — Restrict CA administration and review who can issue, rotate, and revoke certificates. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | PKI is part of identity trust and certificate issuance governance in cloud environments. |
| Recommendation — Separate trust-anchor governance from routine certificate issuance across environments. | ||
Practitioner Guidance
What to prioritise: Define trust boundaries first, then assign each CA tier a clear job. The root should govern trust, while intermediates should handle issuance patterns that may need to change over time without forcing root replacement.
What to verify: Confirm that every intermediate has an explicit policy scope, key protection model, and retirement path. If an intermediate can issue broadly across environments without a clear boundary, it is probably carrying too much risk.
What good looks like: The root is rarely touched, intermediates are replaceable, and certificate consumers can survive intermediate rotation without breaking the trust model. Operational teams can scale issuance without gaining unnecessary control over the highest-value keys.
Practitioner takeaway: A good PKI hierarchy is not just deeper, it is more deliberate. Use depth to separate trust from operations, and use intermediate design to contain failure while keeping issuance agile.
Related resources from NHI Mgmt Group
- How should organisations structure an MSP relationship to improve security and compliance without losing operational control?
- How do organisations balance privileged access control with low operational overhead in modern infrastructure?
- How should organisations structure identity security training so it improves real operational capability, not just certification counts?
- How do organisations balance faster adoption with control when using curated security marketplaces?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
