Integrating Post Quantum Cryptography into Code Signing Workflows

Code signing has been an important part of software trust for a long time, ensuring that applications delivered to users are authentic and untampered with by threat actors. But the foundations of that trust are beginning to change. As quantum computing becomes more realistic, cryptographic algorithms used in today’s code-signing processes, such as RSA and ECC, are likely to become obsolete.

While legitimate quantum computer attacks may not happen tomorrow, the threat is closer than anyone expected. For signed software specifically, the risk that matters isn’t decryption, it’s forgery: an attacker who eventually breaks the underlying signature algorithm doesn’t decrypt or alter software signed years ago, they use the recovered private key to forge a new signature on a malicious artifact that appears to come from the same trusted publisher. This “harvest now, forge later” model makes it critical to start preparing now rather than waiting for quantum computers to become mature enough to crack these cryptographic algorithms. Integrating post-quantum cryptography (PQC) into code signing workflows is not a simple change. It requires rethinking existing processes, tools, and infrastructure to support new algorithms, larger signatures, and changing standards.

Post-quantum code signing integration, defined: adding a quantum-resistant signature algorithm, ML-DSA, SLH-DSA, or LMS/XMSS, as a parallel, dual signature alongside your existing CI/CD pipeline’s classical signing step, without replacing it outright, so the pipeline keeps working for verifiers that haven’t been updated while gaining quantum-resistant protection for those that have.

Key Takeaways

• ML-KEM (FIPS 203) is a key encapsulation mechanism, not a signature algorithm; it has no role in code signing. Code signing uses ML-DSA (FIPS 204), SLH-DSA (FIPS 205), or the stateful hash-based LMS/XMSS (NIST SP 800-208).
• FIPS 204 and 205 have been final NIST standards since August 2024; what’s still uneven is pipeline tooling, HSM firmware, and verifier support across the ecosystem, not the algorithm standards themselves.
• “Hybrid signing” in a CI/CD pipeline today means dual, parallel, independent signatures, one classical and one post-quantum, not a single combined signature format, which is still an unfinished IETF draft.
• This page covers practical pipeline integration. For algorithm selection specifically, see Comparing SLH-DSA, LMS, and XMSS; for the full dated CNSA 2.0 migration architecture, see Architecting the CNSA 2.0 Transition Strategies.

Understanding the PQC Landscape

PQC refers to a new set of cryptographic algorithms designed to stay secure even against quantum computer attacks. Traditional methods like RSA and ECC rely on math problems that quantum computers could eventually solve much faster, whereas PQC is built on problems that are believed to be much harder for them to break.

Most PQC approaches fall into a few categories, like lattice-based, hash-based, code-based, and multivariate cryptography. Of these, lattice-based algorithms are receiving the most attention because they offer a good balance between security and performance. Standardization efforts from groups like NIST are already helping narrow down which algorithms organizations should start preparing for.

The NIST has released FIPS 203, 204, and 205. It’s worth being precise about what each one is for, since they solve different problems and only two of them apply to code signing: FIPS 203 standardizes ML-KEM, a key encapsulation mechanism used to establish shared secrets for encryption (relevant to TLS and key exchange, not to signing); FIPS 204 standardizes ML-DSA, a signature algorithm; and FIPS 205 standardizes SLH-DSA, also a signature algorithm. Code signing uses ML-DSA or SLH-DSA (or the stateful hash-based LMS/XMSS from NIST SP 800-208), never ML-KEM. Part of the need to move to PQC is the pressure from different government mandates that is pushing organizations to migrate to PQC sooner rather than later. CISA and the US are two examples of those that are pushing for PQC migration sooner than others.

That said, PQC isn’t a simple swap for what we use today. These algorithms often come with larger keys, bigger signatures, and different performance impacts. Because of that, organizations need to think through how adopting PQC will affect their current systems—especially in areas like code signing, where speed and compatibility really matter.

Where Traditional Code Signing Workflows Fall Short

Traditional code-signing workflows weren’t built with quantum threats in mind. They rely on classical cryptography, such as RSA and ECC, which are the foundation of most PKI systems today. As quantum computing advances, these algorithms could eventually be broken, thereby weakening the trust in digitally signed software.

One of the biggest issues is how long signed code remains in place. Software that’s signed today might still be used years from now, making the publisher’s signing key a long-lived target. This is where the idea of “harvest now, forge later” comes in—once an attacker can break the signature algorithm protecting that key, they can forge new signatures that appear to come from the same trusted publisher, even though the already-signed software from years ago isn’t itself altered or decrypted.

Another challenge is the lack of crypto agility. That’s the ability to switch between cryptographic algorithms without major changes to your systems. Most code signing tools, certificate authorities, and HSMs are built around older algorithms, so introducing PQC isn’t always simple. This makes it harder for organizations to adapt quickly and increases their overall risk.

Designing a PQC-Ready Code Signing Strategy

Building a PQC-ready code signing strategy starts with being flexible. Instead of relying on a single cryptographic method, your systems should be able to support multiple algorithms and switch between them as things evolve. That’s especially important right now, since PQC standards are still changing and will likely continue to do so. A good way to begin is with a hybrid signing approach. This means using both traditional algorithms and PQC together in the same signature. It lets you start adding quantum-resistant protection while still staying compatible with existing systems, so you don’t break anything in the process.

It’s also important to understand what you already have in place. You should know where your keys, certificates, and signing processes are across your environment. Without that visibility, it’s tough to plan a smooth move to PQC. Having something like a CBOM, or Cryptographic Bill of Materials, can help you ensure that you have the visibility you need into your different systems. Your policies need to evolve, too. That means setting clear rules for when and how PQC is used, how hybrid signatures are managed, and how you stay compliant. Having those guidelines in place helps ensure your approach is deliberate and aligns with your overall security goals.

Integrating PQC into DevOps Pipelines

Bringing PQC into your DevOps pipeline starts with knowing where code signing fits today. In most cases, it happens during the build or release stages, so any changes need to work smoothly with your existing CI/CD process. One of the main challenges is tooling—many current signing tools and APIs weren’t built for PQC, so you may need updated versions or new tools that support hybrid or PQC-based signing.

Performance is another factor to think about. PQC signatures are often larger and can take more time to generate, which may slow down parts of your pipeline or affect how artifacts are distributed. Because of this, it can make sense to start by using PQC only for your most critical applications rather than everything at once. Before rolling anything out fully, testing is key. You’ll want to make sure your signed code is still accepted by the platforms you care about, that it works with existing systems, and that hybrid signatures behave the way you expect. Taking the time to validate early helps avoid bigger issues later on.

Migration Dependencies

Before PQC signing touches a real pipeline, confirm the dependency chain is actually in order:

1. HSM firmware supports the specific algorithm you intend to use, confirmed per model, not assumed from a vendor’s roadmap.
2. Your CA or certificate authority can issue a certificate profile for that algorithm, if the workflow requires a certificate at all.
3. Your CI/CD signing tool or plugin can actually invoke the new algorithm; many existing signing tools and APIs were never built for PQC and need an update, not just an HSM that supports it.
4. The systems that will verify the signature, OS trust stores, deployment gates, package managers, recognize the algorithm; if they don’t, dual signing isn’t optional.

Verification Compatibility

This is the limitation most integration plans underweight. A pipeline can produce a correct ML-DSA signature today, but that signature is only useful to a verifier that recognizes it. Mainstream OS-level signature verification largely doesn’t yet, which is why dual, parallel signing, the classical signature alongside the new one, is the practical pattern rather than an outright replacement. Confirm which category each of your actual downstream verifiers falls into before assuming a pilot generalizes to production.

HSM Readiness

Most legacy HSMs need a firmware update, or in some cases hardware replacement, to support ML-DSA, SLH-DSA, or LMS/XMSS key generation and signing. For each HSM in your pipeline, confirm current firmware capability directly with the vendor, get a specific target date if an update is needed, and don’t assume suite-wide vendor support extends to your specific model.

Testing and Rollback

Test against every verifier the artifact will actually meet in production, not just the one used in development, and measure the size impact of larger PQC signatures on any bandwidth- or storage-constrained distribution channel before committing to a rollout timeline. 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, the classical signature remains valid, and the fix is to pause adding the second signature for that pipeline stage while the incompatibility is diagnosed, not to revoke or re-issue anything.

Future-Proofing Your Code Signing Infrastructure

Future-proofing your code signing setup isn’t about making one big change, it’s about being ready to adapt over time. PQC is still evolving, and new algorithms and standards will continue to emerge. Because of that, it’s important to stay informed on industry updates, including standardization efforts and vendor support, so you can make smart decisions about when to adopt new approaches or move away from older ones.

Flexibility in your infrastructure also matters. Your key management systems and HSMs should be able to support multiple algorithms and adapt as requirements change. Choosing tools built to work well with others and that can evolve will make this transition smoother.

Instead of trying to overhaul everything at once, it’s more practical to take a phased approach. Start small, test what works, and build from there. This gives your team time to learn and adjust without taking unnecessary risk. Regularly reviewing and updating your approach will help ensure your code signing process stays secure and reliable as quantum threats become more real.

How Encryption Consulting Can Help

At Encryption Consulting, we specialize in PKI, encryption, and certificates of all types, and we support our customers. We can help your organization design, implement, and manage your PKI, or you can use our CBOM tool, CBOM Secure. CBOM Secure is a one-stop solution for all your crypto-inventory needs. Our platform tracks the keys, certificates, and protocols used in your organization, allowing you to quickly determine whether your cryptographic assets meet the specific regulatory and compliance standards you need. To learn more about the services and products that Encryption Consulting offers, visit our website at www.encryptionconsulting.com.

Integration Readiness Checklist

• Confirmed which algorithm you need: ML-DSA for general/high-volume signing, SLH-DSA or LMS/XMSS if a long-lived trust anchor or CNSA 2.0 compliance specifically calls for a hash-based scheme.
• Confirmed HSM firmware support for that exact algorithm, per model.
• Confirmed your CI/CD signing tool can invoke the algorithm, not just that the HSM supports it.
• Confirmed which downstream verifiers recognize the new signature, and planned dual signing for any that don’t.
• Piloted on a controlled, lower-risk pipeline stage before scaling to production releases.

Frequently Asked Questions

Is ML-KEM used in code signing?

No. ML-KEM (FIPS 203) is a key encapsulation mechanism for establishing shared secrets, relevant to TLS and key exchange. Code signing uses signature algorithms: ML-DSA (FIPS 204), SLH-DSA (FIPS 205), or LMS/XMSS (NIST SP 800-208).

Do I need to replace my classical signature immediately?

No. Dual, parallel signing, both a classical and a post-quantum signature on the same artifact, is the practical integration pattern while verifier support for post-quantum signatures is still uneven across the ecosystem.

What’s the most common reason a PQC signing pilot fails?

Verifier incompatibility discovered after signing rather than before. The signing side (HSM, CI/CD tool) is usually verified in advance; the verification side often isn’t checked until a signed artifact fails somewhere in the field.

Is a single combined “hybrid” signature format available today?

Not yet as a finalized standard. The relevant IETF specification for composite signatures remains an Internet-Draft. Dual, independent signatures are the lower-risk, currently practical approach.

Conclusion

The move to post-quantum cryptography isn’t just a theoretical idea; it’s something that’s going to happen, and it will change how we think about digital trust. For code signing, where trust is tied directly to software integrity and supply chain security, this matters a lot. If organizations wait too long to prepare, they risk getting stuck with outdated systems that are hard to update when it really counts. On the other hand, starting early gives you time to plan properly, trying things like hybrid signing, getting a better handle on your cryptographic assets, and building in the flexibility to adjust as standards evolve.

There’s no clear finish line for PQC adoption. It’s an ongoing process, not a one-time project. The key is to stay flexible and keep improving over time. By starting now and taking a thoughtful approach, organizations can make sure the trust they build today will still hold up in the future.