Den 29 juni 2026 publicerade NIST sitt senaste vägledningsdokument om kryptoagilitet, CSWP 39upd1. En månad senare, den 28 juli, bekräftade myndigheten att en sårbarhet hade hittats i HAWK, en av kandidaterna i den pågående utvärderingen av nya postkvant-signaturer. Ingen av händelserna påverkar de redan färdigställda standarderna, men de visar något viktigt: övergången från RSA och ECDH till ML-KEM pågår just nu, mitt i produktionsmiljöer, inte i ett framtida scenario. För svenska företag och myndigheter som planerar sin kryptografi fram till 2030 är frågan inte längre om bytet ska göras, utan hur snabbt.
Den här artikeln jämför RSA och ECDH, algoritmerna som i dag skyddar nästan all krypterad trafik, mot ML-KEM, NISTs nya standard för kvantsäkert nyckelutbyte. Om du vill friska upp grunderna i hashfunktioner och kryptografiskt förtroende innan du går vidare är det en bra startpunkt. Vi går igenom nyckelstorlekar, prestandasiffror från tre oberoende källor, kostnadsbilden vid migrering, verkliga exempel på var ML-KEM redan används, och en konkret migrationsguide anpassad för nordiska förhållanden. Målet är att ge dig underlag för att fatta ett beslut som håller längre än nästa säkerhetsrevision.
Det som gör frågan brådskande för svenska bolag just nu är inte bara NIST:s tidsplan utan det faktum att EU:s NIS2-direktiv redan kräver att organisationer kan visa att de hanterar kryptografisk risk löpande, inte bara en gång vid en revision. En postkvant-plan passar rakt in i den processen. Samtidigt sitter många svenska myndigheter, banker och industribolag med infrastruktur som är tänkt att leva i tio, femton eller tjugo år, vilket gör att beslut som tas om kryptografi 2026 i praktiken låser in arkitekturval långt in på 2040-talet.
RSA och ECDH: grunden i dagens krypterade värld
RSA har burit internets kryptografi sedan 1977. Algoritmen bygger på att det är beräkningsmässigt svårt att faktorisera stora tal som är produkten av två primtal. En RSA-2048-nyckel använder en modul på 2048 bitar, vilket motsvarar 256 byte, och säkerheten vilar helt på att ingen dator kan knäcka faktoriseringsproblemet inom rimlig tid. Det har hållit i snart femtio år.
ECDH, elliptisk kurva Diffie-Hellman, löste ett annat problem: RSA:s nycklar växer snabbt när man vill höja säkerhetsnivån, medan elliptiska kurvor ger samma skydd med betydligt mindre nycklar. En ECDH-nyckel på kurvan P-256 är bara runt 65 byte okomprimerad, och varianten X25519 (Curve25519) klarar sig med endast 32 byte för både publik och privat nyckel. Det är en av anledningarna till att X25519 i dag är standardvalet för nyckelutbyte i TLS 1.3, och varför protokoll som Signal och WireGuard bygger på samma kurva.
Problemet är inte att RSA eller ECDH är dåligt konstruerade. Problemet är Shors algoritm. En tillräckligt kraftfull kvantdator skulle kunna lösa både faktoriseringsproblemet bakom RSA och det diskreta logaritmproblemet bakom ECDH i polynomisk tid, vilket gör båda algoritmerna värdelösa över en natt. NIST har därför klassat RSA, ECDH, ECDSA och EdDSA som kvantsårbara mekanismer som organisationer successivt måste ersätta, oavsett hur väl de fungerar mot klassiska attacker i dag.
Det är också värt att skilja på de två rollerna RSA och ECDH fyller. RSA kan användas både för att kryptera ett värde direkt och för att skapa digitala signaturer, medan ECDH enbart löser nyckelutbyte och behöver kompletteras med en separat signaturalgoritm, oftast ECDSA eller EdDSA. I ett vanligt TLS 1.3-handslag i dag är det nästan alltid en variant av elliptisk kurva, exempelvis X25519, som sköter själva nyckelutbytet, medan servern signerar sin del av utväxlingen med ett certifikat baserat på RSA eller ECDSA. Det är just den kombinationen, nyckelutbyte plus signatur, som en fullständig postkvant-migrering måste ersätta i två separata steg.
ML-KEM förklarat: NISTs nya standard för nyckelutbyte
ML-KEM, Module-Lattice-Based Key-Encapsulation Mechanism, blev officiell standard den 13 augusti 2024 genom FIPS 203. Algoritmen bygger vidare på CRYSTALS-Kyber, som vann NISTs postkvant-tävling, och använder strukturerade gitter (lattices) i stället för faktorisering eller elliptiska kurvor. Säkerheten grundar sig på Module-Learning-With-Errors-problemet, ett matematiskt problem som enligt dagens forskning är motståndskraftigt även mot kvantdatorer.
Samma dag publicerade NIST två relaterade standarder. FIPS 204 specificerar ML-DSA, en signaturalgoritm baserad på CRYSTALS-Dilithium. FIPS 205 specificerar SLH-DSA, en hashbaserad signaturstandard byggd på SPHINCS+. Det är en viktig distinktion att hålla isär: ML-KEM löser nyckelutbyte, medan ML-DSA och SLH-DSA löser digitala signaturer. Ett företag som migrerar sin TLS-trafik till ML-KEM har inte automatiskt löst signaturproblemet i sina certifikat, det kräver ett separat spår.
NIST är tydliga med att alla tre standarder är redo att implementeras nu. Det är inte ett forskningsprojekt eller en betaversion, utan en färdig specifikation som redan stöds av stora delar av internetinfrastrukturen, vilket vi går igenom längre ner i artikeln.
Säkerheten i ML-KEM vilar på ett problem som kallas Module-Learning-With-Errors, eller Module-LWE. Enkelt uttryckt handlar det om att lösa ekvationssystem där små, slumpmässiga felvärden har blandats in avsiktligt, vilket gör systemet olösligt utan nyckeln men ändå effektivt att beräkna med rätt nyckel. De tre parametriseringarna ML-KEM-512, ML-KEM-768 och ML-KEM-1024 justerar storleken på de underliggande matriserna för att nå säkerhetsnivå 1, 3 respektive 5, vilket är samma skala NIST använder för att jämföra postkvant-algoritmer mot klassiska AES-nycklar på 128, 192 och 256 bitar.
Teknisk jämförelse: RSA, ECDH, ML-KEM och HQC i siffror
Den mest konkreta skillnaden mellan klassisk och postkvant-kryptografi handlar om storlek. Lattice-baserade algoritmer som ML-KEM producerar betydligt större nycklar och chiffertexter än elliptiska kurvor, och kodbaserade algoritmer som HQC är ännu större. Tabellen nedan samlar de officiella siffrorna från FIPS 203 och HQC:s standardiseringsunderlag, tillsammans med etablerade värden för RSA och ECDH.
| Algoritm | Typ | NIST-säkerhetsnivå | Publik nyckel | Privat nyckel | Chiffertext | Kvantsäker | Status 2026 |
|---|---|---|---|---|---|---|---|
| RSA-2048 | Klassisk faktorisering | Motsvarar AES-112 | 256 byte | 256 byte | 256 byte | Nej | Fasas ut efter 2030 |
| RSA-3072 | Klassisk faktorisering | Motsvarar AES-128 | 384 byte | 384 byte | 384 byte | Nej | Fasas ut efter 2035 |
| ECDH P-256 | Elliptisk kurva | Motsvarar AES-128 | 65 byte | 32 byte | 65 byte | Nej | Fasas ut efter 2035 |
| X25519 | Elliptisk kurva (Curve25519) | Motsvarar AES-128 | 32 byte | 32 byte | 32 byte | Nej | Fortsatt i hybridläge |
| ML-KEM-512 | Lattice-baserad KEM | Nivå 1 | 800 byte | 1 632 byte | 768 byte | Ja | FIPS 203, färdig |
| ML-KEM-768 | Lattice-baserad KEM | Nivå 3 | 1 184 byte | 2 400 byte | 1 088 byte | Ja | FIPS 203, standardval |
| ML-KEM-1024 | Lattice-baserad KEM | Nivå 5 | 1 568 byte | 3 168 byte | 1 568 byte | Ja | FIPS 203, färdig |
| HQC-128 | Kodbaserad KEM (reserv) | Nivå 1 | 2 249 byte | 2 289 byte | 4 481 byte | Ja | Väntar på FIPS 207 |
| HQC-192 | Kodbaserad KEM (reserv) | Nivå 3 | 4 522 byte | 4 562 byte | 8 978 byte | Ja | Väntar på FIPS 207 |
| HQC-256 | Kodbaserad KEM (reserv) | Nivå 5 | 7 237 byte | 7 277 byte | 14 421 byte | Ja | Väntar på FIPS 207 |
| ML-DSA-65 | Lattice-baserad signatur | Nivå 3 | 1 952 byte | 4 032 byte | 3 309 byte (sign.) | Ja | FIPS 204, färdig |
| SLH-DSA-128s | Hashbaserad signatur | Nivå 1 | 32 byte | 64 byte | 7 856 byte (sign.) | Ja | FIPS 205, färdig |
Räkna själv på skillnaden: ML-KEM-768:s publika nyckel på 1 184 byte är cirka 4,6 gånger större än RSA-2048:s 256 byte. HQC-192 går ännu längre och blir nästan 70 gånger större än X25519 i chiffertextstorlek. Det är inte ett marginellt ingenjörsproblem, det är en strukturell förändring som påverkar bandbredd, lagring och protokolldesign i varenda system som förlitar sig på TLS, SSH eller VPN.
Kolumnen “NIST-säkerhetsnivå” i tabellen förtjänar en kort förklaring. NIST delar in postkvant-algoritmer i fem nivåer där nivå 1 ska vara minst lika svår att knäcka som AES-128 mot en kvantattack, nivå 3 motsvarar AES-192 och nivå 5 motsvarar AES-256. Det är viktigt att komma ihåg att nivåerna beskriver en säkerhetskategori, inte ett löfte om att alla algoritmer på samma nivå har identisk beräkningskostnad. Det är precis det som syns i tabellen: ML-KEM-768 och HQC-192 ligger båda på nivå 3, men HQC-192 är över åtta gånger större i chiffertext. I praktiken körs ML-KEM dessutom nästan alltid i ett hybridläge tillsammans med en klassisk kurva som X25519, snarare än ensamt. Tanken är enkel: om en okänd svaghet någon gång skulle hittas i gitterbaserade antaganden, faller anslutningen fortfarande tillbaka på det klassiska skyddet, och vice versa om en kvantdator plötsligt knäcker den klassiska delen.
Prestanda i praktiken: så mäter sig ML-KEM mot RSA och ECDH
Storlek är bara halva bilden. Det som faktiskt märks för en slutanvändare är hur lång tid en TLS-handskakning tar, och där ger tre oberoende mätningar en samstämmig bild. En koreansk studie som körde liboqs 0.15.0 på en Intel Core i7-12700 mätte RSA-2048-nyckelgenerering till en medeltid på cirka 35 millisekunder, med värstafallsvärden upp mot 129 millisekunder. X25519 landade på ungefär 0,10 millisekunder för hela nyckelutbytet. ML-KEM-768 krävde 0,1353 millisekunder för nyckelgenerering, 0,1572 millisekunder för kapsling och 0,1916 millisekunder för avkapsling, alltså storleksordningen tio gånger snabbare än RSA men något långsammare än ren X25519.
Forskningsrapporten “Bridging the Post-Quantum Production Gap” mätte liknande operationer via liboqs och fick kapslingstider på 64,90 mikrosekunder och avkapslingstider på 56,65 mikrosekunder för ML-KEM-768, siffror som ligger i linje med den koreanska studien trots olika testmiljöer. Den tredje källan, “Layered Performance Analysis of TLS 1.3 Handshakes” från 2026, mätte hela handskakningen end-to-end mot en backend med fyra kilobyte nyttolast. Ren X25519 tog 16,54 millisekunder i median. Med hybridläget X25519 plus ML-KEM-512 ökade tiden till 20,26 millisekunder, en ökning på 22,5 procent. Med X25519 plus ML-KEM-768 blev ökningen 18,7 procent, till 19,63 millisekunder.
| Mätning | Klassisk algoritm | Postkvant / hybrid | Resultat | Källa |
|---|---|---|---|---|
| Nyckelgenerering | RSA-2048: ~35 ms medel | ML-KEM-768: 0,1353 ms | ML-KEM cirka 10x snabbare | Koreansk liboqs-studie, i7-12700 |
| Nyckelutbyte | X25519: ~0,10 ms | ML-KEM-768 kapsling: 0,1572 ms | Jämförbar hastighet | Koreansk liboqs-studie, i7-12700 |
| Kapsling/avkapsling | – | ML-KEM-768: 64,90 / 56,65 µs | Mikrosekunder, ej millisekunder | “Bridging the Post-Quantum Production Gap” (arXiv) |
| Full TLS-handskakning | X25519 enbart: 16,54 ms | X25519+ML-KEM-768: 19,63 ms | +18,7 % latens | “Layered Performance Analysis of TLS 1.3 Handshakes” (arXiv) |
| Full TLS-handskakning | X25519 enbart: 16,54 ms | X25519+ML-KEM-512: 20,26 ms | +22,5 % latens | “Layered Performance Analysis of TLS 1.3 Handshakes” (arXiv) |
Slutsatsen från alla tre källorna pekar åt samma håll. ML-KEM är dramatiskt snabbare än RSA för nyckelgenerering, nära X25519 i ren hastighet, och lägger en latensökning på 19-23 procent när det körs i hybridläge tillsammans med klassisk kryptografi. För de flesta webbtjänster är det en overhead som märks i mätningar men knappast för en mänsklig användare som klickar en länk.
En viktig brasklapp hör till alla sådana siffror. Resultaten ovan kommer från olika processorer, kompilatorer och biblioteksversioner, och liboqs-projektets egen benchmarkdokumentation är tydlig med att dess mätningar rapporterar medelantal CPU-cykler under tre sekunders körning, inte en universell konstant som gäller för all hårdvara. En server med AVX2-instruktioner kan se betydligt snabbare ML-KEM-operationer än en äldre eller mer strömsnål processor. Slutsatsen att dra är därför riktningen, inte decimalerna: ML-KEM ligger i samma härad som klassisk elliptisk kurvkryptografi, medan RSA sticker ut som den klart tyngsta av de tre vid nyckelgenerering.
Kostnad och resursoverhead: vad kostar bytet till ML-KEM?
Ingen certifikatutfärdare eller molnleverantör publicerar i dag ett separat pris för “postkvant-kryptering”. Varken DigiCert, Sectigo, GlobalSign eller molnens nyckeltjänster som AWS KMS, Azure Key Vault och Google Cloud KMS har en egen rad på prislistan för ML-KEM eller HQC. Kostnaden är i stället inbäddad i befintlig infrastruktur: bandbredd, beräkningskraft, HSM-kapacitet och den arbetstid det tar att uppgradera system. Det är fortfarande den mest ärliga sammanfattningen man kan ge en budgetansvarig i dag.
Det går dock att kvantifiera resursoverheaden, vilket är den verkliga kostnadsdrivaren bakom en migrering. Tabellen nedan omsätter siffrorna från specifikationstabellen och prestandamätningarna till konkreta kostnadsfaktorer som en infrastrukturbudget faktiskt påverkas av. Notera att raden om CA-kostnad gäller certifikat för digitala signaturer, inte nyckelutbytet i sig, eftersom ML-KEM som KEM-algoritm inte bär ett eget certifikat på samma sätt som en RSA- eller ECDSA-nyckel gör.
| Kostnadsfaktor | RSA/ECDH (klassisk) | ML-KEM-768 (hybrid) | HQC-192 (framtida reserv) |
|---|---|---|---|
| Bandbredd per handskakning | Baslinje | +1 088 byte chiffertext | +8 978 byte chiffertext |
| Latensökning (TLS end-to-end) | Baslinje | +18,7 % | Ej publicerat, bedöms högre |
| CPU-overhead per operation | Baslinje (RSA tyngre vid keygen) | Lägre än RSA för keygen | Högre än ML-KEM enligt NIST |
| Certifikat/CA-kostnad | Standardpris, ingen PQC-premie | Inget separat PQC-pris ännu | Inget separat PQC-pris ännu |
| Dominerande migreringskostnad | – | Bibliotek, testning, personaltid | Väntar på FIPS 207 (cirka 2027) |
För de flesta organisationer landar den verkliga notan inte i licensavgifter utan i interntid: att inventera system, uppgradera TLS-bibliotek till versioner som stödjer hybridläge, och testa att gamla klienter fortfarande kan ansluta under övergångsperioden. Till det kommer indirekta kostnader som sällan syns i en IT-budget förrän projektet redan startat, som att utbilda säkerhetsteam i de nya algoritmerna, uppdatera interna riskregister, och dokumentera framstegen för revisorer under NIS2. Det är ett skäl till att NIST:s eget vägledningsdokument om kryptoagilitet, finaliserat den 29 juni 2026, lägger så stor vikt vid att bygga system som kan byta algoritm utan att byggas om från grunden.
Kryptoagilitet: arkitekturen spelar lika stor roll som algoritmen
Det mest underskattade resultatet av hela postkvant-övergången är kanske inte ML-KEM i sig, utan insikten att nästa algoritmbyte inte blir det sista. HAWK-sårbarheten som upptäcktes i juli 2026 är ett påminnande exempel: även algoritmer som genomgått flera granskningsrundor hos NIST kan visa sig ha brister innan de blir slutgiltiga standarder. System som är hårdkodade mot en specifik algoritm tvingas till en fullständig ombyggnad varje gång något sådant händer. System som är byggda med kryptoagilitet klarar bytet genom en konfigurationsändring.
NIST:s vägledningsdokument CSWP 39upd1 beskriver kryptoagilitet som förmågan att ersätta kryptografiska algoritmer, nyckellängder och protokoll utan att skriva om hela systemet. I praktiken betyder det tre saker för en infrastrukturarkitekt. Först, att separera kryptografiska operationer bakom ett gränssnitt i stället för att hårdkoda ett specifikt bibliotekskall i applikationskoden. För det andra, att låta protokoll som TLS förhandla fram vilken algoritmkombination som faktiskt används, snarare än att låsa en enda uppsättning. För det tredje, att hålla certifikat, nycklar och konfiguration i system som går att rotera i bulk, inte manuellt system för system. De organisationer som redan gjorde det arbetet inför tidigare algoritmbyten, till exempel övergången från SHA-1 till SHA-256, har ett rejält försprång nu.
Varför NIST vill ha en reserv: ML-KEM mot HQC
Den 11 mars 2025 valde NIST HQC som sin femte postkvant-algoritm. Till skillnad från ML-KEM, som bygger på strukturerade gitter, vilar HQC på kodbaserad kryptografi, en helt annan matematisk grund. Anledningen är ren riskhantering. Om ett framtida kryptoanalytiskt genombrott skulle försvaga gitterbaserade antaganden, skulle en kodbaserad reservalgoritm fortfarande stå kvar oskadad. Det är samma logik som att inte lägga alla ägg i en korg, applicerad på matematiska antaganden i stället för investeringar.
Priset för den diversifieringen syns tydligt i siffrorna. HQC-192 har en chiffertext på 8 978 byte, jämfört med ML-KEM-768:s 1 088 byte, en skillnad på över åtta gånger. HQC är dessutom långsammare att beräkna i varje led: nyckelgenerering, kapsling och avkapsling. NIST positionerar därför ML-KEM som förstahandsvalet för praktisk användning, medan HQC reserveras för scenarier där algoritmisk mångfald väger tyngre än prestanda. För ett företag som bygger sin kryptoarkitektur i dag betyder det i praktiken att HQC inte är ett alternativ att vänta på, utan en försäkring som NIST håller i bakfickan om ML-KEM någon gång skulle behöva bytas ut snabbt.
HQC är ännu inte en färdig standard. Den väntas bli FIPS 207, men enligt NIST:s egen tidsplan publiceras ett utkast för offentlig kommentar först senare, följt av en nittiodagars kommentarsperiod, med en färdig standard tidigast 2027. Falcon, en annan algoritm som valdes ut tidigt i processen, väntar på en egen standard, FIPS 206, som fortfarande är under utveckling. Ingen av dessa två bör ännu användas i produktion, de är planerade reserver, inte alternativ man kan välja i dag.
Det här mönstret, flera parallella spår som utvärderas i olika takt, är medvetet från NIST:s sida. Nyckelinkapsling (ML-KEM och HQC) utvärderas separat från signaturer (ML-DSA, SLH-DSA, Falcon/FIPS 206 och de nio kandidaterna i den extra signaturomgången), eftersom de två problemen har olika risktålighet och olika tidspress. En organisation som planerar sin kryptoarkitektur bör alltså inte vänta på att “postkvant-kryptering blir klar” som en enda milstolpe, utan räkna med att nyckelutbyte och signaturer rör sig i olika hastigheter under flera år framöver.
I maj 2026 gick NIST vidare med en helt separat utvärdering: nio ytterligare signaturkandidater avancerade till en tredje granskningsomgång, bland dem FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign och UOV. Den 28 juli 2026 rapporterade NIST att en sårbarhet hade upptäckts i just HAWK. Myndigheten var samtidigt tydlig med att fyndet inte påverkar de redan färdigställda standarderna ML-KEM, ML-DSA eller SLH-DSA, men händelsen är ett bra exempel på varför NIST kör flera parallella utvärderingsspår i stället för att lita på en enda algoritmfamilj.
Verkliga exempel: vem använder ML-KEM redan i dag
ML-KEM är inte ett teoretiskt förslag som väntar på marknadens intresse, det körs redan i produktion hos flera av internets största aktörer. Cloudflares egen SSL/TLS-dokumentation rekommenderar X25519MLKEM768 som hybrid nyckelutbyte och har registrerat TLS-identifieraren 0x11ec för kombinationen. Det är samma mönster som används när ett företag vill ha kvantskydd utan att släppa den klassiska algoritmen, vilket håller dörren öppen om en svaghet skulle upptäckas i den nya standarden.
- Cloudflare – driver X25519MLKEM768 som hybrid nyckelutbyte i sin globala TLS-infrastruktur, dokumenterat i Cloudflares egna utvecklardokument.
- Google Chrome – stödjer hybrid postkvant-TLS där ML-KEM kombineras med klassisk elliptisk kurva för webbläsartrafik.
- AWS – har infört postkvant-TLS i delar av sina molntjänster, med hybridläge som standardmetod.
- OpenSSH – moderna versioner stödjer hybrid nyckelutbyte baserat på ML-KEM-familjen för fjärranslutningar.
- Signal – kör protokollet PQXDH, ett hybridprotokoll som lägger postkvant-skydd ovanpå den klassiska nyckelöverenskommelsen.
- Apple Messages – har tillkännagivit postkvant-skydd för sin meddelandeinfrastruktur som ett led i samma övergång.
HQC saknar i dagsläget ett jämförbart produktionsexempel. Ingen av de källor vi granskat pekar på en bred, dokumenterad driftsättning av HQC i webbläsare, meddelandetjänster eller molninfrastruktur. Det bekräftar bilden ovan: ML-KEM är det praktiska valet just nu, HQC är en plan för framtiden.
Det som driver den breda anslutningen är i första hand biblioteksstöd, inte enskilda produktval. Så fort ett bibliotek som OpenSSL eller en TLS-stack på serversidan stödjer hybrid-ML-KEM som standard, ärver varje tjänst som bygger på biblioteket samma skydd utan att behöva skriva en rad egen kryptokod. Det är också skälet till att migreringskostnaden för de flesta bolag är lägre än den låter: det handlar sällan om att implementera en algoritm från grunden, utan om att uppgradera beroenden och sedan slå på en inställning.
“Harvest now, decrypt later”: hotet som driver tidsplanen
Det finns en specifik anledning till att organisationer agerar nu i stället för att vänta tills kvantdatorer faktiskt kan knäcka RSA. Krypterad trafik som avlyssnas och sparas i dag kan dekrypteras retroaktivt den dag en kvantdator blir kraftfull nog, ett scenario som brukar kallas “harvest now, decrypt later”. Data som måste hållas konfidentiell i tio, tjugo eller trettio år, exempelvis patientjournaler, försvarshemligheter eller finansiella avtal, är därför redan i riskzonen även om den aktuella kvantdatorn inte existerar förrän 2035.
NIST:s egen tidsplan sätter ord på brådskan. Algoritmer som ger en säkerhetsnivå motsvarande 112 bitar, vilket inkluderar RSA-2048, föreslås bli avrådda efter 2030 och helt otillåtna efter 2035. Algoritmer med 128 bitars säkerhet eller högre, som RSA-3072 och de flesta elliptiska kurvor i bruk i dag, får sitta kvar längre men blir otillåtna efter samma slutdatum 2035. Det ger organisationer runt nio år att genomföra en övergång som i praktiken rör nästan varenda system som hanterar kryptering.
Tänk på ett konkret, generellt exempel för att förstå varför det spelar roll redan nu snarare än 2034. Ett exportbolag som skickar krypterade avtalsförslag över VPN i dag förlitar sig troligen på RSA eller ECDH i tunneln. Om den trafiken speglas och lagras av en motpart med andra avsikter, spelar det ingen roll att avtalet undertecknades 2026, innehållet blir läsbart den dag en kvantdator kan bryta nyckelutbytet som skyddade sessionen. Ju längre konfidentialitetskravet sträcker sig, desto tidigare måste skyddet bytas, oavsett när NIST:s formella förbudsdatum infaller.
Så påverkas svenska företag, banker och myndigheter
För svenska organisationer landar frågan i flera lager samtidigt. NIS2-direktivet skärper redan kraven på riskhantering och kryptografisk hygien för tusentals svenska företag, och en formell plan för postkvant-migrering är ett naturligt tillägg till den riskbedömning som lagen redan kräver. Du kan läsa mer om de generella kraven i vår genomgång av cybersäkerhetslagen och NIS2. Myndigheter och kommuner, som ofta sitter med system som ska leva i femton till tjugo år, har särskilt starka skäl att bygga in kryptoagilitet nu snarare än att vänta på en tvingande deadline.
Bank- och betalningsinfrastruktur hör till den kategori som bär störst risk vid ett sent byte, eftersom den kombinerar långa livscykler med extremt känslig data. Det är inte en fråga om att BankID eller svenska storbanker ligger efter, snarare att den sortens infrastruktur kräver extremt noggrann testning innan en ny kryptografisk primitiv rullas ut i skarp drift, vilket gör tidig pilotering värdefull. Telekomoperatörer och kritisk infrastruktur delar samma utmaning: hårdvara med livscykler på tio till femton år måste beställas med kryptoagilitet inbyggd redan i dag, annars blir nästa generations utbyte både dyrare och långsammare.
För en säkerhetsansvarig på ett medelstort svenskt bolag brukar den mest produktiva första åtgärden vara att fråga sina egna leverantörer var de står i sin ML-KEM-resa, snarare än att försöka bygga hybrid-TLS själv. Molnleverantörer, CDN-tjänster och VPN-leverantörer rör sig redan i den riktningen, och i många fall räcker det att aktivera en inställning eller uppgradera en version för att ärva skyddet. Den egna arbetsinsatsen bör i stället läggas på att identifiera var organisationen själv äger kryptografin, exempelvis i interna API:er, filöverföringar eller äldre integrationer mellan system, eftersom det är där ingen extern leverantör gör jobbet åt dig.
Migrationsguide: så byter du från RSA/ECDH till ML-KEM i praktiken
En postkvant-migrering är inte ett enda projekt utan en serie steg som kan köras parallellt med annan säkerhetsutveckling. De flesta organisationer underskattar hur mycket av arbetet som redan är löst av bibliotek och molnleverantörer, och överskattar hur mycket egen kryptokod som faktiskt behöver skrivas. Så här bör ordningen se ut för de flesta organisationer.
- Inventera kryptografiska tillgångar. Bygg en krypto-inventering (ofta kallad CBOM) över vilka system som använder RSA, ECDH, ECDSA eller EdDSA, och var nycklarna lagras. Vår genomgång av nycklar och certifikat i OpenSSL är en bra startpunkt för den delen.
- Klassificera data efter konfidentialitetslivslängd. Identifiera vilken data som måste hållas skyddad längst, det är där “harvest now, decrypt later”-risken är störst och där migreringen bör prioriteras.
- Uppgradera TLS-stacken. Se till att OpenSSL, BoringSSL eller motsvarande bibliotek är uppdaterade till versioner som stödjer hybrid nyckelutbyte med ML-KEM. Grunderna i hur HTTPS och TLS faktiskt fungerar hjälper dig förstå var i kedjan ändringen sker.
- Aktivera hybridläge, inte renodlad PQC. Slå på X25519+ML-KEM-768 i TLS 1.3 som standardkonfiguration, samma val som Cloudflare och Chrome redan gjort.
- Testa kompatibilitet i staging. Kontrollera att äldre klienter, lastbalanserare och mellanprogram inte faller tillbaka på ren klassisk kryptografi utan att du vet om det.
- Separera signaturspåret. Planera ett eget spår för ML-DSA och SLH-DSA, eftersom certifikat och digitala signaturer kräver en annan migreringsväg än nyckelutbyte. Om du vill fräscha upp grunderna i hur digitala signaturer med ECDSA fungerar i dag ger det bra kontext inför bytet.
- Bygg in kryptoagilitet. Följ NIST:s råd i CSWP 39upd1 om att konstruera system där algoritmer kan bytas ut utan en fullständig ombyggnad.
- Håll koll på tidsplanen. Planera internt mot NIST:s deprecieringsdatum 2030 och förbudsdatum 2035, och dokumentera framstegen för revisorer och tillsynsmyndigheter.
De flesta moderna bibliotek, från OpenSSL 3.5 och framåt, gör steg tre och fyra relativt enkla eftersom hybridstödet redan finns inbyggt. Den verkliga tidsåtgången sitter i steg ett, två och fem, där gamla system och beroenden ofta visar sig vara fler och djupare rotade än någon trodde innan inventeringen startade. Den som redan har satt sig in i hur ECDH-nyckelutbyte fungerar i praktiken har ett rejält försprång, eftersom ML-KEM löser exakt samma protokollsteg, bara med ett annat matematiskt fundament.
Användningsfall: när ska du migrera och i vilken ordning
Inte alla organisationer har samma brådska. Nedan är sex konkreta scenarion och vad vi rekommenderar för varje.
- Banker och finansbolag: Starta hybridpiloter nu i icke-kritiska flöden, med mål att ha hybrid-TLS som standard i kundvänd infrastruktur före 2028, god tid före 2030-gränsen.
- Myndigheter och kommuner under NIS2: Prioritera kryptoagilitet och inventering före själva algoritmbytet, eftersom långa systemlivscykler gör ombyggnad dyrare än ombyggnadsbar arkitektur.
- SaaS-bolag och e-handel: Aktivera hybridstöd i TLS-terminering och VPN-infrastruktur så snart leverantören (Cloudflare, AWS, eller motsvarande) erbjuder det som standard, vilket redan sker för många.
- Telekomoperatörer och kritisk infrastruktur: Planera inköp av ny hårdvara med inbyggt PQC-stöd redan nu, givet att utrustningen förväntas leva tio till femton år.
- Vård och system med långlivad känslig data: Högsta prioritet för “harvest now, decrypt later”-skydd, eftersom patientdata som läcker i dag kan dekrypteras om femton år.
- Småföretag och startups: Vänta på att din molnleverantör och dina ramverk sätter hybrid-PQC som standard snarare än att bygga egen kryptografi, det är i linje med hur de flesta redan hanterar TLS i dag.
Oavsett vilket scenario som stämmer bäst på din organisation finns det några fällor värda att undvika. Bygg inte egen kryptografi runt ML-KEM, luta dig på granskade bibliotek. Vänta inte på en “ren” postkvant-lösning innan du gör något alls, hybridläget är redan tillräckligt moget för produktion. Och glöm inte signaturspåret bara för att nyckelutbytet är löst, certifikat och kodsignering följer sin egen tidslinje med ML-DSA och SLH-DSA.
För- och nackdelar: RSA/ECDH mot ML-KEM
Ingen av algoritmerna är ett rent “bättre” val, de löser delvis olika problem under olika tidsramar. RSA och ECDH vinner på mognad och spridning, ML-KEM vinner på att vara det enda alternativet som faktiskt håller mot en kvantdator. Sammanfattningen nedan är tänkt att läsas som två sidor av samma övergång snarare än som konkurrenter, eftersom den praktiska rekommendationen senare i artikeln är att köra båda samtidigt under en övergångsperiod.
RSA och ECDH
- Fördel: Decennier av granskning och praktisk drifterfarenhet i nästan varje system som finns.
- Fördel: ECDH och X25519 är extremt kompakta och snabba, perfekt för resursbegränsade enheter.
- Nackdel: Båda är sårbara för Shors algoritm på en tillräckligt kraftfull kvantdator.
- Nackdel: Omfattas av NIST:s deprecierings- och förbudsdatum 2030/2035.
- Nackdel: All trafik krypterad i dag är exponerad för “harvest now, decrypt later”.
ML-KEM
- Fördel: Färdigställd NIST-standard (FIPS 203) som redan stöds brett i produktion.
- Fördel: Snabbare än RSA för nyckelgenerering, nära X25519 i ren hastighet.
- Fördel: Motståndskraftig mot både klassiska och kvantbaserade attacker enligt dagens kryptoanalys.
- Nackdel: Betydligt större nycklar och chiffertexter än elliptiska kurvor, vilket ökar bandbredden.
- Nackdel: Yngre algoritm med färre år av granskning i verklig drift jämfört med RSA.
- Nackdel: Löser bara nyckelutbyte, signaturer kräver ett separat spår med ML-DSA eller SLH-DSA.
Domslut: vilken kryptografi ska du välja 2026?
Svaret är inte att välja det ena eller det andra, utan att köra båda samtidigt under en övergångsperiod. Hybridläget X25519 plus ML-KEM-768, redan standard hos Cloudflare och Chrome, ger kvantskydd utan att offra den granskning och stabilitet klassisk kryptografi byggt upp under decennier. Siffrorna stödjer valet: en latensökning på 18,7 procent enligt arXiv-studien av TLS-handskakningar är en rimlig kostnad för skydd mot ett hot som annars kan göra all trafik från 2026 läsbar om tio eller femton år.
Ren postkvant-kryptografi utan klassisk backup är inte lika väl motiverad ännu, algoritmerna är för unga för att stå helt själva i kritiska system. HQC förtjänar bevakning men inte produktionsanvändning förrän FIPS 207 är färdig, tidigast 2027. Prioriteringen för de flesta organisationer bör alltså vara: inventera nu, aktivera hybrid-TLS så fort era bibliotek stödjer det, bygg kryptoagilitet för framtida byten, och planera signaturalgoritmerna som ett separat spår. Den organisation som gör detta i år ligger före, inte efter, NIST:s tidsplan.
Det finns inget skäl att betrakta det här som ett engångsprojekt med ett slutdatum. HAWK-sårbarheten i juli 2026 och de pågående utvärderingarna av FAEST, MAYO, SNOVA och övriga signaturkandidater visar att fältet fortfarande rör sig. Den organisation som bygger kryptoagilitet i grunden, snarare än att hårdkoda ML-KEM som “den nya permanenta lösningen”, är den som klarar nästa algoritmbyte på veckor i stället för år. Det är den egentliga lärdomen från 2026: inte att RSA plötsligt blivit farligt över en natt, utan att kryptografisk arkitektur måste planeras för förändring som en permanent egenskap, inte som ett undantag.
Vanliga frågor om RSA, ECDH och ML-KEM
Vad är skillnaden mellan RSA, ECDH och ML-KEM?
RSA och ECDH är klassiska algoritmer för nyckelutbyte och signaturer som bygger på faktorisering respektive elliptiska kurvor. ML-KEM är NISTs nya standard (FIPS 203) för nyckelinkapsling som bygger på strukturerade gitter och är konstruerad för att stå emot attacker från framtida kvantdatorer.
När måste svenska företag byta till postkvant-kryptering?
NIST föreslår att algoritmer med säkerhetsnivå motsvarande 112 bitar, som RSA-2048, ska avrådas efter 2030 och vara helt otillåtna efter 2035. Starkare klassiska algoritmer får sitta kvar längre men faller under samma förbudsdatum 2035.
Är ML-KEM säkert att använda redan i dag?
Ja, FIPS 203 är en färdig, granskad standard som redan driftsätts av Cloudflare, Chrome, AWS, OpenSSH och Signal, oftast i hybridläge tillsammans med klassisk kryptografi.
Vad är “harvest now, decrypt later” och varför spelar det roll?
Det beskriver risken att krypterad trafik som avlyssnas och sparas i dag kan dekrypteras i efterhand när kvantdatorer blir kraftfulla nog. Data som måste vara konfidentiell i många år, som vårddata och finansiella avtal, är därför i riskzonen redan nu.
Behöver vi byta ut digitala signaturer också?
Ja. ML-KEM löser bara nyckelutbyte. Signaturer baserade på RSA, ECDSA eller EdDSA måste ersättas separat med ML-DSA (FIPS 204) eller SLH-DSA (FIPS 205), vilket kräver en egen migreringsplan för certifikat och kodsigneringssystem.
Vad är skillnaden mellan ML-KEM och HQC?
ML-KEM är lattice-baserad och redan färdigställd (FIPS 203). HQC är kodbaserad, utvald som reservalgoritm den 11 mars 2025, men väntar fortfarande på en färdig standard (troligen FIPS 207, tidigast 2027). HQC har betydligt större nycklar och chiffertexter än ML-KEM.
Kostar det mycket att migrera till postkvant-kryptering?
Ingen certifikatutfärdare eller molnleverantör tar i dag ut ett separat PQC-pris. Den verkliga kostnaden ligger i interntid: inventering, biblioteksuppgraderingar och testning, snarare än i licensavgifter.
Påverkar detta BankID och svensk betalningsinfrastruktur?
Bank- och betalningssystem hör till den infrastruktur som bär störst risk vid ett sent byte på grund av långa livscykler och känslig data, vilket gör tidig pilotering av hybrid-TLS särskilt värdefullt för den sektorn.
Vad bör en organisation göra först av allt?
Börja med en inventering av var RSA, ECDH, ECDSA och EdDSA faktiskt används i er miljö, inklusive hos leverantörer. Utan den kartan går det inte att prioritera rätt, och de flesta projekt som fastnar gör det därför att inventeringen hoppades över i hast.
Måste vi vänta på HQC innan vi gör något?
Nej. HQC är en framtida reservalgoritm som tidigast blir en färdig standard 2027. Dagens rekommendation är att gå vidare med ML-KEM i hybridläge nu och bevaka HQC separat, utan att låta tidsplanen för reserven bromsa den primära migreringen.