De flesta rubriker säger att postkvantkryptografi (PQC) är på väg. Men för Microsoft-användare är det redan här. Under de senaste två åren har Microsoft gradvis introducerat PQC-stöd för Windows, Windows Server och Azure, med flera funktioner nu allmänt tillgängliga från och med mitten av 2026.
Den här bloggen går igenom vad Microsoft faktiskt tillkännagav i sin senaste Windows post-quantum-uppdatering, hur det passar in i utrullningen som startade 2024 och vad det innebär för hur din organisation planerar sin egen PQC-migrering.
Hur Microsoft hamnade här
Microsofts PQC-arbete körs genom SymCrypt, det centrala kryptografiska biblioteket under Windows, Azure och Microsoft 365. SymCrypt är det som faktiskt utför kryptering, dekryptering, signering och nyckelutbyte inom Microsofts resurser, och det har genomgått flera FIPS 140-valideringar som en del av Windows Cryptographic Primitives Libraries.
Utrullningen har skett i tydliga, sekventiella steg:
- September 2024: SymCrypt lade till stöd för ML-KEM (FIPS 203, tidigare känt som Kyber) och XMSS, de första PQC-algoritmerna som finns i biblioteket.
- December 2024: Microsoft lade till ML-DSA (FIPS 204, tidigare Dilithium) och LMS till SymCrypt, vilket kompletterar kärnsignaturalgoritmerna tillsammans med det nyckelinkapslingsarbete som redan finns på plats.
- Maj 2025: PQC-funktioner nådde Windows Insiders (Canary Channel) och SymCrypt-OpenSSL 1.9.0 på Linux, vilket låter kunder börja experimentera med ML-KEM och ML-DSA i sina egna miljöer via Cryptography API: Next Generation (CNG) på Windows och SymCrypt-leverantören för OpenSSL (SCOSSL) på Linux.
- November 2025: ML-KEM och ML-DSA blev allmänt tillgängliga på Windows Server 2025 och Windows 11 via CNG och certifikatfunktioner, vilket gav utvecklare produktionsåtkomst till nyckelinkapsling och digitala signaturer.
- Maj 2026: Active Directory Certificate Services (AD CS) på Windows Server 2025 blev allmänt tillgängligt för utfärdande av ML-DSA-certifikat, vilket gjorde PQC direkt till enterprise public key infrastructure (PKI), inte bara till lågnivåkrypto-API:er.
Det är sammanhanget bakom det senaste tillkännagivandet. Det är inte en enskild funktionsnedsläpning. Det är nästa steg i en avsiktlig, flerårig sekvens som började med de kryptografiska primitiverna, gick vidare genom utvecklarriktade API:er och nu har nått PKI- och TLS-lagren som de flesta företag faktiskt är beroende av dagligen.
Med den sekvensen i åtanke, här är exakt vad som har passerat gränsen för allmän tillgänglighet idag.
Vad som är allmänt tillgängligt just nu
Två områden har helt övergått till produktionsanvändning: certifikatutfärdande via AD CS och direkt algoritmåtkomst för utvecklare via Cryptography Next Generation API (CNG).
ML-DSA-certifikatutfärdande via AD CS
Från och med maj 2026 kan AD CS på Windows Server 2025 hantera en ML-DSA-certifikatutfärdarhierarki och utfärda ML-DSA-certifikat för kodsignering, TLS, webbserver, användar- och datormallar samt OCSP- svarssignering. AD CS stöder alla tre NIST -definierade parameteruppsättningar: ML-DSA-44, ML-DSA-65 och ML-DSA-87, vilket låter administratörer byta signatur- och nyckelstorlek mot säkerhetsstyrka beroende på användningsfall.
Det finns en viktig operativ begränsning här, och den formar hela migreringsprojektet: Microsofts egen AD CS-dokumentation går igenom konfigurationen av en CA:s algoritm när du skapar den, med hjälp av Install-AdcsCertificationAuthority med en ML-DSA-kryptografisk leverantör specificerad i förväg, för både rot- och underordnad CA.
AD CS stöder inte äldre kryptografiska tjänsteleverantörer (CSP:er) för någon PQC-algoritm, så alla certifikatmallar eller HSM-integrationer ( Hardware Security Module ) som fortfarande är kopplade till en äldre CSP måste först flyttas till CNG, innan PQC överhuvudtaget kommer in i bilden.
ML-KEM och ML-DSA genom CNG
Sedan uppdateringen i november 2025 har utvecklare haft produktionsåtkomst till ML-KEM för scenarier som behöver nyckelinkapsling eller nyckelutbyte, och till ML-DSA för scenarier med digital signatur, identitetsverifiering och integritetskontroll, allt genom samma kryptografi-API: Nästa generations bibliotek som Windows-utvecklare redan använder för klassiska algoritmer.
Obs: Microsofts dokumentation listar ML-DSA som den enda PQC-algoritmen som är tillgänglig i AD CS idag. ML-KEM-stöd i AD CS, tillsammans med sammansatt ML-DSA och sammansatt ML-KEM, är dokumenterat som planerat för en senare fas snarare än levererat ännu.
Den sista punkten är värd att begrunda, eftersom den leder direkt till det som ännu inte är avslutat.
Vad som fortfarande finns i förhandsgranskning
Ytterligare två delar arbetar fortfarande mot allmän tillgänglighet: hybridnyckelutbyte i TLS-stacken och stöd för sammansatta algoritmer för att kombinera klassisk och postkvantkryptografi i en enda operation.
TLS Hybrid Key Exchange
Windows TLS-stack, Schannel, stöder nu hybridnyckelutbyte som parar ihop en klassisk algoritm med ML-KEM. Detta är nu tillgängligt via Windows Insider Program, med allmän tillgänglighet för Windows 11 och Windows Server 2025 förväntad i en framtida Windows-version. De kombinationer som stöds är X25519 med ML-KEM-768, NIST P-256 med ML-KEM-768 och NIST P-384 med ML-KEM-1024 för en högre säkerhetsnivå. IT-administratörer kan konfigurera dessa på samma sätt som de redan konfigurerar befintliga TLS-kurvor, via grupprincip för domänanslutna miljöer, Mobile Device Management (MDM)-plattformar som Intune eller TLS PowerShell-cmdlets för skriptade konfigurationer.
Resonemanget bakom hybrid , snarare än att hoppa direkt till enbart ML-KEM, är samma resonemang som alla större standardiseringsorgan har enats om: att para ihop en klassisk algoritm med en post-kvant algoritm innebär att en angripare måste bryta båda halvorna av anslutningen för att kompromettera den, inte bara den nyare, mindre stridstestade halvan. Detta riktar sig direkt mot risken att skörda nu, dekryptera senare (HNDL), där en angripare fångar krypterad trafik idag med avsikt att dekryptera den när en tillräckligt kraftfull kvantdator finns, vilket är viktigast för data som måste förbli konfidentiella i åratal.
Stöd för sammansatt algoritm
Microsoft har flaggat för bredare stöd för sammansatta algoritmer, genom att kombinera den klassiska ECDSA-algoritmen med ML-DSA, och det klassiska ECDHE-nyckelutbytet med ML-KEM, som planerat för senare i år. Detta följer IETF:s utkast till arbete med sammansatt ML-DSA och sammansatt ML-KEM. Sammansatta metoder är viktiga eftersom de låter en enda kryptografisk operation integrera både en klassisk och en postkvantkomponent direkt, vilket abstraherar komplexiteten i att kombinera två algoritmer korrekt, snarare än att låta varje applikationsutvecklare implementera den kombinationslogiken själva. När detta väl är klart utökar det PQC-stödet bortom signeringsscenarier till bredare certifikatinteroperabilitet.
Allt som hittills har täckts har varit Windows-centrerat, men Microsofts PQC-arbete sträcker sig långt bortom Windows självt.
Linux- och Azure-sidan
Microsofts PQC-arbete har aldrig varit enbart för Windows. SymCrypt körs också som en backend-leverantör för OpenSSL på Linux genom SCOSSL (SymCrypt-leverantören för OpenSSL), som Microsoft använder för att få FIPS 140-3-kompatibel kryptografi till Azure Linux och Azures molntjänster för myndigheter. SCOSSL 1.9.0 gav samma ML-KEM- och ML-DSA-stöd till Linux som Windows Insiders fick ungefär samtidigt i mitten av 2025, och Microsofts egen Go runtime-version har uppdaterats för att dra nytta av SCOSSLs FIPS 140-3-kompatibla PQC-implementering när den körs på Azure Linux.
Detta är viktigt av en enkel anledning: de flesta Microsoft-företagsmiljöer är inte rena Windows-miljöer. Om dina Azure-arbetsbelastningar körs på Linux, eller om din byggpipeline är beroende av Microsofts Go-verktygskedja, gäller samma underliggande SymCrypt PQC-arbete även där, vilket innebär att din migreringsplanering måste ta hänsyn till båda sidor av miljön snarare än att behandla Windows och Azure Linux som separata problem.
Att veta vad som är tillgängligt är bara användbart om du också vet hur Microsoft förväntar sig att du ska lansera det.
Vad Microsoft ber kunderna att göra nu
Microsofts egna riktlinjer, som går igen i alla dessa tillkännagivanden, är konsekventa: de mest effektiva migreringarna sker i etapper, inte genom att göra enskilda övergångar. Den rekommenderade utgångspunkten är densamma som alla andra PQC-migreringsramverk konvergerar kring. Inventering där kryptografi med offentlig nyckel faktiskt används i din miljö, med början i de system som är mest utsatta för långsiktig sekretessrisk: dokumentarkiv som SharePoint, e-postarkiv, databassystem och säkerhetskopiering eller arkivlagring, inklusive både säkerhetskopior på enheten och i molnet.
Därifrån är Microsofts vägledning att prioritera system som skyddar känsliga data med långa konfidentialitetsgränser, och att testa hybrid- och sammansatta konfigurationer i icke-produktionsmiljöer innan de implementeras i kundorienterade miljöer. Detta överensstämmer med den bredare hybrid-först-strategin som NIST, NSA och i praktiken alla standardiseringsorgan nu rekommenderar: behandla hybrid som standardarbetsläge under övergångsperioden, inte som ett valfritt extra lager ovanpå den "riktiga" PQC-implementeringen.
En praktisk detalj värd att nämna: Microsofts hybrida post-quantum TLS-implementering är byggd på TLS 1.3 . Om delar av er administration fortfarande körs på äldre TLS-versioner måste den uppgraderingen ske innan något av detta PQC-arbete blir relevant, vilket är en användbar tvångsfunktion om er organisation har skjutit upp en TLS 1.3-migrering.
Genom att ta ett steg tillbaka från Microsoft specifikt är denna lansering också en användbar förhandsvisning av vad som kommer i hela branschen.
Varför detta är viktigt utöver Windows specifikt
Windows och Azure ligger under en enorm andel av företagsinfrastruktur, identitetssystem och PKI-distributioner. När Microsoft flyttar utfärdande av ML-DSA-certifikat från förhandsvisning till allmän tillgänglighet i AD CS är det inte en nischfunktion för utvecklare. Det är grunden som de flesta företagscertifikatutfärdare, kodsigneringspipelines och interna TLS-distributioner bygger på, och når produktionsberedskap för postkvantalgoritmer.
Det betyder också att de begränsningar som Microsoft har byggt in i denna utrullning – inga CA-uppgraderingar på plats, stöd för endast CNG, hybrid som standard TLS-position – är en rimlig förhandsvisning av de begränsningar som de flesta organisationer kommer att stöta på oavsett vilken leverantörs PKI de använder. Mönstret är detsamma som syns i hela branschen: parallell infrastruktur under övergången, hybridkryptografi som säkrare standard och en etappvis utrullning som börjar med kryptografiska primitiver och slutar med fullt PKI- och TLS-stöd.
Det är precis det bredare mönstret där extern hjälp tenderar att vara viktigast, oavsett vilken plattform din egendom drivs på.
Hur krypteringskonsulting kan hjälpa
Encryption Consulting specialiserar sig på PKI-strategi , ADCS-arkitektur och hantering av certifikatlivscykeln för företag och myndigheter. Oavsett om du distribuerar ADCS för första gången, moderniserar en äldre PKI, utvärderar din certifikatinfrastruktur för ESC-sårbarheter eller integrerar ADCS med moderna DevOps-verktyg, bidrar vårt team med djupgående expertis på protokollnivå till varje uppdrag.
- PKI-hälsobedömningar: Protokollnivågranskningar av din ADCS-miljö mot Microsoft Open Specifications och säkerhetsstandarder
- ADCS-arkitekturdesign: Design av registreringsstack (MS-WCCE, MS-XCEP/MS-WSTEP, NDES/SCEP), planering av CA-hierarki och styrning av certifikatmallar
- Hantering av certifikatlivscykel: Automatiserad identifiering, övervakning och förnyelse av certifikat i hela företaget
- Säkerhetshärdning: Åtgärdning av ESC-felkonfigurationer, härdning av CA-roller och optimering av CRL/OCSP-infrastruktur
Slutsats
Microsofts post-quantum-utrullning är en av de tydligaste signalerna som finns just nu att PQC-migreringen har gått ur planeringsstadiet och in i produktionsinfrastrukturen som företag redan är beroende av varje dag. Utfärdande av ML-DSA-certifikat är generellt tillgängligt. ML-KEM och ML-DSA är generellt tillgängliga via CNG. TLS hybridnyckelutbyte är i förhandsvisningsfas med allmän tillgänglighet förväntas snart, och stöd för sammansatta algoritmer är på väg senare i år.
Inget av detta eliminerar behovet av en egen migreringsplan. Det betyder att om du kör Windows eller Azure behöver du inte längre bygga en meningsfull del av den underliggande infrastrukturen själv. Det arbete som återstår är inventering, sekvensering och testning, vilket är precis där en strukturerad PQC-beredskapsgranskning förtjänar sin plats.
