Post-kvantkryptografi kommer till AD CS: Vad ML-DSA-stöd verkligen betyder för din Microsoft PKI

Den 12 maj 2026 lanserade Microsoft en av de mest betydelsefulla ändringarna i Active Directory Certificate Services över tjugoåriga historia. Säkerhetsuppdateringen 2026-05 för Windows Server 2025 (KB5087539) gör det möjligt för AD CS att bygga certifikatutfärdare, utfärda certifikat och signera OCSP-svar med hjälp av ML-DSA, den modullatticebaserade digitala signaturalgoritmen som standardiserats av NIST i FIPS 204. Det är den första postkvantalgoritmen som når allmän tillgänglighet i Microsofts inbyggda certifikatutfärdare.

Det spelar ingen roll bortom kryptografin. AD CS förankrar i tysthet certifikatutfärdandet i en mycket stor andel av världens företags Windows-system: domänautentisering, smartkort, enhetsregistrering, intern TLS, kodsignering . I åratal var den allmänna uppfattningen att AD CS befann sig i underhållsläge och att all allvarlig kryptografisk modernisering skulle behöva ske någon annanstans. Utgivningscykeln 2025-2026 vänder på den berättelsen. I den här artikeln analyserar vi vad som levererades, kryptografin bakom den, vad som fungerar idag och vad som inte gör det, de regulatoriska deadlines som driver allt detta och en pragmatisk fasindelad tidslinje som ditt PKI-team kan planera mot.

Snabbt svar: Vad är ML-DSA-stöd i AD CS?

ML-DSA (FIPS 204) är NIST:s post-kvantum digitala signaturalgoritm som nu är tillgänglig i AD CS på Windows Server 2025 via KB5087539 (maj 2026) . Den är endast signaturbaserad , kräver en ny parallell CA-hierarki (ingen migrering på plats) och täcker kodsignering, OCSP och intern certifikatutfärdande. TLS-sessionskonfidentialitet kräver ML-KEM (planerad fas 2). NIST IR 8547 förbjuder alla kvantumsårbara algoritmer efter 2035.

Key Takeaways

• Säkerhetsuppdateringen från maj 2026 (KB5087539) introducerar ML-DSA (NIST FIPS 204 post-kvantumsignaturalgoritm) till AD CS på Windows Server 2025. Certifikatutfärdare, certifikatmallar och onlinesvarare kan nu signera med kvantumresistenta nycklar.
• ML-DSA är endast signaturbaserad. Den skyddar mot framtida förfalskning av certifikat och kodsignaturer; den gör inte TLS-sessioner eller krypterad data kvantsäkra. Det kräver ML-KEM, som Microsoft har planerat för en senare fas tillsammans med sammansatta certifikat.
• Det sker ingen migrering på plats. Befintliga CA:er kan inte konverteras till ML-DSA: man skapar en ny, parallell hierarki. Det gör tidigt labarbete billigt och prokrastinering dyrt.
• Den reglerande klockan är fast även om kvantklockan inte är det: NIST planerar att avveckla RSA-2048 och ECDSA P-256 efter 2030 och förbjuda alla kvantumsårbara algoritmer med offentlig nyckel efter 2035. Förtroendeankare som utfärdas idag överlappar redan dessa datum.
• Det praktiska första steget är inte ett algoritmbyte: det är en kryptografisk inventering och ett automatiseringslager som gör det slutliga bytet till en konfigurationsändring istället för ett flerårigt projekt.
• Företag ligger efter i hela branschen: DigiCerts Quantum Readiness Outlook från juli 2026 visade att 87 % av organisationerna planerar, testar eller implementerar PQC, men endast 7 % har implementerat kvantsäker eller hybridkryptografi för de flesta av sina certifikat. AD CS fas 1-utgåva ger Windows-centrerade företag ett konkret, Microsoft-nativt sätt att börja täppa till det gapet.

Vem borde bry sig om ML-DSA i AD CS

ML-DSA-stöd i AD CS är inte ett beslut som fattas av enskilt team. PKI-ingenjörer äger den tekniska implementeringen, men säkerhetsarkitekter, compliance-team, DevSecOps-ingenjörer och CISO:er har var och en olika ansvarsområden för att säkerställa att organisationens CA-hierarki, certifikattillgångar och kodsigneringspipelines är korrekt positionerade inför NIST IR 8547-deadlines 2030 och 2035.

Roll	Varför det gäller	Åtgärdsobjekt
PKI-ingenjörer och certifikatteam	Ansvarar för den tekniska implementeringen av den parallella ML-DSA CA-hierarkin: CA-installation, mallkonfiguration, OCSP-installation, registreringstestning och NoHash-fällan i skriptade installationer; de fem mallinställningarna som styr ML-DSA (CNG KSP, signaturändamål, ingen nyckelkryptering, inga EFS/S/MIME EKU:er, kompatibilitetsnivå) måste alla vara korrekta, annars försvinner ML-DSA tyst från fliken Kryptografi; CyberArks rapport om maskinidentitetssäkerhet från 2025 fann att 34 % av organisationerna fortfarande hanterar certifikatlivscykler manuellt, och en parallell ML-DSA-hierarki som drivs utan CLM-automatisering kommer inte att skalas till massmigreringsfasen.	Tillämpa KB5087539 på en Windows Server 2025-labb-CA och KB5067036 för att testa klienter före produktionsarbete; upprätta en tvånivås ML-DSA-labbhierarki (rot-CA + utfärdande CA) och validera mall, registrering, OCSP och Authenticode från början till slut; lägg till den parallella hierarkin till CertSecure-hanterare för enhetlig inventering och förnyelsespårning tillsammans med den klassiska egendomen; bygga den kryptografiska inventeringen av den befintliga klassiska egendomen med hjälp av CBOM-säkerhet innan du vidrör produktionen; engagera PKI som en tjänst om den interna PKI-teknikkapaciteten är otillräcklig för att driva två samtidiga hierarkier
Säkerhetsarkitekter	Äg styrningsmodellen för PQC-övergången: definiera vilka arbetsbelastningar som flyttas till ren ML-DSA nu (sluten kodsignering, OCSP, intern attestering), vilka som väntar på sammansatta certifikat (blandade förtroendesökvägar) och vilka som väntar på fas 2 (publik TLS, inloggning med smartkort, NDES-enhetscertifikat); hotet "harvest now-decrypt-late" innebär att övergångens tidslinje inte styrs av när kvantdatorer anländer utan av giltighetstider för förtroendeankare som utfärdats idag; en 20-årig rot som utfärdats 2026 är fortfarande aktiv år 2046, elva år efter förbudsdatumet 2035.	Definiera policyn för arbetsbelastningsklassificering med hjälp av den 8-radiga beslutsmatrisen i den här artikeln; specificera HSM-krav för produktions-ML-DSA-CA:er (verifiera ML-DSA CNG KSP-stöd och FIPS 140-3-valideringsstatus med HSM-leverantörer innan du genomför validering); utforma den parallella hierarkiarkitekturen (offline-rot-CA, utfärdande CA, CDP/AIA, OCSP) för PQ-egendomen; planera den sammansatta certifikatimplementeringsvägen för fas 2 så att migreringar av förlitande parter med blandade förtroenden utformas innan fas 2 levereras; spåra planeringen av algoritmmigrering genom PQC:s kompetenscentrum
DevSecOps och kodsigneringsteam	Egna interna kodsignerings- och firmwaresigneringspipelines, vilka är de mest trovärdiga arbetsbelastningarna för första produktionen för en PQ-hierarki under fas 1: Authenticode (Set-AuthenticodeSignature/Get-AuthenticodeSignature) och .NET 10 MLDsa/MLDsaCng API:er fungerar från början till slut i en sluten loop som organisationen kontrollerar helt och hållet; kodsignering är också en av de mest långlivade signeringsapplikationerna (en signerad binärfil som verifierats om några år måste vara kopplad till ett förtroendeankare som fortfarande är oförfalskbar vid verifieringstillfället), vilket gör det till en av de högst prioriterade arbetsbelastningarna att flytta till ML-DSA.	Pilotera ML-DSA Authenticode-kodsignering i labbhierarkin och validera hela signerings-verifieringscykeln med Set-AuthenticodeSignature och Get-AuthenticodeSignature på uppdaterade Windows 11 24H2/25H2-klienter; bygg en kompatibilitetsmatris för förlitande parter (Windows-versioner, OpenSSL 3.5+, Java, macOS, nätverksapparater, CI/CD-körprogram) innan ML-DSA-kodsignering uppgraderas till produktion; integrera livscykelhantering för ML-DSA-signeringscertifikat i CI/CD-pipelinens automatisering; utvärdera CodeSign Secure för policydrivna, HSM-baserade ML-DSA-signeringsarbetsflöden över Windows-, Linux-, macOS- och CI/CD-pipelines
Compliance- och GRC-team	Måste bekräfta att organisationen har ett dokumenterat program efter kvantmigrering innan trycket från NIST IR 8547-avskrivningen börjar materialiseras i revisioner; ISACA:s Quantum Computing Pulse Poll från april 2025 fann att endast 5 % av organisationerna har en definierad kvantberäkningsstrategi; reglerade branscher inklusive federala myndigheter (CNSA 2.0, upphandlingskrav 2027), hälso- och sjukvård, finansiella tjänster och försvar kan möta ramverksspecifika PQC-beredskapskrav före NIST-deadline 2030; DigiCerts Quantum Readiness Outlook från juli 2026 fann att endast 7 % av organisationerna har implementerat kvantsäker eller hybridkryptografi över de flesta av sina certifikat.	Bekräfta att organisationen har en dokumenterad färdplan för PQC-migrering som är anpassad till NIST IR 8547 och tillämpliga ramverkskrav (CNSA 2.0 för federal, DORA för finansiell, CMMC för försvar); inkludera PQC-migreringsförloppet i det kvartalsvisa efterlevnadspaketet: fullständighet i kryptografisk inventering, status för parallell hierarki-labb, täckning av arbetsbelastningsklassificering och HSM-valideringsplan; mappa NIST IR 8547-deadlines (avveckling 2030, förbjuden 2035) till interna efterlevnadsmilstolpar; utvärdera PQC-beredskap tjänster för en strukturerad bedömning och färdplan
CISO: er	PQC-övergången är en risk på styrelsenivå eftersom efterlevnadskalendern är fast oavsett när kvantdatorer anländer: långlivade förtroendeankare som utfärdas inom klassisk kryptografi idag kommer fortfarande att vara i drift när deadlines 2030 och 2035 når; DigiCerts Quantum Readiness Outlook från juli 2026 fann att 87 % av organisationerna planerar eller pilottestar PQC men endast 7 % har driftsatt i stor skala; KB5087539 tar bort blockeraren "Microsoft har inte levererat något än" för Windows-centrerade organisationer, vilket gör frånvaron av ett PQC-program nu till en medveten riskacceptans snarare än ett teknikgap.	Finansiera PQC-programmet som en strategisk investering: kryptografisk inventering (fas 0), validering av labbhierarki (fas 1) och utbyggnad av CLM-automation (fas 2-4) kräver dedikerad personalstyrka och budget som bör finnas med i planen nu, inte 2029; kräv att PQC-migreringsförloppet (kryptografisk inventeringstäckning, status för parallell hierarki, procentandel av arbetsbelastningsmigrering) rapporteras som en nyckeltal på styrelsenivå kvartalsvis; utvärdera PKI som en tjänst för organisationer som behöver en fullständigt hanterad ML-DSA-hierarki på FIPS 140-3 nivå 3 HSM:er utan att bygga och driva infrastrukturen internt; kräva att planen efter kvantmigrering granskas vid den årliga PKI-programgranskningen mot NIST IR 8547-tidslinjen.

En tyst uppdatering med högljudda implikationer

Det spelar ingen roll bortom kryptografin. AD CS förankrar i tysthet certifikatutfärdandet i en mycket stor andel av världens företags Windows-system: domänautentisering, smartkort, enhetsregistrering, intern TLS, kodsignering . I åratal var den allmänna uppfattningen att AD CS befann sig i underhållsläge och att all allvarlig kryptografisk modernisering skulle behöva ske någon annanstans. Utgivningscykeln 2025-2026 (CRL-partitionering, granskningsförbättringar och nu PQC) vänder på den berättelsen. Microsofts budskap är entydigt: den inbyggda certifikatutfärdaren är en deltagare i post-kvantumövergången, inte ett offer för den.

I den här bloggen analyserar vi vad som levererades, kryptografin bakom det, vad som fungerar idag och vad som inte fungerar, de regulatoriska deadlines som driver allt detta, och en pragmatisk, etappvis tidslinje som ditt PKI-team kan planera mot.

Varför postkvantkryptografi behövs, och varför PKI är först i tur

Varje certifikat som din CA utfärdar idag vilar på RSA eller elliptisk kurvmatematik. Båda hämtar sin säkerhet från problem (heltalsfaktorisering och diskreta logaritmer) som en tillräckligt stor, feltolerant kvantdator som kör Shors algoritm skulle lösa effektivt. Symmetrisk kryptografi klarar sig mycket bättre: Grovers algoritm halverar bara den effektiva nyckelstyrkan, så AES-256 och SHA-2 förblir bekvämt säkra. Det existentiella problemet är koncentrerat just där PKI finns: asymmetriska nycklar och digitala signaturer.

Ingen kan ange året då en kryptografiskt relevant kvantdator anländer. Men risken är redan verksam idag, av två olika skäl:

• Samla nu, dekryptera senareMotståndare spelar in krypterad trafik och stulen chiffertext idag med avsikt att dekryptera den när kvantkapaciteten mognar. All data vars sekretess måste överleva kvanthorisonten (hälsojournaler, immateriella rättigheter, statshemligheter) exponeras effektivt i det ögonblick den korsar ett kvantsårbart nyckelutbyte.
• Långlivat förtroende. Detta är det PKI-specifika problemet, och det handlar om signaturer snarare än sekretess. Ett rot-CA-certifikat som utfärdats 2026 med en giltighetsperiod på femton eller tjugo år måste förbli oförfalskbart fram till 2041 eller framåt. En kodsignering eller firmware-signatur som tillämpas idag kommer att verifieras av förlitande parter om flera år. Om den underliggande algoritmen faller inom det fönstret kan en angripare skapa bedrägliga certifikat och förfalska uppdateringar som är perfekt kopplade till dina förtroendeankare: vilket retroaktivt förgiftar allt som byggts på dem.

Kör på aritmetiken så slutar brådskan att vara teoretisk. Förtroendeankare är de längstlivade kryptografiska artefakterna i alla företag. En klassisk rot som skapas idag satsar på att kvantberäkning inte mognar på ytterligare två decennier, en satsning som NIST, NSA och Microsoft alla offentligt har avböjt att ta.

Standarderna bakom skiftet

I augusti 2024, efter en åtta år lång global konkurrens, färdigställde NIST sina tre första postkvantstandarder. Alla bygger på matematiska problem (främst strukturerade gitter) för vilka ingen effektiv kvantalgoritm är känd:

Standard	Algoritm (härstamning)	Syfte	Status i Windows
FIPS 204	ML-DSA (KRISTALLER-Dilitium)	Digitala signaturer	GA, och bor nu i AD CS
FIPS 203	ML-KEM (CRYSTALS-Kyber)	Nyckelinkapsling / nyckelutbyte	GA i CNG API:er; AD CS-stöd planerat (fas 2)
FIPS 205	SLH-DSA (SPHINCS+)	Statslösa hashbaserade signaturer	Tillgänglig i Microsofts kryptobibliotek; inte en AD CS-algoritm idag

En fjärde signaturstandard, FN-DSA (baserad på Falcon), är fortfarande under utveckling. För PKI-planering för företag är den viktiga parningen enkel: ML-DSA ersätter RSA/ECDSA för signering; ML-KEM ersätter RSA-kryptering och (EC)DH för nyckeletablering. AD CS fas 1 levererar den första halvan av den parningen.

Klockan du faktiskt tävlar mot

Det ärliga svaret på frågan "när kommer kvantdatorer att bryta RSA?" är att ingen vet. Svaret på regelefterlevnaden är mycket mer konkret, eftersom tillsynsmyndigheterna har beslutat att inte vänta på säkerhet. Tre tidslinjer sammanfaller nu inom samma decennium:

Datum	Milestone
Augusti 2024	NIST slutför FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA).
November 2024	NIST IR 8547 (utkast), Övergång till post-kvantkryptografistandarder, publicerar avvecklingsfärdplanen för RSA, ECDSA, ECDH, DSA och ändfälts-DH.
2025	Microsoft tillkännager sitt Quantum Safe-program och levererar PQC-algoritmer via SymCrypt och CNG API:er till Windows Insiders; Linux-stöd följer via SymCrypt-OpenSSL.
Okt-nov 2025	PQC blir allmänt tillgängligt i Windows Server 2025, Windows 11 24H2/25H2 (klientaktivering via KB5067036) och .NET 10.
May 12, 2026	AD CS ML-DSA-stöd GA på Windows Server 2025 via säkerhetsuppdatering KB5087539.
2027	NSA CNSA 2.0Nya förvärv för amerikanska nationella säkerhetssystem måste stödja kvantresistenta algoritmer.
2029	Microsofts uttalade mål för tidigt PQC-implementering i sina egna produkter och tjänster.
2030	NIST IR 8547: algoritmer på 112-bitars säkerhetsnivå (RSA-2048 och ECDSA P-256) är föråldrade. Fortsatt användning kräver dokumenterad riskacceptans.
2033	Microsofts mål att slutföra övergången till PQC, två år före den federala tidsfristen.
2035	NIST IR 8547 / NSM-10: alla kvantumsårbara publika nyckelalgoritmer (RSA vid valfri nyckelstorlek, ECDSA, ECDH, DSA, FFDH) är inte tillåtna. Inget riskacceptansalternativ kvarstår.

Lägg nu över dina egna certifikatlivslängder i den tabellen. En 20-årig rot som utfärdades 2026 löper ut 2046, elva år efter avstängningsdatumet. En 10-årig utfärdande CA som skapades nästa år fungerar fortfarande när RSA-2048 blir ett dokumenterat granskningsresultat. Det är därför Microsoft först levererade CA-support: de objekt med längst livslängd i hierarkin är de som måste flyttas tidigast.

Beredskapsgapet: Vad den senaste datan visar

Tre oberoende undersökningar som publicerats under de senaste arton månaderna kommer samman om samma slutsats: medvetenheten om post-kvantövergången är hög, men inte implementeringen.

• ISACA:s Quantum Computing Pulse Poll, publicerad 28 april 2025 från svar från fler än 2 600 globala experter inom digitalt förtroende, cybersäkerhet, IT-revision och risk, fann att 62 % oroar sig för att kvantberäkning kommer att bryta dagens kryptering, men endast 5 % säger att deras organisation har en definierad strategi eller färdplan för kvantberäkning.
• DigiCerts andra årliga kvantberedskapsprognos, publicerad 23 juli 2026 från en undersökning av 1 001 IT- och cybersäkerhetsbeslutsfattare i USA, Storbritannien och Australien, fann att 87 % av organisationerna planerar, testar eller implementerar PQC-initiativ, men endast 7 % rapporterar kvantsäker eller hybridkryptografi för mer än hälften av sina digitala certifikat: en ökning med mindre än två procentenheter från de 5 % som DigiCert mätte i maj 2025.
• CyberArks rapport om maskinidentitetssäkerhetens tillstånd 2025, publicerad 13 mars 2025 från en undersökning av 1 201 säkerhets- och IT-beslutsfattare, fann att 72 % av organisationerna upplevde minst ett certifikatrelaterat avbrott under 2024, medan 34 % fortfarande hanterar maskinidentitetslivscykler med manuella eller icke-automatiserade metoder.

Sammantaget beskriver dessa siffror det exakta gap som AD CS fas 1-utgåva hamnar i: organisationer vet att övergången är på väg, de flesta har inte implementerat kvantsäker kryptografi i närheten av produktionsskala, och en tredjedel hanterar fortfarande certifikatlivscykler manuellt: samma manuella process som en parallell ML-DSA-hierarki och det krympande giltighetsschemat för offentliga TLS inte tolererar. Att täcka det gapet börjar med upptäcktsarbetet i fas 0 av migreringstidslinjen nedan, inte med själva algoritmbytet; se vår guide om hur man bygger en kryptografisk materiallista för vad det upptäcktsarbetet faktiskt innebär.

Vad Microsoft faktiskt levererade i AD CS

Fas 1 är avsiktligt begränsad: den täcker signeringsplanet för en Microsoft PKI , från början till slut. Mer specifikt kan AD CS på en patchad Windows Server 2025-maskin nu:

• Installera rot-, underordnade-, företags- och fristående certifikatutfärdare vars egna nyckelpar och certifikatsigneringsåtgärder använder ML-DSA, inklusive en fullständig post-kvantkedja när varje nivå använder den.
• Publicera certifikatmallar som utfärdar ML-DSA-lövcertifikat för kodsignering, TLS/webbserver, användar- och datorändamål.
• Registrera dessa certifikat via MMC-snapin-modulen Certificates och certreq.exe, inklusive utvärdering av ACL-mall i autoregistreringsstil.
• Anmäl OCSP svar med ett ML-DSA Online Responder-signeringscertifikat.
• Verifiera och tillämpa Authenticode-kodsignaturer med ML-DSA-certifikat: Set-AuthenticodeSignature och signaturgränssnittet fungerar från början till slut, och .NET 10 exponerar algoritmen för utvecklare via MLDsa/MLDsaCng-klasserna.

Microsoft har publicerat den framtida färdplanen explicit. Supporten kommer i faser, och plattformsteamet har åtagit sig att utöka PQC till alla AD CS-rolltjänster: policyn för certifikatregistrering och registreringswebbtjänster (CEP/CES), NDES och onlinerespondern:

Capability	Standard	Syfte	AD CS-status
ML-DSA (ren)	FIPS 204	PQ digitala signaturer	Tillgänglig nu (fas 1)
ML-KEM	FIPS 203	PQ-nyckelinkapsling	Planerad (fas 2)
Sammansatt ML-DSA	IETF LAMPS-utkast	Klassisk + PQ-signatur i ett certifikat	Planerad (fas 2)
Komposit ML-KEM	IETF LAMPS-utkast	Klassisk + PQ-nyckelinkapsling	Planerad (fas 2)
CEP / CES / NDES / OCSP rolltjänsttäckning	-	PQ-registrering och återkallelse av VVS	Engagerad; anländer stegvis

Plattformsbaslinje. PQC i AD CS kräver Windows Server 2025 med säkerhetsuppdateringen 2026-05 (KB5087539) eller senare på certifikatutfärdaren, och Windows 11 24H2/25H2 med uppdateringen 2025-10 (KB5067036) eller senare vid registrering av klienter. Det finns inga tecken på en backport: Windows Server 2019- och 2022-certifikatutfärdare förväntas inte få PQC-stöd. Om dina utfärdande certifikatutfärdare fortfarande körs på äldre plattformar är operativsystemuppgraderingen nu formellt på den kritiska PQC-sökvägen. Alla PQC-algoritmer kräver också CNG Key Storage Providers: äldre CryptoAPI CSP:er stöds inte.

ML-DSA-förutsättningar, konfigurationssteg och vanliga fel

Använd den här tabellen innan du vidrör AD CS-konsolen. Varje rad mappar en förutsättning eller konfigurationsgrind till valideringskontrollen som bekräftar att den är uppfylld, det vanliga felet när den inte är det, återställningen eller korrigeringen och teamet som äger den. Att arbeta igenom den här tabellen i en laboratoriemiljö före produktionsdistribution förhindrar de fem fel som uppstår konsekvent i ML-DSA-distributioner med första kontakt.

Förutsättning / Konfigurationssteg	Valideringskontroll	Vanligt fel om inte uppfyllt	Åtgärda / Återställa	Ägare
Windows Server 2025 + KB5087539 på CA-värd	winver visar Windows Server 2025; wmic qfe get HotFixID listar KB5087539; ML-DSA visas i Server Manager-nyckelalgoritmlistan under CA-installation	ML-DSA-algoritmen listas inte i CA-installationsguiden; Installationen misslyckas med felet "algoritmen stöds inte".	Installera den kumulativa uppdateringen 2026-05 (KB5087539) eller senare; bekräfta att uppdateringen listas i installerade uppdateringar innan du försöker installera CA igen.	PKI-ingenjör / Windows-infrastruktur
Windows 11 24H2/25H2 + KB5067036 om registrering av klienter	I registreringsguiden visar fältet Nyckelstorlek ett verkligt värde (10 496 / 15 616 / 20 736) inte 0; registreringen slutförs och certifikatet visas i Certifikat MMC.	Registreringsguiden listar ML-DSA men misslyckas vid inskickning; Fältet för nyckelstorlek visar 0, vilket indikerar att algoritmen bara delvis lyser i klientens KSP	Bekräfta att KB5067036 är installerat på klienten; installera eventuella väntande kumulativa uppdateringar; försök igen med registreringen efter att du har bekräftat att nyckelstorleken visar ett giltigt värde.	PKI-ingenjör / Desktop / Klientteknik
CNG-nyckellagringsleverantör vald (inte äldre CSP)	På fliken Kryptografi för certifikatmallen är Leverantörskategori nyckellagringsleverantör; ML-DSA visas i algoritmlistan när Syfte är inställt på Signatur.	ML-DSA visas inte på fliken Kryptografi även efter uppdateringen; mallen använder den äldre CryptoAPI CSP-leverantörskategorin.	Ställ in leverantörskategori till nyckellagringsleverantör i mallfliken Kryptografi; ML-DSA visas sedan när Syfte är inställt på Signatur.	PKI-ingenjör
Mallens syfte inställt på Signatur (exakt)	Fliken Hantering av förfrågningar visar Syfte: Signatur; ML-DSA visas i algoritmlistan på fliken Kryptografi; ingen nyckelkryptering eller nyckelavtal i tillägget för nyckelanvändning	ML-DSA försvinner tyst från fliken Kryptografi; inget felmeddelande visas; det enda symptomet är att ML-DSA inte listas trots att CNG KSP är vald.	Öppna fliken Hantering av förfrågningar i mallen och ställ in Syfte till Signatur; ta bort alla värden för Nyckelkryptering, Nyckelavtal eller EFS/S/MIME EKU; ML-DSA visas igen i algoritmlistan.	PKI-ingenjör
NoHash skickades explicit i skriptad CA-installation	CA-installationsskriptet inkluderar -HashAlgorithmName “NoHash”; efter installationen visar certsrv.msc hashalgoritmen NoHash och signaturalgoritmen ML-DSA; pkiview.msc visar att CA är felfri.	CA-installationen misslyckas med hashalgoritmfel eller installeras med SHA-256-hash tillämpad på en ML-DSA-nyckel, vilket producerar ett icke-kompatibelt CA-certifikat; felet kan vara tyst om skriptet inte validerar det resulterande certifikatet.	Lägg till -HashAlgorithmName "NoHash" till PowerShell-cmdlet:en Install-AdcsCertificationAuthority eller motsvarande certutil -installcert; validera den installerade CA-certifikatsignaturalgoritmen innan några certifikat utfärdas; återskapa CA:n om SHA-256 tillämpades på en ML-DSA-nyckel.	PKI-ingenjör / Automation
HSM CNG KSP verifierad för ML-DSA-stöd	HSM-leverantörsdokumentationen bekräftar ML-DSA-stöd i den specifika installerade firmwareversionen; ML-DSA-nyckelgenerering via HSM CNG KSP lyckas i ett test; FIPS 140-3-valideringscertifikatet täcker ML-DSA-algoritmen och den installerade firmwareversionen	HSM misslyckas med att generera ML-DSA-nyckel eller returnerar felet "algoritmen stöds inte" via CNG KSP; CA-installationen misslyckas vid nyckelgenereringssteget.	Verifiera firmwareversion och CNG KSP-integrationsmognad med HSM-leverantören; uppgradera HSM-firmware om ML-DSA-stöd är tillgängligt i en senare version; kör fas 1-labb på Microsoft Software KSP medan du väntar på HSM-validering.	PKI-ingenjör / HSM-administratör

ML-DSA under huven: Vad PKI-ingenjörer bör veta

ML-DSA härstammar från CRYSTALS-Dilithium, den främsta vinnaren av NIST:s tävling. Dess säkerhet vilar på hårdheten hos problemen Module Learning With Errors och Module Short Integer Solution över strukturerade gitter, matematik utan känd effektiv kvantattack. Två av dess egenskaper formar direkt hur AD CS beter sig, så de är värda att internalisera innan du rör en konsol.

Det är en algoritm som endast använder sig av signaturer

ML-DSA kan inte kryptera data och kan inte utföra nyckelutbyte. Detta enda faktum förklarar de flesta av de konfigurationsbegränsningar du kommer att stöta på: mallar måste vara signaturbaserade, användning av nyckelkryptering och nyckelavtal är förbjuden, EFS och säkra e-post-EKU:er avvisas, och TLS- sessionssekretessen förblir orörd tills ML-KEM anländer. Om ett arbetsflöde behöver en nyckel för att skydda data snarare än att bevisa identitet eller integritet , är ML-DSA fel verktyg av design.

Tre parameteruppsättningar, tre avvägningar mellan säkerhet och storlek

AD CS stöder alla tre FIPS 204-parameteruppsättningar, i rent (icke-komposit) läge. Välj baserat på vilken säkerhetskategori du behöver och vilken budget du har råd med:

Parameteruppsättning	NIST-kategori	Offentlig nyckel	Privat nyckel	namnteckning	”Nyckelstorlek” visas i Windows användargränssnitt
ML-DSA-44	Nivå 2	1,312 B	2,560 B	2,420 B	10,496 bitar
ML-DSA-65	Nivå 3	1,952 B	4,032 B	3,309 B	15,616 bitar
ML-DSA-87	Nivå 5	2,592 B	4,896 B	4,627 B	20,736 bitar

En detalj som förvirrar folk vid första kontakten: Windows-gränssnittet rapporterar nyckelstorlekar som 15 616 bitar, vilket ser främmande ut bredvid RSA-2048. Det är helt enkelt den publika nyckellängden uttryckt i bitar (1 952 byte x 8). Inget exotiskt: bara en mycket större nyckel. Som en fungerande vägledning är ML-DSA-65 den rimliga standarden för att utfärda CA:er och leaf-certifikat (kategori 3 sitter bredvid AES-192), ML-DSA-87 passar roots och långlivade ankare där man vill ha maximal marginal, och ML-DSA-44 är för fall med verkligt storleksbegränsad där kategori 2 är en accepterad handel.

Varför rullgardinsmenyn för hashalgoritmen försvinner

Klassisk PKI bygger på hash-sedan-signera: CA beräknar en sammanfattning av de data som ska signeras och signerar sedan sammanfattningen med sin privata nyckel. Hashvalet var en separat, konfigurerbar frihetsgrad, vilket är precis så branschen hamnade med MD5 och SHA-1 signerade med perfekt fungerande nycklar, och sedan var tvungen att köra mödosamma migreringar för att fixa det. ML-DSA tar bort den knappen: meddelandebehandling är en integrerad del av själva signaturschemat, internt fixerat och inte operatörsvalbart.

AD CS avslöjar detta ärligt. I det ögonblick du väljer en ML-DSA-nyckelalgoritm under CA-installationen, minskas hashalgoritmlistan till en enda post: NoHash. På certifikatmallar gråmarkeras hashväljaren och kontrollen "alternativt signaturformat" (PKCS#1 v2.1-växeln): det finns ingen signaturschemavariant att välja. NoHash betyder inte att data är ohasade; det betyder att hashningen är inbyggd i FIPS 204 och AD CS kommer inte att låtsas att du har ett val. En hel klass av historiska PKI-felkonfigurationer upphör helt enkelt att existera.

Rena vs. sammansatta certifikat: Övergångsfrågan

Postkvantcertifikat finns i två arkitektoniska varianter, och Microsofts färdplan inkluderar medvetet båda:

• Ren. Certifikatet använder en enda postkvantalgoritm: den som AD CS levererar idag. Det är det renaste sluttillståndet, men varje förlitande part i kedjan måste redan förstå ML-DSA för att validera det. I en heterogen kedja full av apparater, inbäddade stackar och äldre mellanprogramvara är det en verklig begränsning.
• Sammansatt. Certifikatet bär en klassisk nyckel (RSA eller ECDSA) och en postkvantnyckel tillsammans, och dess signatur innehåller både en klassisk och en postkvantsignatur. Validering kräver båda för att verifiera, så att förfalska certifikatet innebär att båda algoritmerna bryts, och certifikatet förblir säkert så länge endera av dem gäller. Priset är storleken (du bär två av allt) och kravet att validerare förstår det sammansatta formatet, som för närvarande definieras i IETF LAMPS-utkast.

Praktisk läsning: ren ML-DSA passar i slutna, nya ekosystem där du kontrollerar varje valideringsverktyg: intern kodsignering, infrastrukturattestering, maskin-till-maskin-förtroende inom en hanterad flotta. Composite är migreringsverktyget för blandade fastigheter, där du behöver post-kvantskydd utan att satsa på universellt ML-DSA-stöd från dag ett. AD CS fas 2 är planerad att introducera komposit ML-DSA och komposit ML-KEM ; fram till dess, planera rena distributioner kring kompatibilitetstestning av förlitande parter.

Vilka arbetsbelastningar bör flyttas till ML-DSA nu? En beslutsmatris

Inte alla certifikatarbetsbelastningar är redo att flyttas, och fas 1:s omfattning gör det beslutet mestadels mekaniskt: om en arbetsbelastning behöver kryptering eller är beroende av en rolltjänst som inte har levererats än, väntar den. Använd den här matrisen för att sortera din egen eftersläpning innan du öppnar AD CS-konsolen.

Arbetsbelastning	Byta till ML-DSA nu?	Varför
Intern kodsignering och firmwaresignering	Ja, pilot nu	Authenticode och .NET 10:s MLDsa API:er fungerar från början till slut, och du kontrollerar varje validator i en sluten signeringskedja.
OCSP-svarssignering	Ja, pilot nu	Online Responderns stöd för ML-DSA är GA, och ett signeringscertifikat har låg explosionsradie för testning.
Interna användar- eller datorcertifikat via MMC/certreq	Ja, i en parallell labbhierarki	Registrering är GA, men automatisk registrering och NDES är det inte, så planera för manuell eller skriptad utfärdande under pilotfasen.
Offentliga TLS-/webbservercertifikat	Ännu	Schannel binder inte ML-DSA-servercertifikat för HTTPS, och de flesta offentliga förlitande parter kan inte validera ML-DSA-kedjor.
Smartkortsinloggning och PKINIT	Ännu	Kerberos/PKINIT-autentiseringsflöden stöder inte ML-DSA i den här versionen.
NDES/SCEP-utfärdade enhetscertifikat (MDM)	Ännu	NDES-registreringen för ML-DSA har inte skickats; vänta på den bekräftade rolltjänsttäckningen.
S/MIME- eller EFS-kryptering	Aldrig specifikt med ML-DSA	ML-DSA är endast signaturbaserad; krypteringsarbetsbelastningar behöver ML-KEM, en separat, senare fas.
Certifikat validerade av blandade eller tredjepartsförlitande parter	Vänta på sammansatta certifikat	Sammansatt ML-DSA (fas 2) låter ett certifikat valideras mot både klassiska och post-kvantumverifierare under övergången.

Mönstret under tabellen: allt på "ja"-raderna är en sluten loop som du kontrollerar från början till slut, och allt på "inte än"-raderna är beroende av en rolltjänst, ett protokoll eller en extern förlitande part som Microsoft ännu inte har utökat till ML-DSA. Det är också det snabbaste sättet att förklara fasgränsen för en intressent som inte var närvarande för diskussionen om endast signaturer ovan.

Att etablera en ML-DSA CA: Vad som fungerar idag

Endast nya hierarkier, avsiktligt

Det enskilt viktigaste faktumet vid distribution: ML-DSA CA:er måste vara nyinstallerade. Det sker ingen konvertering på plats av en befintlig CA, och ingen förnyelse-med-ny-algoritm-sökväg: att ändra den offentliga nyckelalgoritmen innebär en ny nyckel, ett nytt certifikat och i praktiken en ny CA-identitet. Microsofts riktlinjer är att bygga en parallell post-kvantumhierarki bredvid din produktions-PKI och migrera arbetsbelastningar medvetet. Hur obekvämt det än låter, speglar det hur disciplinerade PKI-generationer alltid har roterats, och det innebär att du kan börja utvärdera idag utan risk för produktionsutgivning.

Installera CA:n

I konfigurationsguiden för Server Manager AD CS visas nu de tre ML-DSA-parameteruppsättningarna i listan över nyckelalgoritmer tillsammans med RSA och ECDSA, och om du väljer en av dem komprimeras hashlistan till NoHash.

Fältnotering: NoHash-fällan. Du måste skicka -HashAlgorithmName "NoHash" explicit. AD CS-installationsmotorn initierar sina standardinställningar till RSA med SHA-256, och den behåller den SHA-256-hashen även efter att du har bytt nyckelalgoritmen till ML-DSA, så en ML-DSA-installation som utelämnar parametern misslyckas. Samma logik gäller vid automatisering: alla distributionsskript som hårdkodar SHA256 behöver en villkorlig gren innan den berör en PQ CA.

Efter installationen visar certsrv.msc exakt vad du kan hoppas på: Microsoft Software Key Storage Provider som innehar en ML-DSA-nyckel, hashalgoritmen NoHash och ett CA-certifikat vars signaturalgoritm är ML-DSA. Kedjebyggande, CDP/AIA-publicering och hälsokontroller av pkiview.msc fungerar normalt.

Certifikatmallar: fem inställningar som styr allt

ML-DSA visas endast på mallfliken Kryptografi när mallen är korrekt utformad, och flera av kraven kan spåras direkt tillbaka till "endast signaturer":

Mallinställning	Nödvändigt värde	Varför det spelar roll
Kategori för kryptografisk leverantör	Leverantör av CNG-nyckellagring	PQC finns bara i CNG-stacken; äldre CSP-baserade mallar kommer aldrig att lista ML-DSA.
Kompatibilitet (CA och mottagare)	Windows Server 2008 eller senare	CNG-leverantörer visas endast i leverantörslistan på denna kompatibilitetsnivå eller högre.
Hantering av förfrågningar – Syfte	Signatur: exakt	Det här är problemet som kostar folk en eftermiddag: med vilket annat syfte som helst (inklusive "Signatur och kryptering") försvinner ML-DSA tyst från fliken Kryptografi.
Applikationspolicyer (EKU)	Ingen EFS, ingen säker e-post	Båda innebär krypteringsoperationer som ML-DSA inte kan utföra.
Tillägg för nyckelanvändning	Ingen nyckelkryptering, inget nyckelavtal	Samma anledning: nyckelparet kan inte upprätta eller transportera hemligheter.

Registrering, OCSP och kodsignering

Registrering fungerar idag via MMC-guiden för certifikat och certreq.exe från uppdaterade Windows 11 24H2/25H2-klienter. NDES-registrering (SCEP) är uttryckligen inte tillgänglig ännu: relevant om dina MDM-utfärdade enhetscertifikat använder NDES.

Fältnotering: den halvt patchade klienten. På en delvis patchad Windows 11-klient kan registreringsguiden lista ML-DSA och sedan misslyckas när du faktiskt registrerar dig. Kontrollera guidens fält Nyckelstorlek för att se varför: ett verkligt värde (10 496 / 15 616 / 20 736) betyder att klienten är helt aktiverad, medan 0 betyder att algoritmen bara delvis lyser i klientens nyckellagringsleverantör: avsluta patchningen innan du skyller på certifikatutfärdaren.

Online-respondern accepterar ett ML-DSA OCSP-svarssigneringscertifikat (duplicera standardmallen istället för att redigera den) och signerar svar utan klagomål. En kosmetisk egenhet: responderns hash-algoritm-egenskap kan återge ett nonsensvärde för ML-DSA-konfigurationer, eftersom det inte finns någon hash att visa. Ignorera strängen och lita på pkiview.msc , vilket rapporterar att respondern är felfri. Authenticode är på liknande sätt komplett: signering och verifiering med Set-AuthenticodeSignature / Get-AuthenticodeSignature fungerar från början till slut, vilket gör intern kodsignering till en av de mest trovärdiga arbetsbelastningarna i första produktionen för en PQ-hierarki.

Vad som inte finns där än

Ärlig avgränsning är hälften av god konsultverksamhet, så här är den nuvarande gränslinjen i ett perspektiv:

Fungerar idag (fas 1)	Inte än / planerat
ML-DSA Root-, Sub-, Enterprise- och Standalone-CA:er (nyinstallationer)	Migrering på plats eller förnyelse av befintliga CA:er genom algoritmändring: kommer inte att ske; planera parallella hierarkier
ML-DSA-bladutgivning: kodsignering, webbserver, användare, datormallar	NDES/SCEP-registrering; fullständig CEP/CES-webbtjänsttäckning (dedikerad, stegvis)
Registrering via certifikat MMC och certreq.exe	IIS HTTPS-bindningar med ML-DSA-servercertifikat: Schannel TLS-autentisering är ännu inte aktiverad för det.
OCSP-svarssignering med ML-DSA	Kerberos/PKINIT och inloggningsflöden för smartkort
Authenticode-kodsignering och verifiering; .NET 10 MLDsa API:er	Allt krypteringsformat (EFS, S/MIME-kryptering): avsiktligt tills ML-KEM lanseras
Stöd för Windows Server 2025 + Windows 11 24H2/25H2-plattformen	Sammansatta ML-DSA/ML-KEM-certifikat (fas 2); Windows Server 2019/2022 (ingen backport förväntas)

Läs noggrant den högra kolumnen innan du lovar någon ett "kvantsäkert intranät". Dagens release säkrar utfärdande- och signeringsplanet . Sessionsplanet (TLS-nyckelutbyte, och därmed skörda-nu-dekryptera-senare-skydd för data i rörelse) väntar på ML-KEM-integration genom TLS-stacken. Tredjepartsförlitande parter är sin egen gräns: många applikationer, apparater och HSM-anslutande mellanprogramvara analyserar ännu inte ML-DSA-certifikat, så varje pilot behöver en kompatibilitetsmatris, inte ett antagande.

Operativa realiteter: Storlek, HSM:er och att köra två PKI:er

Allt blir större

Gittersäkerhet betalas i byte. Jämför de artefakter som din infrastruktur faktiskt flyttar och lagrar:

Algoritm	Offentlig nyckel	namnteckning	Signatur kontra RSA-2048
RSA-2048	256 B	256 B	1x (baslinje)
ECDSA P-256	~ 64 B	~ 70 B	~ 0.3x
ML-DSA-44	1,312 B	2,420 B	~ 9x
ML-DSA-65	1,952 B	3,309 B	~ 13x
ML-DSA-87	2,592 B	4,627 B	~ 18x

Ett lövcertifikat som väger ungefär 1-1.5 KB med RSA landar i intervallet 6-7 KB vid ML-DSA-65 när du tar hänsyn till den inbäddade publika nyckeln plus den utfärdande CA:ns signatur; en trenivåkedja korsar 20 KB innan handskakningen ens börjar. OCSP-svar växer med en signatur plus, vanligtvis, ett inbäddat signeringscertifikat. Budgetera för konsekvenserna nu: CDP/AIA och OCSP-bandbredd och cachning, certifikatarkiv och CA-databasen, CLM-inventeringar, TLS-post och MTU-beteende när ML-KEM-handskakningar anländer, samt hårda kapacitetsgränser för smartkort, TPM:er och begränsade enheter. Inget av detta är oöverkomligt (publik webb-PKI absorberar samma förändring), men det hör hemma i din kapacitetsmodell, inte i din incident-postmortem.

HSM:er: verifiera innan du lovar

Fas 1-upplevelsen körs på Microsoft Software Key Storage Provider, vilket är bra för labb och många interna hierarkier. Produktionsrötter och utfärdande CA:er i reglerade miljöer vill ha hårdvarubaserade ML-DSA-nycklar, och det beror helt på att din HSM-leverantörs CNG-leverantör exponerar algoritmen på firmware som är (eller är på väg att bli) FIPS 140-3-validerad. De största leverantörerna (Thales Luna, entrust nShield, molnbaserade HSM-tjänster) har lagt till stöd för FIPS 203/204 under de senaste firmwaregenerationerna, men valideringsstatus och KSP-integrationsmognad varierar beroende på modell och version. Gör "visa mig ML-DSA genom din CNG KSP och visa mig valideringspappersarbetet" till en bokstavlig post i din pilotplan och bestäm medvetet om tidiga faser körs på programvarunycklar medan hårdvaran kommer ikapp.

Du kommer att köra två PKI:er i flera år

En parallell hierarki är inte ett helglabb: det är en andra produktionsmiljö med egna mallar, CDP/AIA-publicering, OCSP, övervakning, nyckelceremonier, CP/CPS-delta och så småningom en avvecklingsplan för den klassiska sidan. De organisationer som hanterar detta väl är de som behandlar övergången som ett kryptoagilitetsprogram : om certifikatutfärdande och förnyelse redan är automatiserade och inventeringsdrivna, blir algoritmbyte en konfigurationsändring som utförs av maskiner. Om ditt gods fortfarande förnyar certifikat via kalkylblad och kalenderpåminnelser, kommer PQC-migreringen att kännas som SHA-1-utfasningen igen, förutom för alla certifikat du äger, med större nyttolaster och hårdare deadlines.

En pragmatisk tidslinje för migration

Att mappa de regulatoriska datumen till konkret PKI-arbete ger en plan i fem faser. Fönstren nedan antar att ett företag av meningsfull storlek börjar ungefär nu; komprimera eller sträck efter smak, men behåll ordningen: varje fas minskar riskerna i nästa. För en mer fullständig, teknikövergripande version av denna färdplan utöver AD CS specifikt, se vår guide för PQC-migrering år 2026. Spåra den övergripande planeringen efter kvantmigrering genom PQC Center of Excellence.

Fas	Fönster	Vad man egentligen ska göra
0. Kartläggning av lager och exponering	Nu – slutet av 2026	Bygg ett kryptografiskt inventarium (en CBOM) över CA:er, mallar, nycklar, protokoll, applikationer och inbäddade enheter. Flagga de två högriskklasserna: långlivade signaturer (rötter, kod-/firmwaresignering, dokumentförtroende) och data med lång sekretess som exponeras för skörd-nu-dekryptera-senare. Ta CA-plattformar till Windows Server 2025 och klientflottan till den PQC-kompatibla baslinjen.
1. Parallell PQ-pilot	2026 - 2027	Skapa en isolerad tvånivåhierarki för ML-DSA i labbet. Öva på CA-installation, mallar, MMC/Certreq-registrering, OCSP och Authenticode från början till slut. Kör en kompatibilitetsmatris för förlitande parter (Windows, OpenSSL 3.5+, Java, nätverksapparater, mellanprogram). Mät storlek och prestandadelta. Utarbeta CP/CPS-ändringar och HSM-krav nu, medan ingenting är brådskande.
2. Riktad produktionsanvändning	2027 - 2028	Flytta först arbetsbelastningar för slutna signaturer (intern kodsignering, infrastrukturattestering, dokumentsignering) dit du kontrollerar varje validator. Använd sammansatta certifikat för blandade förtroendevägar när fas 2 levereras. Integrera PQC-stöd i upphandlingsspråket så att varje ny enhet, HSM och applikation levereras redo.
3. Hierarkiövergång	2028 - 2030	Utfärda nästa generations roots och utfärdande CA:er som ML-DSA eller komposit. Standardutfärdande av ny utfärdande bort från RSA-2048 och P-256 inför utfasningen 2030. Integrera ML-KEM för TLS som Windows så aktiverar din lastbalanserings-/inspektionsstack det.
4. Dödsboflytt och pensionering	2030 - 2033	Massmigrera lövgårdar med hjälp av automatiserade verktyg för certifikatlivscykelnMed moderna certifikatvolymer och krympande livslängder är manuell migrering inte en aritmetik som stänger. Avveckla klassiska hierarkier enligt ett publicerat schema, i linje med Microsofts eget mål för fullständig övergång till 2033.
Hårt stopp	2035	RSA, ECDSA och klassisk DH är inte tillåtna enligt NIST IR 8547. Ingenting kvantumsårbart bör finnas kvar i produktionsförtroendevägar.

Vad detta säger om AD CS framtid

Det finns en andra ordningens signal här som är värd att nämna. Under ett decennium var det säkra antagandet att AD CS aldrig skulle få se meningsfulla investeringar igen, och plattformsbeslut fattades i enlighet därmed. Att leverera en NIST-ny signaturalgoritm (med en publicerad flerfasfärdplan som täcker ML-KEM, sammansatta certifikat och registreringsrolltjänster) är inte beteende i underhållsläge.

Tidpunkten sammanfaller också med ett lugnare skifte i det offentliga förtroendeekosystemet: offentliga CA:er tar bort Client Authentication EKU från TLS-certifikat i takt med att rotprogram delar upp server- och klientförtroende, vilket innebär att den enorma världen av mTLS (tjänstnät, enhetsflottor, B2B API-autentisering) migrerar till privata CA:er oavsett om någon planerade det eller inte. En privat CA-plattform som levereras med OS-licensen, integreras med AD-identitet och nu signerar med postkvantalgoritmer är plötsligt en mycket rationell landningszon för dessa arbetsbelastningar. AD CS överlever inte bara PQC-övergången; den använder den för att återinträda i samtalet.

Hur kan krypteringskonsultation hjälpa till?

Allt ovan reduceras till ett sekvenseringsproblem: vet vad du har, bevisa vad som fungerar, automatisera växlingen och träffa datum som redan finns i kalendern. Det är precis det som Encryption Consulting arbetar med varje dag: vi har hjälpt fler än 100 Fortune 500-organisationer att utvärdera, designa och driva sina kryptografiska tillgångar, och våra PQC-rådgivningstjänster byggdes för just denna övergång:

Där lagen fastnar	Hur vi hjälper
"Vi vet faktiskt inte var kvantumsårbar kryptografi finns i vår miljö."	Vårt PQC-rådgivningsengagemang börjar med en kvanthotbedömning, och CBOM-säkerhet bygger en automatiserad, kontinuerligt uppdaterad kryptografisk materialförteckning över certifikat, nycklar, algoritmer och protokoll: inventeringen som varje senare fas är beroende av.
"Vi behöver en försvarbar färdplan, inte ett vetenskapligt projekt."	Vi levererar en färdplan och strategi för kvantberedskap i linje med NIST-, CISA- och NSA-riktlinjer: etappvisa milstolpar, kryptoagil driftsmodell och proof-of-concept-validering av kandidatalgoritmer innan något når produktionsläget.
"Vår AD CS-miljö behöver en parallell PQ-hierarki som är korrekt utformad."	Vår PKI-bedömning och design-/implementeringstjänster omfattar hierarkiarkitektur, HSM-integration, CP/CPS-utveckling och mallstyrning, och PKI-som-en-tjänst kan vara värd för post-kvantgenereringen på FIPS 140-3 nivå 3 HSM:er om du hellre vill konsumera den än att bygga den.
"När algoritmen ändras har vi tiotusentals certifikat att flytta."	CertSecure-hanterare, vår plattform för hantering av certifikatlivscykeln, byggdes med kryptoagilitet i centrum: kontinuerlig identifiering över AD CS, HashiCorp Vault, moln- och enhetsanläggningar, riskprofilerad inventering och zero-touch-förnyelse i flottaskala: så en algoritmmigrering blir en policyförändring, inte ett projekt som sträcker sig över flera kvartal.
"Vår kodsignering måste klara övergången intakt."	CodeSign Secure tillhandahåller policydrivna, HSM-baserade signeringsarbetsflöden över Windows-, Linux-, macOS- och CI/CD-pipelines: det naturliga kontrollplanet för att flytta Authenticode- och firmware-signering till postkvantalgoritmer.

Slutsats

Uppdateringen från maj 2026 kan bäst förstås som en startskott. AD CS kan nu bygga ett helt post-kvantumsigneringsplan (CA-hierarki, utfärdande, OCSP, kodsignering ) på standardiserad, NIST-godkänd kryptografi, med nyckelinkapsling och sammansatta certifikat redan på den publicerade färdplanen. Teknikfrågan har flyttats från "när kommer Microsoft att gå vidare?" till "hur redo är mina tillgångar att följa efter?"

Osäkerheten kring kvanthårdvara går åt båda hållen, men inte efterlevnadskalendern: 2030 och 2035 är nedskrivna, och förtroendeankare som undertecknats idag kommer fortfarande att leva när dessa datum infaller. De organisationer som kommer att ta sig igenom denna övergång lugnt är de som behandlar den som ett kryptoagilitetsprogram: lager först, automatisering sedan, algoritmer tredje. Stå upp i labbhierarkin, hitta dina inkompatibiliteter medan de är billiga och låt själva bytet vara tråkigt. Det är så bra PKI-teknik alltid har sett ut.

Det här inlägget granskas kvartalsvis med tanke på aktiva NIST IR 8547, Microsoft AD CS-färdplan och HSM-leverantörens PQC-valideringsscheman, och omedelbart när Microsoft levererar en ny AD CS PQC-funktion eller NIST uppdaterar tidslinjen för utfasning.

Vanliga frågor om partihandel med mat och dryck

Kan jag uppgradera min befintliga AD CS CA till ML-DSA?

Nej. ML-DSA CA:er måste vara nyinstallerade: det sker ingen konvertering på plats och ingen förnyelse-med-ny-algoritm-sökväg, eftersom ändring av den offentliga nyckelalgoritmen innebär en ny nyckel och en ny CA-identitet. Det mönster som stöds är en parallell postkvantumhierarki som drivs tillsammans med din befintliga PKI medan arbetsbelastningar migreras.

Gör ML-DSA i AD CS min TLS kvantsäker?

Inte än. ML-DSA täcker signaturer: certifikat- och OCSP-integritet, kodsignering, autentisering av identiteter. Sessionskonfidentialitet beror på nyckelutbytet, vilket behöver ML-KEM via TLS-stacken; idag binder IIS inte ens ett ML-DSA-servercertifikat för HTTPS . Skydd av data i rörelse med "harvest-now-decrypt-later" kommer med nyckelinkapslingsfasen, inte den här.

Vilken ML-DSA-parameteruppsättning bör jag standardisera på?

ML-DSA-65 (NIST kategori 3) är den pragmatiska standarden för utfärdande av CA:er och lövcertifikat. Reservera ML-DSA-87 för rötter och långlivade ankare där maximal marginal motiverar storleken, och behandla ML-DSA-44 som ett avsiktligt undantag för storleksbegränsade scenarier där kategori 2 är ett accepterat riskbeslut.

Varför kan jag inte välja en hashalgoritm när jag använder ML-DSA i AD CS?

Eftersom FIPS 204 integrerar meddelandebehandling i själva signaturschemat finns det inget separat hash-sedan-signera-steg att konfigurera. AD CS representerar detta som det enda NoHash-alternativet. Kom ihåg att skicka det explicit i skriptade installationer; installationsmotorns standardinställningar förblir RSA/SHA-256 och korrigeras inte automatiskt när du väljer en ML-DSA-nyckel.

Kommer Windows Server 2019 eller 2022 att få stöd för ML-DSA/PQC i AD CS?

Det finns inga tecken på en backport: PQC i AD CS är en funktion i Windows Server 2025. Om dina certifikatutfärdare körs på äldre plattformar ligger operativsystemuppgraderingen nu på den kritiska vägen efter kvantum och hör hemma i nästa års plan, inte 2030-talet.

Vad är den viktigaste slutsatsen från den här artikeln om ML-DSA-stöd i AD CS?

Microsofts uppdatering från maj 2026 (KB5087539) ger AD CS möjligheten att bygga ett helt post-kvantumsigneringsplan med hjälp av ML-DSA (FIPS 204). ML-DSA är endast signaturbaserad och kräver nya parallella hierarkier snarare än migrering på plats. Det praktiska första steget är en kryptografisk inventering, inte ett algoritmbyte: NIST IR 8547 föråldrar RSA-2048 och ECDSA P-256 efter 2030 och förbjuder alla kvantumsårbara algoritmer efter 2035, och långlivade förtroendeankare som utfärdas idag överlappar redan dessa datum.

Varför är ML-DSA i AD CS viktigt för PKI-team på stora företag?

AD CS förankrar certifikatutfärdande över företagens Windows-system: domänautentisering, smartkort, enhetsregistrering, intern TLS, kodsignering. DigiCerts Quantum Readiness Outlook från juli 2026 fann att 87 % av organisationerna planerar eller pilottestar PQC, men endast 7 % har implementerat kvantsäker eller hybridkryptografi över de flesta av sina certifikat. KB5087539 ger Windows-centrerade PKI-team en konkret, Microsoft-inbyggd utgångspunkt. Den regulatoriska klockan är fast: RSA-2048 och ECDSA P-256 är föråldrade efter 2030, alla kvantsårbara algoritmer är otillåtna efter 2035 enligt NIST IR 8547.

Vilka risker ökar om post-quantum PKI-planering hanteras manuellt eller reaktivt?

Tre riskkategorier ökar: exponering mot långvarigt förtroendeankare (en 20-årig rot som utfärdades 2026 är fortfarande aktiv 2046, elva år efter förbudsdatumet 2035); exponering mot skörd-nu-dekryptera-senare (motståndare som registrerar krypterad trafik idag avser att dekryptera den när kvantkapaciteten mognar); och komplexitet vid migrering av fastigheter (CyberArks rapport från 2025 fann att 34 % av organisationerna fortfarande hanterar certifikatlivscykler manuellt, vilket gör bulkmigrering av ML-DSA till en händelse på SHA-1-nivå i mycket större skala).

Vilka förutsättningar krävs innan man implementerar ML-DSA i AD CS?

Fem förutsättningar måste alla vara uppfyllda: Windows Server 2025 + KB5087539 på CA-värden; Windows 11 24H2/25H2 + KB5067036 vid registrering av klienter; CNG Key Storage Provider vald i certifikatmallen (inte äldre CSP); certifikatmallens syfte är exakt inställt på Signature; och -HashAlgorithmName "NoHash" skickades explicit i alla skriptbaserade CA-installationer. Förutsättningstabellen tidigare i den här artikeln täcker valideringskontrollen, vanliga fel och korrigeringar för varje.

Vilka vanliga fel bör administratörer vara uppmärksamma på när de distribuerar ML-DSA i AD CS?

Fem fel uppstår konsekvent: ML-DSA saknas på fliken Kryptografi (mallens Syfte är inte exakt inställt på Signatur); CA-installationen misslyckas med ett hashalgoritmfel (NoHash utelämnades från installationskommandot); registreringen misslyckas på en klient som listar ML-DSA med nyckelstorlek som visar 0 (klienten är delvis patchad); OCSP-hashalgoritmen visar ett nonsensvärde för ML-DSA (endast kosmetiskt, lita på pkiview.msc); och HSM misslyckas med att generera en ML-DSA-nyckel (HSM-firmware stöder ännu inte ML-DSA via CNG KSP). Tabellen över förutsättningar och vanliga fel i den här artikeln mappar varje fel till dess korrigering.

Referenser och vidare läsning

• Översikt över postkvantkryptografi i AD CS (Microsoft Learn)
• Vad är ML-DSA-stöd i AD CS? (Microsoft Learn)
• KB5087539: Säkerhetsuppdatering från 12 maj 2026 för Windows Server 2025
• Microsoft Security Community: Post-Quantum Cryptography API:er är nu allmänt tillgängliga på Microsofts plattformar