Why do post-quantum migrations need to cover both PKI and signing workflows?

Why post-quantum migration has to span trust roots and signed artefacts

Post-quantum migration is not just a cryptography refresh. Certificates, certificate authorities, revocation, and validation logic keep operational identities trustworthy, while signatures protect the integrity of software, firmware, containers, and other artefacts that move through the supply chain. If an organisation only replaces one side, it can still be left with a working trust fabric that depends on algorithms it can no longer defend. NIST’s control structure for cryptographic governance and integrity management is a useful reference point for treating those two layers as separate but linked obligations.

That distinction matters because PKI failures and signature failures surface differently. PKI problems usually break authentication, service trust, device enrolment, and revocation handling. Signature problems usually break build integrity, release trust, and the ability to prove that code or firmware is what it claims to be. In practice, many security teams discover the gap only after a certificate rollover succeeds but a build pipeline, firmware verifier, or package trust chain still depends on legacy signing algorithms.

How the two migration tracks work together

PKI migration and signing migration move at different speeds because they protect different trust decisions. PKI is about whether an identity can be issued, chained, validated, and revoked. Signing is about whether a payload can be proven intact and attributable at the point it is consumed. In a post-quantum programme, those decisions must be assessed separately because the same algorithm transition may not reach the same operational layers at the same time.

For PKI, teams need to examine certificate profiles, chain validation, intermediate lifetimes, OCSP or CRL handling, hardware-backed key protection, and where certificates are used for mutual authentication across devices, workloads, APIs, and administrators. For signing, they need to inventory what is signed, who or what signs it, which verifiers trust it, and whether consumers can enforce the new algorithm before the old one is retired. That includes code signing, firmware signing, package signing, container attestations, and SBOM or metadata signatures where they support trust decisions.

• PKI migration changes identity assurance and trust establishment.
• Signing migration changes integrity assurance and provenance.
• Both need versioned trust policies, because mixed-state environments are normal during transition.
• Both need clear rollback rules, since one broken verifier can block release or access paths.

The practical implication is that transition planning has to follow the trust boundary, not the organisational chart. A platform team may own certificate rollout while build, product security, and firmware groups own signing workflows. Those streams must still converge on shared policy for algorithm acceptance, key protection, and deprecation timing. Where trust decisions are embedded in automation, the migration must also update validators, not just issuers.

NIST’s published controls on cryptographic protection and system integrity help frame that split cleanly: one part covers how trust is established and managed, the other covers how artefact integrity is preserved through the lifecycle.

Where this guidance breaks down is in environments with legacy devices or third-party products that cannot consume post-quantum algorithms yet; in those cases, organisations may need compensating controls and a staged trust boundary rather than a single cutover.

Where migrations become messy: hybrid periods, legacy verifiers, and mixed trust chains

Tighter crypto migration often increases operational complexity, requiring organisations to balance stronger long-term assurance against short-term compatibility risk.

One common edge case is a hybrid period where post-quantum-capable issuers coexist with legacy verifiers. That is usually unavoidable, but it creates an operational tradeoff: the more broadly you permit mixed algorithms, the easier it is to keep systems running, yet the harder it becomes to prove that every trust decision is post-quantum ready. Another edge case is dependency asymmetry, where a certificate path can be updated but a signed artefact validator cannot, or the reverse.

Guidance vs consensus is still evolving on exact algorithm cutover timing, but there is broad agreement that “PKI first, signing later” or “signing first, PKI later” is the wrong mental model. Both should be treated as coordinated tracks with separate inventories, acceptance criteria, and retirement dates. The real test is whether every place that issues trust and every place that consumes trust can validate the same policy state.

Organisations also underestimate how many non-human systems depend on certificate trust and signatures at once. Device fleets, service meshes, CI pipelines, package managers, firmware updaters, and software bill of materials ecosystems may each fail in different ways if the migration is incomplete. For that reason, mixed trust chains should be treated as a governed exception, not a normal steady state.

Practitioner Guidance

What to prioritise: Treat identity trust and artefact integrity as separate inventories. If you only track certificates, you will miss the places where signing decisions are enforced at build, release, or update time.

What to verify: Confirm that every verifier, not just every issuer, can process the target algorithm set. The most common failure is a successful migration on the producing side with an unmodified consumer still enforcing legacy trust rules.

Decision rule: If a system both authenticates identities and validates artefacts, it needs a coordinated migration plan rather than a single cryptographic upgrade ticket. Split ownership, but keep one deprecation timeline.

What practitioners underestimate: Revocation, rollback, and exception handling are often harder than initial issuance. If those paths are not designed up front, post-quantum readiness can look complete while trust recovery remains fragile.

Practitioner takeaway: The real migration objective is not “use post-quantum crypto somewhere,” but “preserve trustworthy identity and trustworthy artefacts everywhere the organisation makes a security decision.”

Related resources from NHI Mgmt Group

• How should security teams build cryptographic agility for post-quantum PKI migrations?
• How should security teams implement post-quantum cryptography without breaking signing workflows across large environments?
• Who is accountable for planning post-quantum cryptography adoption across PKI, signing, and key management?
• What does a mature secrets governance program need to cover?