Quantum-Resistant Encryption: 3 Rollout Paths [2026]

wpnews.pro

NIST finalized ML-KEM in FIPS 203 on August 13, 2024, and the draft NIST IR 8547 timeline would deprecate quantum-vulnerable RSA and ECC uses after 2030 and disallow them after 2035. That draft dates from November 2024 and no later version has been confirmed, so the deadlines are proposals, not settled rules. What teams must decide today is not whether to adopt quantum-resistant encryption but which rollout path to take.

Three paths compete. Hybrid key exchange pairs ML-KEM with X25519 and ships first. Pure ML-KEM drops the classical half and waits on the IETF. Composite ML-KEM bolts a lattice key onto RSA-OAEP, ECDH, X25519 or X448 so certificates and message formats keep a classical anchor. The status quo, plain RSA and elliptic curves, remains the baseline every path gets measured against.

The choice matters because key exchange is the part of post-quantum cryptography that cannot wait. Anyone recording encrypted traffic today can try to decrypt it later. If you already know the RSA vs ML-KEM size comparison, skip ahead to the specs table. If not, the sections below walk through each path in order, with the October 2026 status of every standard and draft that touches it.

Don't miss new tech stories on Google

Add Shattered once in the Google app and our stories show up in your news suggestions.

Add now

Quantum-Resistant Encryption in October 2026: Where Standards Stand #

Start with what is final in post-quantum cryptography. NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) on August 13, 2024. ML-KEM defines three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. Migration guidance dated October 18, 2026 describes ML-KEM as the principal agreed post-quantum key-encapsulation mechanism and recommends ML-KEM-768 or ML-KEM-1024 where appropriate. NIST itself says that organizations should apply the finalized standards now and migrate systems that depend on quantum-vulnerable public-key cryptography.

Next, what is not final. NIST IR 8547 is still an initial public draft. Any article that states RSA is banned in 2035 as fact is overselling a proposal. The HQC backup algorithm is also not yet a standard, and current guidance expects its final standard in 2027. HQC complements ML-KEM. It does not replace it.

The IETF has done the most visible work in the last few months. RFC 9935, published in March 2026, defines X.509 algorithm identifiers for ML-KEM, so certificates and PKI tooling can now carry ML-KEM keys. Drafts cover TLS 1.3 groups, IKEv2, JOSE and CMS. None of these drafts amounts to an adopted standard until it clears the IETF process, and several remain in review as of this week. Libraries move faster than standards bodies. Current migration guidance says ML-KEM can be deployed through OpenSSL 3.5 or later, Go 1.24 or later, BoringSSL and rustls, subject to whatever validation requirements apply to you.

That gap between final in NIST and final in every protocol is why the rollout path matters. A path that works for a public web server may be impossible for a smart card, a signed email, or a Kerberos realm. The IETF draft landscape in October 2026 splits cleanly into three families, and each family maps to one rollout path in this comparison. The ML-KEM-768 and ML-KEM-1024 choice also feeds into which path you pick, because higher-strength hybrids have their own drafts. Here is how the field looks before any deployment judgment.

Final and citable: FIPS 203, FIPS 204, FIPS 205 (all August 13, 2024) and RFC 9935 for ML-KEM in X.509 (March 2026).
Draft or in review: the NIST IR 8547 timeline, the standalone ML-KEM TLS group document, the ML-KEM-1024/X448 hybrid (dated October 9, 2026), the composite ML-KEM drafts for X.509 and CMS, and the IKEv2, Kerberos and JOSE drafts.
Expected later: the HQC standard, which guidance puts at 2027.

Anyone choosing a path should read the status column of every claim, not just the headline. The sections that follow keep final and draft material separate, and the verdict at the end ranks the paths on that basis.

Why Key Exchange Moves First and RSA and ECC Stay Behind #

RSA-2048 is not post-quantum safe, and guidance from several sources says so without hedging. Elliptic-curve cryptography (ECDH, ECDSA, EdDSA) sits in the same bucket. A sufficiently capable quantum computer running Shor’s algorithm would break the factoring and discrete-logarithm problems both schemes rely on. Today ECC is not broken by any quantum machine, and RSA is not broken either. The risk is about the future value of data captured now.

That is why key establishment gets attention before signatures. An attacker who records an encrypted session today and decrypts it years later wins even if the signature on the handshake was valid at the time. A forged signature, by contrast, only matters while the attacker can use it live. The ordering is analysis, not a NIST rule, but it drives the sequencing in nearly every migration plan published this year.

The status quo also has a history of its own. Plain RSA key exchange was already on its way out of TLS before quantum came up, a story told in the RSA key exchange versus ECDHE breakdown. A JOSE draft updated on October 16, 2026 goes further for one legacy mode. It states that NIST has disallowed RSAES-PKCS1-v1_5 for federal use since the end of 2023, and it proposes deprecating the RSA1_5 algorithm for new protocols and deployments. That is a draft proposal, not a final IETF standard. It does show how legacy RSA modes are getting squeezed from two directions, classical weaknesses and quantum planning.

Elliptic curves had a second piece of news this month. Researchers reportedly reconstructed where the random seeds behind the NIST elliptic-curve parameters came from, apparently tracing them to conventional pseudorandom generation from 1997 and 1998. The write-up on the NIST curve seeds bounty covers the claim in detail. Reports did not establish a backdoor, and the finding does not directly break commonly used secp256k1 deployments. Treat it as a transparency result, not a break. Read it as one more argument for planning the move away from classical curves on an orderly schedule, not for panic.

One point trips up buyers. RSA the algorithm and RSA Security the company are different things. RSA Security sells identity products, and its published pricing for RSA ID Plus reportedly lists $3, $5 and $7 per user per month across three tiers. Those prices have nothing to do with the cost of the RSA algorithm, which is a public-key scheme anyone can implement. The research behind this comparison also found no RSA Security post-quantum migration product announced in the past three months.

For a deeper look at the lattice side of that trade, the ML-KEM against RSA at the parameter level piece covers key and ciphertext sizes. The rest of this comparison treats RSA and ECC as the post-quantum cryptography baseline: widely deployed, universally compatible, quantum-vulnerable, and on a draft retirement clock that starts after 2030.

Path 1: Hybrid ML-KEM With X25519 for TLS #

Hybrid key exchange runs two key agreements at once and mixes the results. The widely discussed pairing is X25519MLKEM768, which combines the classical X25519 curve with ML-KEM-768. If someone breaks the lattice math, X25519 still protects the session against classical attackers. If a quantum computer breaks X25519, ML-KEM still protects it. An attacker needs to defeat both. IETF work in 2026 favors this pattern, and guidance from October describes hybrid mode as the practical deployment path today.

The hybrid path also fits existing software. Servers keep the TLS 1.3 handshake shape and add a named group. Clients that do not know the group fall back to X25519 or another classical choice. That fallback is the reason hybrid has become the first quantum-resistant encryption most users touch, usually without noticing.

How the Hybrid Groups Work

One report says RFC 10024 was published in August 2026 and standardizes three hybrid TLS 1.3 groups: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. Treat that as a reported detail and check the RFC Editor index before citing it in a compliance document. The same report says the IESG approved the draft as Informational and marked the groups “Recommended: N”, which tells you the IETF is still cautious about pushing any single hybrid on the whole internet. For the P-256 side of the pairing, see the X25519 versus P-256 comparison.

For performance questions, the ML-KEM versus X25519 TLS 1.3 test covers handshake costs. The key point for planning is structural. ML-KEM key shares are larger than X25519 key shares, so the first flight of a handshake grows. Middleboxes that mishandle larger ClientHello messages are the usual source of trouble, not the cryptography itself. Test through your real network path before flipping a default.

The Higher-Security Variant: ML-KEM-1024 With X448

An Internet-Draft dated October 9, 2026 specifies a hybrid of ML-KEM-1024 and X448 for TLS 1.3. It targets a higher security level than X25519MLKEM768. It is a draft, not an adopted standard, and nothing in the current material confirms a deployment plan for it. If your policy demands the largest ML-KEM parameter set, this is the draft to track, but production traffic today uses the smaller hybrid.

Google Cloud is the clearest example of hybrid going default. According to a GRCLens write-up on post-quantum TLS and hybrid key exchange, Google Cloud load balancers enable X25519MLKEM768 by default beginning in October 2026, with an opt-out through October 2027. That is a secondary report, so confirm against Google’s own documentation before you plan around it. If accurate, it means a large share of cloud-fronted services will negotiate hybrid groups without their owners touching a config file.

The downside of the hybrid path is cost without full payoff. You carry two algorithms, two code paths and larger handshakes, and you still depend on X25519 until you retire it. Hybrid also does nothing for your certificate chain, which still uses classical signatures. Hybrid protects confidentiality now. It does not finish the migration.

Path 2: Pure ML-KEM and the IETF Review Queue #

Pure ML-KEM removes the classical component. Key exchange then rests entirely on the module-lattice assumption behind FIPS 203. The IETF draft defines ML-KEM-512, ML-KEM-768 and ML-KEM-1024 as TLS 1.3 named groups, and its IETF announcement was a Last Call for an Informational RFC. Reporting from July 30, 2026 says the last call began that day. A separate report from late September says publication was on hold while the draft stayed in review. The draft has not changed the final status of FIPS 203, and it is not a published RFC as of this writing.

Why would anyone choose pure over hybrid? Three reasons come up. Some regulated environments want a single approved algorithm and no extra moving parts. Some constrained devices cannot afford two key agreements. And some designers see hybrid as a temporary crutch that adds attack surface, since two implementations mean two places to introduce a bug. Each argument has merit, and none is universal.

The case against pure is also three-sided. First, ML-KEM is a young standard compared with elliptic curves, which have decades of cryptanalysis behind them. A new attack on module lattices would hit pure deployments without any safety net. Second, NIST itself keeps HQC in reserve because it wants a backup that rests on a different mathematical foundation. Third, guidance from October 18, 2026 recommends combining ML-KEM with an established classical mechanism in certain deployments rather than using the lattice mechanism alone. The standard’s authors are not telling anyone to drop the classical half yet.

The HAWK episode shows why caution is reasonable. HAWK, a lattice-based signature candidate, was withdrawn from consideration on July 28, 2026. NIST states the issue does not affect finalized standards including ML-KEM and ML-DSA, which use different mathematical foundations and remain ready for implementation. One report links an AI model to finding the HAWK flaw, though that claim is unconfirmed. The lesson holds either way: lattice candidates can fall, and a design that keeps a classical fallback survives surprises better.

In practice, pure ML-KEM suits a narrow set of cases today. It makes sense for greenfield internal protocols where you control both ends, for devices where a hybrid would not fit, and for environments whose auditors require a single NIST-approved primitive. For public-facing TLS, hybrid wins on risk. Revisit the question once the TLS draft publishes as an RFC and your compliance regime says what it accepts.

Path 3: Composite ML-KEM in X.509 and CMS #

Composite keys solve a different problem than hybrid TLS. A hybrid handshake mixes two shared secrets on the wire. A composite key packs two keys into one object, so a certificate or an encrypted message carries both a classical and a post-quantum key under a single identifier. The IETF LAMPS drafts define composite ML-KEM combinations with RSA-OAEP, ECDH, X25519 and X448, one draft for X.509 and a sibling for the Cryptographic Message Syntax (CMS). One report says an October 6, 2026 revision proposed those combinations. Both remain drafts.

The appeal is operational. Many systems cannot handle two separate keys per identity. Email encryption, document signing workflows and PKI-heavy enterprise tools expect one certificate and one key. A composite key lets those tools carry a post-quantum component without changing their data model. RFC 9935 already gives X.509 the algorithm identifiers for ML-KEM, which is the groundwork. The certificate side of this story ties directly to the X.509 certificate versus Merkle tree certificate debate over how much a post-quantum chain should weigh.

OpenPGP shows the composite idea at work. Migration guidance dated October 18, 2026 says current OpenPGP post-quantum arrangements pair ML-KEM and ML-DSA with elliptic-curve components, and it cites RFC 9980 for that update. The same guidance says RSA key holders must generate new keys to use the new arrangements. In other words, elliptic curves stay relevant inside post-quantum designs for now, while old RSA keys cannot simply be upgraded in place.

The composite path carries its own risks. The drafts are still moving, so identifiers and encodings could change before publication. Library support lags behind the TLS hybrids. And a composite certificate that includes RSA-OAEP keeps an RSA component alive, which may conflict with a policy that wants RSA gone after 2030. A related COSE and JOSE draft makes a subtler point. It says RSA and ECC can serve both key-encapsulation and signature roles, whereas current post-quantum algorithms do not provide one universal replacement for both functions. Migration therefore needs separate answers for encryption and for signing.

Use composite where a single-key data model forces your hand, such as email, signed documents and enterprise PKI. Skip it for new protocols where you control the handshake, since hybrid or pure key agreement is simpler there. Whatever you pick, pin your implementation to a draft version and plan to revisit it when the RFC lands.

Specs Table: Four Approaches Side by Side #

Attribute	Status quo (RSA, ECC)	Path 1: Hybrid (X25519MLKEM768)	Path 2: Pure ML-KEM	Path 3: Composite ML-KEM
Standards basis	Long-standing RSA and elliptic-curve standards	FIPS 203 plus X25519, IETF TLS hybrid work	FIPS 203 (finalized August 13, 2024)	FIPS 203 plus LAMPS composite drafts
IETF status	Mature and deployed	Hybrid groups in IETF standardization work	Draft under IETF review	Internet-Drafts for X.509 and CMS
Named identifiers	RSA-OAEP, ECDH, ECDSA, EdDSA	X25519MLKEM768	ML-KEM-512, ML-KEM-768, ML-KEM-1024	ML-KEM with RSA-OAEP, ECDH, X25519 or X448
Quantum resistance	No, quantum-vulnerable	Yes, through the ML-KEM half	Yes	Yes, through the ML-KEM component
Survives a lattice break	Not applicable	Against classical attackers only	No	Against classical attackers only
Survives a classical break	No	Yes, through ML-KEM	Yes	Yes, through ML-KEM
Parameter sets in scope	RSA and elliptic-curve key sizes in use today	ML-KEM-768	ML-KEM-512, ML-KEM-768 and ML-KEM-1024	ML-KEM-768 and ML-KEM-1024 depending on the draft
Main protocols	All of them	TLS 1.3, IKEv2 and others	TLS 1.3, JOSE HPKE	X.509, CMS, OpenPGP-style messaging
Library support	Universal	OpenSSL 3.5 or later, Go 1.24 or later, BoringSSL, rustls	Same libraries, subject to validation	Narrower, follows draft maturity
Certificate support	Full	Does not change the certificate chain	RFC 9935 identifiers available	Designed for certificates
Fallback to classical clients	Not needed	Yes	No, client must support ML-KEM	Depends on the profile
Draft NIST IR 8547 posture	Deprecate after 2030, disallow after 2035 (draft)	Fits the transition	Fits the end state	Keeps an RSA or ECC component during transition
Main risk	Harvest-now, decrypt-later exposure	Larger handshakes, two code paths	No safety net if lattices fall	Draft churn, library gaps
Best fit	Legacy systems awaiting migration	Public TLS and VPN endpoints	Closed systems with one approved primitive	Email, signed documents, enterprise PKI

A few cells deserve a note. The lattice-break row is analysis: hybrid and composite designs keep a classical component, and that component holds against classical attackers only. No row claims any path is proven against a future quantum attack on the classical half, because X25519 and the RSA and ECDH components fall to Shor’s algorithm in the same way plain RSA and ECC do. The hybrid column lists only the one group named in verified guidance. Other reported hybrid groups appear in the Path 1 section, with the caveat that they come from a single report.

Evidence and Benchmarks: What the Sources Show #

Readers hoping for a latency chart will not find one here, and that is deliberate. The current verified source set offers no cross-path throughput or handshake-time measurements for October 2026, and inventing numbers would mislead more than it helps. What the sources do offer is evidence on maturity, status and direction, which is what decides rollout order. The table below lines up the strongest items by source type.

Source	Date	What it establishes	Effect on path choice
NIST FIPS 203	August 13, 2024	ML-KEM final with three parameter sets	All three paths rest on this standard
NIST migration guidance	Not listed	Apply finalized standards now and migrate vulnerable systems	Inaction is not a supported option
Draft NIST IR 8547 via Keyfactor and others	Reported October 6 to 7, 2026	Deprecate after 2030, disallow after 2035, still a draft	Sets the planning horizon, not a legal deadline
PQC migration guide on postquantum.com	October 18, 2026	ML-KEM-768 or 1024 recommended, OpenSSL 3.5 or later, Go 1.24 or later, BoringSSL, rustls	Library path exists for hybrid and pure
IETF RFC 9935	March 2026	X.509 identifiers for ML-KEM	Certificates can carry ML-KEM keys
IETF composite drafts	October 2026	ML-KEM combined with RSA-OAEP, ECDH, X25519, X448	Gives the composite path its design
NIST HAWK withdrawal	July 28, 2026	HAWK removed from consideration, ML-KEM and ML-DSA unaffected	Shows lattice-family risk is real but contained
IETF JOSE deprecation draft	October 15 to 16, 2026	RSA1_5 proposed for deprecation, disallowed federally since end of 2023	Legacy RSA modes are already on the way out

Adoption evidence adds a second angle. MITRE-related reporting, summarized by QuantaKrypto, said enterprise PQC adoption had reached the “Integration” stage for confidentiality in several areas, but no area had reached “Validated Integration”, which requires a FIPS 140-3-validated module. The headline of that item says authentication lags key exchange. That fits the sequencing logic above: confidentiality is moving, authentication is behind. Treat the report as a single-source summary and look at MITRE’s own text before quoting figures.

Three sources make a useful triangulation. NIST says finalized standards are ready. The IETF shows protocol work moving from standards into concrete integration across X.509, TLS hybrid work, composite combinations, JOSE, CMS, IKEv2 and Kerberos. Guidance from migration advisers says libraries are shipping. Taken together, they point to hybrid first, composite where formats force it, and pure ML-KEM once the TLS draft is published and validation catches up.

For hard performance data, run your own measurements. Measure handshake completion time and failure rate through your real load balancers, proxies and clients, with the hybrid group enabled for a slice of traffic. Compare against a classical-only control group over a full business cycle. A synthetic lab test cannot reproduce a middlebox that chokes on a large ClientHello, and that is the failure that actually breaks production.

Cost Table: What Each Path Costs to Adopt #

ML-KEM is a published standard, not a product, and the standard itself carries no official price or license fee according to the research behind this piece. The real costs sit in engineering time, testing, validation and operations. The table below ranks them as editorial estimates, not vendor quotes, so adjust to your environment.

Cost item	Status quo	Path 1: Hybrid	Path 2: Pure	Path 3: Composite
Library upgrade work	None	Low (OpenSSL 3.5 or later, Go 1.24 or later, BoringSSL or rustls)	Low to medium	Medium to high
Handshake and size overhead	Baseline	Medium, two key agreements	Medium, one larger key agreement	Medium, larger certificates and messages
Network compatibility testing	None	High, middlebox risk	High, plus client support gaps	Medium
Certificate and PKI changes	None	None	Medium (RFC 9935 identifiers)	High (composite profiles)
Compliance and validation work	Existing	Medium	Medium to high	High, drafts still moving
Rollback complexity	None	Low, fall back to classical group	High, no fallback	Medium
Exposure cost of waiting	Highest	Lowest for confidentiality	Low	Low for message confidentiality

Hardware sits in a separate cost bucket. SEALSQ’s VaultIC409 secure element was reported on October 12, 2026 as supporting ML-KEM, ML-DSA, RSA and ECC for hybrid security architectures. Reports of that kind suggest embedded vendors are shipping parts that handle both old and new algorithms, but check datasheets and certification status for any part you plan to buy. Devices already in the field will need firmware that adds ML-KEM, or a plan to replace them before the draft 2030 and 2035 dates arrive.

The largest hidden cost is inventory. You cannot price a migration until you know where RSA and ECC live in your estate: TLS terminators, VPN gateways, code-signing pipelines, SSH hosts, smart cards, message encryption, third-party SaaS. A cryptographic inventory costs staff time but cuts every later estimate. Most teams find the surprises in embedded devices and vendor-managed systems, not in the web tier.

Real-World Deployments: Six Cases From October 2026 #

Here is what is actually shipping, with the confidence level attached to each item.

Google Cloud load balancers: according to GRCLens, X25519MLKEM768 turns on by default beginning in October 2026, with opt-out through October 2027. Single secondary source, so confirm with Google.
Cloudflare GeoKey Manager: Quantum Computing Report recently reported that Cloudflare launched a post-quantum GeoKey Manager using hybrid ML-KEM-768 plus X25519 encryption for regional data sovereignty. This is a concrete commercial hybrid deployment, reported by one outlet.
OpenPGP post-quantum update: guidance dated October 18, 2026 describes RFC 9980 pairing ML-KEM and ML-DSA with elliptic-curve components, with RSA key holders needing new keys. A composite-style deployment in a widely used message format.
NIST PIV credentials: NIST published initial working drafts for post-quantum updates to the PIV standards. Follow-up material proposes a dual-stack approach that keeps existing classical keys and adds ML-KEM and ML-DSA objects for incremental migration. These remain preliminary working materials, not formal public drafts.
SEALSQ VaultIC409: a secure element reported on October 12, 2026 as supporting ML-KEM, ML-DSA, RSA and ECC. Hardware vendors are building for the transition period, not the end state.
Lazarus malware: Kaspersky reported in late October 2026 that a Lazarus-linked campaign used post-quantum encryption, and other reports describe ML-KEM protecting malware communications. Attackers adopt the standard too, which cuts both ways for defenders.

Two patterns stand out. First, every concrete deployment is hybrid or dual-stack, not pure. Nobody in this list has switched off classical cryptography. Second, the vendors with the clearest incentive, cloud platforms and edge networks, are the ones pushing hybrid defaults, and the head-to-head numbers on that are in the Cloudflare versus AWS post-quantum TLS comparison. Standards-body work is catching up to deployment, not leading it.

Tunnels are the third place hybrid shows up. IPsec and WireGuard operators face the same larger-key-share question as TLS, with different constraints on packet size and rekeying. The IETF’s IKEv2 draft for ML-KEM reportedly covers the IPsec side. The tradeoffs for WireGuard, which has no standards-track hybrid yet, are laid out in the post-quantum WireGuard versus classical WireGuard piece.

The Kerberos and constrained-device drafts show the long tail. A PKINIT draft updated on October 5, 2026 proposes ML-KEM support for Kerberos initial authentication. An EDHOC-related draft updated October 8 proposes KEM-based post-quantum authentication for lightweight protocols. IETF constrained-device guidance was reported in IESG Evaluation on October 15 with ML-KEM interfaces referenced. None of these is final, but they show ML-KEM becoming the default building block across the protocol suite.

Signatures, HQC and the Gaps That Remain #

A key-exchange migration is only half a migration. Certificates, code signing and document signing still use RSA and elliptic-curve signatures, and the post-quantum signature story is less mature. NIST finalized ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) on August 13, 2024. For the three-way comparison, the ML-KEM, ML-DSA and SLH-DSA breakdown lines up the trade-offs.

MITRE-related reporting amplified the lag, with the QuantaKrypto summary headlined authentication lags key exchange. An IETF DNSSEC strategy draft dated October 16, 2026 shows the same pattern from the protocol side. It discusses ML-DSA, Falcon, XMSS and LMS and notes implementation and testing efforts still under way. A hybrid TLS handshake does not help if the certificate on the other end is still a classical signature that a quantum machine could forge. That risk is smaller than harvest-now exposure, but it will grow as the hardware improves.

HQC fills a different gap. NIST reportedly selected it on March 11, 2025 as a backup key-encapsulation mechanism built on error-correcting codes, not lattices. Its final standard is expected in 2027, so it is not available as a replacement today. IETF drafts already exist for HQC in TLS 1.3 (dated October 15, 2026) and for IKEv2 (October 24), yet the TLS draft itself describes ML-KEM as the primary post-quantum KEM. If you want the math and performance side, the ML-KEM versus HQC comparison covers it. For rollout planning, HQC matters as insurance: crypto-agile systems can swap it in if lattices ever wobble.

Crypto-agility is the practical takeaway. Whichever path you choose, design the system so the key-exchange algorithm is a configuration choice, not a compiled-in constant. NIST is also revising the underlying key-establishment documents: after public comments on a July 2025 proposal, it decided to update SP 800-56Ar3 and revise SP 800-56Cr2. A draft of SP 800-133 Revision 3 on key generation and the TLS guidelines in SP 800-52 Revision 2 have both been through public comment this year. Every one of those documents can shift what compliance auditors expect.

Use-Case Recommendations #

Match your quantum resistant encryption path to the system, not to the headline. These six recommendations assume today’s draft and library status and should be revisited when the relevant IETF documents publish.

Public websites and APIs behind a CDN or cloud load balancer: enable hybrid X25519MLKEM768 and keep classical groups for fallback. Watch error rates, since middlebox trouble shows up here first.
Internal service meshes you fully control: hybrid first. Consider pure ML-KEM only after the TLS draft publishes and your auditors accept it. Keep a rollback switch.
VPN and IPsec gateways: follow the IKEv2 ML-KEM draft and hybrid support in your vendor’s software. Test rekeying behavior under load before a company-wide push.
Email, signed documents and enterprise PKI: track the composite ML-KEM drafts and OpenPGP’s RFC 9980 arrangement. Plan new keys for RSA holders. Do not expect in-place upgrades.
Government and federal contractors: follow NIST’s October 13 guidance to apply finalized standards, watch the PIV dual-stack work, and treat NIST IR 8547 as a planning horizon until it is final.
Embedded and long-lived devices: prefer parts and firmware that support both classical and post-quantum algorithms, since replacement cycles can outlast the draft 2030 and 2035 dates. Ask vendors about ML-KEM support and FIPS 140-3 validation status.

Teams with data that must stay secret for many years should move first, whichever path they pick. Teams whose data loses value within days can sequence later. Both groups should start the inventory now, because the inventory takes the longest and every path depends on it.

Migration Guide: Eight Steps From Inventory to Rollout #

The sequence below works for most organizations. It assumes a hybrid-first TLS rollout, with composite and pure paths handled as separate workstreams once their drafts publish.

Inventory every use of RSA and ECC. List TLS terminators, VPN gateways, SSH, code signing, smart cards, message encryption and vendor systems. Record the data lifetime of each.
Rank systems by secrecy lifetime. Data that must stay confidential for years goes first. Short-lived data goes last.
Upgrade libraries. Move to OpenSSL 3.5 or later, Go 1.24 or later, BoringSSL or rustls, depending on your stack. Check validation requirements if you need FIPS 140-3 modules.
Enable hybrid groups on a test tier. Add X25519MLKEM768 to the preferred group list, keep X25519 as the fallback, and watch handshake failures.
Test through the real network path. Run traffic through your actual proxies, firewalls and load balancers. Fix middlebox failures before widening the rollout.
Roll out in stages. Start with a small share of traffic, compare error rates against a classical control, then widen.
Plan the certificate side. Follow RFC 9935, the composite drafts and your CA’s roadmap. Plan new keys for any RSA identities in OpenPGP.
Review quarterly. Track NIST IR 8547, the TLS draft, HQC and the composite drafts, and adjust the plan as each reaches final status.

Commands for a First Test

With OpenSSL 3.5 or later, you can check whether a server negotiates the hybrid group. The second command shows the ML-KEM algorithms your build supports. For more cryptography coverage across the site, browse the cryptography section.

openssl s_client -connect example.com:443 -groups X25519MLKEM768 -brief
openssl list -kem-algorithms

On the server side, an nginx build linked against a recent OpenSSL can prefer the hybrid group and keep X25519 as a fallback. Verify the directive against your own nginx and OpenSSL versions before deploying.

ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519;

Log the negotiated group per connection so you can measure what share of real traffic uses the hybrid. Without that log, you cannot tell whether your rollout reached anyone, and you cannot compare failure rates between groups.

Pros and Cons of Each Path #

Status quo (RSA and ECC only)

Pro: universal compatibility, no engineering work, decades of cryptanalysis.
Con: quantum-vulnerable, exposed to harvest-now attacks, on a draft retirement clock after 2030.

Path 1: Hybrid ML-KEM with X25519

Pro: protects against both classical and quantum attackers, falls back to classical clients, library support exists today, matches current IETF direction.
Con: larger handshakes, two code paths, middlebox risk, no help for certificate signatures.

Path 2: Pure ML-KEM

Pro: simplest design, one approved primitive, suits constrained devices and single-algorithm policies.
Con: no safety net if lattices fall, TLS draft not yet a published RFC, clients must support ML-KEM, current guidance favors combining with a classical mechanism.

Path 3: Composite ML-KEM

Pro: fits single-key data models in email, documents and PKI, keeps a classical anchor while adding ML-KEM.
Con: drafts still change, library support lags, may keep an RSA component alive.

Read the pros and cons by data lifetime and by system type. A path that looks weak for a public website can be the only workable choice for a signed-mail workflow, and the reverse holds too.

Verdict: Hybrid First, Composite Where Formats Demand It #

Hybrid ML-KEM with X25519 wins for quantum resistant encryption on public TLS today. It is the only path that has library support, a classical fallback, concrete deployments and IETF momentum all at once. NIST’s guidance says to apply the finalized standards now, FIPS 203 has been final since August 13, 2024, and migration guidance names OpenSSL 3.5 or later, Go 1.24 or later, BoringSSL and rustls as ready paths. Waiting for a perfect standard is a choice to leave recorded traffic exposed.

Composite ML-KEM is the right answer for certificates and message formats once the LAMPS drafts publish. Pure ML-KEM waits on the TLS document and on auditors. The draft NIST IR 8547 dates of 2030 and 2035 give planning shape but no legal force, and HQC’s expected 2027 standard gives crypto-agile systems a second option. Teams that start the inventory this quarter and enable hybrid on a test tier by early 2027 will be ahead of nearly every proposed deadline. Teams that wait for the drafts to finish will start the same work later, under more pressure.

Frequently Asked Questions #

What is quantum-resistant encryption?

It means public-key algorithms designed to withstand attacks from quantum computers. NIST standardized the key-establishment member of that family, ML-KEM, in FIPS 203 on August 13, 2024, and it is meant to take over the job that RSA and elliptic-curve key exchange do today.

Is RSA-2048 safe against quantum computers?

No. RSA-2048 should not be presented as post-quantum safe. The draft NIST IR 8547 proposes deprecating RSA and ECC uses after 2030 and disallowing them after 2035, though that draft is not final.

What is the difference between hybrid and pure ML-KEM?

Hybrid ML-KEM combines ML-KEM with a classical mechanism such as X25519, so a session stays protected if either half holds. Pure ML-KEM uses only the lattice mechanism. Current guidance favors combining ML-KEM with a classical mechanism in certain deployments, and the standalone ML-KEM TLS draft is still under IETF review.

Which ML-KEM parameter set should I use?

FIPS 203 defines ML-KEM-512, ML-KEM-768 and ML-KEM-1024. Guidance dated October 18, 2026 recommends ML-KEM-768 or ML-KEM-1024 where appropriate. The widely discussed hybrid, X25519MLKEM768, uses ML-KEM-768.

Is the NIST 2030 and 2035 deadline final?

No. It comes from NIST IR 8547, an initial public draft from November 2024 with no later version confirmed. Use it as a planning horizon, not as a settled requirement.

Does HQC replace ML-KEM?

No. HQC is a code-based backup, and guidance expects its final standard in 2027. It complements ML-KEM, which remains the recommended choice.

Which libraries support ML-KEM today?

Migration guidance dated October 18, 2026 lists OpenSSL 3.5 or later, Go 1.24 or later, BoringSSL and rustls, subject to any validation requirements that apply to your environment.

Do I need new certificates for post-quantum key exchange?

Not for a hybrid TLS key exchange, which does not change the certificate chain. Certificates matter for the signature side and for composite keys. RFC 9935 defines X.509 algorithm identifiers for ML-KEM, and OpenPGP’s post-quantum update requires RSA key holders to generate new keys.

Should I wait for the final standards before migrating?

No. NIST says organizations should apply the finalized standards now. FIPS 203 is final. The pending drafts affect protocol details, not whether to start the inventory and a hybrid pilot.

source & further reading

shattered.io — original article Fine-Tune an LLM With QLoRA: 12 Steps, 90 Min [2026] Tesla 2026.38.5.6: FSD v14.3.12, 20% Faster Reaction [2026] Write Cursor Skills: 12 Steps, 45 Min [2026]