Intermediate CA

What an Intermediate CA does in the certificate chain

An Intermediate CA is the delegated issuer between the Root CA and the end-entity certificate. It signs leaf certificates for defined uses, while keeping the root key offline and reducing the blast radius of compromise. That separation is what makes hierarchy practical: policy can be enforced below the root without putting the trust anchor itself into day-to-day issuance.

Because the intermediate is the operational issuer, it is also the point where certificate policy becomes concrete. Constraints such as permitted name spaces, key usages, validity periods, and issuance workflows are applied here, not at the root. In that sense, the intermediate is not just a structural layer, it is the control plane for certificate issuance.

Why intermediate CAs matter for trust and policy

Intermediate CAs let organisations separate trust anchor management from routine certificate issuance. That matters because roots should change rarely, while issuance needs to support service onboarding, renewal, revocation, and use-case-specific policy. A well-designed hierarchy also makes it easier to compartmentalise different certificate populations, such as public TLS, internal services, devices, or private PKI use cases.

The hierarchy is only safe when the intermediate is deliberately constrained. A technically constrained intermediate can narrow what it may issue, which helps prevent accidental overreach and makes policy enforcement auditable. The PKI Basics Guide covers the surrounding chain-of-trust concepts, including validation, CRL, OCSP, and the operational differences between public and private PKI.

For public trust specifically, the governing expectations for issuance, revocation, and hierarchy design are shaped by the CA/Browser Forum, so intermediate CA behaviour must align with the policies that apply to the certificate population it serves.

Operational controls around an Intermediate CA

Most certificate governance happens at the intermediate layer because that is where issuance can be inspected, logged, approved, and separated by policy. Administrators typically need to track the intermediate's signing key, certificate chain, constrained uses, renewal schedule, and revocation pathways as part of normal PKI operations.

An intermediate CA also creates a practical boundary for change control. If the intermediate key, policy, or issuing profile is altered, the impact is narrower than changing the root, but still broad enough to affect many downstream certificates. That is why inventory, ownership, and lifecycle discipline matter as much here as cryptographic strength.

The root should be protected as a high-value trust anchor, while the intermediate carries the day-to-day operational burden. When that burden is not controlled, certificate issuance can drift from intended policy even if the root remains secure.

Failure modes and compromise impact

The main security concern with an intermediate CA is that compromise of its signing key can enable fraudulent certificate issuance within the scope of that intermediate. Depending on how broad the intermediate's authority is, the resulting exposure can range from limited impersonation to large-scale trust failure across multiple services or environments.

Revocation and replacement are especially important because certificate trust is transitive. If an intermediate is distrusted, all certificates chaining to it may need review, reissue, and validation against the affected trust stores. The CA Compromise and Mass Certificate Replacement Playbook is directly relevant to the recovery mechanics that follow intermediate compromise or distrust.

In practice, the hardest part is often not the cryptography, but the inventory and replacement burden. Organisations need to know which systems rely on the affected chain, how long certificates remain accepted in clients, and which trust stores must be updated to restore confidence in the hierarchy.

How to think about Intermediate CAs in governance

An intermediate CA should be treated as a governed issuance authority, not as a passive implementation detail. The key question is not only whether it exists, but whether its scope is intentionally limited, its lifecycle is owned, and its issuance behaviour matches the policy it is supposed to enforce.

For practitioners, the useful mental model is delegation with constraints. The root establishes trust, the intermediate enforces policy, and the end-entity certificate is the product delivered to a workload, user, device, or service. When that delegation is clear, certificate governance becomes easier to reason about and much easier to audit.

Related resources from NHI Mgmt Group

• What is the difference between a root CA, an intermediate CA, and an end-entity certificate?
• What happens when an Intermediate CA fails in a multi-tier PKI design?
• 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?