Cross-Signing

How Cross-Signing Extends Trust

Cross-signing lets one certificate authority vouch for another CA’s certificate so clients can accept the second CA through an existing trust chain. It is often a migration tool, for example when organisations are moving between roots or bridging older and newer PKI hierarchies, but the trust relationship now depends on more than one issuer and more than one valid path.

That added flexibility is useful, but it also means the security outcome is no longer governed by a single root. Client behaviour, path-building rules, certificate policies, and revocation handling can all influence which chain is accepted, so a cross-signing arrangement must be designed with the same care as the CAs it connects.

Why Cross-Signing Is Operationally Useful

Cross-signing is most valuable when an organisation needs continuity while changing trust anchors. It can preserve interoperability for legacy clients, reduce service disruption during CA transitions, and allow a new CA hierarchy to be introduced without forcing every relying party to update trust stores at once.

It is also used to extend trust across organisational or ecosystem boundaries when a common trust anchor is impractical. In practice, that makes cross-signing a bridge mechanism, not a permanent substitute for a clean trust architecture. The more long-lived the bridge becomes, the harder it is to reason about which CA actually controls trust decisions.

Chain Complexity and Validation Behaviour

Cross-signing increases the number of possible certification paths, and that complexity is where implementation bugs and policy mistakes tend to appear. Different clients may prefer different chains, ignore intended constraints, or handle intermediates differently, especially if the environment contains multiple roots, overlapping issuers, or inconsistent trust stores.

Validation quality matters as much as certificate issuance. A relying party should build the chain the organisation expects, not merely any chain that happens to verify mathematically. Path length, name constraints, policy constraints, EKU handling, and revocation checking all affect whether the intended trust model is actually enforced.

Trust Path Control and Governance

Because cross-signing can keep old and new trust anchors alive at the same time, it creates a governance problem as well as a technical one. Teams need clear ownership for which CAs are trusted, which cross-certificates remain valid, and when a bridge certificate should be retired so that stale trust does not persist indefinitely.

That governance becomes especially important in large environments where one CA change can affect many applications, devices, and partner integrations. Without deliberate lifecycle control, cross-signing can quietly expand the blast radius of a compromised or misused CA by leaving more than one acceptable trust route in place.

When Cross-Signing Becomes a Security Concern

The main security risk is not that cross-signing is inherently unsafe, but that it can obscure trust boundaries. If a lower-assurance CA is cross-signed into a stronger hierarchy, or if an unintended chain is accepted by clients, the organisation may grant trust wider than planned.

Attackers and misconfigurations both benefit from ambiguity in certificate path selection. A weakly controlled bridge can let a malicious or compromised certificate chain present itself as trusted, especially where revocation is incomplete or clients cache old validation decisions.

Failure mechanism: Multiple valid trust paths, inconsistent client validation, or stale cross-certificates can let an unintended issuer satisfy trust checks.

Impact: Clients may accept certificates from a CA that should no longer be trusted, which can undermine authentication, traffic confidentiality, and integrity across dependent services.

Practitioner Guidance

Governance implication: Treat cross-signing as a temporary trust bridge with explicit ownership, expiry, and retirement criteria. The key practitioner decision is not whether it can work, but how long it should remain part of the trust model before the environment is simplified.

What to watch for: Validate the exact chains your clients build, not just the chain you intended to publish. In mixed PKI environments, review trust stores, revocation behaviour, and certificate constraints together, because the real risk is often a valid but undesired path rather than a failed one.

Related resources from NHI Mgmt Group

• How should organisations implement cross-border digital signing when contracts must remain legally valid across multiple jurisdictions?
• How do compliance teams evaluate whether a cross-border signing process is actually operating within regulatory boundaries?
• What do teams get wrong about cross-signing during a root certificate transition?
• Cross-Border Digital Signing