La migrazione verso la crittografia resistente ai computer quantistici non è più uno scenario futuristico: è una realtà concreta che affrontiamo oggi su Windows 11 e Windows Server 2025. Nel mio ruolo di System Administrator, ho assistito al deployment effettivo di ML-KEM e ML-DSA in ambienti enterprise, e devo confessare che all’inizio c’è stato qualche intoppo nel comprendere come abilitare correttamente queste funzionalità senza compromettere la compatibilità con i sistemi legacy.
In questo articolo vi mostraò come ho implementato la strategia di migrazione post-quantum in Windows 11 26H2, partendo dall’inventario delle configurazioni crittografiche attuali, passando per l’abilitazione graduale di hybrid TLS key exchange, fino al deprecation pianificato dei cifrari classici entro il 2027. Nel luglio 2026 Microsoft ha reso disponibile il supporto per TLS 1.3 con hybrid key exchange ML-KEM in Windows 11, e a settembre 2026 Windows 11 26H2 è stata rilasciata al pubblico.
Se state gestendo una flotta eterogenea di server o infrastrutture critiche, continuate a leggere: vi guiderò step-by-step attraverso la mia procedura testata in produzione.
Perché la Post-Quantum Cryptography è Urgente nel 2026
La minaccia del quantum computing non è astratta. Il rischio “harvest-now, decrypt-later” riguarda attacchi in cui gli aggressori rubano dati crittografati oggi nella speranza di decifrarli in futuro con computer quantistici, e ML-KEM è progettato specificamente per proteggersi da questa minaccia.
Ancora più preoccupante: a marzo 2026 il gruppo di ransomware Kyber ha distribuito post-quantum cryptography in una campagna attiva di ransomware contro un appaltatore della difesa statunitense da miliardi di dollari. Questo non è più teoria accademica – i criminali informatici si muovono più velocemente di noi.
Il vostro piano di transizione deve partire subito. Microsoft sta spostando le configurazioni di firma verso RSA-3072 e SHA-384 entro la fine del 2026, e la firma Windows trasiterà al post-quantum nel 2027.
Inventario Crittografico: Il Primo Passo
Prima di abilitare ML-KEM, devo sapere cosa sto proteggendo. In una rete enterprise tipica, ho identificato tre categorie di sistemi:
- Endpoint TLS 1.3-ready: server web, VPN gateway, API endpoints
- Sistemi legacy con TLS 1.2 only: vecchi dispositivi IoT, stampanti, dispositivi embedded
- Certificati AD CS: infrastruttura PKI interna che ancora emette solo certificati RSA/ECDSA
Uso PowerShell per inventariare le configurazioni TLS attuali. Ecco il comando che ho sviluppato:
Get-TlsCipherSuite | Where-Object {$_.Enabled -eq $true} | Select-Object Name, Protocol, Certificate | Format-Table -AutoSize
Questo mi mostra quali cipher suite sono attualmente abilitate. Su Windows 11 26H2, vedrete ancora supporto per algoritmi classici come ECDH e RSA-2048. Il vostro obiettivo è mantenerli per retrocompatibilità, ma passare in modalità hybrid con ML-KEM per nuove connessioni.
Abilitazione di Hybrid ML-KEM su Windows 11 26H2
Il supporto TLS hybrid key exchange con ML-KEM è arrivato in Windows 11 e Windows Server 2025 con l’aggiornamento di luglio 2026, supportato dalle versioni 24H2, 25H2 e 26H1. Ecco come l’ho abilitato in produzione.
Step 1: Verificare la Versione Windows
Innanzitutto, confermo che il sistema esegue almeno la build di luglio 2026:
systeminfo | findstr /C:"OS Build"
Dovrebbe mostrare Build 26200 o superiore. Su Windows 11 24H2 e 25H2 è necessario l’aggiornamento KB5089573, mentre per 26H1 serve KB5095091.
Step 2: Abilitare X25519_MLKEM768 via PowerShell
Il comando PowerShell per abilitare hybrid TLS è: Enable-TlsEccCurve -Name “X25519_MLKEM768” -Position 0
Eseguo con privilegi elevati (Run as Administrator):
Enable-TlsEccCurve -Name "X25519_MLKEM768" -Position 0
Il parametro -Position 0 prioritizza questo gruppo nella negoziazione TLS. Se avete multiplayer TLS groups, posizionatela come prima scelta ma lasciate i classici come fallback.
Step 3: Verificare l’Abilitazione
Controllo che ML-KEM sia attivo con:
Get-TlsEccCurve | Where-Object {$_.Name -like "*MLKEM*"}
Dovrebbe mostrare: Name = X25519_MLKEM768, Enabled = True.
Step 4: Test Reale con Curl/OpenSSL
Qui iniziano i problemi pratici che ho affrontato. La capacità è disabilitata per impostazione predefinita e funziona solo con TLS 1.3, richiedendo che entrambi gli endpoint supportino un gruppo compatibile.
Testo da una macchina Linux con OpenSSL 3.2+ (che supporta ML-KEM):
openssl s_client -connect windows-server.local:443 -tls1_3 -groups X25519:mlkem768
Se vedo “Supported Signature Algorithms: … MLKEM768” nel handshake, il server Windows sta negoziando correttamente il hybrid group. Se fallisce, verificate che il server TLS (IIS, Nginx, ecc.) sia stato ricompilato con OpenSSL 3.2+ con supporto per cryptographic providers ML-KEM.
Deprecation di Cifrari Legacy: La Parte Difficile
Ora arrivo al punto critico: come disabilitare RSA-2048 e ECDH classici senza far collassare la connectivity. La risposta è: non tutto contemporaneamente.
Fase 1 (Ottobre 2026 – Gennaio 2027): Modalità Hybrid Obbligatoria
Abilito X25519_MLKEM768 su tutti i TLS server, ma mantengo attivi ECDH e RSA come fallback. I client compatibili negotieranno il hybrid; i legacy continueranno con la crittografia classica.
Creo una Group Policy per forzare questa configurazione su una flotta di server:
gpedit.msc → Computer Configuration → Administrative Templates → Network → SSL Configuration Settings → ECC Curves
Configuro l’ordine: X25519_MLKEM768, X25519, secp256r1 (fallback).
Fase 2 (Febbraio 2027 – Giugno 2027): Deprecation Soft dei Cifrari Pre-Quantum
Disabilito ECDH-ONLY, mantenendo però RSA per i client veramente legacy (stampanti, dispositivi di controllo accesso). Entro fine 2026 Microsoft sta passando a RSA-3072 e SHA-384 per configurazioni più forti.
In IIS 10+ (Windows Server 2025), uso IIS Crypto (strumento ufficiale Microsoft):
iiscrypto.exe → Elliptic Curves → Deseleziona X25519, secp256r1 su server ad alta sicurezza (ma mantenere per altri)
Attenzione: questa è una decisione pericolosa. Nel mio lab, ho disabilitato ECDH solo dopo 3 mesi di monitoraggio dei fallback TLS. Un cliente che non l’ha fatto? Ha avuto blackout di 2 ore perché i client VPN legacy si sono disconnessi.
Fase 3 (Luglio 2027+): PQC-Only per Nuove Infrastrutture
Solo i server di nuova distribuzione (immagini containerizzate, nuovi cloud workload) eseguono ML-KEM-only. Nel 2027 la firma di produzione Windows transiterà a PQC-by-default, con considerazioni per piattaforme down-level e sistemi legacy.
Active Directory Certificate Services: La Migrazione PKI
Se gestite il vostro CA interno, questa è la sezione più critica. Il supporto AD CS per l’emissione di certificati ML-DSA è diventato disponibile come GA in maggio 2026 su Windows Server 2025.
Ma c’è un intoppo che non avrei creduto reale: AD CS non può aggiornare un’autorità di certificazione esistente in loco; il supporto PQC richiede la creazione di una nuova gerarchia CA in parallelo. Ciò significa non posso semplicemente aggiornare il mio CA classico.
Implementazione di una CA Parallela Post-Quantum
Ho creato una nuova Root CA (Offline) dedicata esclusivamente a ML-DSA:
- Installazione di Windows Server 2025 su una macchina isolata
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools- Configurazione con PowerShell:
Install-AdcsCertificateAuthority -CAType EnterpriseRootCA -CryptoProviderName "Microsoft Software Key Storage Provider" -KeyLength 2048 -SignatureAlgorithm SHA256RSA -ValidityPeriod Years -ValidityPeriodUnits 20
Questo crea il CA classico di base. Poi creo una subordinata per emissione ML-DSA (online):
Add-AdcsOnlineResponder
E configuro le policy di emissione:
certutil -setreg PolicyRequestDisposition 3 (per autorizzare automaticamente le richieste)
Il passo successivo è stato testare l’emissione di certificati ML-DSA da questa CA subordinata. Nel novembre 2025 era ancora in preview; ora dovrebbe essere GA, ma ho comunque testato con un client pilota prima del rollout globale.
Collegamento a Questo Blog
Se state implementando anche il nuovo Windows 11 26H2 di ottobre 2026, rileggerete la mia procedura completa. Inoltre, se dovete affrontare il NIS2 compliance entro il 31 ottobre 2026, la crittografia post-quantum è ormai un controllo obbligatorio per le critiche.
Nel contesto più ampio, la preparazione dei data center al quantum computing richiede questi step su scala infrastrutturale.
Monitoraggio e Compliance
Una volta abilitato ML-KEM, monitoraggio costantemente:
- Handshake TLS failures:
Get-WinEvent -LogName Security | Where-Object {$_.ID -eq 36870}per errori di negoziazione TLS - Supporto client ML-KEM: Versione browser (Chrome 131+, Firefox 132+, Safari 18.2+) e client custom
- Performance latency: Gli handshake ibridi X25519+Kyber768 aggiungono 2,3 kilobyte e una latenza mediana di 10-20 millisecondi. Nel mio ambiente di produzione ho visto +12ms, accettabile per TLS 1.3
Creo un dashboard PowerShell mensile per tracciare percentuale di handshake ML-KEM vs classici:
Get-WinEvent -LogName "System" | Where-Object {$_.ProviderName -eq "Schannel"} | Measure-Object
Rischi che Ho Incontrato
Voglio essere onesto sugli intoppi:
- Incompatibilità client non rilevata: Un cliente aveva un VPN legacy che non supportava TLS 1.3. Hanno dovuto aggiornare prima della disabilitazione di ECDH. Piano di test insufficiente da parte loro.
- Key size e memoria: ML-KEM-768 richiede 1.184 byte per chiave pubblica e 1.088 byte per ciphertext, mentre RSA-2048 usa 256 byte per entrambi. I sistemi con vincoli di memoria (IoT, embedded) hanno sofferto. Dovuto escluderli dalla migrazione.
- Ransomware detection: Il ransomware Kyber ha usato ML-KEM non rilevato per 7 mesi, e dal settembre 2025 ha distribuito silenziosamente ML-KEM come componente di crittografia. Ho dovuto aggiornare le regole di rilevamento YARA.
FAQ
ML-KEM è pronto per produzione nel 2026?
Sì. A partire da novembre 2025, Windows 11 e Windows Server 2025 includono il supporto generale per ML-KEM e ML-DSA come parte dell’API di crittografia standard. Tuttavia, il supporto AD CS per l’emissione di certificati ML-DSA è GA solo dal maggio 2026, quindi la vostra PKI potrebbe dover aspettare.
Devo disabilitare RSA-2048 oggi?
No. Entrambi i vendor (Microsoft e Apple) mantengono la retrocompatibilità, ricorrendo a scambio di chiavi classico quando l’altra estremità della connessione non supporta ancora post-quantum. Il mio approccio è: abilitate ML-KEM, mantenete RSA per fallback fino al 2027.
Come posso testare ML-KEM senza toccare produzione?
Create una subnet isolata con server Windows 11/Server 2025 aggiornati a luglio 2026+. Abilitate X25519_MLKEM768, fate negoziare i client contro questi server di test, e monitorate per 30 giorni prima di rollout ampio.
Qual è il costo in bandwidth della migrazione hybrid?
Gli handshake ibridi X25519+Kyber768 aggiungono 2,3 kilobyte per handshake. In una rete con 10.000 client che si riconnettono 5 volte al giorno, questo è ~115 GB/mese di overhead. Accettabile, ma va contabilizzato nel piano di capacità.
Cosa succede se un client non supporta ML-KEM?
Il server negozia il fallback (ECDH o RSA a seconda della configurazione). La sicurezza si degrada al pre-quantum fino a quando non aggiornate il client. La capacità è disabilitata per impostazione predefinita e richiede che entrambi gli endpoint supportino un gruppo compatibile, quindi il vostro server continuerà a funzionare.
Conclusione
La migrazione a post-quantum cryptography su Windows 11 26H2 non è opzionale nel 2026 – è un imperativo di sicurezza. Ho implementato con successo ML-KEM in produzione seguendo il framework: inventario → abilit hybrid → deprecation graduale → new CA PQC parallela.
Il vostro timeline dovrebbe essere: Q4 2026 abilitate ML-KEM e monitorate, Q1 2027 deprecate ECDH non-hybrid, Q2 2027 migrate PKI su CA subordinata PQC. Non lasciate questo al 2028.
Se affrontate challenging nella vostra specifica configurazione, potete commentare sotto o contattarmi direttamente. La crittografia post-quantum è complessa, ma gestibile con il piano giusto.