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

Why This Matters for Security Teams

Post-quantum migration is not just a certificate replacement exercise. If teams only refresh PKI roots, intermediates, and endpoint certificates, they leave the signing plane untouched, which means code, firmware, container images, SBOMs, and pipeline artifacts can still be trusted through legacy assumptions. The real risk is that identity and integrity are enforced in different places, and attackers only need one weak link to preserve persistence or poison the build chain.

This matters because PKI and signing workflows solve different problems. PKI establishes who or what a device, workload, or service is. Signing establishes whether an artifact has been altered and whether it came from an approved signer. In practice, those controls must move together during PQC planning, especially where service identities and release signing are intertwined with secrets, CI/CD, and third-party dependencies. NIST guidance on control selection in NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful baseline for separating identity assurance from integrity protection.

NHI Management Group research also shows how often the surrounding identity layer is already fragile: 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 79% have experienced secrets leaks. In practice, many security teams discover the signing gap only after a pipeline compromise or artifact tampering incident has already occurred, rather than through planned cryptographic migration.

How It Works in Practice

A practical post-quantum programme treats PKI and signing as two coordinated but distinct migration tracks. PKI covers issuance, validation, revocation, trust anchors, and lifecycle management for machine identities. Signing covers the cryptographic attestation of software and related artifacts. If the organisation changes one without the other, the cryptographic trust chain becomes inconsistent and operationally brittle.

For PKI, teams should inventory every place certificates are issued or consumed: TLS termination, mTLS between services, device identity, VPN access, service meshes, and automation accounts. For signing, teams should inventory all artefacts that rely on trusted provenance: source commits, release binaries, packages, containers, firmware, infrastructure-as-code, and SBOMs. The migration plan should define where classical algorithms remain acceptable during a transition window and where dual-signing or hybrid trust is required.

• Use separate ownership for PKI operations and release engineering, but align both under one crypto-agility roadmap.
• Map every trust consumer to its validating library, agent, or runtime so algorithm support is tested before cutover.
• Rotate signing keys with the same discipline used for certificates, including revocation, escrow decisions, and recovery procedures.
• Validate whether build systems, artifact registries, and deployment controllers can verify post-quantum or hybrid signatures before enforcement.

For implementation patterns, current guidance suggests using certificate lifecycle controls alongside artifact provenance controls rather than waiting for a single universal PQC standard for every workflow. Where software supply chains are mature, teams often use transparency logs, policy gates, and reproducible builds to reduce blind trust while cryptographic standards evolve. The GitHub Action GitHub Action tj-actions Supply Chain Attack is a clear example of why signing integrity must be treated as part of identity protection, not a separate hygiene task.

These controls tend to break down in mixed environments where legacy HSMs, older TLS stacks, and build pipelines cannot validate new algorithms at the same time.

Common Variations and Edge Cases

Tighter cryptographic control often increases operational overhead, requiring organisations to balance stronger assurance against compatibility, latency, and migration risk. That tradeoff becomes sharper in environments that include embedded devices, regulated firmware, air-gapped plants, or vendor-managed platforms where key material cannot be changed quickly.

Some teams assume PQC can be phased in one layer at a time, but current guidance suggests that the safest approach is to align trust anchors, signing policy, and revocation handling together. For example, a service may accept a post-quantum certificate while still trusting a package signed with a legacy key, which creates a false sense of completion. Likewise, code signing can be modernised while PKI remains vulnerable to weak issuance or poor revocation, leaving workload identity exposed.

Another edge case is third-party trust. If external suppliers sign firmware, dependencies, or updates, the organisation needs clear policy for which algorithms are acceptable now, which are allowed only during transition, and which are rejected outright. That is especially important where device identity and software provenance intersect. The Schneider Electric credentials breach illustrates how identity and access failures can cascade into broader trust exposure when credential and control boundaries are not aligned.

Best practice is evolving, but the operational rule is simple: if one trust path is migrated and the other is not, attackers will target the weaker one first.

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?
• What does a mature secrets governance program need to cover?
• How do organisations prepare PKI for post-quantum change?