An Intermediate CA sits below the Root CA and issues end-entity certificates for defined use cases. It helps reduce exposure of the root key while allowing policy separation, lifecycle control, and delegated issuance. In practice, it is the operational layer where most certificate governance is enforced.
Expanded Definition
An Intermediate CA is the operational certificate authority that sits between a trust anchor and the certificates used by workloads, services, devices, and agent identities. In PKI design, it enables policy separation, constrained issuance, and safer key management than placing issuance duties on the Root CA. NHI teams often treat it as the control point for certificate profiles, naming rules, validity periods, revocation behavior, and approval workflows.
Definitions vary across vendors on how much authority an Intermediate CA should hold, but the security intent is consistent: reduce root exposure while preserving delegated issuance. In modern NHI programs, an Intermediate CA may back service-to-service TLS, workload attestation, signed artifacts, or agent authentication, provided the issuing policy is tightly scoped and auditable. NIST guidance on certificate and access control governance is a useful baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls.
The most common misapplication is treating an Intermediate CA like a general-purpose signing service, which occurs when teams issue overly broad templates without lifecycle limits or revocation planning.
Examples and Use Cases
Implementing an Intermediate CA rigorously often introduces governance overhead, requiring organisations to weigh faster delegated issuance against tighter policy, audit, and rotation controls.
- Issue short-lived mTLS certificates for microservices through a scoped Intermediate CA instead of distributing long-lived credentials across deployment pipelines.
- Separate production, test, and partner trust domains by using distinct intermediates with different certificate policies and revocation paths.
- Support workload identity for agents and automation tools, where certificate issuance must be tied to posture, environment, and approved use case rather than a shared key.
- Use an Intermediate CA as the enforcement layer for renewal, revocation, and template drift detection in a certificate lifecycle program.
- For a real-world breach context, review the New York Times breach alongside the broader certificate and secret exposure patterns described in NIST guidance.
In broader PKI practice, certificate authority hierarchy and scope control are closely aligned with the identity governance expectations reflected in CISA Zero Trust Maturity Model, especially where strong service identity is required for east-west traffic and automated systems.
Why It Matters in NHI Security
Intermediate CAs matter because they convert certificate issuance from an ad hoc trust decision into a governed control surface. When their scope is too broad, a single compromise can cascade into widespread impersonation of services, workloads, or agents. When their rotation, revocation, or policy separation is weak, organisations accumulate hidden trust paths that are hard to inspect and even harder to unwind. That is why certificate governance belongs in the same conversation as NHI lifecycle management, secret rotation, and Zero Trust enforcement.
This is especially important in environments where identities multiply rapidly. NHI Mgmt Group reports that NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs. An Intermediate CA becomes the practical mechanism for managing that scale without expanding root trust. It also supports the broader principle that proper NHI governance is foundational to Zero Trust, as reflected in NIST Cybersecurity Framework and related identity control guidance.
Organisations typically encounter the operational importance of an Intermediate CA only after a certificate compromise, expired chain, or failed revocation event, at which point the intermediate becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Intermediate CA scope and issuance policy map to certificate governance and trust boundary control. |
| NIST Zero Trust (SP 800-207) | SC-23 | Zero Trust requires strong service identity and limited trust propagation through delegated CAs. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and credential governance extend to machine certificate authorities. |
| NIST SP 800-63 | AAL2 | Certificate strength and assurance expectations inform NHI authentication design. |
| OWASP Agentic AI Top 10 | A-02 | Agent identities often rely on certificates issued through intermediates with constrained authority. |
Bind agent certificates to narrow scopes, short lifetimes, and revocation-ready lifecycle controls.
Related resources from NHI Mgmt Group
- 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?
- How should security teams choose between self-signed and CA-signed SAML certificates?
