A subordinate CA is a certificate authority that sits below the root CA and issues certificates within a defined scope. It can be used to separate trust by location, certificate type, key type, or business function. If compromised, only that branch and its issued certificates usually need revocation.
What a subordinate CA is
A subordinate CA is an intermediate certificate authority that operates under a root ca and issues certificates only within a bounded trust scope. That scope can be defined by business function, certificate profile, geography, or key hierarchy.
Its value is architectural: it lets organisations divide trust without giving every issuance workflow direct access to the root. That separation matters because compromise of a subordinate CA is usually less catastrophic than compromise of the root, but it still affects every certificate chain that depends on it.
How subordinate CA trust chains work
A subordinate CA sits one step below the root in the PKI hierarchy. The root CA signs the subordinate CA certificate, and the subordinate CA then signs end-entity certificates or, in some designs, further subordinate CAs.
This chain is what makes the subordinate CA trusted. The root does not usually issue leaf certificates directly in day-to-day operations. Instead, it delegates issuance authority downward so that operational teams, business units, or environment-specific PKI segments can issue certificates while the root stays offline or tightly protected.
That delegation is why subordinate CAs are central to PKI design. They reduce operational dependence on the root, but they also create additional trust edges that must be governed carefully. If the subordinate CA’s policy, key protection, or issuance scope is weak, the entire branch becomes a reliability and security concern.
Why organisations use subordinate CAs
Subordinate CAs are commonly used to separate trust domains. An organisation might run one subordinate CA for internal user certificates, another for device certificates, and another for a specific business line or geography. That separation can simplify policy enforcement and limit blast radius.
They are also useful when different certificate profiles need different lifecycles, templates, or approval rules. A subordinate CA can enforce constraints that are harder to express cleanly at the root level, especially in larger environments with mixed public-facing and internal PKI requirements.
In practice, this is often about control and containment. The subordinate CA becomes the operational boundary where certificate issuance is delegated, audited, and restricted. The root CA remains the ultimate trust anchor, but it should not be treated as the everyday issuance engine.
What happens when a subordinate CA is compromised
The main security reason subordinate CAs exist is blast-radius reduction. If a subordinate CA is compromised, the damage is usually confined to the certificates it issued, rather than the entire PKI. That containment is only effective if scopes are truly separated and revocation processes are well understood.
Compromise can still be severe. An attacker with subordinate CA control can mint trusted certificates, impersonate services, sign malicious leaf certificates, or undermine encryption trust within the affected branch. Publicly trusted certificate ecosystems add further governance pressure, because issuance and revocation expectations are tightly controlled by browser trust programs and baseline requirements from the CA/Browser Forum.
Operationally, recovery can be difficult if the subordinate CA was widely used or if certificate inventories are incomplete. The organisation may need to revoke the subordinate CA certificate, reissue downstream certificates, and validate that dependent systems no longer trust the compromised chain.
Risk and Threat Considerations
Subordinate CAs reduce root exposure, but they also create a high-value target because anyone who controls one can issue trusted certificates within its scope. The security risk is not just key theft, it is trust abuse at scale inside the delegated boundary.
Failure mechanism: Weak key protection, overbroad issuance policy, or poor segregation lets an attacker or misconfiguration turn a delegated trust node into a certificate-forging capability. The same branch-level authority that improves flexibility can also concentrate risk if the subordinate CA is too permissive or too widely trusted.
Impact: Trusted impersonation, fraudulent service identity, broken revocation response, and wider PKI recovery work can follow. If the branch is used for critical services, compromise can cascade into authentication failures, transport trust loss, or emergency certificate replacement across dependent systems.
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 CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Subordinate CAs rely on protected certificate lifecycle and revocation controls. |
| SC-12 — Cryptographic Key Establishment and Management | A subordinate CA is a key-management trust point whose private key must be tightly governed. | |
| SC-17 — Public Key Infrastructure Certificates | Subordinate CAs are a core PKI construct for delegated certificate issuance and trust chains. | |
| Recommendation — Protect subordinate CA credentials and enforce certificate lifecycle controls for delegated issuance. Treat subordinate CA private keys as high-value cryptographic material and restrict their use. Use PKI certificate controls to constrain issuance scope and validate certificate chains. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Subordinate CAs depend on secure cryptographic use for certificate issuance and chain trust. |
| Recommendation — Apply cryptographic controls to subordinate CA keys and certificate issuance processes. | ||
| CIS Controls v8 | CIS-3 — Data Protection | PKI trust material and CA keys are sensitive assets requiring strong protection. |
| Recommendation — Classify and protect subordinate CA keys and certificate materials as critical assets. | ||
Related resources from NHI Mgmt Group
- Why do subordinate CAs reduce operational risk compared with issuing everything from a root CA?
- When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?
- What is the difference between self-signed and CA-signed client certificates?
- What is the difference between SPIFFE-based identity and a service mesh CA?
