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.
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 | High (fastest sign/verify cycle) | General package signing, DevOps, CI/CD supply chain |
| SLH-DSA (SPHINCS+) | FIPS 205 (Finalized) | Stateless hash-based (SHA-2/SHAKE) | 8–50 KB | 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 |
ML-DSA-65 signatures are approximately 52 times the size of ECDSA signatures. 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. Relative to classical RSA (baseline 100%):
- ML-DSA performs at approximately 150% of classical RSA throughput, meaning it is actually faster than RSA for signing operations due to its efficient lattice-based design.
- SLH-DSA performs at approximately 5% of classical RSA throughput, which is 10x to 100x slower, making it unsuitable 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 will create a throughput bottleneck that defeats the purpose of an automated pipeline. ML-DSA is the correct choice for performance-sensitive signing contexts; SLH-DSA should be 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.
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, stateless 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.
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.
