A root CA is the trust anchor at the top of the hierarchy and is self-signed. A subordinate CA sits beneath it and is authorized to issue or further delegate certificates within a defined scope, such as location, key type, or certificate purpose. The root should stay offline, while subordinates handle day-to-day issuance.
How root and subordinate CAs differ in governance
The governance difference is about trust, not just hierarchy. The root CA is the ultimate trust anchor, so its private key, operating environment and approval process must be treated as exceptional. A subordinate CA is delegated authority: it can issue certificates only within the policy, naming and path constraints that the root or parent CA has allowed.
That means the root governs the PKI’s root of trust, while the subordinate governs the controlled execution of issuance. In a well-run hierarchy, the root stays narrow in scope and highly protected, while subordinates carry the operational burden of day-to-day certificate issuance and renewal.
Why the root CA is handled differently from an issuing CA
The root CA is usually kept offline because compromise of the root affects the whole chain of trust. Its main job is to sign subordinate CA certificates, not to service routine issuance requests. That separation reduces exposure and limits how often the highest-value key must be used.
A subordinate CA is designed for activity. It can be online, monitored and integrated with issuance workflows, because its compromise is bounded by the authority it was given. In enterprise PKI, that boundary is enforced through certificate policy, certification practice statements, and technical constraints such as name constraints and path length limits.
For readers building or reviewing a hierarchy, the practical distinction is whether the CA is meant to establish trust or operate trust. NHIMG’s Enterprise PKI Design and CA Hierarchy Guide is the most direct reference for offline roots, issuing CAs, constraints and root key ceremonies.
What subordinate CA authority should and should not include
A subordinate CA should issue only the certificate types and naming scopes it was explicitly delegated. That delegation may be limited by location, business unit, certificate purpose, key type or application trust domain. If a subordinate can issue outside that intended scope, the hierarchy stops being a governance control and becomes a broad trust accelerator.
This is why the subordinate’s operating model matters as much as its cryptography. You want issuance logging, revocation publishing, certificate profile control and a clear review path for policy changes. The root can define trust, but the subordinate is where most governance failures show up first, especially when issuance is overbroad or poorly monitored.
For PKI operators, certificate lifecycle discipline matters because issuance scope, key custody and renewal workflows all interact. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide helps connect CA hierarchy decisions to lifecycle automation, certificate expiry and key protection.
Risk and Threat Considerations
A weak CA hierarchy creates a large blast radius. If a root CA private key is exposed, every subordinate certificate chain depends on a trust anchor that can no longer be assumed valid. If a subordinate CA is overprivileged, compromised or misconfigured, an attacker can issue trusted certificates inside the approved scope and use that trust to impersonate systems, intercept traffic or establish persistence.
Failure mechanism: The hierarchy fails when delegated issuance authority is broader than intended, when root key custody is weak, or when revocation and policy controls are not strong enough to contain a compromised subordinate CA.
Impact: Loss of trust can cascade across applications, users and services that rely on the PKI, forcing emergency revocation, certificate replacement and, in some cases, rebuilds of trust stores and dependent integrations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-57 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service Organizations) | PKI hierarchies govern certificate-based authentication for subordinate issuers and relying parties. |
| IA-5 — Authenticator Management | CA private keys and issuance credentials require lifecycle controls and protection. | |
| SC-12 — Cryptographic Key Establishment and Management | Root and subordinate CA governance depends on protected key establishment and custody. | |
| Recommendation — Apply IA-9 to constrain and verify certificate-based trust between CAs and dependent systems. Manage CA keys and issuer credentials with strict lifecycle, rotation and revocation controls. Protect CA key establishment, storage and use with strong custody and ceremony controls. | ||
| NIST SP 800-57 | Key Management | The question centers on cryptographic key lifecycle and trust-anchor governance in PKI. |
| Recommendation — Use key lifecycle policy to separate offline root custody from subordinate operational issuance. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | PKI governance is a cryptographic control problem requiring managed CA trust and issuance. |
| Recommendation — Control CA cryptographic use, trust anchor protection and certificate issuance procedures. | ||
Practitioner Guidance
What to verify: Confirm that the root CA is offline or tightly isolated, that subordinate CA certificates have explicit scope constraints, and that the CP and CPS describe who can approve issuance changes. If a subordinate can issue certificates beyond a clear business or technical boundary, the hierarchy is already too loose.
What good looks like: The root is used rarely, issuance is delegated only to bounded intermediates, and every subordinate CA has an obvious owner, revocation path and audit trail. The governance test is simple: the root should define trust, while the subordinate should only execute the issuance policy it was given.
Practitioner takeaway: Treat the root as the trust anchor that must be protected from routine operations, and treat each subordinate CA as a delegated control that must be narrowly scoped, observable and revocable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org