up:: The New Standards MOC

NIST SP 800-227 (KEM Guidance)

NIST SP 800-227 is the NIST Special Publication titled “Recommendations for Key-Encapsulation Mechanisms,” finalized on September 18, 2025, that defines what a key-encapsulation mechanism is and how to implement and use one securely, serving as the foundational companion to FIPS 203. Where FIPS 203 standardizes one specific KEM (ML-KEM), SP 800-227 is the general framework: it defines a KEM as a set of three algorithms (key generation, encapsulation, and decapsulation), it names the security property a general-purpose KEM should meet (indistinguishability under chosen-ciphertext attack, IND-CCA2), and it works through concrete constructions including a KEM built from Diffie-Hellman (ECDH-KEM) and the approved combiners for joining KEMs into hybrids. It’s the document that turns “use ML-KEM” into a principled account of what a KEM is and how to use it safely.

The short version:

1. It’s NIST’s general guidance on key-encapsulation mechanisms, published September 18, 2025, and it’s the companion to FIPS 203, which standardizes one specific KEM.
2. It defines a KEM as three algorithms: KeyGen (make a key pair), Encaps (produce a ciphertext and a shared secret from the public key), and Decaps (recover the shared secret from the ciphertext with the private key).
3. It sets the security target. A general-purpose KEM should be IND-CCA (secure against active attackers), which SP 800-227 notes is what the literature calls IND-CCA2, and ML-KEM is believed to satisfy it.
4. It works constructions concretely, including ECDH-KEM (a KEM built from elliptic-curve Diffie-Hellman) and RSA-based and ML-KEM examples, showing that classical key-establishment fits the KEM interface too.
5. It covers multi-algorithm KEMs and approved key combiners, the sanctioned way to join a classical and a post-quantum KEM so the shared secret holds if either half survives, which is the basis of hybrid key establishment.

Think of a KEM like a tamper-evident lockbox delivery. Someone gives you their open, empty lockbox (the public encapsulation key). You put a freshly generated random combination inside, snap it shut so only their private counterpart can open it, and send back the sealed box (the ciphertext), keeping a copy of the combination (the shared secret). They open the box with their private half and read the same combination. Now you both know a secret number nobody watching the delivery could learn, and you use it to lock the rest of your conversation. SP 800-227 is the rulebook for how that lockbox has to work: what the three steps are, how strong the box must be against someone who gets to tamper with deliveries, and how to send two boxes at once so the secret survives even if one design turns out weak.

What is NIST SP 800-227?

NIST SP 800-227 is a NIST Special Publication that provides recommendations for key-encapsulation mechanisms, covering their definitions, properties, and secure use, and it’s the general guidance document that sits underneath the specific KEM standard, FIPS 203. Its identity, for citation:

1. Title: “Recommendations for Key-Encapsulation Mechanisms.”
2. Issuer: NIST (National Institute of Standards and Technology).
3. Status and date: Final, published September 18, 2025.
4. Role: The companion to FIPS 203. FIPS 203 standardizes ML-KEM as the algorithm; SP 800-227 defines what a KEM is in general and how to implement and use any KEM securely.

Source: NIST, “Recommendations for Key-Encapsulation Mechanisms,” SP 800-227, September 18, 2025, NIST SP 800-227.

The reason a general KEM document exists alongside a specific KEM standard is that KEMs are now the primary way NIST expects key establishment to happen in a post-quantum world, so the community needs a shared, authoritative account of what the interface is, what security it must provide, and how to combine KEMs safely. SP 800-227 is that account.

What is a KEM, per SP 800-227?

Per SP 800-227, a KEM is a set of algorithms two parties use to securely establish a shared secret key over a public channel, and the mechanism is defined by three algorithms working together. This three-algorithm definition is the heart of the document.

1. KeyGen (key generation). Alice generates a private decapsulation key and a corresponding public encapsulation key. She publishes the encapsulation key and keeps the decapsulation key secret.
2. Encaps (encapsulation). Bob uses Alice’s public encapsulation key to generate a fresh shared secret key and a ciphertext that encapsulates it. He keeps the shared secret and sends the ciphertext to Alice.
3. Decaps (decapsulation). Alice uses the ciphertext and her private decapsulation key to compute the same shared secret key Bob generated.

The result is that Alice and Bob hold an identical shared secret key that an eavesdropper watching the public channel cannot learn, and that key is then used with symmetric-key cryptography to protect the actual communication. SP 800-227 also requires that sensitive intermediate values produced inside KeyGen, Encaps, and Decaps be destroyed before the algorithm terminates, a concrete implementation obligation.

Source: NIST SP 800-227, §2 (Overview of Key-Encapsulation Mechanisms), September 2025, NIST SP 800-227.

The important framing is that this interface is what ML-KEM implements, and it’s also what a classical scheme like Diffie-Hellman can be expressed as. The KEM interface is general, and that generality is what lets classical and post-quantum key establishment be combined and reasoned about the same way.

What security does SP 800-227 require of a KEM?

SP 800-227 requires that a general-purpose KEM be secure against active attackers, a property it calls IND-CCA, which it notes is what the cryptographic literature refers to as IND-CCA2. The document builds this up through two security notions, and the distinction between them is exactly why the stronger one is the target.

1. IND-CPA (against passive attackers). The weaker notion formalizes semantic security against an eavesdropper: given the encapsulation key and a ciphertext, an attacker can’t distinguish the true shared secret from a random string. IND-CPA captures security against passive adversaries who only observe.
2. IND-CCA (against active attackers). The stronger notion, which SP 800-227 identifies as IND-CCA2 in standard terminology, additionally withstands an attacker who can submit chosen ciphertexts and observe how they decapsulate. Real-world adversaries are active, so this is the security a general-purpose KEM should provide, and ML-KEM is believed to satisfy it.

Source: NIST SP 800-227, §2.3 Theoretical Security of KEMs (IND-CPA and IND-CCA definitions and footnote on IND-CCA2), September 2025, NIST SP 800-227.

The practical consequence is that the security bar for a KEM you’d deploy for general key establishment is IND-CCA2, and the design machinery that gets a lattice KEM there is the Fujisaki-Okamoto transform, which upgrades an IND-CPA scheme to IND-CCA. SP 800-227 gives the definitions; ML-KEM’s construction is what meets them.

What is ECDH-KEM, and why does SP 800-227 describe it?

ECDH-KEM is a key-encapsulation mechanism built from elliptic-curve Diffie-Hellman, and SP 800-227 describes it to show that a classical, quantum-insecure key-establishment scheme fits the same KEM interface as a post-quantum one, which is what makes classical and post-quantum KEMs composable. The document works through three constructions, ECDH-KEM, an RSA-based KEM, and ML-KEM, and ECDH-KEM is the one that connects the new framework to the existing elliptic-curve infrastructure.

The construction expresses ECDH as a KEM: key generation is the same as generating an ECDH key pair, encapsulation performs one party’s ECDH actions to produce the ciphertext and derive the shared secret, and decapsulation performs the other party’s actions to recover it. SP 800-227 is explicit that ECDH-KEM is a quantum-insecure KEM based on ECDH key exchange, so it’s not a post-quantum scheme, it’s the classical scheme cast in the KEM shape.

Source: NIST SP 800-227, §5.1.1 (A KEM From Diffie-Hellman) and §5 (ECDH-KEM), September 2025, NIST SP 800-227.

The reason this matters is the hybrid transition. If elliptic-curve key establishment and ML-KEM are both expressed as KEMs, they can be combined through a key combiner into a single shared secret, which is precisely how hybrid key exchange in TLS works. ECDH-KEM in SP 800-227 is the formal bridge that lets the classical half of a hybrid be reasoned about with the same interface as the post-quantum half.

How does SP 800-227 handle hybrids and key combiners?

SP 800-227 covers multi-algorithm KEMs and PQ/T (post-quantum/traditional) hybrids, and it specifies approved key combiners, the sanctioned methods for joining the shared secrets of two or more KEMs so the result is secure if any one of them is. This is the section that gives hybrid key establishment its NIST footing.

The idea is that during the transition, an organization wants to run a classical KEM (like ECDH-KEM) and a post-quantum KEM (like ML-KEM) together, so the session key stays secure as long as either the classical or the post-quantum half holds. That protects against two risks at once: a future quantum computer breaking the classical half, and an as-yet-undiscovered weakness in the newer post-quantum half. The combiner is the function that mixes the two shared secrets into one final key, and doing it correctly is security-critical, because a naive combination can undermine the guarantee. SP 800-227’s approved key combiners are the vetted way to do it.

Source: NIST SP 800-227, §4.6 (Multi-Algorithm KEMs and PQ/T Hybrids) and §4.6.2 (Approved Key Combiners), September 2025, NIST SP 800-227.

This ties SP 800-227 directly to the deployed reality of the transition. The KEM combiners that TLS hybrid named groups use are exactly this construction, so SP 800-227 is the authoritative source for why hybrid key establishment is safe and how to build the combiner that makes it so.

How does SP 800-227 relate to FIPS 203 and the other standards?

SP 800-227 is the general KEM guidance and FIPS 203 is the specific KEM standard, so they’re a matched pair: SP 800-227 tells you what a KEM is and how to use one securely, and FIPS 203 gives you the one NIST-standardized KEM to use. The relationship mirrors how NIST separates general guidance from specific algorithm standards elsewhere.

Document	What it is	Scope
FIPS 203	The standard for ML-KEM	One specific, mandatory-to-standard KEM algorithm
SP 800-227	Recommendations for KEMs	The general framework: definition, security, constructions, hybrids
KEM concept	The primitive itself	What the interface is and why key establishment moved to it
Hybrid cryptography	Combining KEMs	The transitional pattern SP 800-227’s key combiners make safe

The takeaway is that SP 800-227 is where the reasoning lives. When you need to justify why a hybrid is secure, why IND-CCA2 is the right bar, or how a classical scheme and ML-KEM combine, SP 800-227 is the primary source, and FIPS 203 is the algorithm you plug into that reasoning.

Common misconceptions

1. “SP 800-227 is just another name for FIPS 203.” They’re different documents with different jobs. FIPS 203 standardizes one KEM (ML-KEM); SP 800-227 is the general guidance defining what any KEM is, what security it needs, and how to combine KEMs.
2. “A KEM is a kind of encryption algorithm.” A KEM establishes a shared secret key, it doesn’t encrypt your message directly. You use the KEM’s shared secret with symmetric-key cryptography to protect the actual data.
3. “IND-CPA is good enough for a deployed KEM.” SP 800-227 sets the general-purpose bar at IND-CCA (IND-CCA2 in the literature), which withstands active, chosen-ciphertext attackers. IND-CPA only covers passive eavesdroppers, so real deployments need the stronger notion.
4. “ECDH-KEM is a post-quantum algorithm because it’s in the KEM guidance.” SP 800-227 is explicit that ECDH-KEM is quantum-insecure. It’s the classical Diffie-Hellman scheme cast as a KEM, included to show that classical schemes fit the interface and can be combined with a post-quantum KEM.
5. “Hybrid key establishment is unofficial or non-standard.” SP 800-227 covers multi-algorithm KEMs and specifies approved key combiners, giving hybrid key establishment explicit NIST guidance. It’s the sanctioned method, not a workaround.

Questions people ask

What is NIST SP 800-227? It’s NIST’s “Recommendations for Key-Encapsulation Mechanisms,” finalized September 18, 2025, the general guidance on what a KEM is and how to use one securely. It’s the companion to FIPS 203, which standardizes the specific KEM, ML-KEM.

Is SP 800-227 final? Yes, it was published as a final document on September 18, 2025. It went through a public draft process before finalization, and the final is the version to cite.

What are the three KEM algorithms? KeyGen generates a public encapsulation key and a private decapsulation key; Encaps uses the public key to produce a ciphertext and a shared secret; Decaps uses the private key and the ciphertext to recover the same shared secret. Those three are the definition of a KEM in SP 800-227.

What security does a KEM need? SP 800-227 sets the general-purpose target at IND-CCA, which it notes is IND-CCA2 in standard terminology, meaning security against active attackers who can submit chosen ciphertexts. ML-KEM is believed to meet it, reaching IND-CCA via the Fujisaki-Okamoto transform.

What is ECDH-KEM? It’s a KEM built from elliptic-curve Diffie-Hellman, described in SP 800-227 as a quantum-insecure example. Its purpose is to show that a classical scheme fits the KEM interface, which is what lets it be combined with a post-quantum KEM into a hybrid.

Does SP 800-227 approve hybrid key exchange? Yes. It covers multi-algorithm KEMs and PQ/T hybrids and specifies approved key combiners, the vetted way to join a classical and a post-quantum KEM so the shared secret is safe if either half holds. That’s the basis for the TLS hybrid groups.

Do I need to read SP 800-227 to deploy ML-KEM? To simply deploy ML-KEM, FIPS 203 is the algorithm standard. SP 800-227 is what you read to understand the security reasoning, use ML-KEM correctly in a protocol, and build a hybrid with an approved key combiner, so it’s the guidance behind correct use rather than the algorithm itself.

---

Everything here is the map, given freely. When your team needs its key-establishment surfaces moved onto standardized KEMs, its hybrids built with approved key combiners, and the whole thing sequenced against your systems, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-14 · Maintained by Addie LaMarr, LaMarr Labs.