ML-KEM and the Future of Code Signing in a PQC World 

Introduction 

We’ve relied on algorithms like RSA and ECC for years to protect everything from emails to software updates. They’ve held up pretty well as long as attackers don’t have a quantum computer. But that’s the problem: quantum computing is no longer just a theoretical idea. It’s progressing fast enough that cryptographers are seriously thinking about what happens when these machines become practical. 

Quantum computers break things in a very specific way. They don’t just make our systems faster; they make some cryptographic problems trivial, like factoring large numbers (which breaks RSA) or solving the discrete log problem (which breaks ECC). That means if we continue using current algorithms, anything encrypted or signed today could be cracked in the future, once a quantum computer catches up. 

This is where post-quantum cryptography steps in. It’s not about fixing broken systems, it’s about future-proofing them. We need new algorithms that stay safe even if quantum computers become a reality. That’s exactly the problem ML-KEM is built to solve. 

ML-KEM’s role in code signing, defined precisely: ML-KEM (FIPS 203) is a key encapsulation mechanism, not a signature algorithm, and it plays no part in the code signing operation itself. Its legitimate use near a signing environment is securing the network transport, TLS or mTLS, between a signing client and a remote signing service or HSM, or protecting a provisioning channel. It does not make an RSA or ECDSA signature quantum-resistant. That requires a post-quantum signature algorithm instead, ML-DSA (FIPS 204), SLH-DSA (FIPS 205), or LMS/XMSS (NIST SP 800-208).

Key Takeaways

• ML-KEM is a key encapsulation mechanism (KEM), used to establish a shared secret, not to sign anything. It has no role in the cryptographic signing operation that produces a code signature.
• Encrypting the network channel to a signing service with ML-KEM does not make the resulting signature quantum-resistant. If the signature itself is RSA or ECDSA, it remains just as vulnerable to a future cryptographically relevant quantum computer regardless of how securely the signing request traveled to get there.
• Achieving an actual quantum-resistant code signature requires signing with ML-DSA, SLH-DSA, or LMS/XMSS. See Comparing SLH-DSA, LMS, and XMSS for choosing between them, and Architecting the CNSA 2.0 Transition Strategies for the full migration architecture.
• ML-KEM is still worth adopting for signing infrastructure, just for a narrower reason than “quantum-safe signing”: protecting the transport channel to a remote HSM or signing API from a harvest-now-decrypt-later attack on the traffic itself.

Overview of ML-KEM  

ML-KEM stands for Module-Lattice Key Encapsulation Mechanism, and it’s part of the new set of cryptographic algorithms selected by NIST to help protect against quantum threats. You might’ve heard of Kyber ML-KEM, which is basically Kyber with a formal name as it moves toward standardization. 

At its core, ML-KEM helps two systems establish a shared secret over an insecure connection. It’s like Diffie-Hellman or RSA-based key exchange, but built to resist quantum attacks. That makes it a perfect fit for securing communication between apps, systems, and even hardware like HSMs, especially in sensitive workflows like code signing. 

Why does this matter now? Because many software vendors, certificate authorities, and security tools are already thinking ahead. If you’re building systems that will be used 5 or 10 years from now, you can’t ignore the quantum angle anymore. ML-KEM helps ensure that your key exchange mechanisms won’t become tomorrow’s weakest link. 

What is ML-KEM? 

Origins of ML-KEM from Kyber 

ML-KEM didn’t just pop out of nowhere. It’s actually the formal name for a tried-and-tested algorithm called Kyber, which has been around for a while in post-quantum cryptography circles. When NIST (National Institute of Standards and Technology) ran a global competition to choose new cryptographic standards that can stand up to quantum attacks, Kyber stood out. 

After years of testing, discussions, and security evaluations, NIST gave it the green light in 2022 as its go-to algorithm for key exchange in a quantum-safe world. As part of finalizing the standard, Kyber was renamed ML-KEM, which stands for Module-Lattice based Key Encapsulation Mechanism. Think of it as the official version of Kyber that’s now being adopted in real-world systems. 

ML-KEM’s Job: A Quantum-Safe KEM 

So, what does ML-KEM actually do? It’s a Key Encapsulation Mechanism or KEM for short. In simple terms, it’s used to securely exchange a shared secret key between two parties over an insecure connection. This is the key step in many cryptographic systems: you and someone else need to agree on a secret that no one else can see, even if they’re watching everything you send. 

Traditionally, we’ve used algorithms like RSA and Elliptic Curve Diffie-Hellman for this. But those won’t survive a quantum attack. ML-KEM steps in as a replacement—it lets you encapsulate (or “wrap”) a shared secret in a way that’s safe even if someone has access to a future quantum computer. 

And just like traditional KEMs, once the shared secret is exchanged, it can be used for symmetric encryption, like AES, to protect data or sign software packages in transit.

Why ML-KEM Works: The MLWE Problem 

Under the hood, ML-KEM is built on something called the Module Learning With Errors problem, or MLWE for short. This sounds complicated, but here’s the gist: 

Imagine trying to solve a simple math problem where someone has deliberately added a bit of noise to the answer. You might still get close, but cracking it perfectly, especially across many dimensions, is incredibly hard. That’s the essence of MLWE: it’s based on math problems that are easy to compute one way but painfully hard to reverse, especially when noise is thrown in. 

This kind of math holds up even when a quantum computer gets involved. That’s why MLWE-based algorithms like ML-KEM are considered safe bets for the future. It’s not just theory; this problem has been analyzed for years, and no one’s found a practical way to break it with either classical or quantum methods. 

How ML-KEM Works 

Let’s break it down into what actually happens when you use ML-KEM to securely exchange a key. It’s fast, efficient, and works kind of like a secure digital handshake with some serious math behind the scenes. 

Key Generation 

First up: key generation. This is where one party (let’s say, a server) creates a public key and a private key. The public key is shared with others, and the private key is kept safe and never leaves the system. 

Think of it like this: 

• Public Key: A lock you hand out to anyone who wants to send you a secret. 
• Private Key: The key that opens the lock and lets you read that secret. 

In ML-KEM, these keys are based on lattice math (specifically the MLWE problem), which makes them strong against attacks from quantum computers. 

Encapsulation and Decapsulation 

Now comes the encapsulation part. 

Suppose a client wants to send a shared secret to the server. Here’s what happens: 

• The client uses the server’s public key to create a ciphertext (a scrambled message). 
• Along with the ciphertext, the client also generates a shared secret key. 
• The ciphertext gets sent over to the server. 

Then comes decapsulation: 

• The server uses its private key to decrypt the ciphertext. 
• It gets the same shared secret key that the client generated. 

Now, both sides have the exact same secret, without actually sending the key over the network. Even if someone’s eavesdropping, they can’t figure out the secret, because they’d need the private key, and solving the math problem without it is practically impossible (even for quantum machines). 

Security Levels: ML-KEM-512, 768, 1024

ML-KEM comes in three levels, each offering a different level of security: 

• ML-KEM-512: Recommended for most use cases, roughly equivalent to 128-bit classical security. 
• ML-KEM-768: A step up, offering about 192-bit security. 
• ML-KEM-1024: Highest level, with 256-bit security, ideal if you’re securing stuff that really can’t be risked. 

Each level increases the size of the keys and ciphertexts a bit, but also increases the difficulty for attackers trying to break the encryption. In short: pick the level that fits your risk profile and performance needs. 

Resistance to Quantum Attacks 

So, how is ML-KEM “quantum-safe”? Here’s the simple idea: ML-KEM is based on lattice problems that are hard to solve even for quantum computers. Algorithms like Shor’s (which breaks RSA and ECC) don’t help much here. And despite years of cryptanalysis, no one’s figured out how to break MLWE-based systems efficiently with quantum techniques. 

In fact, one of the reasons Kyber (now ML-KEM) was selected by NIST is because it struck a solid balance between performance and quantum resistance. It’s fast enough for practical use, yet backed by solid math that makes quantum attacks a no-go. 

ML-KEM in the NIST PQC Standardization Process 

NIST’s Role in Post-Quantum Standardization 

The National Institute of Standards and Technology (NIST) isn’t just another acronym in cryptography; they’re basically the referees. When it comes to what encryption gets used in government, critical infrastructure, and major industry systems, NIST decides what’s safe and what’s outdated. 

Back in 2016, NIST kicked off a global competition to find cryptographic algorithms that could stand up to quantum computers. The idea was simple: let researchers submit their best ideas, throw every known attack at them, and see what survives. 

Out of 80+ submissions, only a few made it to the finish line. One of them was Kyber, which now carries the name ML-KEM as part of the official standard. 

Why Kyber (ML-KEM) Was Chosen 

So why did Kyber beat the competition? 

Here’s what made it stand out: 

• Strong Security Foundation: Based on the Module Learning With Errors (MLWE) problem, which is widely trusted in the crypto world. 
• Efficient Performance: It’s fast and doesn’t need huge keys or ciphertexts. Great for real-world systems, including low-power devices. 
• Clean Design: Unlike some other candidates, Kyber had a straightforward, well-documented implementation that made auditing and integration easier. 
• Broad Support: It gained popularity in early prototypes and open-source libraries like OpenQuantumSafe, so it already had momentum. 

The result? NIST selected Kyber for standardization and renamed it ML-KEM in 2022. That makes it the official post-quantum KEM of the future. 

ML-KEM vs Traditional Key Exchange Algorithms (RSA/ECC) 

Let’s be honest, RSA and ECC have done their job pretty well over the years. They’re behind the scenes in your HTTPS connections, secure email, VPNs, and yes, even code signing. But with quantum computing getting closer, it’s time to look at what happens when we compare those classics to ML-KEM, the post-quantum alternative.

Performance 

When it comes to speed, ML-KEM actually holds up surprisingly well. 

• RSA gets slower as you increase key sizes (which you must do for better security). 
• ECC is faster than RSA but not designed to handle quantum resistance. 
• ML-KEM is designed for performance with security in mind. It’s fast at both key generation and encapsulation/decapsulation, even faster than RSA in many cases. 

For real-world use cases like TLS or code signing infrastructure, this makes ML-KEM a serious upgrade, not just a fallback. 

Key Sizes 

Here’s where the numbers get interesting: 

Algorithm	Public Key Size	Ciphertext Size	Security Level
RSA-2048	~256 bytes	~256 bytes	~112-bit
ECC (P-256)	~64 bytes	~64 bytes	~128-bit
ML-KEM-512	~800 bytes	~768 bytes	128-bit PQ
ML-KEM-768	~1200 bytes	~1088 bytes	192-bit PQ

Yes, ML-KEM keys and ciphertexts are larger than ECC and RSA, but they’re still small enough to work efficiently in most systems. They’re also far smaller than some other post-quantum algorithms that NIST didn’t select. 

Security Assumptions 

• RSA relies on the difficulty of factoring large numbers. 
• ECC depends on solving the elliptic curve discrete log problem. 
• Both of those get wrecked by quantum computers using Shor’s algorithm. 

ML-KEM, on the other hand, is based on lattice problems, specifically MLWE. These aren’t just resistant to known quantum attacks; they’ve been studied for years with no major cracks. That’s why ML-KEM is considered safe even in the future when working with quantum machines. 

So, if you want your system to be secure in 10–15 years, ML-KEM is the smarter bet. 

Impact on Resource-Constrained Environments 

You’d think larger keys would make ML-KEM hard to use on tiny devices, but it’s actually surprisingly efficient. 

• Unlike some PQ algorithms that need lots of memory or CPU, ML-KEM keeps things lean. 
• It’s been tested on everything from cloud servers to microcontrollers, and it performs well across the board. 
• Many TLS and VPN prototypes already run with ML-KEM just fine on mobile phones and embedded chips. 

Sure, if you’re trying to run cryptography on a sensor running off a coin cell battery, you’ll need to test carefully. But in most real-world cases, ML-KEM is fast and light enough to get the job done even where ECC used to shine. 

The Role of ML-KEM in Code Signing 

How Code Signing Works 

Code signing is how software publishers prove that their app or update hasn’t been tampered with. Here’s the basic flow: 

• The publisher hashes the code (to create a digital fingerprint). 
• That hash is signed with a private key. 
• When users or systems receive the software, they verify the signature using the matching public key, usually stored in a certificate. 

If the signature checks out, the code is trusted. If not, it’s flagged. Simple enough, but the whole process depends on public key crypto, usually RSA or ECC, to make it trustworthy. 

What’s the Problem? Quantum Breaks It  

Traditional code signing uses algorithms like RSA and ECC, which are fine until a quantum computer enters the picture. 

• Quantum computers can crack RSA and ECC using Shor’s algorithm. 
• That means attackers could one day forge signatures, and your system would have no idea it’s been tricked. 

Even if quantum computers aren’t here yet, attackers could harvest signed code and certificates now and break them later. That’s a big problem for long-lived code (like firmware or OS updates) or anything stored offline. 

It’s worth being precise about what fixes that problem, because it isn’t ML-KEM. The “harvest now, forge later” risk lives entirely in the signature algorithm: if RSA or ECDSA can eventually be broken, an attacker who recorded a signed artifact can forge new signatures with a recovered key, regardless of how that artifact was transmitted. The only fix for that specific risk is signing with a post-quantum signature algorithm, ML-DSA, SLH-DSA, or LMS/XMSS, in place of or alongside RSA/ECDSA. ML-KEM addresses a different, narrower problem entirely, described below.

What ML-KEM Actually Does Near a Signing System 

ML-KEM doesn’t touch the signature at all. Its legitimate role is securing the network channel around the signing operation, specifically: 

• The TLS/mTLS connection between a signing client and a remote signing service or HSM 
• A certificate or key provisioning channel, so the exchange itself resists a future quantum attacker recording today’s traffic 

Here’s where ML-KEM fits in: it gives you a quantum-safe way to protect the network traffic between systems that coordinate around code signing, without changing what algorithm actually produces the signature. That’s especially relevant in hybrid crypto models, where you combine a quantum-safe transport layer with whatever signature algorithm your trust ecosystem currently requires, while planning the separate migration to a post-quantum signature algorithm for the signature itself. 

Think of ML-KEM as protecting the pipe the signing request travels through, not the seal applied at the end of it. Both matter, but they solve different problems, and only the second one addresses the harvest-now-forge-later risk to the signature. 

Where ML-KEM Fits in the Signing Workflow  

• Certificate Provisioning

  When you’re requesting a code signing certificate from a CA, ML-KEM can be used to: 

  1. Encrypt private keys or challenge responses during provisioning.
  2. Make the entire exchange quantum-safe, so attackers can’t intercept or replay it years later.
  3. This protects the provisioning channel itself; it does not change the certificate’s own key type. A code signing certificate carries a signature public key (RSA, ECDSA, or, once migrated, ML-DSA/SLH-DSA), never a KEM key, since a certificate’s job is to verify signatures, not exchange session secrets.
• Signing Server to Client Communication

  A lot of companies use a remote signing server (or HSMs) that handle private keys. ML-KEM can be used to: 

  1. Set up a secure channel between the client and the signing service.
  2. Protect API tokens, key handles, or command payloads from interception, even by future quantum attackers.
  3. Avoid reliance on RSA-based TLS by supporting quantum-safe key exchange.
• Secure Software Delivery Pipelines

  In automated CI/CD setups, secrets often pass between tools, containers, or cloud services. ML-KEM can help: 

  1. Encrypt ephemeral keys or signing instructions between pipeline steps.
  2. Ensure build agents or signers aren’t exposed, even if the pipeline is public-facing.
  3. Lay the foundation for quantum-resilient build processes, where both transport and signing hold up against future threats.

Integrating ML-KEM into Our CodeSign Secure

If you’re building or maintaining secure software pipelines, our CodeSign Secure is designed to make code signing smarter, more automated, and future-proof. And with ML-KEM now standardized by NIST, it’s time to bring post-quantum protection into the picture,  without throwing out everything that already works. 

Real-World Integration with Tools (OpenSSL, PQCrypto Libraries) 

You don’t need to reinvent everything to start using ML-KEM. Thanks to active open-source work and early adoption, you can already plug it into many familiar tools: 

• OpenSSL (via forks like [OpenQuantumSafe’s liboqs]) supports ML-KEM for key exchange. 
• Libraries like PQClean, liboqs, and PQCrypto have clean, production-ready implementations. 
• Our CodeSign Secure builds on this by offering ML-KEM-based secure channels between the signing client and the signing backend, using these battle-tested libraries under the hood. 

In short, we bring ML-KEM into your stack without asking you to rip out OpenSSL or abandon your automation scripts. 

Transport-Layer Hybrid: ML-KEM Alongside RSA/ECDSA Signing 

Let’s be realistic: most ecosystems still rely on RSA or ECDSA for digital signatures, especially when compatibility matters (Windows Authenticode, Apple Notarization, etc.), and migrating the signature algorithm itself is a separate, larger project from anything covered here. 

What our platform supports today is layering ML-KEM into the transport around that unchanged signing operation: 

• RSA/ECDSA continues to produce the actual signature, unchanged. 
• ML-KEM secures the session between the signing client and the signing service or HSM. 

To be precise about what this does and doesn’t achieve: it protects the signing request and any secrets in transit from a harvest-now-decrypt-later attack on the network traffic itself. It does not make the resulting RSA or ECDSA signature quantum-resistant, that signature remains exactly as vulnerable to a future quantum computer as it would be without ML-KEM in the transport. The two protections are independent; adopting one is not a substitute for planning the other. For an actual quantum-resistant signature, the migration path is to ML-DSA, SLH-DSA, or LMS/XMSS, covered in Comparing SLH-DSA, LMS, and XMSS. 

HSM and PKCS#11 Support 

Our platform already supports PKCS#11 for interacting with HSMs, and we’re extending this to support post-quantum key exchanges and hybrid signing too. 

• ML-KEM keys can be stored and managed using the vendor-specific extensions or embedded alongside traditional keys. 
• We support signing workflows where the session is protected using ML-KEM, and the signature is performed using a PKCS#11-backed private key (like RSA-3072 or ECDSA-P384). 

It’s fully compatible with Thales, nShield, and other leading HSMs, and we’re working with vendors to expand native support for ML-KEM keys under PKCS#11. 

Challenges and Considerations 

Switching to post-quantum crypto like ML-KEM isn’t just flipping a switch. It’s a move with some trade-offs and a few things to think through, especially if you’re working with code signing systems that need to stay reliable, fast, and compatible. 

Performance vs. Security Trade-offs

ML-KEM is fast for a post-quantum algorithm, but it’s not as lightweight as ECC or RSA when it comes to key and ciphertext sizes. 

• For example, ML-KEM-512 public keys are around 800 bytes, and ciphertexts are similar, much bigger than ECC, but still manageable. 
• If you go for higher security levels (like ML-KEM-768 or -1024), expect even larger keys and more CPU usage during encapsulation and decapsulation. 

So, if you’re using ML-KEM in something like CI/CD pipelines or embedded systems, you’ll need to balance security needs with how much overhead your system can handle. In most modern server setups, it’s barely noticeable, but it’s something to test. 

Interoperability with Legacy Systems 

Here’s the sticky part: a lot of tools, protocols, and platforms don’t know what to do with post-quantum algorithms. 

• Most operating systems, browsers, and mobile platforms still expect RSA or ECDSA keys in certificates. 
• Build tools, CI/CD platforms, and package managers aren’t yet ready for full PQ crypto. 

That’s why hybrid schemes matter. You can layer ML-KEM into the handshake or transport, while still using RSA or ECC where compatibility is critical. It’s a way to move forward without breaking existing stuff. 

Secure Storage and Protection of ML-KEM Keys 

ML-KEM keys, like any private key, need to be stored securely and managed carefully. But there are some quirks to deal with: 

• Not all HSMs or key stores support ML-KEM yet. 
• Some PKCS#11 modules may need vendor-specific extensions to hold ML-KEM key objects. 
• If you’re doing software-based key storage (not ideal), you’ll need strong OS-level protections, encryption, and access control. 

In our platform, we’re working on HSM-backed and encrypted container-based storage for ML-KEM key material, along with support for exporting keys in formats like [NIST’s SP 800-56Cr1] so you can keep things clean and auditable. 

Conclusion 

ML-KEM isn’t a theoretical upgrade, it’s NIST’s finalized standard for quantum-safe key exchange, and it has a genuine role to play around code signing infrastructure: protecting the network channel between a signing client and a remote signing service or HSM, and securing certificate and key provisioning traffic, from a harvest-now-decrypt-later attack on that traffic itself. 

What it does not do is make a code signature quantum-resistant. That’s an easy claim to make casually and an important one to get right: if your signing operation still produces an RSA or ECDSA signature, that signature carries exactly the same long-term risk, forgeable by a future cryptographically relevant quantum computer, whether or not ML-KEM protects the network traffic around it. The two are independent protections, and treating transport security as a substitute for migrating the signature algorithm itself is the kind of false confidence that leaves the actual “trust now, forge later” risk unaddressed. 

The practical path is to pursue both, on their own timelines: layer ML-KEM into signing infrastructure transport now, since it’s a comparatively low-disruption change, and separately plan the migration of the actual signature algorithm to ML-DSA, SLH-DSA, or LMS/XMSS, since that’s the change that actually protects signed artifacts against a future quantum computer. 

Frequently Asked Questions

Does adding ML-KEM to my signing pipeline make my code signatures quantum-resistant?

No. ML-KEM secures the network transport around the signing operation. The signature itself is only as quantum-resistant as the signature algorithm used to produce it, RSA and ECDSA remain fully vulnerable to a future quantum computer regardless of transport security. Achieving a quantum-resistant signature requires signing with ML-DSA, SLH-DSA, or LMS/XMSS instead.

Can a code signing certificate use an ML-KEM key?

No. A code signing certificate carries a signature public key, since its purpose is verifying signatures, not establishing shared secrets. ML-KEM keys have no place in a code signing certificate’s key usage.

Is it still worth adopting ML-KEM if it doesn’t fix the signature problem?

Yes, for the problem it does solve: a future quantum computer could decrypt today’s recorded network traffic, so protecting the transport to a remote signing service or HSM with ML-KEM closes a real, separate exposure. It just isn’t the fix for signature-forgery risk.

If you’re looking to make this shift without the headache, our code signing platform, CodeSign Secure, is designed to help with both halves of this: ML-KEM-protected transport to the signing service today, and a supported migration path to ML-DSA and LMS signature algorithms for the signature itself. Whether you’re modernizing your signing infrastructure or just getting started, our platform gives you the tools to stay ahead without compromising compatibility or security.