ML-KEM vs ML-DSA: FIPS 203 Mod 204 i TLS 1.3

NIST satte punktum efter otte års udvælgelsesproces i august 2024, da myndigheden offentliggjorde de første tre endelige post-quantum-standarder: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) og FIPS 205 (SLH-DSA). To år senere, i oktober 2026, er spørgsmålet ikke længere om kvantesikker kryptografi kommer, men hvordan danske og nordiske it-afdelinger konkret vælger mellem de to mest udbredte byggesten: ML-KEM til nøgleudveksling og ML-DSA til digitale signaturer. De løser forskellige problemer, men forveksles ofte i indkøbsmøder og arkitekturdiagrammer, og det er dyrt at vælge forkert, når certifikatkæder, netværksudstyr og gamle protokolimplementeringer først er bygget om.

Denne artikel sammenligner ML-KEM og ML-DSA i detaljer: hvad de dækker, hvilke biblioteker der understøtter dem i 2026, hvad de koster at implementere, og hvornår man skal bruge den ene frem for den anden. Vi trækker på NIST‘s egne tidslinjer og udkast til standarder, en uafhængig biblioteksmatrix fra PQC Library Comparison Matrix, Det Hvide Hus’ migrationsdirektiv M-26-15, og brancheanalyser fra Thales og Fortinet, som alle har offentliggjort opdateret materiale i løbet af 2026. Målet er en praktisk guide til arkitekter og sikkerhedsansvarlige, ikke endnu en akademisk gennemgang af gitterbaseret matematik.

Hvorfor haster det? Trusselsbilledet bag post-quantum kryptografi

Den mest almindelige indvending mod post-quantum-migration lyder: ingen kvantecomputer kan i dag knække RSA-2048 eller ECC, så hvorfor bruge budget på det nu? Fortinet beskriver i sin gennemgang af kvantecomputer-sikkerhed den strategi, branchen kalder “harvest now, decrypt later”: en modstander opsnapper krypteret trafik eller stjæler krypterede databaser i dag og lagrer dem, velvidende at indholdet først kan dekrypteres, når en tilstrækkeligt stærk kvantecomputer findes, muligvis om 10 til 20 år. For data med lang fortrolighedshorisont, som sundhedsjournaler, forsvarshemmeligheder, finansielle aftaler eller personoplysninger under GDPR, betyder det, at krypteringen skal være kvantesikker allerede i dag, ikke først når angriberen får nøglen til at dekryptere den.

Det er den risikomodel, der ligger bag både NIST’s og Det Hvide Hus’ insisteren på, at migrationen starter nu og ikke afventer en konkret kvantecomputer-trussel. For danske og nordiske organisationer, der arbejder med sundhedsdata, kritisk infrastruktur eller langsigtede kontrakter, er “harvest now, decrypt later” ikke en teoretisk øvelse, det er en konkret grund til at prioritere ML-KEM og ML-DSA i den kommende investeringsplan, uanset om man er underlagt amerikansk lovgivning eller ikke. Trafik, der krypteres med klassisk RSA eller ECC i dag, kan stadig blive opsnappet og gemt af en modstander, der spiller det lange spil.

Risikoen forstærkes af, at kvantecomputerudviklingen ikke følger en lineær tidslinje, man kan planlægge ud fra med sikkerhed. Fremskridt kommer ofte i spring, drevet af gennembrud i fejlkorrigering og qubit-stabilitet, og det betyder, at et “sikkert” tidsvindue på papiret kan krympe hurtigere end forventet. Thales fremhæver i sin strategigennemgang, at den konservative tilgang er at behandle kvantetruslen som en planlægningsrisiko på linje med andre langsigtede infrastrukturrisici, snarere end en akut brandalarm. Det ændrer ikke på konklusionen: migrationen skal starte nu, men det ændrer på, hvordan man kommunikerer den internt til ledelsen, som en del af almindelig risikostyring og ikke en panikreaktion på en enkelt nyhedsoverskrift.

Hvad er ML-KEM? Fra CRYSTALS-Kyber til FIPS 203

ML-KEM står for Module-Lattice-based Key Encapsulation Mechanism og var tidligere kendt under forskningsnavnet CRYSTALS-Kyber. NIST gjorde algoritmen til en officiel amerikansk standard som FIPS 203 i august 2024, og formålet er snævert, men kritisk: at etablere en delt hemmelig nøgle mellem to parter over et usikkert netværk, uden at en fremtidig kvantecomputer kan bryde udvekslingen bagefter. Det er præcis den opgave, RSA-nøgleudveksling og elliptisk kurve-Diffie-Hellman (ECDH) løser i dag, og det er derfor ML-KEM er den mest oplagte post-quantum-kandidat til TLS 1.3, SSH og IPsec-VPN’er, altså de protokoller der dagligt etablerer millioner af krypterede forbindelser uden brugeren lægger mærke til det.

Standarden kommer i tre parametersæt: ML-KEM-512, ML-KEM-768 og ML-KEM-1024, hvor tallet groft sagt afspejler sikkerhedsniveauet og dermed også nøglestørrelsen og beregningstiden. ML-KEM-768 har sat sig fast som branchens foretrukne mellemniveau, fordi det giver en sikkerhedsmargin, der matcher AES-192, uden den ekstra overhead det højeste niveau medfører. Ifølge PQC Library Comparison Matrix dropper Googles BoringSSL-bibliotek bevidst både ML-KEM-512, fordi sikkerhedsmarginen er for tynd til Googles smag, og ML-KEM-1024, fordi den ekstra beregningsoverhead ikke giver nok i praksis for de fleste af selskabets egne tjenester. Det er et stærkt signal om, hvor branchen reelt lander, selv når standarden formelt tilbyder tre valgmuligheder: når en af verdens største browserleverandører vælger ét niveau, bliver det hurtigt en de facto-standard for resten af økosystemet.

En vigtig teknisk detalje, mange glemmer: ML-KEM er ikke en direkte erstatning for ECDH i protokolsproget, men en mekanisme, hvor den ene part krypterer (“indkapsler”) en tilfældig hemmelighed til den anden parts offentlige nøgle. Det betyder, at protokoller skal opdateres til at håndtere en anden udvekslingsmekanisme, ikke bare udskifte et nøgletal. Det er en af grundene til, at hybridgrupper, hvor klassisk ECDH køres side om side med ML-KEM, er blevet den foretrukne overgangsstrategi frem for et direkte spring.

For driftsteams betyder det konkret, at en TLS 1.3-server, der annoncerer X25519MLKEM768, i realiteten kører to parallelle nøgleudvekslinger og kombinerer resultaterne til én session-nøgle. Hvis en klient ikke kender ML-KEM, falder forbindelsen automatisk tilbage til ren X25519, så bagudkompatibiliteten bevares. Prisen er en lidt større “ClientHello”-pakke og en smule mere CPU-tid per håndtryk, men for de fleste webtjenester er den ekstra belastning umærkelig i praksis sammenlignet med andre dele af en typisk sideindlæsning.

Hvad er ML-DSA? Fra CRYSTALS-Dilithium til FIPS 204

ML-DSA, eller Module-Lattice-based Digital Signature Algorithm, er den anden halvdel af NIST’s første PQC-bølge og blev standardiseret som FIPS 204 samtidig med ML-KEM i august 2024. Hvor ML-KEM handler om at aftale en nøgle, handler ML-DSA om at bevise identitet og integritet: certifikater, kodesignering og autentificering af alt fra softwareopdateringer til offentlige id-kort. Algoritmen var tidligere kendt som CRYSTALS-Dilithium og deler samme matematiske fundament som ML-KEM, nemlig strukturerede gitterproblemer (module lattices), men er optimeret til en helt anden opgave, nemlig at generere en signatur, der entydigt kan verificeres som kommende fra indehaveren af en bestemt privat nøgle.

Ligesom ML-KEM findes ML-DSA i tre niveauer: ML-DSA-44, ML-DSA-65 og ML-DSA-87. Her bliver forskellen til klassisk kryptografi mærkbar på en måde, de fleste udviklere endnu ikke har regnet ind i deres kapacitetsplaner. Det amerikanske OMB-migrationsdirektiv M-26-15 fra Det Hvide Hus beskriver ML-DSA-signaturer som typisk 1-2 KB, hvilket er markant større end de 64-512 byte man kender fra RSA og ECDSA. For et enkelt TLS-håndtryk er det næsten ligegyldigt, men for certifikatkæder med flere mellemliggende certifikater, for IoT-enheder med begrænset båndbredde, eller for systemer der signerer millioner af transaktioner om dagen, bliver den ekstra vægt en reel arkitekturbeslutning, der kan påvirke alt fra DNSSEC-pakkestørrelser til OCSP-svartider.

Signaturstørrelsen er grunden til, at mange organisationer vælger at prioritere ML-KEM-migrationen før ML-DSA. Nøgleudveksling sker typisk én gang per forbindelse, mens signaturer kan optræde flere gange i en enkelt certifikatkæde eller i hver enkelt signeret transaktion. Det gør ML-DSA’s praktiske konsekvenser mere synlige, selv om algoritmen i sig selv er lige så færdigudviklet og NIST-godkendt som ML-KEM.

En anden praktisk konsekvens er, hvordan ML-DSA påvirker signerings- og verifikationstid i systemer med høj gennemstrømning. Kodesigneringsservere, der signerer tusinder af artefakter om dagen i et CI/CD-pipeline, vil typisk kunne absorbere den ekstra signaturstørrelse uden problemer, fordi signeringen sker asynkront og uden for den kritiske brugerflade. Certifikatudstedere, der skal validere kæder i realtid under et TLS-håndtryk, mærker det derimod tydeligere, fordi hver ekstra kilobyte lægger sig til den samlede datamængde, der skal overføres, før en forbindelse er etableret.

NIST’s standardiseringsrejse: tidslinjen bag FIPS 203, 204 og 205

NIST startede sit Post-Quantum Cryptography-projekt i 2016 som en åben international konkurrence, hvor forskere fra hele verden indsendte kandidatalgoritmer til offentlig gennemgang og kryptoanalyse. Processen trak eksperter fra universiteter, teknologivirksomheder og myndigheder ind i flere runder af offentlig test, hvor svage kandidater blev sorteret fra, mens de stærkeste blev finpudset. Efter flere udvælgelsesrunder landede NIST på CRYSTALS-Kyber og CRYSTALS-Dilithium som de primære vindere, sammen med SPHINCS+ som en konservativ sikkerhedsreserve baseret på et helt andet matematisk problem end gitterproblemer, nemlig hashfunktioner. Tankegangen var at have mindst to matematisk uafhængige tilgange klar, så en eventuel svaghed i gitterbaserede algoritmer ikke lammer hele migrationen.

I august 2024 blev de tre omdøbt og offentliggjort som endelige standarder: ML-KEM (FIPS 203), ML-DSA (FIPS 204) og SLH-DSA (FIPS 205, baseret på SPHINCS+). Navneskiftet fra forskningsnavne til FIPS-betegnelser er mere end kosmetik, det markerer overgangen fra akademisk kandidat til bindende amerikansk standard, som føderale myndigheder og deres leverandører skal følge.

NIST har efterfølgende gjort det klart, at organisationer ikke skal vente på, at en kvantecomputer rent faktisk kan knække RSA eller ECC, før migrationen begynder. Standarderne er, ifølge NIST selv, klar til implementering nu. Den holdning er blevet forstærket i 2026, hvor NIST i juni offentliggjorde udkast til opdaterede PIV-standarder (Personal Identity Verification), som definerer, hvordan amerikanske føderale id-kort skal bruge post-quantum-algoritmer. Det er et konkret eksempel på, at standardiseringsarbejdet er flyttet fra teori til egentlig infrastruktur, og det samme mønster ses i Det Hvide Hus’ OMB-direktiv M-26-15, der kræver, at føderale agenturer har aktive migrationsplaner for deres kryptografiske afhængigheder, med konkrete milepæle og rapporteringskrav.

Processen er desuden ikke slut. NIST fortsætter arbejdet med en fjerde runde af algoritmer, der skal give yderligere diversitet i nøgleindkapsling, så branchen ikke er afhængig af en enkelt matematisk tilgang. Det er et vigtigt signal om, at ML-KEM og ML-DSA skal ses som det første, solide lag i en løbende proces, ikke som et endestation, hvor standardiseringsarbejdet stopper. Organisationer bør derfor designe deres kryptografiske arkitektur med en vis grad af algoritme-agilitet, så fremtidige opdateringer kan rulles ud uden en total ombygning, nogenlunde som man i dag kan skifte TLS-cipher suite uden at genskrive hele applikationen.

Teknisk sammenligning: ML-KEM mod ML-DSA punkt for punkt

Den letteste måde at huske forskellen på er dette: ML-KEM låser en dør op, ML-DSA beviser hvem der låste den op. De deler matematisk DNA, begge bygger på problemet med at løse strukturerede gitterligninger, men adresserer hver sin halvdel af et sikkert system. Tabellen nedenfor stiller de to standarder op mod hinanden på de egenskaber, der faktisk betyder noget, når man skal vælge, teste og rulle dem ud i et dansk eller nordisk driftsmiljø.

Egenskab	ML-KEM	ML-DSA
Tidligere forskningsnavn	CRYSTALS-Kyber	CRYSTALS-Dilithium
FIPS-standard	FIPS 203	FIPS 204
Endeligt godkendt af NIST	August 2024	August 2024
Primær funktion	Nøgleindkapsling (key encapsulation)	Digital signatur
Typisk anvendelse	TLS 1.3, SSH, IPsec-VPN	Certifikater, kodesignering, identitet
Antal parametersæt	3 (512 / 768 / 1024)	3 (44 / 65 / 87)
Branchens foretrukne niveau	ML-KEM-768	Varierer efter krav til sikkerhedsmargin
Understøttet i OpenSSL 3.5	Alle tre niveauer	Alle tre niveauer
Understøttet i BoringSSL	Kun ML-KEM-768	Alle tre niveauer
Hybrid TLS 1.3-gruppe tilgængelig	Ja, X25519MLKEM768	Endnu ikke standardiseret som hybridgruppe
Belastning versus klassisk kryptografi	Moderat ekstra kommunikationsoverhead	Signaturer på cirka 1-2 KB, markant større end RSA/ECDSA
Reservestandard	Ingen officiel NIST-reserve endnu	SLH-DSA (FIPS 205) som konservativt alternativ

Det vigtigste at tage med fra tabellen er, at ML-KEM allerede kører i produktion hos store aktører i hybridform, mens ML-DSA stadig kæmper med den praktiske konsekvens af større signaturer. Det betyder ikke, at ML-DSA er umodent, standarden er lige så færdig som ML-KEM, men signaturstørrelsen tvinger arkitekter til at tænke certifikatkæder, netværksbudgetter og lagringskrav igennem på en måde, nøgleudveksling ikke kræver. En anden pointe er, at ML-KEM allerede har en etableret hybridvej gennem gruppen X25519MLKEM768, mens ML-DSA endnu venter på en lignende bredt accepteret hybrid-signaturmekanisme, hvilket forklarer en del af forskellen i udrulningstempo mellem de to standarder.

Et sidste punkt, der ofte overses i tekniske sammenligninger, er nøglegenereringstid. ML-KEM og ML-DSA er begge betydeligt hurtigere at generere nøgler til end man måske forventer fra gitterbaseret matematik, hvilket er en af grundene til, at NIST valgte dem frem for andre kandidater i standardiseringsprocessen. Det gør dem praktisk anvendelige selv i scenarier, hvor nøgler roteres ofte, som i kortlivede TLS-sessioncertifikater eller i systemer, der genererer nye nøglepar for hver transaktion af sikkerhedsmæssige årsager.

Biblioteksstøtte i 2026: hvem understøtter hvad?

En standard er kun så god som de biblioteker, der implementerer den. PQC Library Comparison Matrix har opdateret sin sammenligning i oktober 2026 og gennemgår, hvilke af de store kryptografibiblioteker der reelt understøtter alle seks parametersæt. Billedet er mere fragmenteret, end man måske tror, selv to år efter FIPS 203 og 204 blev endelige, og det er netop den slags detalje, der afgør, om et migrationsprojekt kan gennemføres på den platform, en organisation allerede har investeret i.

Bibliotek	ML-KEM-512	ML-KEM-768	ML-KEM-1024	ML-DSA-44	ML-DSA-65	ML-DSA-87
OpenSSL 3.5	Ja	Ja	Ja	Ja	Ja	Ja
BoringSSL	Nej	Ja	Nej	Ja	Ja	Ja
wolfSSL 5.7+	Ja	Ja	Ja	Ja	Ja	Ja
liboqs (Open Quantum Safe) 0.10+	Ja	Ja	Ja	Ja	Ja	Ja
Bouncy Castle 1.79	Ja	Ja	Ja	Ja	Ja	Ja
AWS-LC	Delvis	Ja	Delvis	Ja	Ja	Ja

Mønstret er tydeligt: forskningsorienterede og bredt anvendte biblioteker som OpenSSL, wolfSSL, liboqs og Bouncy Castle dækker alle seks parametersæt, fordi deres brugere spænder fra forskere til bankinfrastruktur og derfor har brug for fleksibilitet. BoringSSL, som driver Chrome og store dele af Googles egen infrastruktur, har derimod gjort et bevidst produktvalg og kun shippet det parametersæt, Google selv vil stå bag i produktion. Det er en pointe, danske it-afdelinger bør hæfte sig ved: man kan ikke gå ud fra, at “biblioteket understøtter post-quantum” betyder, at alle seks parametersæt er tilgængelige. Det skal tjekkes niveau for niveau, og helst dokumenteres i den samme kortlægning, man i øvrigt bruger til at følge klassiske TLS-cipher suites.

AWS-LC’s delvise support af ML-KEM-512 og ML-KEM-1024 er et godt eksempel på, hvordan selv store cloud-udbydere prioriterer deres udviklingsressourcer efter, hvad deres egne tjenester reelt har brug for, frem for at implementere hele standarden på én gang. For organisationer, der bygger på AWS-infrastruktur, betyder det, at man bør afklare konkret, hvilket niveau man kan forvente understøttet i de tjenester, man allerede bruger, før man lægger en tidsplan.

Det samme gælder for sprogspecifikke biblioteker uden for den klassiske C/C++-verden. Java- og .NET-udviklere, der læner sig på Bouncy Castle, får i praksis adgang til hele paletten af parametersæt uden selv at skulle vente på en separat PQC-pakke, mens teams der arbejder i Go eller Rust oftere må kigge mod bindings til liboqs, fordi de native økosystemer stadig er under opbygning. Det er en konkret grund til, at migrationsplanen bør indeholde en liste over, hvilke programmeringssprog organisationen reelt bruger i produktion, og ikke kun hvilke protokoller der skal opdateres.

Eksempel på hybrid TLS 1.3-konfiguration

I praksis betyder hybrid-understøttelse, at en server kan annoncere både en klassisk elliptisk kurve og ML-KEM-768 i samme håndtryk, så klienter uden post-quantum-support stadig kan forbinde, mens klienter der understøtter det, automatisk får det ekstra sikkerhedslag. Et typisk eksempel på, hvordan man tester det lokalt med en OpenSSL 3.5-installation, ser sådan ud:

openssl s_client -connect eksempel.dk:443 -groups X25519MLKEM768
openssl genpkey -algorithm ML-DSA-65 -out mldsa65-privat.pem

Den første kommando tester, om en server allerede annoncerer den hybride gruppe X25519MLKEM768, som kombinerer klassisk X25519-nøgleudveksling med ML-KEM-768. Den anden genererer et ML-DSA-65-nøglepar, som kan bruges til at udstede et testcertifikat i et staging-miljø, før man rører produktionstrafik. Begge kommandoer er gode udgangspunkter for et internt proof of concept, før man beslutter, hvilket niveau der skal rulles bredt ud.

Benchmarks fra tre kilder: hvad siger NIST, biblioteksmatrixen og Det Hvide Hus?

Når man sammenligner to kryptografiske standarder, er det fristende at lede efter et enkelt benchmark-tal, der afgør sagen. Her er ærligheden vigtigere end et pænt tal: de offentligt tilgængelige kilder i 2026 giver ikke et entydigt operationer-per-sekund-tal, der kan sættes direkte op mod RSA eller ECC på tværs af alle platforme, fordi ydelsen afhænger kraftigt af hardware, biblioteksversion og hvilket parametersæt man vælger. Det, man derimod kan sammenligne solidt, er de strukturelle forskelle, som tre uafhængige kilder er enige om, og det er faktisk mere nyttigt for en beslutningstager end et isoleret laboratorietal fra en specifik processor.

NIST selv fastslår, at begge algoritmefamilier er klar til produktion og ikke kræver yderligere afventning, en konklusion der bygger på års offentlig kryptoanalyse under standardiseringsprocessen. PQC Library Comparison Matrix dokumenterer, hvordan de store biblioteker reelt har prioriteret deres implementeringsarbejde, hvilket er et praktisk mål for, hvor modent hvert parametersæt er i felten, uafhængigt af, hvad specifikationen i teorien tillader. Og Det Hvide Hus’ OMB-direktiv M-26-15 giver den mest konkrete belastningsvurdering: ML-KEM introducerer mere kommunikationsoverhead end klassisk ECC, men holder sig på et niveau, direktivet kalder moderat og håndterbart til nærtidig post-quantum-brug, mens ML-DSA’s signaturer på 1-2 KB skaber reel båndbredde- og certifikatkæde-belastning, som skal planlægges aktivt, særligt i miljøer med mange mellemliggende certifikater eller begrænset netværkskapacitet.

Konklusionen fra alle tre kilder trækker i samme retning: ML-KEM er den lettere migration at absorbere i eksisterende netværksprotokoller, mens ML-DSA kræver et mere grundigt kig på, hvor i stakken signaturstørrelsen gør mest skade, typisk i certifikatkæder med flere led eller i systemer, der signerer meget ofte. Ingen af kilderne anbefaler at vente på bedre benchmarks, før man begynder. De anbefaler i stedet at teste i eget miljø, fordi den reelle ydelse altid vil afhænge af den konkrete infrastruktur, man kører på.

En praktisk tilgang til egen benchmarking er at måle tre ting isoleret: tiden det tager at generere et nøglepar, tiden det tager at gennemføre selve håndtrykket med den nye gruppe aktiveret, og den samlede datamængde der sendes over netværket. De tre tal fortæller mere om, hvad en specifik organisation reelt vil opleve, end et generisk tal fra en producents marketingmateriale, fordi de afspejler den faktiske hardware, netværkslatens og trafikmønster, systemet kører under.

Pris og implementeringsomkostninger: hvad koster det reelt?

Hverken ML-KEM eller ML-DSA har en licenspris i traditionel forstand. Begge er åbne standarder, og de fleste implementeringer er open source. Omkostningen ligger derfor ikke i softwarelicenser, men i udviklertimer, testinfrastruktur og eventuel kommerciel support. NIST har desuden etableret et patentlicensprogram, der skal sikre, at organisationer ikke rammes af uventede patentkrav, når de implementerer de nye standarder, hvilket fjerner en juridisk risiko, mange virksomheder ellers ville have skullet afklare selv, før de kunne gå i produktion med gitterbaseret kryptografi.

Løsning	Licenstype	Omkostningsprofil	Bedst til
OpenSSL 3.5	Open source (Apache 2.0)	Gratis bibliotek, intern implementeringstid dominerer omkostningen	Virksomheder med egen sikkerhedsstab
BoringSSL	Open source	Gratis, Google-vedligeholdt, men begrænset parametervalg	Chrome- og Google-økosystemet
wolfSSL 5.7+	Open source + kommerciel support	Gratis kerne, betalt support og certificeringspakker	Indlejrede systemer og IoT
liboqs (Open Quantum Safe)	Open source	Gratis, forsknings- og testfokuseret	Udviklere der tester PQC før produktion
Bouncy Castle 1.79	Open source	Gratis, understøtter Java og .NET	Enterprise Java-applikationer
AWS-LC	Open source, AWS-vedligeholdt	Biblioteket er gratis, men AWS-tjenester der bruger det faktureres efter normal cloud-takst	AWS-kunder
Kommerciel nøglehåndtering (fx Thales)	Kommerciel licens	Variabel virksomhedspris, kræver dialog med leverandør	Regulerede sektorer med høje compliance-krav

For de fleste danske og nordiske virksomheder er den reelle regning altså ikke en licensfaktura, men timer brugt på at opdatere TLS-terminering, teste hybridgrupper, og i ML-DSA’s tilfælde genvurdere certifikatstørrelser i hele kæden. Thales anbefaler i sin strategigennemgang, at organisationer starter med en kortlægning af, hvor klassisk RSA og ECC bruges i dag, før de vælger, hvilke systemer der skal migreres først, netop fordi den skjulte omkostning sidder i kompleksiteten af eksisterende infrastruktur, ikke i selve algoritmerne. En organisation med hundredvis af interne tjenester, der alle har hardkodet understøttede cipher suites, vil typisk opleve, at kortlægningsfasen tager længere tid end selve kodeændringen.

Det er også værd at overveje totalomkostningen ved at vente. Hvis migrationen skubbes til, et kryptografisk brud bliver akut, vil arbejdet skulle ske under tidspres, med dyrere konsulentbistand og højere risiko for driftsfejl, end hvis det planlægges roligt over de kommende år som en del af den almindelige patch- og opgraderingscyklus.

Kommercielle udbydere af hardware-sikkerhedsmoduler og nøglehåndtering, som Thales, positionerer sig i stigende grad som et lag over de åbne biblioteker snarere end et alternativ til dem. Deres produkter håndterer typisk nøglelivscyklus, revisionsspor og compliance-rapportering på tværs af ML-KEM og ML-DSA, hvilket kan være værd prisen for organisationer i regulerede sektorer som finans og sundhed, men som sjældent er nødvendigt for en mindre virksomhed, der kan styre nøgler direkte gennem et open source-bibliotek.

Fem virkelighedsnære eksempler fra 2026

Post-quantum-migrationen er ikke længere et teoretisk tankeeksperiment. Her er konkrete eksempler fra det seneste år, der viser, hvordan ML-KEM og ML-DSA allerede bruges eller kræves i praksis hos myndigheder, leverandører og teknologivirksomheder.

Amerikanske banker under føderale deadlines: Ifølge TechGig opfordres amerikanske banker til at indføre post-quantum-kryptografi, før føderale frister træder i kraft, med direkte henvisning til ML-KEM og ML-DSA som de primære byggesten i den finansielle sektors migrationsplaner.
Nyt sikkerhedsøkosystem fra MetTel Labs: MetTel Labs annoncerede i 2026 et initiativ til at bygge et post-quantum-sikkerhedsøkosystem, så virksomheder kan forberede sig på kvanteæraen gennem fælles standarder, delt infrastruktur og samarbejde mellem leverandører.
ML-DSA i Active Directory Certificate Services: Kryptus har dokumenteret, hvordan en Certificate Authority baseret på ML-DSA kan integreres i Microsofts AD CS, et konkret eksempel på, hvordan virksomheds-PKI begynder at tage signaturstandarden i brug i helt almindelige Windows-miljøer.
NIST’s egne PIV-id-kort: NIST’s opdaterede udkast til PIV-standarder fra juni 2026 beskriver, hvordan amerikanske føderale medarbejderkort skal understøtte post-quantum-signaturer, hvilket gør ML-DSA til en del af fysisk adgangskontrol, ikke kun netværkstrafik.
Føderalt migrationsdirektiv fra Det Hvide Hus: OMB-direktivet M-26-15 kræver, at alle amerikanske føderale agenturer har aktive migrationsplaner for deres kryptografiske systemer, med ML-KEM og ML-DSA som de centrale standarder, planerne skal bygge på, og med krav om løbende statusrapportering.
Chrome og BoringSSL’s selektive support: Googles beslutning om kun at implementere ML-KEM-768 i BoringSSL, fremfor alle tre niveauer, er i sig selv et virkelighedseksempel på, hvordan en af verdens mest brugte browsere vælger at skalere post-quantum-support i praksis frem for at følge specifikationen slavisk.

Tilsammen viser de seks eksempler et mønster, der går igen i hele branchen: migrationen sker ikke som en koordineret, samtidig omstilling, men lag for lag, drevet af den enkelte organisations egen risikovurdering og regulatoriske tryk. Banker og myndigheder bevæger sig først, fordi deadlines og compliance-krav tvinger dem til det, mens browserleverandører og biblioteksudviklere bevæger sig, fordi deres brugerbase er stor nok til, at selv små sikkerhedsforbedringer giver mening at investere i tidligt.

Migrationsguide: syv trin til post-quantum kryptografi i praksis

Uanset om man styrer infrastruktur i en dansk kommune, en bank eller en mindre softwarevirksomhed, følger en realistisk migration til ML-KEM og ML-DSA et nogenlunde fælles mønster, der går igen i både Thales’ strategianbefalinger og Det Hvide Hus’ direktiv. Trinene herunder kan tilpasses til organisationens størrelse, men rækkefølgen bør holdes, da senere trin afhænger af resultaterne fra de tidligere.

Kortlæg den kryptografiske fodspor. Find hvor RSA, ECDH og ECDSA bruges i dag, fra TLS-terminering til interne mikroservices, batch-jobs og IoT-enheder. Uden denne liste er det umuligt at prioritere korrekt.
Prioriter efter risiko og levetid. Systemer, der skal fungere i 10-15 år endnu, eller som håndterer data med lang fortrolighedshorisont, flyttes først, netop på grund af “harvest now, decrypt later”-risikoen.
Test hybridgrupper i staging. Begynd med X25519MLKEM768 eller tilsvarende hybridgrupper, så klassisk sikkerhed bevares, mens post-quantum-laget testes mod ægte trafikmønstre.
Opdater til PQC-understøttede biblioteksversioner. OpenSSL 3.5, wolfSSL 5.7+ eller liboqs 0.10+ er naturlige udgangspunkter afhængigt af platform og eksisterende afhængigheder.
Genvurder certifikatkæder før ML-DSA-udrulning. Tjek om øget signaturstørrelse påvirker timeout-grænser, lagringskvoter eller netværksudstyr med faste pakkestørrelser, især ældre firewalls og load balancere.
Rul gradvist ud i produktion. Start med interne systemer eller lavrisiko-trafik, før kundevendte tjenester migreres, og overvåg fejlrater tæt i de første uger.
Uddan drift- og udviklingsteams løbende. De nye algoritmers fejlmønstre og ydelseskarakteristika er anderledes end klassisk kryptografi, og det kræver ny viden i både sikkerheds- og driftsteams, før de kan fejlfinde selvstændigt.

De syv trin er ikke et engangsprojekt, der afsluttes og lægges på hylden. Fordi NIST allerede arbejder på en fjerde runde af algoritmer, og fordi hybridgrupper formentlig vil blive udfaset til ren post-quantum-kryptografi, når tilliden til de nye standarder vokser, bør migrationen behandles som en tilbagevendende del af organisationens sikkerhedsprogram, på linje med patching og sårbarhedsscanning, snarere end et projekt med en fast slutdato.

Fordele og ulemper ved ML-KEM

Fordel: Allerede understøttet som hybridgruppe i flere store biblioteker og browsere, hvilket gør udrulning hurtigere.
Fordel: Moderat overhead gør det lettere at indpasse i eksisterende TLS 1.3- og VPN-protokoller uden store ombygninger.
Fordel: Bred biblioteksstøtte fra OpenSSL til liboqs giver valgfrihed på tværs af platforme og programmeringssprog.
Ulempe: Ikke alle parametersæt er tilgængelige i alle biblioteker, som set med BoringSSL’s fravalg af ML-KEM-512 og 1024.
Ulempe: Kræver protokolopdateringer i ældre systemer, der ikke kender hybridgrupper, hvilket kan betyde udskiftning af netværksudstyr.

Fordele og ulemper ved ML-DSA

Fordel: NIST-godkendt med stærk sikkerhedsmargin og allerede i brug i PKI-systemer som AD CS.
Fordel: Har en officiel reservestandard i SLH-DSA (FIPS 205), hvis der skulle opstå svagheder i gitterbaserede algoritmer.
Fordel: Understøttet fuldt ud i stort set alle større biblioteker, inklusive BoringSSL, i modsætning til ML-KEM’s mere selektive support.
Ulempe: Signaturer på 1-2 KB belaster certifikatkæder, lagring og båndbredde markant mere end RSA eller ECDSA.
Ulempe: Mangler endnu en bredt standardiseret hybrid-signaturgruppe til TLS 1.3, i modsætning til ML-KEM’s X25519MLKEM768.

Hvornår skal du bruge ML-KEM, og hvornår ML-DSA?

Fordi de to standarder løser forskellige problemer, er svaret oftest “begge, men i forskellige lag af systemet”. Her er seks konkrete anbefalinger til, hvor man bør starte, baseret på de anvendelsesområder NIST og Det Hvide Hus selv peger på.

Offentlige TLS 1.3-webservere og API’er: Start med ML-KEM-768 i hybridform, da understøttelsen allerede er bred og overheaden håndterbar for det meste webtrafik.
SSH og IPsec-VPN-forbindelser: ML-KEM er den naturlige kandidat, da nøgleudveksling er kerneopgaven i begge protokoller, og ændringen kan ofte gøres uden synlig brugerpåvirkning.
Kodesignering og softwareleverandørkæder: ML-DSA-65 eller ML-DSA-87 bør prioriteres her, da integriteten af signerede opdateringer er kritisk, og signaturstørrelsen sjældent er en flaskehals ved engangssignering af en installationspakke.
Certifikatmyndigheder og PKI-infrastruktur: ML-DSA, med SLH-DSA som konservativ backup, matcher den tilgang NIST selv anvender i opdaterede PIV-standarder til identitetsbeviser.
Finansielle institutioner under regulatoriske deadlines: Begge standarder bør indgå i migrationsplanen, prioriteret efter de konkrete tidslinjer myndighederne sætter, som det ses i det amerikanske OMB-direktiv og i bankernes egne meldinger.
Indlejrede og IoT-enheder med begrænset kapacitet: ML-KEM-512 hvor biblioteket understøtter det er oftest mere realistisk end ML-DSA-87, hvis enheden sjældent signerer, men ofte skal etablere forbindelser på begrænset strøm og hukommelse.

Verdict: hvilken standard vinder i din arkitektur?

Der er ikke en samlet vinder mellem ML-KEM og ML-DSA, fordi de ikke konkurrerer om samme opgave. Men hvis man tvinges til at prioritere, hvor man starter, peger data fra NIST, PQC Library Comparison Matrix og Det Hvide Hus’ direktiv i samme retning: begynd med ML-KEM i hybridform på TLS 1.3, SSH og VPN, fordi biblioteksstøtten er bredere, overheaden lavere, og risikoen for driftsproblemer mindre. Lad ML-DSA-migrationen følge tæt efter, men planlagt mere grundigt, fordi signaturstørrelsen på 1-2 KB kræver et reelt kig på certifikatkæder og netværksbudgetter, før man ruller det ud bredt i produktion.

Organisationer, der venter på et endnu klarere signal, bør bemærke, at NIST allerede har erklæret begge standarder klar til produktion, og at store aktører som Google, AWS og biblioteker som Bouncy Castle allerede har implementeret dem i varierende grad. Ventetiden koster mere end den sparer, og “harvest now, decrypt later”-risikoen løber, uanset om en organisation er klar til at handle på den eller ikke. Den praktiske konklusion for danske og nordiske it-afdelinger er derfor at behandle ML-KEM-migrationen som et driftsprojekt, der kan startes nu, og ML-DSA-migrationen som et arkitekturprojekt, der kræver lidt mere forarbejde, men ikke mere ventetid.

Sat op mod hinanden i tal: ML-KEM har allerede fuld eller delvis support i mindst seks store biblioteker, en standardiseret hybridgruppe i X25519MLKEM768, og tre parametersæt hvor det midterste niveau er blevet branchens de facto-valg. ML-DSA har samme biblioteksdækning og den samme treniveau-struktur, men mangler stadig en bredt udbredt hybrid-signaturmekanisme og bærer en signaturstørrelse, der ifølge Det Hvide Hus’ tal er flere gange større end klassisk RSA eller ECDSA, afhængigt af hvilket niveau man sammenligner med. Det er den konkrete forskel, der bør styre, hvilken standard man ruller ud først, ikke en generel fornemmelse af, hvad der lyder vigtigst.

Ofte stillede spørgsmål

Hvad er forskellen mellem ML-KEM og ML-DSA?

ML-KEM bruges til at etablere en delt hemmelig nøgle mellem to parter (nøgleindkapsling), mens ML-DSA bruges til digitale signaturer og beviser identitet eller integritet. De løser forskellige dele af et sikkert system og bruges typisk sammen, ikke i stedet for hinanden, ligesom RSA-nøgleudveksling og RSA-signaturer historisk har eksisteret side om side.

Er Kyber og Dilithium det samme som ML-KEM og ML-DSA?

Ja. CRYSTALS-Kyber blev omdøbt til ML-KEM, og CRYSTALS-Dilithium blev omdøbt til ML-DSA, da NIST gjorde dem til endelige standarder i august 2024. Navneskiftet afspejler, at algoritmerne gik fra forskningskandidater til officielle FIPS-standarder, men den underliggende matematik er den samme.

Hvornår blev ML-KEM og ML-DSA officielle NIST-standarder?

Begge blev endeligt godkendt i august 2024 som henholdsvis FIPS 203 (ML-KEM) og FIPS 204 (ML-DSA), sammen med SLH-DSA som FIPS 205. Siden da har NIST og andre myndigheder arbejdet på at opdatere tilstødende standarder, som PIV-kortspecifikationerne, til at bruge dem.

Understøtter min browser allerede ML-KEM?

Browsere baseret på BoringSSL, som Chrome, understøtter ML-KEM-768 i hybridform. Understøttelsen varierer dog mellem browsere og biblioteker, så det bør tjekkes konkret for den enkelte platform og version, man bruger, før man regner med, at alle besøgende automatisk får post-quantum-beskyttelse.

Hvorfor er ML-DSA-signaturer så meget større end RSA- eller ECC-signaturer?

Det skyldes den underliggende matematik. Gitterbaserede signaturer som ML-DSA kræver mere data for at opnå samme sikkerhedsniveau som klassiske algoritmer. Det amerikanske OMB-migrationsdirektiv beskriver ML-DSA-signaturer som typisk 1-2 KB, langt over de 64-512 byte man kender fra RSA og ECDSA, hvilket kan mærkes i certifikatkæder med flere led.

Skal jeg vente med at migrere til post-quantum kryptografi?

NIST og Det Hvide Hus’ migrationsdirektiv anbefaler begge aktiv planlægning nu, ikke senere. Standarderne er færdige, bibliotekerne er tilgængelige, og flere store aktører har allerede implementeret dem i produktion. Risikoen ved “harvest now, decrypt later” betyder desuden, at data krypteret med klassiske algoritmer i dag kan være sårbar, selv hvis migrationen afventer.

Hvilke biblioteker understøtter begge standarder fuldt ud i 2026?

OpenSSL 3.5, wolfSSL 5.7+, liboqs 0.10+ og Bouncy Castle 1.79 understøtter alle seks parametersæt af ML-KEM og ML-DSA. BoringSSL og AWS-LC har mere selektiv eller delvis support, afhængigt af hvilket parametersæt man efterspørger.

Hvad er SLH-DSA, og hvordan relaterer det sig til ML-DSA?

SLH-DSA (FIPS 205, baseret på SPHINCS+) er en konservativ reservesignatur-standard, der bruger et andet matematisk fundament end ML-DSA, nemlig hashfunktioner i stedet for gitterproblemer. Den er tiltænkt som backup, hvis der skulle opstå svagheder i gitterbaserede algoritmer som ML-DSA, og bruges derfor ofte sammen med eller som alternativ til ML-DSA i højsikkerhedsmiljøer som PKI til offentlige id-kort.