The software supply chain runs on trust, and every signed binary depends on one foundational assumption, that the cryptographic algorithms protecting those signatures, specifically RSA and ECDSA, cannot be broken by any attacker with the available compute resources. But that assumption is no longer indefinitely safe.
The emergence of Cryptographically Relevant Quantum Computers (CRQCs) introduces a systemic risk to every digital signature scheme in production today. NIST finalized its first post-quantum cryptographic standards in August 2024 and explicitly urged system administrators to begin integration immediately. Regulators and technology leaders are moving in lockstep, from NSA’s CNSA 2.0 mandate requiring ML-DSA adoption for national security systems, to Google and Cloudflare’s target of full PQC adoption across their infrastructure by 2029.
The question is no longer whether organizations need to transition their code signing infrastructure to post-quantum algorithms. It is whether they will finish that transition before a CRQC makes the delay consequential.
We will break down the PQC algorithm landscape, the specific implementation challenges for code signing, the architecture strategies, and the phased migration roadmap that gives software supply chain teams a clear path forward, with no operational downtime. For the timestamping, HSM readiness, and long-term verification mechanics that determine whether a signature applied today still validates in twenty years, see our PQC for Code Signing: Protecting Long-Lived Software and Firmware.
PQC code signing strategy, defined: a prioritized, phased plan for moving a software supply chain’s signing infrastructure to quantum-resistant algorithms, ML-DSA, SLH-DSA, or FN-DSA, chosen by workload rather than by default, deployed alongside classical signatures during the transition, and sequenced so root-of-trust changes happen before dependent systems rather than after.
Key Takeaways
- FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) have been final NIST standards since August 2024. FN-DSA (FIPS 206) is still an Initial Public Draft, expected to finalize in late 2026 or early 2027, not a released standard yet.
- Algorithm choice is workload-specific: ML-DSA for high-volume CI/CD signing, where it generally performs competitively with or faster than RSA in published benchmarks, SLH-DSA for long-lived trust anchors where its conservative, slower profile is acceptable, FN-DSA (once final) for constrained IoT/embedded devices.
- Hybrid signing (classical plus PQC, applied in parallel) is the practical pattern today because verifier support for PQC signatures is still uneven across the ecosystem; this is the same dual-signature approach detailed for CI/CD specifically in our SLSA Level 3 architecture piece.
- This page is the prioritization and architecture-strategy layer for the general software supply chain. For the CNSA 2.0-specific transition schedule and five-phase migration, see Architecting the CNSA 2.0 Transition Strategies; for choosing between hash-based signature schemes specifically, see Comparing SLH-DSA, LMS, and XMSS.
- You cannot migrate what you cannot inventory; 34% of enterprises cite lack of centralized cryptographic visibility as a primary barrier to PQC readiness.
Why PQC Code Signing Can’t Wait
When most organizations think about the quantum threat, they frame it as a future problem. But for software supply chains, algorithmic improvements are reducing the qubit requirements for cracking RSA-2048. In 2019, breaking RSA-2048 was estimated to require approximately 20 million qubits, but by 2025, newer architectures using Quantum Low-Density Parity-Check (QLDPC) codes have reduced that estimate to approximately 100,000 qubits, which is a 20-times reduction driven purely by algorithmic innovation, not hardware, in under six years.
Unlike encrypted communications, where “harvest now, decrypt later” applies to confidentiality, signed software carries a different risk: “Trust Now, Forge Later.” A signed installer, a firmware image, a software update package: these artifacts remain in circulation for years or decades. If a CRQC arrives and classical signature algorithms are broken, an attacker can retroactively forge signatures on malicious artifacts that appear indistinguishable from legitimate historically signed software. The window of risk is not when a CRQC arrives, but it is the entire lifespan of every classically signed artifact that will still be in production at that point.
The Citi Institute’s January 2026 report, Quantum Threat: The Trillion-Dollar Security Race Is On, estimates a 19 to 34% probability of a quantum computer breaking RSA-2048 by 2034, with approximately 20 billion active IoT devices worldwide currently exposed to the quantum threat over their operational lifetimes. For software teams managing products with multi-year service lives, the transition to PQC code signing is not an early-mover advantage anymore. It is a supply chain risk mitigation that needs to be underway now.
NIST PQC Algorithms for Code Signing
NIST finalized its first three post-quantum cryptographic standards on August 13, 2024, effective immediately for US federal use and serving as the global benchmark for industry adoption. For digital signatures, which form the foundation of code signing, three algorithms are available or approaching finalization.
Choosing the right algorithm is a critical architectural decision that affects everything from CI/CD pipeline performance to root-of-trust longevity. Here is how the NIST signature algorithms compare for code signing applications:
| Algorithm | Standard | Core Principle | Signature Size | Throughput | Best Suited For |
|---|---|---|---|---|---|
| ML-DSA (CRYSTALS-Dilithium) | FIPS 204 (Finalized) | Structured lattice (Module-LWE) | 2–3 KB | Generally competitive with or faster than classical schemes in published benchmarks | General package signing, DevOps, CI/CD supply chain |
| SLH-DSA (SPHINCS+) | FIPS 205 (Finalized) | Stateless hash-based (SHA-2/SHAKE) | 8–50 KB | Substantially lower; significant overhead | Long-term archival, mission-critical trust anchors |
| FN-DSA (FALCON) | FIPS 206 (Initial Public Draft; expected final late 2026 or early 2027) | Compact lattice (NTRU-based) | 0.6–1.2 KB | Fast (optimized for constrained devices) | IoT firmware, embedded systems, resource-constrained hardware |
Implementation Challenges
The PQC code signing algorithms are standardized and the security proofs are solid. It is an operational and infrastructure challenge. But there are a few things that require explicit planning:
Signature and Key Size Inflation
The most immediately visible change when moving from classical to PQC algorithms is the significant increase in key and signature sizes.
| Component | RSA-3072 (Classical) | ML-DSA-65 (PQC) |
|---|---|---|
| Public Key | ~384 bytes | ~1,952 bytes |
| Private Key | ~384 bytes | ~4,032 bytes |
| Signature | ~384 bytes | ~3,309 bytes |
Using a raw 64-byte P-256 ECDSA signature as the comparison point, an ML-DSA-65 signature (3,309 bytes) is approximately 52 times larger. That ratio holds specifically against the raw 64-byte representation; real-world encoded (DER) ECDSA signatures are commonly somewhat larger than 64 bytes, so this comparison should be read as illustrative of the scale of the increase rather than a universal multiplier against ECDSA signatures generally. For high-volume signing pipelines processing thousands of artifacts per day, this size increase affects storage requirements, network transfer times for signed artifacts, and the capacity of any systems that handle, validate, or cache signatures.
These impacts are manageable with proper architecture planning. Client-side hashing ensures that only hashes rather than full artifact binaries traverse the signing infrastructure, and hardware acceleration in modern Hardware Security Modules (HSM) mitigates the compute overhead.
Legacy HSM Gap
Organizations should verify their specific HSM model’s PQC roadmap and plan firmware upgrades accordingly. Most legacy FIPS 140-2 certified HSMs lack native support for NIST PQC standards. Organizations running older HSM firmware will need to either upgrade to FIPS 140-3 capable firmware with PQC support or manage a “dual-stack” approach during the transition period where classical signing continues on existing HSMs while PQC signing runs on updated or new hardware.
FIPS 140-3 certification for HSM firmware with PQC support is progressing, with Entrust, Thales, Securosys, and Utimaco all having shipped or announced PQC-capable firmware updates.
Performance Differences
The three NIST PQC signature algorithms have meaningfully different performance characteristics, though exact figures vary significantly by parameter set, the RSA key size used as the comparison baseline, whether you’re measuring signing or verification, the specific software library and CPU architecture, HSM implementation, hardware acceleration, and whether message pre-hashing is used. Treat any specific throughput percentage, including the general characterizations below, as illustrative rather than portable across environments; benchmark against your own library, hardware, and parameter set before relying on a number.
- ML-DSA generally performs competitively with, and in many published benchmarks faster than, classical RSA for signing operations, owing to its efficient lattice-based design.
- SLH-DSA is substantially slower than classical RSA in most configurations, often by one to two orders of magnitude, which makes it a poor fit as a primary signing algorithm in high-volume pipelines.
This performance difference is critical for algorithm selection. Choosing SLH-DSA for a CI/CD pipeline that signs hundreds of artifacts per build cycle risks creating a throughput bottleneck that defeats the purpose of an automated pipeline. ML-DSA is generally the better choice for performance-sensitive signing contexts; SLH-DSA is generally reserved for the long-lived trust anchor use cases where its conservative security profile justifies the performance cost.
Validation Bottleneck
Every operating system, browser, security tool, and software installation platform that validates signatures on signed artifacts must be updated to recognize and validate PQC signatures. This is a multi-year ecosystem synchronization challenge. An organization that begins signing with ML-DSA today will produce artifacts whose PQC signatures cannot be verified by systems that have not yet been updated. This is precisely why hybrid signing, which applies both a classical and a PQC signature to every artifact, is the correct architecture for the transition period.
According to a research, 48% of enterprises report they are currently unprepared for quantum threats, while 34% cite a lack of centralized visibility across their cryptographic assets as a primary barrier to PQC readiness. You cannot migrate what you cannot inventory.
The foundational step for any PQC migration program is a complete cryptographic discovery exercise that identifies every certificate, every key, and every signing operation across the build, signing, and distribution pipeline. Encryption Consulting provides CBOM Secure to help you maintain an inventory for all the cryptographic objects in your environment. Without this inventory, PQC migration plans are built on incomplete information.
Hybrid Signing: Dual Signatures, Not a Composite Format
Worth being precise about what “hybrid” means here, since it gets used loosely. The practical approach today is dual, parallel signatures: the artifact carries a classical signature and a PQC signature as two independent signature blocks. A verifier that hasn’t been updated checks the classical signature and ignores the one it doesn’t recognize; an updated verifier can check both. A single combined “composite” signature format for X.509 certificates is still an IETF Internet-Draft, not a finalized standard, as of 2026, so building production tooling against it is premature. Dual signing is the lower-risk choice for now.
Migration Dependencies: The Build Order
The priority framework below tells you what matters most; this is the technical order those items actually have to happen in.
- Confirm HSM firmware supports the specific algorithm (ML-DSA, SLH-DSA, or later FN-DSA) you intend to use; this has to be verified per model, not assumed from a vendor’s general PQC roadmap.
- Upgrade root and intermediate CA infrastructure, since it’s the trust anchor for everything signed downstream and has to move before dependent systems.
- Integrate PQC signing into the CI/CD pipeline as an additional, parallel signing step, not a replacement, so classical signing continues uninterrupted.
- Confirm which downstream verifiers (OS trust stores, package managers, internal deployment gates) can check the new signature, and treat any that can’t as still dependent on the classical signature.
- Pilot on a controlled, lower-risk product line before scaling, and only retire the classical signature once verifier coverage across your actual distribution channels is confirmed, not assumed.
Testing
Before scaling beyond a pilot, test against every verifier the artifact will actually meet in production, not just the one used in development, since unrecognized-signature handling is not guaranteed to be consistent across platforms. Measure the size impact of PQC signatures on artifact size and transfer time for any bandwidth-constrained distribution channel, and load-test signing throughput under the real algorithm and volume, particularly if SLH-DSA is in the mix, given its substantially lower throughput relative to ML-DSA.
Rollback
Because dual signing adds a second, independent signature rather than replacing the first, rollback during a pilot is low-risk: if the PQC signature causes an unexpected verification failure somewhere in the field, the classical signature remains valid, and the fix is to pause adding the second signature for that artifact stream while the incompatibility is diagnosed. The situation that needs real caution is retiring the classical signature entirely; do that only after verifier coverage is confirmed, since reversing that decision after the fact means re-enabling dual signing rather than a simple configuration change.
Dated Roadmap
| Milestone | Date |
|---|---|
| FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) finalized | August 13, 2024 |
| FIPS 206 (FN-DSA) expected finalization | Late 2026 or early 2027 (still draft) |
| CNSA 2.0 support-and-prefer date for software/firmware signing | 2025 (already passed) |
| CNSA 2.0 exclusively-use date for software/firmware signing | 2030 |
| Google and Cloudflare target for full PQC adoption across their infrastructure | 2029 |
| Full NSS transition (per NSM-10) | 2035 |
Strategic Prioritization
Organizations that attempt to address every aspect in PQC transition simultaneously will find it difficult to follow and prioritize the tasks. The framework below, drawn directly from the supply chain risk profile, categorizes actions by urgency and importance.
Deploy Now: Important and Urgent
- Upgrading Root and Intermediate certificate authorities (CAs) to PQC-compliant algorithms, as CA infrastructure is the trust anchor for everything downstream and must move first.
- Resolving Harvest Now, Decrypt Later (HNDL) risks for high-value signed artifacts by re-signing long-lived software with hybrid signatures before the threat window opens.
- Addressing performance and latency implications of larger PQC key and signature sizes before they impact production pipeline throughput.
- Validating hybrid signing architecture for backward compatibility against your actual distribution and verification infrastructure before any production rollout.
Strategic Planning: Important but Less Urgent
- Developing and testing hybrid signature schemes across representative use cases in your specific software ecosystem.
- Selecting PQC algorithms for each product line and signing use case based on performance requirements, device constraints, and signature longevity needs.
- Designing crypto-agility architecture so signing infrastructure can swap algorithms and rotate keys without requiring a full pipeline rebuild each time.
- Mapping third-party supply chain compatibility to understand which downstream partners, distribution platforms, and verification tools are ready to consume PQC-signed software.
Tactical Tasks: Urgent but Operationally Focused
- Managing the certificate volume increases that come with key rotation during migration.
- Responding to compliance reporting requirements for regulatory inquiries.
- Integrating PQC signing into CI/CD pipelines alongside legacy tools during the transition.
Monitor: Less Urgent and Less Important Now
- Post-deployment analysis of PQC algorithm stability over time.
- PQC migration for non-critical legacy systems.
- Tracking future quantum attack vendor developments.
How Encryption Consulting’s CodeSign Secure Helps
CodeSign Secure is Encryption Consulting’s enterprise code signing management platform, and it is specifically designed to support PQC code signing migration at every phase of the roadmap above.
PQC Algorithm Support
CodeSign Secure v3.02 supports production-grade signing with all primary NIST PQC algorithms as a detachable signature for signing and verification processes:
- ML-DSA (FIPS 204) at all three security levels (ML-DSA-44, ML-DSA-65, and ML-DSA-87) for general package and supply chain pipelines
- SLH-DSA (FIPS 205) for long-term archival signing and mission-critical trust anchor applications
- LMS (NIST SP 800-208) for firmware and IoT signing applications where hash-based, stateful quantum resistance is preferred
HSM-Backed Key Management for PQC Keys
CodeSign Secure stores all private signing keys, both classical and PQC, inside FIPS 140-2 Level 3 certified Hardware Security Modules. The platform integrates with Entrust nCipher, Thales Luna, Securosys, Utimaco, as well as cloud HSMs from AWS and Azure, all of which have shipped or announced ML-DSA and SLH-DSA support in their PQC-capable firmware.
CI/CD Pipeline Integration
CodeSign Secure integrates natively with Azure DevOps, Jenkins, GitLab CI, TeamCity, and other major pipeline platforms, supporting both API-based and command-line invocation. PQC signing operations can be configured as controlled, policy-enforced stages in release pipelines, no different from existing classical signing workflows from the developer’s perspective.
Granular Access Control and Audit Logging
Role-Based Access Control in CodeSign Secure governs who can request PQC signing operations, what artifacts can be signed with which algorithm and certificate, and what approval steps are required. Every signing event, including the algorithm used, the certificate, the artifact hash, the timestamp, and the approving identity, is logged immutably.
Software Vulnerability Scanning
CodeSign Secure includes pre-signing software vulnerability scanning and pre/post hash verification as part of the signing workflow. Before a PQC signature is applied, the platform can validate that the artifact being signed has cleared defined security review criteria, ensuring that the quantum-resistant signature is applied to a secure artifact and not just a cryptographically protected one.
Frequently Asked Questions
Which PQC signature algorithm should I use for CI/CD code signing?
ML-DSA (FIPS 204). In most published benchmarks it performs competitively with or faster than classical RSA, making it suitable for high-volume pipelines, though exact throughput depends on your specific library, hardware, and parameter set. SLH-DSA’s throughput is substantially lower, often by an order of magnitude or more, which makes it a poor fit for routine build-time signing; it’s better reserved for long-lived trust anchors.
Is FN-DSA ready to use today?
Not yet. FN-DSA (FIPS 206) is still an Initial Public Draft as of 2026, expected to finalize in late 2026 or early 2027. Plan for it, but don’t build production dependencies on it before it’s a released standard.
Do I need to replace classical signatures immediately?
No, and you shouldn’t. Dual, parallel signing, both a classical and a PQC signature on the same artifact, is the practical approach while verifier support for PQC signatures across the ecosystem is still uneven.
What’s the single biggest blocker organizations underestimate?
Verifier compatibility. An artifact can be correctly signed with ML-DSA today, but that signature is only useful to systems that have been updated to recognize it; this is a multi-year ecosystem synchronization problem, not a signing problem.
Where do I start if I haven’t inventoried my signing infrastructure yet?
With cryptographic discovery: a complete inventory of every certificate, key, and signing operation across the build, signing, and distribution pipeline. Migration plans built without this inventory are working from incomplete information.
Conclusion
The post-quantum transition for code signing is not a single event. It is a multi-year architectural evolution that requires deliberate planning, phased execution, and infrastructure that can carry both classical and quantum-resistant signing operations simultaneously during the transition period.
Regulatory mandates including NIST’s 2030 and 2035 deadlines, CNSA 2.0’s ML-DSA adoption requirements, and the UK NCSC’s migration milestones are setting concrete expectations that organizations in both public and private sectors are already working to meet. And the Trust Now, Forge Later threat means that every classically-signed artifact with a long distribution lifespan is accumulating risk today that will materialize when a CRQC arrives.
At Encryption Consulting, we built CodeSign Secure to make the PQC transition actionable today, with ML-DSA and SLH-DSA support with detachable signatures, and the infrastructure controls that compliance and governance programs require.
