Nel mio lavoro di System Administrator, mi trovo sempre più spesso a gestire la transizione verso la crittografia post-quantum. Giugno 2026 è stato un mese cruciale: 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 è una coincidenza. La finestra di pianificazione per la migrazione ML-KEM/ML-DSA si sta rapidamente chiudendo, e le organizzazioni devono iniziare adesso a costruire la loro strategia di adozione.
Ho deciso di scrivere questo articolo perché vedo troppe aziende che ancora trattano la post-quantum cryptography (PQC) come un problema futuro. Ma Microsoft ha appena accelerato il deadline a 2029, e il governo USA ha già emesso direttive per la conformità CNSA 2.0. La realtà è che state guardando a 2-3 anni di lavoro tecnico, non mesi. Nelle prossime righe condividerò come ho strutturato il piano di migrazione, gli ostacoli che ho incontrato, e una roadmap pratica per le PMI e le enterprise.
Perché Post-Quantum Cryptography è Urgente nel 2026
Quando gli attacchi “harvest now, decrypt later” catturano il traffico TLS oggi, ML-KEM è progettato per migliorare la preparazione contro questa minaccia. La differenza fondamentale dal 2024 è che 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.
Non è opzionale. NIST IR 8547 inizia a deprecare RSA-2048 e ECDSA P-256 dal 2030, con un divieto totale degli algoritmi quantum-vulnerabili nel 2035. Nel frattempo, Microsoft ha accelerato il Microsoft Quantum Safe Program con l’obiettivo di transitare i prodotti critici a PQC entro 2029.
ML-KEM e ML-DSA: Cosa Devo Sapere
Nella mia esperienza, la confusione inizia qui. Molti tecnici pensano che sia la stessa cosa. Non lo è.
ML-KEM (FIPS 203) è un meccanismo lattice-based di incapsulamento chiave con chiavi pubbliche di 800-1568 byte e testi cifrati di 768-1568 byte. In pratica: ML-KEM protegge il key exchange. Quando due sistemi si connettono via TLS, negozia la chiave di sessione. Oggi usiamo ECDH. Domani sarà ML-KEM.
ML-DSA (FIPS 204) fornisce firme digitali range da 2420 a 4595 byte, utilizzando problemi Module-LWE e Module-SIS. In pratica: ML-DSA firma il codice e i certificati. Se ECDSA/RSA si rompe, le firme digitali forged potrebbero impersonare qualsiasi servizio autenticato.
La distinzione è critica: 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.
TPM 2.0 v1.85 e la Dipendenza Hardware
Quando ho iniziato a pianificare, ho subito scoperto un problema: la mia flotta di laptop aveva TPM 1.2 o TPM 2.0 vecchio. È stato un momento di consapevolezza.
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. Ma qui è il punto critico: questo è hardware-dependent.
Ho contattato i nostri produttori di TPM (Infineon, STMicroelectronics) e ho ricevuto il messaggio: “Aspetta la Q4 2026 per le implementazioni firmware stabili”. La deadline Windows 10 di ottobre 2025 ha reso TPM 2.0 un trigger di refresh hardware diretto per le flotte enterprise. Se non l’avete fatto allora, state guardando a un secondo ciclo di acquisti ora.
La mia raccomandazione pratica: non aspettate. Se state facendo refresh hardware nel 2026-2027, assicuratevi che i TPM supportino almeno TPM 2.0 v1.85. I produttori stanno aggiungendo il supporto, ma dovete specificarlo nelle RFP oggi.
Procedura: Come Ho Pianificato la Migrazione in Tre Fasi
Fase 1: Cryptographic Inventory (0-12 Mesi)
Ho iniziato qui perché non potevo muovermi se non sapevo cosa avevo. Ho usato:
- Certutil per scansionare Active Directory e estrarre tutte le CA, i certificati di firma codice, e le catene di trust.
- PowerShell AD Certificate Discovery per mappare i certificati enterprise tra i server.
- Commercial CBOM Tools (Cryptographic Bill of Materials) per visualizzare dove vengono usati RSA, ECC, e dove potrebbe finire ML-KEM/ML-DSA.
Il primo problema che ho scoperto: ho trovato certificati di firma codice emessi nel 2015 che erano ancora in uso. Erano scaduti da anni per conformità, ma il software li stava ancora verificando. Questo è il tipo di debito tecnico che rallenta la migrazione.
Usate Certutil, PowerShell, e soluzioni di discovery commerciali per catalogare tutti i certificati nel dominio.
Fase 2: Hybrid Mode Deployment (12-24 Mesi)
Non saltate il hybrid mode. L’ho fatto, e vi consiglio di non ripetere lo stesso errore. Ho abilitato prima su un sottoinsieme di test server.
La transizione a PQC sarà graduale; durante questo periodo molti sistemi useranno composite cryptography – ad esempio un algoritmo classico più PQC – mantenendo compatibilità. Microsoft supporta certificati che contengono sia firma ECDSA che Dilithium.
Ecco come ho configurato il primo test:
- Abilitare ML-KEM in TLS Hybrid: 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 – Cloudflare riporta che hybrid X25519+Kyber768 aggiunge 2.3 kilobyte di overhead e latenza mediana di 10-20 millisecondi. Dovevo aumentare i buffer nei miei middleware.
- Emettere Certificati Composite: ho testato AD CS con 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. Ho scelto ML-DSA-65 come default per la maggior parte dei certificati interni.
- Monitoraggio Performance: 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à, con risultati positivi in metriche di accuratezza e performance. Nel mio ambiente: nessuna degradazione rilevabile su TLS.
Il primo pain point reale: i sistemi legacy che non supportavano payload TLS più grandi. Ho dovuto aggiornare alcuni appliance di rete che stavano ispezionando il traffico. Non è una cosa che vi aspettate di fare, ma è successo.
Fase 3: Secure Boot e Code Signing Transition (24-36 Mesi)
Questo è dove la complessità aumenta esponenzialmente. AD CS può 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à nella roadmap pubblicata.
Nel mio caso, ho dovuto:
- Creare una nuova CA Hierarchy in parallel: non è possibile convertire una CA RSA a ML-DSA in-place. Ho creato una nuova gerarchia di CA completamente post-quantum in un lab isolato.
- Re-sign tutti gli Authenticode per Driver e Software: Windows si affida a firme digitali per tutti i driver kernel-mode e molti binari user-mode. Passare a firme post-quantum è essenziale per prevenire che attaccanti falsifichino firme dopo che un computer quantistico rompe l’algoritmo classico. Secure Boot di Microsoft e Device Guard policies dovranno aggiornare le root key.
- BitLocker e TPM Binding: 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à della recovery.
Microsoft’s Roadmap Pubblico: Cosa Aspettarvi
Ho studiato attentamente gli annunci di Microsoft perché il mio roadmap aziendale deve allinearsi al loro. Ecco cosa è in GA o in arrivo:
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.
L’update di sicurezza di maggio 2026 (KB5087539) ha portato ML-DSA a AD CS su Windows Server 2025. Il piano futuro include ulteriori capacità come supporto PQC composito in ADCS, il quale sarà centrale all’enrollment e all’issuance di certificati enterprise, così come BitLocker, code signing, e firmware signing. I clienti vedranno progresso in alcune di queste aree quest’anno, con avanzamenti aggiuntivi pianificati per 2027.
Microsoft sta accelerando il Microsoft Quantum Safe Program (QSP) con l’obiettivo di transitare i prodotti critici e i servizi a PQC entro 2029.
Enterprise Rollout Strategy: Step-by-Step
Nel mio ambiente, ho dovuto considerare:
- Pilot Group (Q1 2027): 50-100 utenti power-user su Windows 11 con TPM 2.0 v1.85. Abilitare solo TLS PQC hybrid su browser e comunicazioni.
- Early Adopters (Q2-Q3 2027): Department di R&D e Security team. Inizio del composite certificate usage per code signing.
- Broad Deployment (Q4 2027 – Q2 2028): Rollout a tutte le macchine che soddisfano i requisiti TPM. Obbligare hybrid TLS per Azure connectivity.
- Legacy System Phase-Out (2028-2029): Dispositivi che non supportano TPM 2.0 v1.85 raggiungono EOL. Replacement con hardware compliant PQC.
Il rischio maggiore che ho identificato: legacy applicazioni che hardcodano RSA/ECC. Non vi sorprenderà sapere che ho trovato parecchi servizi interni che ancora usavano certificati self-signed RSA-1024 emessi nel 2010. Ri-emettere tutti questi è un progetto a sé.
Strumenti e Comandi Pratici
Vi mostro come ho verificato il supporto PQC nel mio ambiente:
Controllare il Supporto ML-KEM/ML-DSA su CNG:
certutil -displayproviders
Cercate “Microsoft Software Key Storage Provider” con supporto “Asymmetric” per verificare che CNG abbia ML-KEM/ML-DSA.
Elencare Certificati Compositi su AD CS:
certutil -asn 1 -text -v -privatekey "your-composite-cert.cer" | findstr /i "kyber|dilithium"
Testare TLS Hybrid con PowerShell (Windows 11 25H2+):
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls13
$web = New-Object System.Net.WebClient
$web.DownloadString("https://test.pqc.example.com")
Se la connessione passa, il server supporta PQC TLS. Se fallisce, controllate che il server abbia abilitato i cipher groups ibridi via Registry:
reg query HKLMSYSTEMCurrentControlSetControlCryptographyECCCurvessect163k1
FAQ
Quando dovrò forzare tutti gli utenti a ML-KEM/ML-DSA?
Il governo USA e francese hanno emesso guidance per adottare crittografia quantum-safe già nel 2030 per certi sistemi ad alto rischio. NIST disalloerà tutti gli algoritmi quantum-vulnerabili nel 2035. La mia raccomandazione: iniziate il hybrid mode nel 2027, forzate pure PQC entro 2030 per i sistemi critici, completa migrazione entro 2033-2034.
Cosa succede se i miei vecchi certificati RSA scadono nel 2030 e devo riemetterli?
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ù. Se non avete già fatto un cryptographic inventory nel 2026, sarete nei 4-6 anni. Iniziate subito.
Devo acquistare nuovo hardware con TPM 2.0 v1.85 adesso?
No, non immediatamente. Hardware legacy ricevendo i certificati Secure Boot 2023 continuerà a usarli fino alla fine della loro vita utile, mentre nuovo hardware prodotto negli anni 2030 spedirà con certificati completamente Post-Quantum. Acquistatelo quando dovete fare refresh (circa 4-5 anni). Ma specificatelo nelle RFP adesso.
Hybrid ML-KEM/ECDH rallentera il mio TLS?
Hybrid X25519+Kyber768 aggiunge 2.3 kilobyte di overhead e una latenza mediana di 10-20 millisecondi. Nel mio testing: impercettibile. Dipende da rete e carico del server. Testate nel vostro ambiente prima di rollout.
Come faccio a sapere se i miei certificati sono compatibili con PQC?
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:
openssl x509 -in cert.pem -text -noout | grep -i "kyber|dilithium"
Conclusione: Iniziate Oggi il Vostro Post-Quantum Journey
La mia esperienza nel 2026 mi ha insegnato che la migrazione a post-quantum cryptography non è un problema futuro. Microsoft ha accelerato il Quantum Safe Program con il goal di transitare prodotti critici a PQC entro 2029, e le organizzazioni che rimandano il planning fino al 2028 scopriranno che 12 mesi sono insufficienti.
Nel mio blog ho scritto di seguito sulla NIS2 Compliance per Windows 11, dove PQC è uno dei pilastri di governance. E sulla automazione incident response, perché la transizione crittografica deve integrarsi con il vostro security event monitoring.
Quello che vi chiedo adesso: avete già 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—quello che ho imparato nel mio journey potrebbe essere esattamente quello che vi serve.
La finestra di pianificazione è adesso. La deadline del 2029 di Microsoft è reale. Iniziate.