Research window: 18–19 August 2026. Two developments recorded by the IETF on 18 August moved post-quantum email security closer to operational reality. One advanced a standards-track method for combining ML-KEMML-KEM-1024The NIST-standardised way for two systems to agree on a secret key without a quantum computer being able to work it out. It replaces the key exchange used by most of the internet today. with traditional cryptography in Cryptographic Message Syntax (CMS). The other updated a high-assurance S/MIME profile for US National Security Systems.
The shared message is practical: post-quantum migration is no longer only about choosing algorithms. Security teams must prepare certificates, message formats, client capabilities, downgrade controls and long-term decryption processes.
What changed on 18 August
The IETF Security Area Directorate completed its Last Call review of Composite ML-KEM for use in CMS with a result of Ready. The reviewer described the draft as clear and well written and reported no editorial issues. The LAMPS working-group document is intended for the Standards Track, has been submitted to the IESG and is currently waiting for Area Director action.
Separately, revision 05 of the CNSA 2.0 profile for S/MIME was posted and moved into IESG review through the Independent Submission stream. It specifies a quantum-resistant configuration for email used by US National Security Systems and other government systems processing high-value information.
Status matters: these are process milestones, not final approvals. The composite CMS document is still an Internet-Draft. The CNSA profile is an Informational independent submission and explicitly does not represent IETF consensus.
Track one: combine ML-KEMML-KEM-1024The NIST-standardised way for two systems to agree on a secret key without a quantum computer being able to work it out. It replaces the key exchange used by most of the internet today. with established cryptography
The LAMPS draft defines how composite key-encapsulation mechanisms can be used inside CMS. CMS is the message container behind S/MIME and other signed or encrypted content workflows. The proposal pairs ML-KEM-768 or ML-KEM-1024ML-KEM-1024The NIST-standardised way for two systems to agree on a secret key without a quantum computer being able to work it out. It replaces the key exchange used by most of the internet today. with an established mechanism such as RSA-OAEP, ECDH, X25519 or X448. The two component secrets are combined into one shared secret.
This composite approach is designed for a transition period in which organizations want protection from a future cryptographically relevant quantum computer without placing all trust in a single new primitive. It uses the KEMRecipientInfo structure defined by RFC 9629, and it also describes certificate conventions and how S/MIME clients may advertise composite-algorithm capabilities.
A “Ready” security review is a positive quality signal, but it is not equivalent to publication as an RFC. Implementers should continue tracking IESG decisions, identifier assignments and interoperability work before treating the draft as a stable production baseline.
Track two: a strict CNSA 2.0The standards we followNIST and CNSA 2.0 are the official rulebooks that say which encryption is strong enough to survive quantum computers. “Mapped” means every algorithm we deploy has been matched to what those rulebooks require. profile for S/MIME
The revised CNSA 2.0The standards we followNIST and CNSA 2.0 are the official rulebooks that say which encryption is strong enough to survive quantum computers. “Mapped” means every algorithm we deploy has been matched to what those rulebooks require. profile takes a different path. It specifies ML-DSA-87ML-DSA-87A quantum-safe digital signature. It is what proves a message, a software update, or a server really came from who it claims, and has not been altered. for digital signatures and ML-KEM-1024ML-KEM-1024The NIST-standardised way for two systems to agree on a secret key without a quantum computer being able to work it out. It replaces the key exchange used by most of the internet today. for key establishment. It also requires SHA-384 or SHA-512 for message digests, AES-256AES-256The encryption that protects stored data and the contents of a connection. Quantum computing weakens it but does not break it, so AES-256 stays safe to keep using.-GCM for content encryption and AES key wrap with padding for key encryption.
Revision 05 adds an important integrity requirement: signedAttrs must be present for every SignerInfo to reduce the risk of existential-forgery attacks against signed content. The profile also requires certificate validation and timely revocation checking through CRLs or OCSP.
This is a high-assurance government profile, not a universal enterprise recommendation. Its own text notes that the suite will not suit every use case and encourages data owners to perform risk assessments. It would obsolete RFC 8755 only if approved, and its current review does not turn it into an IETF standard or a binding mandate.
Why the two tracks belong in one migration plan
The composite draft prioritizes transitional resilience and interoperability: a post-quantum KEM and a traditional mechanism protect the same content-encryption key. The CNSA profile prioritizes a prescriptive, fully quantum-resistant configuration for a defined high-security environment. Organizations may encounter both models through suppliers, partners, regulated environments or cross-domain messaging.
That makes crypto-agilityCrypto-agilityBeing able to swap one encryption algorithm for another without rebuilding your systems. It is what turns the next migration into a configuration change instead of a project. more important than a one-time algorithm swap. A mail platform may need to process different certificate profiles, larger keys and signatures, new CMS recipient structures and mixed recipient capabilities while preserving auditability and archival access.
Security tasks to start now
- Inventory: identify every product and workflow that creates, verifies, encrypts, decrypts or archives CMS and S/MIME content.
- Map dependencies: record certificate authorities, gateways, hardware security modules, mail clients, mobile clients and partner systems involved in each flow.
- Test formats: validate
KEMRecipientInfo, composite certificates, ML-KEM-1024ML-KEM-1024The NIST-standardised way for two systems to agree on a secret key without a quantum computer being able to work it out. It replaces the key exchange used by most of the internet today., ML-DSA-87 and required signed attributes in a controlled interoperability lab. - Measure impact: track message growth, certificate size, latency, memory use and gateway limits rather than assuming classical performance profiles still apply.
- Control fallback: define capability negotiation and downgrade policy so unsupported clients cannot silently force weaker protection.
- Protect continuity: test certificate renewal, revocation, key recovery, legal hold and long-term archive decryption before production rollout.
- Track status: pin implementation decisions to specific draft versions and reassess them when the IETF records change.
The practical takeaway
The important news is not that post-quantum email is finished. It is that implementable profiles are becoming detailed enough for engineering teams to test real message flows. The safest next step is a version-aware pilot that treats certificates, interoperability, downgrade resistance and operational recovery as first-class migration requirements.
Primary sources
- IETF Security Directorate Last Call review: Composite ML-KEM for CMS
- IETF Datatracker: Composite ML-KEM for use in CMS
- IETF Datatracker history: CNSA 2.0 S/MIME profile
- CNSA 2.0 profile for S/MIME, revision 05
Quanten Security will continue to monitor these documents as their status evolves. This article reports standards activity observed during the stated research window and does not claim final IETF approval.