Cross-Signing

Expanded Definition

Cross-signing is a PKI trust-extension technique in which one certificate authority signs another CA’s certificate so that clients can build a valid path through an already trusted anchor. In NHI environments, it is usually introduced during CA migration, federation, or ecosystem interoperability, where service identities, automation platforms, and API clients must trust more than one issuing hierarchy without a disruptive cutover.

Its security value is convenience: organisations can phase trust from an old CA to a new one instead of reissuing every certificate at once. The tradeoff is that the trust graph becomes harder to reason about, especially when multiple chains are technically valid. That complexity is why validation logic, path length constraints, and revocation handling matter as much as the certificate contents themselves. Guidance varies across vendors on how strictly clients should prefer one chain over another, so operators should verify actual path-building behavior rather than assume the intended chain will be used.

For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful when mapping certificate lifecycle, trust boundary, and access-control obligations around CA relationships. The most common misapplication is leaving cross-signed paths in production after migration, which occurs when teams forget to retire legacy trust anchors and clients continue to accept the old chain.

Examples and Use Cases

Implementing cross-signing rigorously often introduces temporary ambiguity in certificate path selection, requiring organisations to weigh migration continuity against the operational cost of monitoring multiple trust routes.

• During CA migration, a legacy internal root cross-signs the new root so service accounts and automation jobs continue to authenticate while certificates are reissued in stages.
• In a multi-domain enterprise, separate PKI hierarchies cross-sign each other to support trust between platform teams, but only after explicit policy review and path validation.
• For third-party federation, a partner CA may be cross-signed to reduce onboarding friction for workload identities, especially when API gateways and mTLS clients already trust the current hierarchy.
• In lab or pilot environments, cross-signing can simulate production trust migration before changes are applied to secrets, certificate authorities, and deployment pipelines.

NHIMG’s Ultimate Guide to NHIs is relevant because certificate trust decisions directly affect service accounts, API keys, and other machine identities that depend on stable authentication paths. For standards context, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control baseline for managing those trust relationships. Cross-signing is not a substitute for strong governance of issuance, rotation, and revocation.

Why It Matters in NHI Security

Cross-signing matters because NHI ecosystems rarely fail in a clean, single-chain way. When multiple valid trust paths exist, attackers can exploit weak client validation, forgotten legacy roots, or stale trust stores to impersonate issuing authorities and extend access to services, pipelines, and automated agents. That risk becomes more serious when certificates are embedded in CI/CD, service meshes, and integration workflows where machine identities authenticate at machine speed.

NHIMG research shows that 91.6% of secrets remain valid five days after notification, which illustrates how slowly trust artifacts are often remediated in practice. Cross-signing magnifies that lag because both the certificates and the trust anchors may need coordinated retirement. It also makes audit work harder: teams must prove which chain was trusted, which CA issued it, and whether the client accepted an unintended path. Mismanagement can therefore create invisible persistence for compromised machine identities.

Organisations typically encounter the operational cost of cross-signing only after a migration, compromise, or trust-store cleanup reveals that legacy chains still authenticate workloads, at which point the concept becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Where does cross-environment agent discovery fit in an IAM programme?
• What is the difference between PIM and cross-cloud privilege governance?
• Why do cross-domain attacks create more risk than single-domain intrusions?
• How should teams rotate JWT signing keys without breaking production traffic?