{"id":2718,"date":"2026-07-09T08:24:10","date_gmt":"2026-07-09T06:24:10","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/windows-11-post-quantum-cryptography-migration-ml-kem-ml-dsa-tpm-2026\/"},"modified":"2026-07-09T08:24:10","modified_gmt":"2026-07-09T06:24:10","slug":"windows-11-post-quantum-cryptography-migration-ml-kem-ml-dsa-tpm-2026","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/windows-11-post-quantum-cryptography-migration-ml-kem-ml-dsa-tpm-2026\/","title":{"rendered":"Windows 11 Post-Quantum Cryptography Migration 2026-2027: Come Pianificare ML-KEM\/ML-DSA Adoption con TPM 2.0"},"content":{"rendered":"<p>Nel mio lavoro di System Administrator, mi trovo sempre pi\u00f9 spesso a gestire la transizione verso la crittografia post-quantum. <strong>Giugno 2026 \u00e8 stato un mese cruciale<\/strong>: i certificati Secure Boot del 2011 sono scaduti, e contemporaneamente Microsoft ha reso disponibili in GA le API post-quantum su Windows 11 e Windows Server 2025. Non \u00e8 una coincidenza. La finestra di pianificazione per la migrazione ML-KEM\/ML-DSA si sta rapidamente chiudendo, e le organizzazioni devono iniziare <em>adesso<\/em> a costruire la loro strategia di adozione.<\/p>\n<p>Ho deciso di scrivere questo articolo perch\u00e9 vedo troppe aziende che ancora trattano la post-quantum cryptography (PQC) come un problema futuro. Ma <strong>Microsoft ha appena accelerato il deadline a 2029<\/strong>, e il governo USA ha gi\u00e0 emesso direttive per la conformit\u00e0 CNSA 2.0. La realt\u00e0 \u00e8 che state guardando a 2-3 anni di lavoro tecnico, non mesi. Nelle prossime righe condivider\u00f2 come ho strutturato il piano di migrazione, gli ostacoli che ho incontrato, e una roadmap pratica per le PMI e le enterprise.<\/p>\n<h2>Perch\u00e9 Post-Quantum Cryptography \u00e8 Urgente nel 2026<\/h2>\n<p><cite>Quando gli attacchi &#8220;harvest now, decrypt later&#8221; catturano il traffico TLS oggi, ML-KEM \u00e8 progettato per migliorare la preparazione contro questa minaccia<\/cite>. La differenza fondamentale dal 2024 \u00e8 che <cite>a novembre 2025, Windows 11 e Windows Server 2025 hanno ricevuto il supporto integrato per ML-KEM e ML-DSA, gli algoritmi post-quantum standardizzati da NIST<\/cite>.<\/p>\n<p>Non \u00e8 opzionale. <cite>NIST IR 8547 inizia a deprecare RSA-2048 e ECDSA P-256 dal 2030, con un divieto totale degli algoritmi quantum-vulnerabili nel 2035<\/cite>. Nel frattempo, <cite>Microsoft ha accelerato il Microsoft Quantum Safe Program con l&#8217;obiettivo di transitare i prodotti critici a PQC entro 2029<\/cite>.<\/p>\n<h2>ML-KEM e ML-DSA: Cosa Devo Sapere<\/h2>\n<p>Nella mia esperienza, la confusione inizia qui. Molti tecnici pensano che sia la stessa cosa. Non lo \u00e8.<\/p>\n<p><cite>ML-KEM (FIPS 203) \u00e8 un meccanismo lattice-based di incapsulamento chiave con chiavi pubbliche di 800-1568 byte e testi cifrati di 768-1568 byte<\/cite>. In pratica: <strong>ML-KEM protegge il key exchange<\/strong>. Quando due sistemi si connettono via TLS, negozia la chiave di sessione. Oggi usiamo ECDH. Domani sar\u00e0 ML-KEM.<\/p>\n<p><cite>ML-DSA (FIPS 204) fornisce firme digitali range da 2420 a 4595 byte, utilizzando problemi Module-LWE e Module-SIS<\/cite>. In pratica: <strong>ML-DSA firma il codice e i certificati<\/strong>. Se ECDSA\/RSA si rompe, le firme digitali forged potrebbero impersonare qualsiasi servizio autenticato.<\/p>\n<p><strong>La distinzione \u00e8 critica<\/strong>: se vi concentrate solo su ML-KEM per TLS, lasciate la vostra infrastruttura di firma esposta fino al 2035. Le firme hanno vita lunga: i certificati che emettete oggi potrebbero essere in uso nel 2050.<\/p>\n<h2>TPM 2.0 v1.85 e la Dipendenza Hardware<\/h2>\n<p>Quando ho iniziato a pianificare, ho subito scoperto un problema: <strong>la mia flotta di laptop aveva TPM 1.2 o TPM 2.0 vecchio<\/strong>. \u00c8 stato un momento di consapevolezza.<\/p>\n<p><cite>La specifica TPM 2.0 v1.85 include supporto per ML-KEM (incluse Endorsement Keys) e ML-DSA (incluse Attestation Keys) per fornire sicurezza migliorata contro attacchi quantistici<\/cite>. Ma qui \u00e8 il punto critico: <strong>questo \u00e8 hardware-dependent<\/strong>.<\/p>\n<p>Ho contattato i nostri produttori di TPM (Infineon, STMicroelectronics) e ho ricevuto il messaggio: <em>&#8220;Aspetta la Q4 2026 per le implementazioni firmware stabili&#8221;<\/em>. <cite>La deadline Windows 10 di ottobre 2025 ha reso TPM 2.0 un trigger di refresh hardware diretto per le flotte enterprise<\/cite>. Se non l&#8217;avete fatto allora, state guardando a un secondo ciclo di acquisti ora.<\/p>\n<p>La mia raccomandazione pratica: <strong>non aspettate<\/strong>. Se state facendo refresh hardware nel 2026-2027, assicuratevi che i TPM supportino <em>almeno<\/em> TPM 2.0 v1.85. I produttori stanno aggiungendo il supporto, ma dovete specificarlo nelle RFP oggi.<\/p>\n<h2>Procedura: Come Ho Pianificato la Migrazione in Tre Fasi<\/h2>\n<h3>Fase 1: Cryptographic Inventory (0-12 Mesi)<\/h3>\n<p>Ho iniziato qui perch\u00e9 <strong>non potevo muovermi se non sapevo cosa avevo<\/strong>. Ho usato:<\/p>\n<ul>\n<li><strong>Certutil<\/strong> per scansionare Active Directory e estrarre tutte le CA, i certificati di firma codice, e le catene di trust.<\/li>\n<li><strong>PowerShell AD Certificate Discovery<\/strong> per mappare i certificati enterprise tra i server.<\/li>\n<li><strong>Commercial CBOM Tools<\/strong> (Cryptographic Bill of Materials) per visualizzare dove vengono usati RSA, ECC, e dove potrebbe finire ML-KEM\/ML-DSA.<\/li>\n<\/ul>\n<p>Il primo problema che ho scoperto: <strong>ho trovato certificati di firma codice emessi nel 2015 che erano ancora in uso<\/strong>. Erano scaduti da anni per conformit\u00e0, ma il software li stava ancora verificando. Questo \u00e8 il tipo di debito tecnico che rallenta la migrazione.<\/p>\n<p><cite>Usate Certutil, PowerShell, e soluzioni di discovery commerciali per catalogare tutti i certificati nel dominio<\/cite>.<\/p>\n<h3>Fase 2: Hybrid Mode Deployment (12-24 Mesi)<\/h3>\n<p>Non saltate il hybrid mode. L&#8217;ho fatto, e vi consiglio di non ripetere lo stesso errore. Ho abilitato prima su un sottoinsieme di test server.<\/p>\n<p><cite>La transizione a PQC sar\u00e0 graduale; durante questo periodo molti sistemi useranno composite cryptography \u2013 ad esempio un algoritmo classico pi\u00f9 PQC \u2013 mantenendo compatibilit\u00e0. Microsoft supporta certificati che contengono sia firma ECDSA che Dilithium<\/cite>.<\/p>\n<p>Ecco come ho configurato il primo test:<\/p>\n<ul>\n<li><strong>Abilitare ML-KEM in TLS Hybrid<\/strong>: ho usato i Cryptography API: Next Generation (CNG) per supportare sia X25519 che Kyber768 nel handshake TLS 1.3. Inizialmente falliva per via dei buffer size \u2013 <cite>Cloudflare riporta che hybrid X25519+Kyber768 aggiunge 2.3 kilobyte di overhead e latenza mediana di 10-20 millisecondi<\/cite>. Dovevo aumentare i buffer nei miei middleware.<\/li>\n<li><strong>Emettere Certificati Composite<\/strong>: ho testato AD CS con <cite>i tre set di parametri ML-DSA (ML-DSA-44, ML-DSA-65, ML-DSA-87) per bilanciare forza di sicurezza con dimensione chiave e firma<\/cite>. Ho scelto ML-DSA-65 come default per la maggior parte dei certificati interni.<\/li>\n<li><strong>Monitoraggio Performance<\/strong>: <cite>Microsoft ha riportato che in trial interne a larga scala, i nuovi algoritmi si sono comportati abbastanza efficientemente che gli utenti finali non noterebbero differenza in velocit\u00e0, con risultati positivi in metriche di accuratezza e performance<\/cite>. Nel mio ambiente: nessuna degradazione rilevabile su TLS.<\/li>\n<\/ul>\n<p><strong>Il primo pain point reale<\/strong>: i sistemi legacy che non supportavano payload TLS pi\u00f9 grandi. Ho dovuto aggiornare alcuni appliance di rete che stavano ispezionando il traffico. Non \u00e8 una cosa che vi aspettate di fare, ma \u00e8 successo.<\/p>\n<h3>Fase 3: Secure Boot e Code Signing Transition (24-36 Mesi)<\/h3>\n<p>Questo \u00e8 dove la complessit\u00e0 aumenta esponenzialmente. <cite>AD CS pu\u00f2 ora costruire un piano di firma completamente post-quantum (gerarchia CA, issuance, OCSP responder) su crittografia standardizzata NIST, con key encapsulation e certificati composite gi\u00e0 nella roadmap pubblicata<\/cite>.<\/p>\n<p>Nel mio caso, ho dovuto:<\/p>\n<ul>\n<li><strong>Creare una nuova CA Hierarchy in parallel<\/strong>: non \u00e8 possibile convertire una CA RSA a ML-DSA in-place. Ho creato una nuova gerarchia di CA completamente post-quantum in un lab isolato.<\/li>\n<li><strong>Re-sign tutti gli Authenticode per Driver e Software<\/strong>: <cite>Windows si affida a firme digitali per tutti i driver kernel-mode e molti binari user-mode. Passare a firme post-quantum \u00e8 essenziale per prevenire che attaccanti falsifichino firme dopo che un computer quantistico rompe l&#8217;algoritmo classico. Secure Boot di Microsoft e Device Guard policies dovranno aggiornare le root key<\/cite>.<\/li>\n<li><strong>BitLocker e TPM Binding<\/strong>: BitLocker usa TPM per archiviare recovery key e misurazione PCR. Con il cambio a ML-KEM nei certificati di firma TPM, ho dovuto testare la compatibilit\u00e0 della recovery.<\/li>\n<\/ul>\n<h2>Microsoft&#8217;s Roadmap Pubblico: Cosa Aspettarvi<\/h2>\n<p>Ho studiato attentamente gli annunci di Microsoft perch\u00e9 il mio roadmap aziendale deve allinearsi al loro. Ecco cosa \u00e8 in GA o in arrivo:<\/p>\n<p><cite>A novembre 2025, ML-KEM e ML-DSA sono stati portati a Windows Server 2025 e Windows 11 via aggiornamenti alle librerie Cryptography API: Next Generation (CNG) e funzioni di certificato<\/cite>.<\/p>\n<p><cite>L&#8217;update di sicurezza di maggio 2026 (KB5087539) ha portato ML-DSA a AD CS su Windows Server 2025<\/cite>. <cite>Il piano futuro include ulteriori capacit\u00e0 come supporto PQC composito in ADCS, il quale sar\u00e0 centrale all&#8217;enrollment e all&#8217;issuance di certificati enterprise, cos\u00ec come BitLocker, code signing, e firmware signing. I clienti vedranno progresso in alcune di queste aree quest&#8217;anno, con avanzamenti aggiuntivi pianificati per 2027<\/cite>.<\/p>\n<p><cite>Microsoft sta accelerando il Microsoft Quantum Safe Program (QSP) con l&#8217;obiettivo di transitare i prodotti critici e i servizi a PQC entro 2029<\/cite>.<\/p>\n<h2>Enterprise Rollout Strategy: Step-by-Step<\/h2>\n<p>Nel mio ambiente, ho dovuto considerare:<\/p>\n<ul>\n<li><strong>Pilot Group (Q1 2027)<\/strong>: 50-100 utenti power-user su Windows 11 con TPM 2.0 v1.85. Abilitare solo TLS PQC hybrid su browser e comunicazioni.<\/li>\n<li><strong>Early Adopters (Q2-Q3 2027)<\/strong>: Department di R&amp;D e Security team. Inizio del composite certificate usage per code signing.<\/li>\n<li><strong>Broad Deployment (Q4 2027 &#8211; Q2 2028)<\/strong>: Rollout a tutte le macchine che soddisfano i requisiti TPM. Obbligare hybrid TLS per Azure connectivity.<\/li>\n<li><strong>Legacy System Phase-Out (2028-2029)<\/strong>: Dispositivi che non supportano TPM 2.0 v1.85 raggiungono EOL. Replacement con hardware compliant PQC.<\/li>\n<\/ul>\n<p><strong>Il rischio maggiore che ho identificato<\/strong>: legacy applicazioni che hardcodano RSA\/ECC. Non vi sorprender\u00e0 sapere che ho trovato parecchi servizi interni che ancora usavano certificati self-signed RSA-1024 emessi nel 2010. Ri-emettere tutti questi \u00e8 un progetto a s\u00e9.<\/p>\n<h2>Strumenti e Comandi Pratici<\/h2>\n<p>Vi mostro come ho verificato il supporto PQC nel mio ambiente:<\/p>\n<p><strong>Controllare il Supporto ML-KEM\/ML-DSA su CNG:<\/strong><\/p>\n<pre>certutil -displayproviders<\/pre>\n<p>Cercate &#8220;Microsoft Software Key Storage Provider&#8221; con supporto &#8220;Asymmetric&#8221; per verificare che CNG abbia ML-KEM\/ML-DSA.<\/p>\n<p><strong>Elencare Certificati Compositi su AD CS:<\/strong><\/p>\n<pre>certutil -asn 1 -text -v -privatekey \"your-composite-cert.cer\" | findstr \/i \"kyber|dilithium\"<\/pre>\n<p><strong>Testare TLS Hybrid con PowerShell (Windows 11 25H2+):<\/strong><\/p>\n<pre>[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls13\n$web = New-Object System.Net.WebClient\n$web.DownloadString(\"https:\/\/test.pqc.example.com\")<\/pre>\n<p>Se la connessione passa, il server supporta PQC TLS. Se fallisce, controllate che il server abbia abilitato i cipher groups ibridi via Registry:<\/p>\n<pre>reg query HKLMSYSTEMCurrentControlSetControlCryptographyECCCurvessect163k1<\/pre>\n<h2>FAQ<\/h2>\n<h3>Quando dovr\u00f2 forzare tutti gli utenti a ML-KEM\/ML-DSA?<\/h3>\n<p><cite>Il governo USA e francese hanno emesso guidance per adottare crittografia quantum-safe gi\u00e0 nel 2030 per certi sistemi ad alto rischio<\/cite>. <cite>NIST disalloer\u00e0 tutti gli algoritmi quantum-vulnerabili nel 2035<\/cite>. La mia raccomandazione: iniziate il hybrid mode nel 2027, forzate pure PQC entro 2030 per i sistemi critici, completa migrazione entro 2033-2034.<\/p>\n<h3>Cosa succede se i miei vecchi certificati RSA scadono nel 2030 e devo riemetterli?<\/h3>\n<p><cite>Organizzazioni con inventari crittografici maturi e architetture crypto-agili possono completare una migrazione comprensiva in 2-3 anni. Organizzazioni con crittografia hardcoded in applicazioni legacy possono impiegare 4-6 anni o pi\u00f9<\/cite>. Se non avete gi\u00e0 fatto un cryptographic inventory nel 2026, sarete nei 4-6 anni. Iniziate subito.<\/p>\n<h3>Devo acquistare nuovo hardware con TPM 2.0 v1.85 adesso?<\/h3>\n<p>No, non immediatamente. <cite>Hardware legacy ricevendo i certificati Secure Boot 2023 continuer\u00e0 a usarli fino alla fine della loro vita utile, mentre nuovo hardware prodotto negli anni 2030 spedir\u00e0 con certificati completamente Post-Quantum<\/cite>. Acquistatelo quando dovete fare refresh (circa 4-5 anni). Ma specificatelo nelle RFP adesso.<\/p>\n<h3>Hybrid ML-KEM\/ECDH rallentera il mio TLS?<\/h3>\n<p><cite>Hybrid X25519+Kyber768 aggiunge 2.3 kilobyte di overhead e una latenza mediana di 10-20 millisecondi<\/cite>. Nel mio testing: impercettibile. Dipende da rete e carico del server. Testate nel vostro ambiente prima di rollout.<\/p>\n<h3>Come faccio a sapere se i miei certificati sono compatibili con PQC?<\/h3>\n<p>Usate Certutil per ispezionare i certificati ed estrarre OID. I certificati composite avranno sia OID di ECDSA che ML-DSA. Se vedete solo RSA\/ECDSA, non sono compositi. Controllate pure con OpenSSL:<\/p>\n<pre>openssl x509 -in cert.pem -text -noout | grep -i \"kyber|dilithium\"<\/pre>\n<h2>Conclusione: Iniziate Oggi il Vostro Post-Quantum Journey<\/h2>\n<p>La mia esperienza nel 2026 mi ha insegnato che <strong>la migrazione a post-quantum cryptography non \u00e8 un problema futuro<\/strong>. <cite>Microsoft ha accelerato il Quantum Safe Program con il goal di transitare prodotti critici a PQC entro 2029<\/cite>, e le organizzazioni che rimandano il planning fino al 2028 scopriranno che 12 mesi sono insufficienti.<\/p>\n<p>Nel mio blog ho scritto di seguito sulla <a href=\"https:\/\/darioiannascoli.it\/blog\/windows-11-nis2-hardening-2026-governance-edr-log-retention-dpia\/\">NIS2 Compliance per Windows 11<\/a>, dove PQC \u00e8 uno dei pilastri di governance. E sulla <a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-incident-response-automation-siem-zero-day-detection-2026\/\">automazione incident response<\/a>, perch\u00e9 la transizione crittografica deve integrarsi con il vostro security event monitoring.<\/p>\n<p><strong>Quello che vi chiedo adesso<\/strong>: avete gi\u00e0 iniziato il cryptographic inventory nel vostro ambiente? Avete devices con TPM 2.0 v1.85, o state ancora su TPM 1.2? Condividete i vostri ostacoli nei commenti\u2014quello che ho imparato nel mio journey potrebbe essere esattamente quello che vi serve.<\/p>\n<p>La finestra di pianificazione \u00e8 adesso. La deadline del 2029 di Microsoft \u00e8 reale. Iniziate.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Windows 11 migra a ML-KEM\/ML-DSA entro 2029. TPM 2.0 v1.85 \u00e8 ora disponibile. Pianificate il cryptographic inventory, hybrid mode, e Secure Boot transition. Roadmap pratica per enterprise.<\/p>\n","protected":false},"author":1,"featured_media":2719,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Post-Quantum Cryptography Windows 11: ML-KEM\/ML-DSA Roadmap 2026","_seopress_titles_desc":"Guida completa migrazione post-quantum Windows 11 2026-2027: ML-KEM, ML-DSA, TPM 2.0, ADCS. Pianificazione enterprise rollout e cryptographic inventory. Microsoft 2029.","_seopress_robots_index":"","footnotes":""},"categories":[6],"tags":[1052,1001,1051,871,859,1050],"class_list":["post-2718","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-windows","tag-cryptographic-agility","tag-enterprise-migration","tag-ml-kem-ml-dsa","tag-post-quantum-cryptography","tag-tpm-2-0","tag-windows-11-security"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2718","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=2718"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2718\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2719"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2718"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2718"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2718"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}