Hybrid vs Ren ML-KEM i TLS 1.3: 36x Større [2026]

IETF publiserte RFC 10024 i august 2026 og satte dermed et formelt punktum for en debatt som har pågått i TLS-arbeidsgruppen siden 2023: skal nettlesere og servere bytte nøkler med en hybrid-kombinasjon av klassisk og kvantesikker kryptografi, eller er det på tide å stole fullt og helt på ML-KEM alene? Samme sommer sto et konkurrerende utkast, draft-ietf-tls-mlkem, i IETF-vidt Last Call med frist 13. august 2026. Det utkastet fjerner den klassiske komponenten helt. Begge løsningene bruker samme underliggende algoritme, ML-KEM, standardisert av NIST som FIPS 203. Forskjellen ligger i hva som faktisk skjer i TLS 1.3-håndtrykket når klient og server bytter nøkler. Cloudflare melder at rundt 52 prosent av trafikken til nettverket allerede bruker den hybride varianten X25519MLKEM768, mens ren ML-KEM fortsatt er nesten fraværende i produksjon. Denne sammenligningen går gjennom byte for byte hva forskjellen koster i håndtrykk-størrelse, hvilke ytelsestall Cloudflare, Google og NIST har målt, og hvilken variant norske og nordiske virksomheter bør velge når post-kvante TLS går fra anbefaling til krav.

Hva er ML-KEM, og hvorfor TLS 1.3 må bli kvantesikker

ML-KEM står for Module-Lattice-Based Key-Encapsulation Mechanism. Algoritmen bygger på CRYSTALS-Kyber, som NIST omdøpte da den ble et offisielt utkast. NIST publiserte den endelige versjonen som FIPS 203, og i 2026 regner myndigheten FIPS 203 sammen med signaturstandardene FIPS 204 (ML-DSA) og FIPS 205 (SLH-DSA) som selve grunnlinjen for post-kvante kryptografi. Alle tre har status som fullverdige FIPS-standarder, på linje med AES og SHA-2, ifølge NISTs eget prosjektarkiv for post-kvante kryptografi.

Grunnen til at TLS 1.3 må endres nå, og ikke når en kvantedatamaskin faktisk finnes, handler om et angrepsmønster kjent som harvest-now-decrypt-later. En motstander kan lagre kryptert trafikk i dag og dekryptere den senere, når en tilstrekkelig kraftig kvantedatamaskin bryter dagens elliptisk kurve-kryptografi. Bankdata, helsejournaler og myndighetskommunikasjon som må holdes hemmelig i ti eller tjue år, er allerede utsatt selv om selve angrepet ligger et stykke fram i tid. Det er nettopp derfor TLS-arbeidsgruppen i IETF har brukt over tre år på å standardisere hvordan ML-KEM skal kobles inn i nøkkelutvekslingsdelen av håndtrykket, altså der klient og server blir enige om en felles hemmelig nøkkel før selve datatrafikken krypteres.

ML-KEM finnes i tre parametersett. ML-KEM-512 tilsvarer om lag AES-128 i sikkerhetsnivå, ML-KEM-768 tilsvarer AES-192, og ML-KEM-1024 tilsvarer AES-256. Nesten all produksjonstrafikk i 2026 bruker ML-KEM-768, fordi det treffer en balanse mellom nøkkelstørrelse og sikkerhetsmarginal som passer for vanlig nettlesertrafikk. Det er også ML-KEM-768 som ligger i bunnen av begge løsningene denne artikkelen sammenligner: den hybride varianten X25519MLKEM768 og det rene ML-KEM-utkastet. NIST beskriver selv de fullstendige tallene for nøkkel- og cifferstørrelser i FIPS 203-dokumentet, og det er nettopp disse tallene, ikke estimater eller avrundinger, som ligger til grunn for sammenligningene i denne artikkelen.

Det er verdt å minne om hvorfor akkurat nøkkelutveksling er den første delen av TLS som byttes ut, og ikke signaturene. En kvantedatamaskin som kjører Shors algoritme, kan i teorien bryte den matematiske hemmeligheten bak både ECC-baserte signaturer og ECC-baserte nøkkelavtaler. Forskjellen ligger i når skaden skjer. En signatur beviser at en melding kom fra riktig avsender akkurat i det øyeblikket den ble verifisert, og en fremtidig kvantedatamaskin kan ikke gå tilbake og forfalske en signatur som allerede er godtatt. En nøkkelutveksling derimot beskytter innholdet i en samtale for alltid, eller i hvert fall så lenge innholdet er hemmeligholdt. Dermed haster det mer å bytte ut nøkkelutvekslingen enn signaturene, og det er nøyaktig denne prioriteringen NIST og IETF har fulgt siden 2022.

Hybrid ML-KEM forklart: X25519MLKEM768 i praksis

Hybrid ML-KEM kjører to nøkkelutvekslinger samtidig i ett og samme TLS 1.3-håndtrykk. Klienten genererer både en klassisk X25519-nøkkel og en ML-KEM-768-nøkkel, pakker begge inn i key_share-utvidelsen i ClientHello, og sender dem i samme melding. Serveren svarer med sin egen X25519-nøkkel og en ML-KEM-ciphertekst. Begge parter kombinerer så de to hemmelige verdiene til én felles nøkkel gjennom en nøkkelavledningsfunksjon. Resultatet er sikkert bare hvis minst én av de to underliggende algoritmene holder. RFC 10024, som ble publisert som Proposed Standard i august 2026, formaliserer nettopp denne konstruksjonen under navnet Post-Quantum Traditional Hybrid Key Agreement, og RFC 9954 fra juli samme år beskriver det generelle designmønsteret som ligger til grunn.

Kostnaden er synlig i byte. Der en ren X25519-utveksling sender 32 byte fra hver part, sender hybrid-varianten 1216 byte fra klienten (32 byte X25519 pluss 1184 byte ML-KEM-768-nøkkel) og 1120 byte fra serveren (32 byte X25519 pluss 1088 byte ciphertekst). Det er en økning på rundt 36 ganger i selve nøkkelutvekslingen, og økningen er stor nok til at ClientHello-meldingen som regel må splittes i to nettverkspakker i stedet for én, ifølge Cloudflares egen dokumentasjon om post-kvante kryptografi. Likevel er hybrid-modellen i dag standardvalget hos så godt som alle store aktører nettopp fordi den ikke krever at man stoler blindt på en algoritme som er under ti år gammel.

Navnet X25519MLKEM768 følger en fast navnekonvensjon i IETF: den klassiske kurven først, deretter den post-kvante algoritmen, satt sammen uten bindestrek. Samme mønster går igjen i andre hybridgrupper som er under arbeid, som SecP256r1MLKEM768 for miljøer som krever NIST-godkjente kurver fremfor X25519, og SecP384r1MLKEM1024 for de strengeste sikkerhetsnivåene. Alle disse deler den samme grunnkonstruksjonen: kjør begge algoritmene, kombiner resultatene, og la sikkerheten hvile på den sterkeste av de to.

Ren ML-KEM forklart: utkastet som dropper klassisk krypto

Der hybrid-modellen kjører to algoritmer parallelt, fjerner ren ML-KEM den klassiske komponenten helt. draft-ietf-tls-mlkem definerer tre nye NamedGroups for TLS 1.3: ML-KEM-512, ML-KEM-768 og ML-KEM-1024, uten noen tilknyttet X25519- eller P-256-nøkkel. IESG utstedte IETF-vidt Last Call for utkastet 30. juli 2026, med frist for siste kommentarer 13. august, og en beslutning ventes kort tid etter. Målet med spesifikasjonen er å gi implementører et enklere alternativ når de fullt ut stoler på ML-KEM, uten overhead fra en algoritme de uansett ikke lenger regner som nødvendig sikkerhetsnett.

Byte-messig er ren ML-KEM-768 faktisk litt mindre enn hybrid-varianten. Klientens nøkkel er 1184 byte og serverens ciphertekst er 1088 byte, til sammen 2272 byte mot 2336 byte for X25519MLKEM768. Forskjellen er beskjeden, rundt 64 byte, siden det meste av overheaden uansett kommer fra selve ML-KEM-nøkkelen og ikke fra den lille X25519-komponenten. Den egentlige fordelen med ren ML-KEM ligger derfor ikke i håndtrykk-størrelse, men i enklere kode: én algoritme å implementere, teste og vedlikeholde, i stedet for to som må kombineres riktig. postquantum.com oppsummerer kjernen i uenigheten presist: kampen mellom ren og hybrid ML-KEM handler i bunn og grunn om hvem som tar tapet dersom det en dag dukker opp en ukjent svakhet i ML-KEM.

Argumentet for å fjerne den klassiske komponenten er ikke bare estetisk. Hver ekstra algoritme i et TLS-bibliotek er også en ekstra kilde til implementasjonsfeil, sidekanalsårbarheter og vedlikeholdsbyrde over tid. Kryptografer som forsvarer ren ML-KEM, peker gjerne på at X25519 selv en gang var det nye, uprøvde alternativet til RSA, og at bransjen til slutt måtte stole på det for at nøkkelutvekslingen skulle bli enklere og raskere. De mener ML-KEM fortjener samme tillit etter tre år med offentlig kryptoanalyse under NISTs standardiseringsprosess, uten at noen har funnet praktiske angrep mot algoritmen. Motargumentet, som de fleste store TLS-biblioteker fortsatt følger i 2026, er at tre år er kort tid sammenlignet med de over tjue årene X25519 har blitt testet i offentligheten.

Denne uenigheten gjenspeiler seg også i hvem som driver de to utkastene. RFC 10024 er allerede en vedtatt standard med bred konsensus bak seg, mens draft-ietf-tls-mlkem fortsatt samler innspill fra implementører og sikkerhetsforskere om nøyaktig hvilke advarsler og bruksbegrensninger som bør følge en ren PQ-løsning. Flere av kommentarene i den offentlige IETF-diskusjonen har handlet om hvordan man tydelig skal advare mot å bruke ren ML-KEM i systemer med lang levetid, nettopp fordi konsekvensene av en fremtidig svakhet blir langt større der enn i kortlevde tilkoblinger.

Spesifikasjoner side om side: hybrid mot ren ML-KEM

Egenskap	Hybrid ML-KEM (X25519MLKEM768)	Ren ML-KEM-768
Standard / status	RFC 10024, Proposed Standard (aug. 2026)	draft-ietf-tls-mlkem, IETF Last Call (jul.–aug. 2026)
Algoritmekombinasjon	X25519 + ML-KEM-768	Kun ML-KEM-768
Klientens nøkkeldel	1216 byte	1184 byte
Serverens nøkkeldel/ciphertekst	1120 byte	1088 byte
Totalt nøkkelutveksling	~2336 byte	~2272 byte
Økning vs. klassisk X25519 (64 byte)	~36x	~35x
Sikkerhetsmodell	Krever brudd på både ECC og ML-KEM samtidig	Krever kun brudd på ML-KEM
Server-ops/sek (Cloudflare-benk, Kyber768-tall)	~70 000 (ML-KEM) i tillegg til ~17 000 (X25519)	~70 000
Nettleserstøtte som standard (2026)	Chrome 124+, Firefox 132+, Edge	Ingen større nettleser som standard
CDN-støtte i produksjon	Cloudflare (siden okt. 2022), Akamai Enhanced TLS	Ingen store CDN-er i produksjon per 2026
Anbefalt av NIST NCCoE (SP 1800-38C)	Ja, som overgangsvalg	Ikke vurdert som hovedvalg ennå
ClientHello splittes i to pakker	Ja, som regel	Ja, som regel
Bibliotekstøtte (2026)	OpenSSL, BoringSSL, s2n-tls, wolfSSL	Delvis, avhenger av utkast-versjon

Tabellen viser hvorfor hybrid fortsatt dominerer til tross for en marginalt større nøkkelutveksling: modenheten i standard, bibliotek og nettleserstøtte er rett og slett langt foran. Ren ML-KEM er teknisk sett den enklere løsningen, men den mangler ennå den brede produksjonstestingen som hybrid-varianten har samlet siden Cloudflare begynte å rulle den ut i 2022. Legg også merke til at forskjellen i rå håndtrykk-størrelse mellom de to er liten, rundt 64 byte for ML-KEM-768-varianten, mens forskjellen i økosystemstøtte er enorm. Det er sjelden man ser et så tydelig gap mellom den tekniske spesifikasjonen og den praktiske tilgjengeligheten i kryptografi.

Ytelse og benchmarks: hva målte Cloudflare, Google og NIST

Tre uavhengige kilder har publisert konkrete ytelsestall for ML-KEM i TLS 1.3, og alle tre peker i samme retning: den ekstra sikkerheten koster nesten ingenting i praksis, selv om håndtrykket blir mange ganger større i byte.

Kilde	Metrikk	Resultat
Cloudflare (blog.cloudflare.com/post-quantum-for-all)	Server-operasjoner per sekund, X25519	~17 000
Cloudflare (blog.cloudflare.com/post-quantum-for-all)	Server-operasjoner per sekund, Kyber768/ML-KEM-768	~70 000
Google Chrome-teamet (blog.google/chromium)	Median økning i håndtrykk-forsinkelse med hybrid Kyber	~4 %
NIST (csrc.nist.gov, “Building Post-Quantum Cloud Services”)	CPU-ytelse PQ-hybrid vs. klassisk på AWS c6i.xlarge	8–10x raskere
NIST (samme presentasjon)	PQCs andel av total responstid, median ~107 ms	~0,1 %
NIST NCCoE, SP 1800-38C (utkast)	Håndtrykktid, P-256+Kyber-512 vs. X25519 alene	Minimal målbar forskjell

Google Chrome-teamet forklarer selv hvorfor forsinkelsen oppstår: en Kyber-nøkkelutveksling sender rundt 1 kilobyte per part, mot 32 byte for X25519 alene, og den ekstra størrelsen fører til at ClientHello må splittes i to pakker på nettverksnivå. Det er splittingen, ikke selve krypteringsberegningen, som står for mesteparten av den målte forsinkelsen på 4 prosent. NIST sine tall fra AWS-instanser viser noe som overrasker mange: ML-KEM er faktisk raskere å regne ut enn klassisk elliptisk kurve-kryptografi på moderne prosessorer, fordi gitterbaserte operasjoner egner seg godt for vektorisering. CPU-kostnaden er derfor ikke problemet med post-kvante TLS. Det er de ekstra kilobyten på nettverket som gir den lille forsinkelsen brukerne av og til merker.

Det er en nyanse verdt å ta med seg fra NISTs prosjektside for post-kvante kryptografi: forsinkelsestallene over gjelder i hovedsak nye, fullstendige håndtrykk. TLS 1.3 gjenbruker sesjoner så ofte det lar seg gjøre, gjennom en mekanisme kalt session resumption, der klient og server gjenbruker en tidligere fremforhandlet nøkkel uten å kjøre en ny nøkkelutveksling i det hele tatt. For en typisk bruker som besøker samme nettsted flere ganger i løpet av en økt, treffer den ekstra kostnaden fra ML-KEM derfor bare et fåtall av de faktiske tilkoblingene, ikke hver eneste forespørsel.

Et siste moment fra benchmarkene fortjener oppmerksomhet: forskjellen mellom laboratorietester og målinger i faktisk internett-trafikk. I kontrollerte labforhold har enkelte studier funnet at hybrid post-kvante nøkkelutveksling kan øke oppsettstiden for en tilkobling med mellom 10 og 20 prosent, mens den samme effekten nesten forsvinner når man måler på ekte internett-trafikk hos Cloudflare, Google og Apples iCloud Private Relay. Grunnen er at vanlig nettverksforsinkelse, TCP-oppstart og andre faktorer allerede dominerer bildet, slik at noen hundre ekstra mikrosekunder fra ML-KEM knapt er målbare i sluttbrukeropplevelsen.

Cloudflare har også advart om en grense man ikke bør nærme seg: i en tidligere analyse fra 2024 fant selskapet at når nøkkelutvekslingen nærmer seg 9 kilobyte, øker forsinkelsen med rundt 15 prosent, og krysser man 10 kilobyte, risikerer man en hel ekstra rundtur på nettverket, med et forsinkelsestap på over 60 prosent. Både hybrid X25519MLKEM768 og ren ML-KEM-768 ligger trygt under 2,5 kilobyte, langt fra denne grensen. Det er først når man kombinerer ML-KEM-1024 med større klassiske kurver som P-384 eller P-521, slik enkelte wolfSSL-konfigurasjoner med SecP521r1MLKEM1024 gjør, at man begynner å nærme seg tall som er verdt å måle nøye.

Sikkerhetsmodellen: hvorfor bransjen fortsatt velger hybrid

Sikkerhetsargumentet for hybrid-modellen er enkelt å forstå og vanskelig å avfeie. ML-KEM er en relativt ung algoritme sammenlignet med X25519, som har vært gjenstand for kryptoanalyse i over et tiår uten alvorlige svakheter. OpenSSL Corporation formulerer selskapets holdning kort og direkte: “The default is hybrid.” Med det sikter selskapet til at et post-kvante-algoritme og en klassisk algoritme kjøres sammen, og resultatene kombineres, slik OpenSSL selv beskriver konstruksjonen: “A post-quantum algorithm and a classical one run together, results combined.” Om ML-KEM skulle vise seg å ha en svakhet ingen har oppdaget ennå, faller sikkerheten tilbake på den velprøvde X25519-komponenten. Beskrivelsen av ren ML-KEM er tilsvarende presis fra samme kilde: “The classical component removed,” altså at nettopp den sikkerhetsmarginen forsvinner når man går for den rene varianten.

IETF-arbeidsgruppen som står bak RFC 10024, formulerer målet med konstruksjonen slik i utkastet som lå til grunn for standarden: “The goal of this approach is to provide security against both classical and quantum adversaries while maintaining compatibility with existing infrastructure and protocols.” Det er nettopp denne doble sikringen, mot både klassiske og kvantebaserte angrep samtidig, som gjør hybrid til default hos Cloudflare, Chrome, Firefox og Akamai i 2026. Et separat IETF-utkast som analyserer risikoen ved rene post-kvante-algoritmer konkluderer enda mer direkte: “Our observation is that hybrid key establishment is preferable over standalone ML-KEM until a powerful CRQC exists which breaks most bits of pre-quantum.” CRQC står for en kryptografisk relevant kvantedatamaskin, altså en maskin kraftig nok til faktisk å true dagens ECC-kryptografi. Så lenge en slik maskin ikke finnes, mener forfatterne at hybrid er det tryggeste valget, selv om det koster noen ekstra byte og mikrosekunder.

Denne typen forsiktighet er ikke unik for TLS. Samme logikk styrer hvordan bransjen har innført andre nye kryptografiske primitiver historisk: man kombinerer det nye med det velprøvde helt til det nye har bevist seg over tid, og fjerner først det gamle når tilliten er godt nok forankret gjennom faktisk drift i stor skala. For ML-KEM anslår flere av kildene i denne artikkelen at det vil ta minst frem til slutten av tiåret før den rene varianten kan regne med samme brede tillit som hybrid-varianten allerede har opparbeidet seg.

Kostnad og infrastruktur ved utrulling

Verken ML-KEM eller X25519 koster penger som sådan, algoritmene er åpne og lisensfrie. Kostnaden ligger i båndbredde, CPU-tid og hvor mye kode team må vedlikeholde. Tabellen under samler de reelle driftskostnadene ved å velge det ene fremfor det andre, basert på tallene fra Cloudflare og NIST over.

Ressurs	Hybrid ML-KEM	Ren ML-KEM
Ekstra båndbredde per håndtrykk	~2,27 KB	~2,21 KB
CPU-kostnad per tilkobling	Lavere enn X25519 alene, siden ML-KEM-operasjonen er raskere enn ECC-operasjonen den erstatter	Lavest, kun én algoritme kjøres
Kodekompleksitet og angrepsflate	Høyere, to algoritmer må implementeres og vedlikeholdes riktig	Lavere, én algoritme
Krav til TLS-bibliotek (2026)	Dekket av OpenSSL 3.2+, BoringSSL, s2n-tls, wolfSSL	Krever støtte for draft-ietf-tls-mlkem, færre biblioteker klare
Samsvar med CNSA 2.0 / overgangskrav	Akseptert overgangsløsning i amerikanske myndighetskrav	Ikke fullt dekket av gjeldende overgangsveiledning ennå
Driftsrisiko ved feilkonfigurasjon	Lav, klassisk komponent gir fallback	Høyere, ingen fallback om ML-KEM-implementasjonen har feil

For de fleste virksomheter er den reelle kostnadsforskjellen liten. Ekstra båndbredde på et par kilobyte per nytt håndtrykk er ubetydelig for de fleste driftsbudsjett, og TLS-sesjonsgjenopptak gjør at fullstendige håndtrykk uansett skjer sjelden per bruker. Den kostnaden som faktisk teller, er personaltid: å teste, overvåke og eventuelt feilsøke to algoritmer i produksjon tar mer tid enn å overvåke én. Det er nøyaktig den avveiningen sikkerhetsteam må gjøre når de vurderer om de skal vente på ren ML-KEM eller gå videre med hybrid allerede nå.

For virksomheter med svært høyt trafikkvolum, som store nettbanker eller offentlige portaler med millioner av daglige økter, kan CPU-effekten likevel telle i praksis. Her er nettopp Cloudflares og NISTs tall nyttige: fordi ML-KEM-operasjoner er raskere enn de klassiske ECC-operasjonene de kommer i tillegg til, øker ikke den totale CPU-belastningen nevneverdig selv når man går fra ren klassisk kryptografi til hybrid. Enkelte team har faktisk rapportert lavere total CPU-bruk etter overgang, ganske enkelt fordi ML-KEM-delen av beregningen er så effektiv at den kompenserer for at man nå gjør to nøkkeloperasjoner i stedet for én.

Slik ligger utrullingen an i 2026: nettlesere, CDN-er og skytjenester

Utrullingen av hybrid ML-KEM har gått raskere enn de fleste post-kvante-standarder pleier å gjøre, mens ren ML-KEM fortsatt er i tidlig fase. Det skyldes delvis at store aktører begynte å eksperimentere med hybridkombinasjoner allerede før noen offisiell RFC forelå, basert på tidlige utkast og den forløperen som het CECPQ2 hos Google. Da FIPS 203 endelig ble ferdigstilt og RFC 10024 fulgte etter, hadde altså store deler av industrien allerede års erfaring med å drifte hybrid post-kvante TLS i produksjon. Seks konkrete eksempler viser hvor langt de to variantene faktisk har kommet.

Cloudflare: Har tilbudt hybrid post-kvante nøkkelutveksling til alle nettsteder og API-er som går gjennom TLS 1.3 på nettverket siden oktober 2022. X25519MLKEM768 er i dag den anbefalte gruppen, mens det eldre X25519Kyber768Draft00 er avviklet. Cloudflare rapporterer at rundt 43 prosent av menneskegenerert trafikk brukte hybrid PQ-nøkkelutveksling i midten av september 2025, og andelen hadde steget til rundt 52 prosent innen slutten av samme år.
Google Chrome: Aktiverte hybridisert Kyber-støtte som standard fra versjon 124 i april 2024, senere oppdatert til ML-KEM. Chrome-teamet publiserte selv målingen av den 4 prosent store medianøkningen i håndtrykk-forsinkelse som fulgte med.
Mozilla Firefox: Aktiverte X25519MLKEM768 som standard fra versjon 132 i november 2024, og har siden utvidet støtten til å gjelde QUIC og HTTP/3 i tillegg til vanlig TLS 1.3.
Akamai Enhanced TLS: Aktiverte post-kvante kryptografi som standard for leddet mellom klient og Akamai-kant i første kvartal 2026, og meldte i august 2026 at hele veien, inkludert Akamai-til-Akamai-trafikk, nå har fullverdig post-kvante beskyttelse.
AWS-miljøer og s2n-tls: NIST sin egen presentasjon om post-kvante skytjenester bruker AWS-instanser av typen c6i.xlarge som testgrunnlag, og viser hybrid ML-KEM i praktisk drift med lav målt overhead.
wolfSSL: Tilbyr hybridgrupper som SecP521r1MLKEM1024 direkte som kommandolinjevalg i TLS 1.3-håndtrykk, og markedsfører støtte for CNSA 2.0-kravene til amerikanske myndigheter.

Mønsteret er tydelig: alle de store aktørene som faktisk har rullet ut post-kvante TLS i produksjon, har landet på hybrid, ikke ren ML-KEM. Det skyldes ikke at ren ML-KEM er teknisk dårligere, men at standarden rett og slett er yngre. draft-ietf-tls-mlkem nådde IETF-vidt Last Call først i slutten av juli 2026, mens hybrid-varianten har vært under aktiv utrulling siden 2022 og fikk sin formelle RFC-status først i august 2026, lenge etter at industrien allerede hadde tatt den i bruk basert på tidligere utkast.

Et sjuende poeng verdt å nevne er origin-siden av ligningen, altså trafikken mellom en CDN og den faktiske opprinnelsesserveren bak den. Her henger utrullingen tydelig etter: analyser publisert i 2026 anslår at bare en liten andel av opprinnelsesservere globalt klarer å forhandle post-kvante nøkkelutveksling selv om andelen har åttedoblet seg siden 2023. Det betyr at mange virksomheter i praksis er beskyttet på strekningen mellom nettleser og CDN-kant, men fortsatt sårbare på strekningen videre inn til egen infrastruktur, med mindre de har oppdatert den selv.

Bruksområder: når bør du velge hybrid, og når kan ren ML-KEM vurderes

Valget mellom hybrid og ren ML-KEM avhenger mer av hvor konservativ trusselmodellen din er, og hvor lenge dataene dine må forbli hemmelige, enn av rå ytelse. En tjeneste som håndterer engangsdata med lav sensitivitet, har helt andre krav enn en bank eller et sykehus som må beskytte informasjon i flere tiår fremover. Her er seks konkrete situasjoner og hvilken variant som passer best i hver av dem.

Offentlig sektor og finans underlagt NIS2 eller tilsvarende krav: Velg hybrid ML-KEM nå. Det er den eneste varianten med formell RFC-status og bred bibliotekstøtte, og den gir en klassisk sikkerhetsmargin som revisorer og tilsyn kjenner igjen.
Langtidsarkivering og dokumenter som må holdes hemmelige i flere tiår: Hybrid er riktig valg allerede i dag, nettopp på grunn av harvest-now-decrypt-later-trusselen. Å vente på ren ML-KEM gir ingen fordel når data uansett må beskyttes fra nå av.
Offentlige nettsteder og API-er bak en stor CDN: Følg CDN-leverandørens standardvalg. Både Cloudflare og Akamai har allerede gjort hybrid til default, og det krever normalt ingen ekstra konfigurasjon fra kunden.
Interne mikrotjenester med kort levetid på dataene, i samme datasenter: Her kan man forsvarlig vente på og pilotere ren ML-KEM, siden konsekvensen av en eventuell fremtidig ML-KEM-svakhet er mindre alvorlig når dataene uansett har kort verdi over tid.
Ressursbegrensede IoT- og innebygde enheter: Vurder ren ML-KEM-512 for å spare de få hundre bytene hybrid-kombinasjonen legger på toppen, men sjekk nøye at TLS-biblioteket enheten bruker faktisk støtter det aktuelle utkastet før produksjonssetting.
Programvareleverandører som selger til amerikanske myndighetskunder: Hybrid ML-KEM er foreløpig det tryggeste valget for å dekke CNSA 2.0-relaterte krav, siden ren ML-KEM ennå ikke er like godt dekket i overgangsveiledningen.

Fellesnevneren i alle seks anbefalingene er at hybrid nesten alltid er standardvalget, og at ren ML-KEM foreløpig hører hjemme i piloter og eksperimentmiljøer heller enn i kritisk produksjon. Det kan endre seg raskt. Så snart draft-ietf-tls-mlkem blir en ferdig RFC, og minst én stor nettleser eller CDN begynner å tilby den som standard, bør sikkerhetsteam sette av tid til å evaluere den rene varianten på nytt, spesielt for de ressursbegrensede miljøene der de sparte bytene faktisk merkes.

Migreringsguide: fra klassisk ECDHE til post-kvante TLS 1.3

De fleste team trenger ikke å skrive egen kryptokode for å ta i bruk hybrid ML-KEM. Jobben består stort sett i å oppdatere biblioteker og eksplisitt sette riktig gruppe i konfigurasjonen. Slik gjør du det i praksis.

Kartlegg hvilke TLS-biblioteker og -versjoner tjenestene dine faktisk bruker i dag, og sjekk om de allerede støtter X25519MLKEM768.
Oppgrader til en versjon med hybrid-støtte: OpenSSL 3.2 eller nyere, BoringSSL, s2n-tls eller wolfSSL dekker alle X25519MLKEM768 per 2026.
Aktiver hybridgruppen eksplisitt i serverkonfigurasjonen i stedet for å stole på standardinnstillinger som kan variere mellom versjoner.
Test håndtrykket mot både nye og eldre klienter, siden enkelte eldre mellombokser og brannmurer kan feiltolke den splittede ClientHello-meldingen.
Mål faktisk håndtrykk-forsinkelse i eget nettverk før og etter, i stedet for å anta at Cloudflares og Googles tall gjelder identisk for din trafikkprofil.
Rull ut gradvis, gjerne først på interne tjenester, deretter på offentlige endepunkter med lavere trafikkvolum.
Overvåk feilrater og TLS-handshake-avbrudd nøye de første ukene, spesielt fra eldre nettverksutstyr i bedriftsnett.
Følg med på draft-ietf-tls-mlkem og vurder en pilot på ren ML-KEM først når IESG har fattet endelig beslutning og biblioteket ditt har stabil støtte.

Et eksempel på hvordan man kan teste at hybrid post-kvante nøkkelutveksling faktisk forhandles fram, er å bruke OpenSSL sitt kommandolinjeverktøy direkte mot en server som allerede støtter det, slik som Cloudflare-beskyttede nettsteder:

openssl s_client -connect eksempel.no:443 -groups X25519MLKEM768 -tls1_3

# Se etter denne linjen i utskriften for å bekrefte hybrid-forhandling:
# Server Temp Key: X25519MLKEM768

# Sammenlign håndtrykk-størrelse mot klassisk ECDHE:
openssl s_client -connect eksempel.no:443 -groups X25519 -tls1_3

Om serveren svarer med X25519MLKEM768 i den første kommandoen, er hybrid post-kvante kryptografi allerede aktivt for den tilkoblingen. Mangler den linjen, forhandler forbindelsen fortsatt ren klassisk ECDHE, og biblioteket eller serverkonfigurasjonen må oppdateres.

Vanlige feil ved overgang til post-kvante TLS

De fleste problemene team støter på under migrering til hybrid ML-KEM, skyldes ikke selve kryptografien, men nettverksutstyr og prosesser som aldri ble designet for et håndtrykk på over 2 kilobyte. Kjenner du disse fallgruvene på forhånd, går overgangen langt raskere.

Den vanligste feilen er å anta at gamle mellombokser, lastbalanserere og brannmurer håndterer den splittede ClientHello-meldingen korrekt. Enkelte eldre nettverksenheter er skrevet med en implisitt antakelse om at hele ClientHello alltid får plass i én enkelt TCP-pakke, og de feiltolker eller forkaster tilkoblinger når meldingen strekker seg over to. Dette er nøyaktig den typen feil Google observerte etter at Chrome 124 ble sluppet, med rapporterte tilkoblingsfeil fra brukere bak eldre bedriftsutstyr. Løsningen er å teste mot ekte nettverksutstyr i egen infrastruktur før man ruller ut i full skala, ikke bare i et isolert testmiljø.

Den andre vanlige feilen er å forveksle støtte i biblioteket med støtte i konfigurasjonen. Et OpenSSL-bibliotek fra 2026 kan fint støtte X25519MLKEM768 uten at gruppen faktisk er aktivert som standard i din spesifikke server- eller applikasjonskonfigurasjon. Sjekk alltid den faktiske forhandlingen med et verktøy som openssl s_client, slik beskrevet over, i stedet for å stole på versjonsnummeret alene.

Den tredje feilen er å overse origin-leddet. Selv om en tjeneste ligger bak en CDN som Cloudflare eller Akamai, og dermed får hybrid post-kvante kryptografi automatisk mellom nettleser og kant, er forbindelsen videre fra CDN til opprinnelsesserveren ofte fortsatt klassisk. Cloudflare har selv pekt på at bare en liten andel av opprinnelsesservere per 2026 klarer å forhandle post-kvante nøkkelutveksling, selv om andelen vokser raskt. Full beskyttelse krever derfor at man også oppdaterer TLS-konfigurasjonen på egne servere bak CDN-en, ikke bare stoler på at CDN-leddet dekker hele veien.

Fordeler og ulemper: hybrid ML-KEM mot ren ML-KEM

Hybrid ML-KEM (X25519MLKEM768), fordeler:

Formell status som Proposed Standard gjennom RFC 10024, publisert august 2026.
Sikkerhetsfallback til klassisk X25519 om ML-KEM skulle vise seg svak.
Bred støtte i Chrome, Firefox, Edge, Cloudflare og Akamai allerede i produksjon.
Akseptert som overgangsløsning i amerikanske CNSA 2.0-relaterte krav.

Hybrid ML-KEM, ulemper:

Litt større håndtrykk enn ren ML-KEM, om lag 64 byte mer i ML-KEM-768-varianten.
To algoritmer å implementere, teste og vedlikeholde over tid.
Noe høyere kompleksitet i kodebasen sammenlignet med én enkelt algoritme.

Ren ML-KEM, fordeler:

Enklere kodebase, kun én algoritme å implementere og vedlikeholde.
Marginalt mindre håndtrykk enn hybrid-varianten.
Enklere feilsøking, siden det kun finnes én mulig feilkilde i selve nøkkelutvekslingen.

Ren ML-KEM, ulemper:

Ingen sikkerhetsfallback om ML-KEM skulle ha en ukjent svakhet.
Fortsatt under IETF Last Call i 2026, ikke en ferdig RFC.
Svært begrenset støtte hos store CDN-er, nettlesere og skytjenester per i dag.
Ikke fullt dekket av gjeldende overgangsveiledning fra NIST og amerikanske myndigheter.

Dommen: hvilken bør norske virksomheter velge

Tallene peker i én klar retning for de aller fleste virksomheter i Norge og Norden akkurat nå: hybrid ML-KEM, altså X25519MLKEM768, er riktig valg. Standarden har formell RFC-status, biblioteker som OpenSSL, BoringSSL, s2n-tls og wolfSSL støtter den allerede, og Cloudflare-tallene viser at over halvparten av trafikken på et av verdens største nettverk allerede bruker den uten målbar nedgang i pålitelighet. Kostnaden, en håndfull ekstra kilobyte og en median forsinkelse på rundt 4 prosent ifølge Googles egne Chrome-målinger, er neglisjerbar sammenlignet med risikoen ved å la sensitive data ligge ubeskyttet mot fremtidige kvanteangrep.

Ren ML-KEM er ikke et dårlig forslag, det er bare for tidlig. Med utkastet fortsatt i IETF Last Call sommeren 2026, og uten den samme brede produksjonstestingen som hybrid-varianten har samlet siden 2022, mangler ren ML-KEM foreløpig modenheten et flertall av virksomheter bør kreve før de fjerner den klassiske sikkerhetsmarginen helt. IETF-forfatterne bak risikoanalysen av standalone ML-KEM sier det selv: hybrid er å foretrekke helt til en kraftig nok kvantedatamaskin faktisk finnes. Inntil videre er anbefalingen enkel. Aktiver X25519MLKEM768 der TLS-biblioteket ditt støtter det, følg utviklingen i draft-ietf-tls-mlkem, og vurder en pilot på ren ML-KEM først når IESG har fattet endelig beslutning og flere store aktører har fulgt etter.

Verdt å understreke til slutt: dette er ikke et valg man tar én gang for alle. TLS 1.3 gjør det mulig å tilby flere nøkkelgrupper samtidig og la klient og server forhandle seg fram til den beste felles løsningen. Norske virksomheter som aktiverer hybrid ML-KEM i år, låser seg altså ikke fast. Når ren ML-KEM en dag når samme modenhetsnivå som hybrid har i 2026, vil overgangen trolig innebære en enkel konfigurasjonsendring snarere enn en ny runde med grunnleggende arkitekturarbeid.

Ofte stilte spørsmål

Hva er forskjellen mellom ML-KEM og Kyber?
ML-KEM er NISTs offisielle navn på algoritmen som tidligere het CRYSTALS-Kyber. Navneendringen kom da NIST publiserte den endelige standarden som FIPS 203. Det er samme underliggende matematikk, bare med et nytt offisielt navn.

Er hybrid ML-KEM tregere enn vanlig TLS 1.3?
Ja, men marginalt. Google Chrome-teamet målte en median økning i håndtrykk-forsinkelse på rundt 4 prosent, hovedsakelig fordi den større ClientHello-meldingen må splittes i to nettverkspakker. NIST sine tall fra AWS-miljøer viser at selve regnekraften ML-KEM krever, faktisk er lavere enn for klassisk elliptisk kurve-kryptografi.

Må jeg bytte TLS-bibliotek for å bruke hybrid ML-KEM?
I de fleste tilfeller holder det å oppdatere til en nyere versjon av det biblioteket du allerede bruker. OpenSSL 3.2 og nyere, BoringSSL, s2n-tls og wolfSSL støtter alle X25519MLKEM768 per 2026, uten at du trenger å bytte bibliotek helt.

Når blir ren ML-KEM en fullverdig standard?
draft-ietf-tls-mlkem sto i IETF-vidt Last Call med frist for kommentarer 13. august 2026. IESG venter med å fatte en endelig beslutning kort tid etter det, men foreløpig har ikke utkastet formell RFC-status slik RFC 10024 for hybrid-varianten har.

Påvirker ML-KEM sertifikater og digitale signaturer i TLS?
Nei, ikke direkte. Denne sammenligningen gjelder nøkkelutvekslingsdelen av håndtrykket, ikke autentiseringen. Post-kvante signaturer håndteres av separate standarder som ML-DSA og SLH-DSA, og de første post-kvante-sertifikatene ventes ikke å bli bredt tiltrodd av nettlesere før tidligst 2027.

Støtter norske og nordiske nettsteder allerede hybrid ML-KEM?
Alle nettsteder som ligger bak Cloudflare, har tilbudt hybrid post-kvante nøkkelutveksling siden oktober 2022, og enda flere norske virksomheter får det automatisk gjennom Akamai Enhanced TLS etter at selskapet meldte full utrulling i august 2026. Nettsteder som kjører egen TLS-terminering, må selv oppdatere biblioteket sitt for å få den samme beskyttelsen.

Kan jeg kjøre både hybrid og ren ML-KEM samtidig på samme server?
Ja. TLS 1.3 forhandler gruppevalg per tilkobling, så en server kan i prinsippet tilby både X25519MLKEM768 og en ren ML-KEM-gruppe og la klienten velge. I praksis gir det liten mening før ren ML-KEM har fått bredere klientstøtte.

Hva skjer om jeg ikke gjør noe og fortsetter med kun klassisk ECDHE?
Trafikken din forblir sårbar for harvest-now-decrypt-later-angrep der data som må holdes hemmelig i flere år, kan bli lagret nå og dekryptert senere. For de fleste virksomheter uten spesielt lange konfidensialitetskrav er ikke dette akutt i 2026, men NIST og store nettleseraktører anbefaler uansett at overgangen starter tidlig, siden full utrulling på tvers av en hel infrastruktur tar tid.

Koster det noe å aktivere hybrid ML-KEM hos en CDN-leverandør?
Nei, i de fleste tilfeller ikke. Cloudflare tilbyr hybrid post-kvante nøkkelutveksling som en del av standard TLS-terminering uten ekstra kostnad, og Akamai har meldt at funksjonen er tilgjengelig for Enhanced TLS-kunder uten tillegg i prisen. Kostnaden ligger i eget arbeid med å oppdatere origin-servere, ikke i selve CDN-tjenesten.

Hybrid vs Ren ML-KEM: 36x Større TLS-Håndtrykk [2026]