Post-quantum signature migration succeeds only when every relying party can still establish trust. A signing service may generate ML-DSA in milliseconds, yet a bootloader, package manager, offline recovery image, customer agent, archive validator, or timestamp workflow may reject the result for years. Unlike a short-lived transport session, signed software and certificates can outlive the infrastructure that created them. Plan the migration around verifier populations, trust anchors, formats, key custody, and long-term evidence before changing issuers.
Code signing adds a sharp availability consequence: a failed validation can stop a fleet from updating, while a permissive fallback can let attackers install legacy-signed or stripped content. PKI adds hierarchy and path-building complexity across roots, intermediates, end entities, revocation, relying-party stores, and policies. The objective is not simply to issue a post-quantum certificate. It is to move authentication from one trust graph to another without creating an unverified interval or stranding supported systems.
Use final signature standards and current encodings
FIPS 204 standardizes ML-DSA parameter sets 44, 65, and 87. FIPS 205 standardizes multiple SLH-DSA parameter sets with SHA-2 or SHAKE and small or fast tradeoffs. Choose parameters through applicable policy, security strength, performance, object-size, and ecosystem requirements. A generic supports ML-DSA statement is incomplete if product and verifier versions support different parameter sets or formats.
The IETF has progressed important encoding work: RFC 9881 defines ML-DSA algorithm identifiers and conventions for X.509 certificates and CRLs, while RFC 9909 does so for SLH-DSA. These are necessary interoperability building blocks, not proof that public web PKI, every code-signing container, platform trust store, or validation library accepts the algorithms. Profile each application separately.
Inventory the complete signature trust graph
For every signing use, identify artifact format, signature container, signer, key store, certificate profile, root and intermediates, timestamp or transparency service, policy engine, distribution channel, every verifier class, revocation source, archive, and recovery path. Record who updates each verifier and its supported lifetime. Include factory tools, manufacturing lines, disaster images, air-gapped systems, customer-controlled endpoints, partner build systems, and third-party marketplaces.
Model dependencies as a graph. A root may sign several intermediates; one signing service may serve many products; one embedded verifier may trust keys burned into millions of devices. Connect nodes to algorithms, key identifiers, validity, owners, formats, firmware versions, and replacement mechanisms. The graph supports impact analysis when a key, algorithm, provider, or certificate profile changes. Flat certificate inventory misses non-certificate roots and embedded public keys common in firmware.
| Trust component | Migration question | Failure consequence | Evidence |
|---|---|---|---|
| Root or embedded key | Can relying parties add a PQC trust anchor securely? | No path to new signatures | Trust-store and device-version coverage |
| Intermediate CA | Do profiles and path builders support new algorithms? | Chain rejection or policy mismatch | Cross-implementation path tests |
| Signing service | Can keys be generated, backed up, audited and used at scale? | Issuance outage or key exposure | HSM/KMS lifecycle and throughput tests |
| Artifact format | Can it carry multiple or PQC signatures unambiguously? | Parser failure or signature stripping | Format conformance and negative tests |
| Timestamp | How is signing time proven after certificate expiry? | Loss of long-term validity | Timestamp profile and archive validation |
| Recovery verifier | Can offline and rollback paths validate new releases? | Emergency restore cannot boot or install | Disaster exercise |
Choose a transition pattern with explicit acceptance semantics
Common patterns include separate classical and post-quantum artifacts, multiple independent signatures in one format, composite signatures or certificates, parallel trust chains, and staged direct trust in new public keys. The correct pattern depends on existing format and verifier behavior. Define whether both signatures must validate, either is sufficient, or policy changes by cohort and date. Document what happens if one signature, certificate, or metadata element is missing or malformed.
Beware downgrade and stripping. If legacy verifiers accept a classical signature and upgraded verifiers accept either signature, an attacker may remove the PQC signature unless the container or policy detects absence. Requiring both can improve transition integrity but makes availability depend on both algorithms and paths. Separate artifacts simplify some parsers but can split distribution and audit identity. Threat-model exact semantics rather than labeling the design dual signed and assuming the phrase defines security.
| Pattern | Advantage | Primary risk | Suitable condition |
|---|---|---|---|
| Separate artifacts | Legacy and PQC formats evolve independently | Wrong artifact served or inconsistent content | Distribution binds both to one release digest |
| Multiple signatures | One object can serve mixed verifier policy | Stripping or ambiguous acceptance | Container defines protected signature set |
| Composite signature | Single algorithm identifier expresses combined result | Limited ecosystem and larger object | Standardized profile and full verifier support |
| Parallel chains | Existing and PQC PKI can operate concurrently | Path selection and policy complexity | Relying parties expose selected path |
| Direct key trust | Avoids full certificate hierarchy for devices | Anchor update and recovery burden | Managed product root with secure update |
| Hard cutover | Simple final state | Stranded verifiers and outage | Closed fleet proves complete readiness |
Deploy verification capability before signing dependency
Add parsers, algorithm identifiers, public-key handling, path validation, signature verification, policy, telemetry, and error reporting to relying parties while releases remain classically trusted. Test valid and invalid ML-DSA and selected SLH-DSA objects, wrong parameters, absent algorithm fields, malformed lengths, corrupted signatures, unknown roots, expired certificates, revocation, and oversized inputs. Verify constant-time and resource behavior in maintained libraries rather than embedding a temporary demonstration implementation.
Measure verifier coverage by active installed versions, not shipped code. Devices may be offline, pinned, customer-controlled, or unable to update. Define a minimum safe cohort for dual or PQC signing and a policy for unsupported versions. Maintain classical security updates during the transition where obligations require them; using signature migration to force unrelated upgrades can encourage customers to disable verification or remain exposed.
Engineer the new signing key lifecycle
Define key generation, entropy, approval, activation, permitted mechanisms, signing quotas, backup or replication, disaster recovery, rotation, compromise response, revocation, and destruction. Determine whether HSM, cloud KMS, offline signer, or isolated service supports the final algorithm and format in the required validated mode. Test client APIs, object sizes, session behavior, concurrency, audit events, and backup restoration. A vendor roadmap is not proof that your key can survive a regional failure.
Keep release authorization outside the primitive. A strong PQC key controlled by a compromised CI job still signs malicious software. Require immutable artifact digests, separated approval, bounded signer identities, build provenance, logging, and artifact admission. Associate every signature with release, product, policy, signer service, key version, and source evidence. Restrict key use across product families so one compromise does not authenticate the entire portfolio.
Preserve timestamps, revocation, and long-term validation
Decide what a verifier should accept after a signing certificate expires, an algorithm is deprecated, a key is revoked, or the product is offline. Timestamps can support evidence that a signature existed during a valid period, but timestamp signatures and chains have their own migration. Archives may need renewed evidence records, preserved policies, certificates, revocation information, transparency proofs, and verifier software. Legal or regulated document signatures may impose format-specific requirements beyond code signing.
Avoid indefinite trust merely because an artifact is old. Define validation policy by artifact type, release date, vulnerability status, product support, and recovery need. Keep emergency rollback images signed and verifiable under current recovery policy. Test a clean-room validation using retained materials without online services. Long-term trust is an evidence system, not a single signature check made at publication.
Roll out, monitor, and retire classical trust deliberately
Start with test roots and synthetic artifacts, then internal tooling, controlled product cohorts, dual-signature production, and eventually PQC-required cohorts. Monitor signature size, signing and verification latency, HSM throughput, package growth, update bandwidth, validation failures, selected path, timestamp behavior, and rollback. Preserve release equivalence so classical and PQC forms authenticate the same artifact digest and metadata.
Retirement has several steps: stop creating new legacy keys, stop issuing selected certificates, stop signing new releases classically, remove classical acceptance from managed verifiers, and finally remove old anchors where supported artifacts no longer need them. Each step needs coverage and recovery evidence. NIST's crypto agility guidance emphasizes preserving operations while replacing cryptography; a rushed trust-anchor removal is the opposite of agility.
Key takeaways
- Inventory every signer, format, chain, verifier, timestamp, archive, and recovery path as one trust graph.
- Deploy and measure verifier capability before relying on post-quantum signatures.
- Define exact acceptance semantics for multiple, composite, parallel, or separate signature patterns.
- Protect release authorization and artifact identity in addition to the PQC private key.
- Retire classical issuance and trust in measured stages with long-term validation and recovery evidence.
Frequently asked questions
Can an ML-DSA certificate be used everywhere X.509 is used?
No. RFC 9881 defines PKIX encodings, but each protocol, library, platform, certificate profile, trust program, and relying party must support and permit them. Test the complete application path.
Should upgraded verifiers accept either classical or PQC signature?
Only if that policy is intentional and stripping is addressed. Either-valid improves compatibility but may retain classical dependence. Both-valid increases dependency and availability risk. Bind the required set to authenticated metadata.
Does a timestamp make a signature valid forever?
No. It can prove timing under a validation model, but timestamp trust, revocation, algorithm policy, evidence preservation, and format rules still determine long-term acceptance. Archives need active maintenance.
Conclusion
Post-quantum PKI migration is a coordinated change to trust, not merely a new key type. Start with the graph of relying parties and long-lived evidence, deploy verification, select explicit transition semantics, engineer signing custody, and test recovery. Then move issuance and acceptance through measured cohorts before retiring classical anchors. That ordering preserves the essential property throughout the migration: customers and systems can determine exactly which release or identity they should trust.