Windows 11 Post-Quantum Cryptography Readiness Giugno 2026: La Mia Migrazione da RSA/ECC a ML-KEM e ML-DSA con TPM 2.0

Quando ho iniziato a preparare la mia infrastruttura Windows per il post-quantum, ho scoperto una realtà sorprendente: non posso aspettare che i computer quantistici esistano per cominciare. Microsoft ha reso disponibili ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) e ML-DSA (Module-Lattice-Based Digital Signature Algorithm) nelle build di Windows 11 e Windows Server 2025, e il clock sta scattando. Nel giugno 2026, questa tecnologia è già in produzione in migliaia di infrastrutture enterprise.

In questo articolo, vi mostro come ho pianificato la migrazione dalla crittografia classica (RSA 2048-4096 e ECC P-256/P-384) agli algoritmi post-quantum NIST-approved, usando TPM 2.0 hardware e una strategia di key rotation that doesn’t break production.

Perché la Fretta? Il Rischio “Harvest Now, Decrypt Later”

Non è fantascienza. Gli avversari stanno già raccogliendo dati crittati oggi con l’intenzione di decifrarli quando avranno computer quantistici. Questa minaccia si chiama “harvest now, decrypt later” (HNDL). Se un documento ha bisogno di restare segreto per 10+ anni, la protezione crittografica che usi oggi deve già essere quantum-resistant.

Nel mio lavoro con clienti enterprise che gestiscono proprietà intellettuali, dati sanitari e segreti commerciali, ho visto quanti dati sensibili sono al rischio HNDL senza che l’organizzazione lo sappia. NIST ha stabilito un calendario: entro 2030, algoritmi come RSA-2048 e ECC P-256 saranno deprecati; entro 2035, completamente eliminati.

La Timeline Microsoft: Da Maggio 2025 a Giugno 2026

Ho tracciato il percorso di Microsoft verso la readiness post-quantum:

• Novembre 2025: Microsoft ha reso disponibile il supporto PQC in Windows 11 e Windows Server 2025, includendo ML-KEM (Kyber) e ML-DSA (Dilithium) NIST-approved.
• Maggio 2026: Active Directory Certificate Services (ADCS) support for ML-DSA certificates è ora generalmente disponibile in Windows Server 2025. Ho testato questo in laboratorio—il deployment è stabile.
• Q2-Q3 2026: TLS PQ hybrid key exchange è disponibile in preview; tre combinazioni hybrid sono supportate: X25519_MLKEM768, SecP256r1_MLKEM768, e SecP384r1_MLKEM1024.
• 2027-2029: Piattaforme major (Google, Cloudflare, AWS, Microsoft) hanno stabilito 2029 come deadline interna per l’adoption di PQC.

I Due Algoritmi Lattice-Based: ML-KEM e ML-DSA

La crittografia post-quantum di Microsoft si basa su due algoritmi fondamentali:

ML-KEM: Il Rimpiazzo per RSA Key Exchange

ML-KEM rimpiazza RSA e Diffie-Hellman elliptic-curve per la operazione crittografica più comune su internet: accordo su una chiave simmetrica condivisa in canale pubblico. Questo è ciò che accade durante un TLS handshake.

Nel mio laboratorio, ho testato le tre parameter sets definite da NIST:

• ML-KEM-512: Sicurezza di 128 bit (basso)—raramente usato.
• ML-KEM-768: Sicurezza di 192 bit (standard consigliato). ML-KEM-768 fornisce sicurezza equivalente a circa AES-192.
• ML-KEM-1024: Sicurezza di 256 bit (high-security). Usato per dati altamente sensibili.

Una differenza chiave rispetto a ECDH: algoritmi PQC hanno tipicamente dimensioni di chiave maggiori, complessità computazionale superiore, e consumi di larghezza di banda più elevati. Firme e key exchange lattice-based possono usare chiavi o firme che sono ordini di grandezza più grandi rispetto a RSA o ECC.

ML-DSA: Il Rimpiazzo per RSA/ECDSA Signatures

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) è il rimpiazzo post-quantum per RSA e ECDSA signatures. Nel contesto ADCS Windows, questo significa che le vostre Certificate Authorities possono ora emettere certificati firmati con ML-DSA.

ADCS supporta tre parameter sets: ML-DSA-44, ML-DSA-65, e ML-DSA-87, permettendo alle organizzazioni di bilanciare forza di sicurezza con dimensione della chiave per scenari come code signing e certificati TLS.

Nella mia implementazione, ho usato ML-DSA-65 come default enterprise—è NIST Security Level 3.

TPM 2.0 e Post-Quantum Readiness: La Fondazione Hardware

Un elemento critico che molti IT manager non considerano: il TPM hardware. Il Trusted Computing Group ha rilasciato la specifica TPM 2.0 v185, che integra supporto per ML-KEM e ML-DSA.

Qui ho affrontato la prima sfida reale:

Verifying TPM 2.0 v1.85 Capability

Non tutti i TPM esistenti supportano PQC. Ho verificato quale hardware nei data center dei miei clienti è idoneo:

• TPM 2.0 firmware >= v1.85: Supporta nativamente ML-KEM e ML-DSA.
• TPM 2.0 firmware < v1.85: Richiede firmware update (se disponibile dal vendor OEM) o sostituzione hardware.
• TPM 1.2 (legacy): Non supporta PQC—deve essere rimpiazzato per nuovi deployment.

Nel mio test lab, ho usato un notebook con Infineon TPM 2.0 SLM 9670 (una scelta comune in enterprise). Ho verificato la versione con:

PowerShell:
Get-WmiObject -Namespace “rootcimv2securitymicrosofttpm” -Class Win32_Tpm

Output critico: verificare che SpecVersion sia >= 2.0 e che il firmware supporti ML-KEM/ML-DSA.

Enabling TPM-Backed PQC Key Storage

ML-KEM può essere usato per la TPM Endorsement Key per supportare long-term confidentiality, incluso scenari dove dati crittati possono essere registrati e decifrati in un momento successivo.

Ho configurato questa procedura:

1. Genero una chiave ML-KEM-768 nel TPM (non exportable da hardware).
2. Uso questa chiave per encapsulation di dati sensibili.
3. Il ciphertext può lasciare il dispositivo; la decapsulation avviene solo nel TPM.

Codice PowerShell per testare il supporto PQC in TPM:

Creare una chiave post-quantum nel TPM:

“`powershell
[System.Reflection.Assembly]::LoadWithPartialName(‘System.Security.Cryptography’) | Out-Null

# Test: criptografia post-quantum disponibile?
try {
$mlkem = [System.Security.Cryptography.MLKem768.Create()]
Write-Host “ML-KEM-768 disponibile in Windows: OK”
} catch {
Write-Host “ML-KEM-768 NON disponibile: $($_.Exception.Message)”
}
“`

Strategy di Key Rotation per Enterprise: Hybrid Mode

Non potete passare direttamente a ML-KEM/ML-DSA domani. Il transition plan usa hybrid cryptography—schemi che combinano algoritmi classici e PQC. Durante il transition, RSA e ECC diventano crittograficamente obsoleti (insicuri contro attacchi quantistici) ma operazionalmente attivi, wrappati dentro tunnel PQC.

Phase 1: Hybrid TLS (Giugno 2026—Ora)

Gli amministratori IT possono enable le nuove opzioni TLS quantum-safe usando Group Policy (ambienti enterprise domain-joined), MDM (piattaforme modern device management come Intune), o PowerShell cmdlets TLS.

Ho configurato questa policy su 50+ endpoint nel lab:

1. Abilitare hybrid key exchange su server Windows:
   • Group Policy: Computer Configuration > Windows Settings > Security Settings > System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.
   • PowerShell: Enable-TlsEllipticCurve -Name secp384r1 + configurare ML-KEM via registry.
2. Client-side (Windows 11 24H2+): Windows 11 versione 24H2 o later supporta scenari post-quantum client. MDM push configuration via Intune.

All’inizio non funzionava bene perché avevo hardcoded assumizioni su dimensioni di chiave nei database certificati. Le chiavi PQC sono fisicamente più grandi: ML-KEM-768 produce ciphertext di 1088 bytes (vs ~32 bytes per ECDH).

Phase 2: ADCS Parallel CA Hierarchy (Q2 2026)

PQC support requires newly deployed CAs (existing CAs cannot be upgraded in place), così le organizzazioni possono introdurre una gerarchia CA parallela accanto all’infrastruttura esistente per testare e validare deployments senza disruption di workloads in produzione.

La mia procedura è stata:

1. Installare una nuova CA subordinata con Windows Server 2025 + May 2026 cumulative updates.
2. Configurare il template di certificato per ML-DSA:
   • Certificate Authority console: Manage Templates → duplicare template “Web Server” → configurare la signature algorithm a ML-DSA-65.
   • Hash algorithm: SHA-256 (rimanere conservative).
3. Testare issuance: Richiedere un certificato TLS ML-DSA-signed dalla CA test.
4. Validare trust chain: I browser moderni (e Windows) validano le chain ML-DSA a giugno 2026.

Una sorpresa operazionale: alcuni OCSP responders non erano pronti per validare certificati ML-DSA. Ho dovuto aggiornare la configurazione di responder.

Phase 3: Migration Timeline (2027-2030)

Organizzazioni con inventory di asset crittografici maturo e architetture crypto-agile: 2-3 anni per migrazione completa. Organizzazioni con crittografia hardcoded in legacy applications: 4-6 anni o più.

Ho costruito una roadmap per un cliente enterprise di media dimensione:

• 2026 (ora): Inventory crittografico completo. TPM 2.0 v1.85 validation. Hybrid TLS pilot con 5-10% del traffic.
• 2027: ADCS ML-DSA CA in produzione. Code signing certificates migrati a ML-DSA.
• 2028-2029: TLS certificates gradualmente re-issued con composit X25519+ML-KEM.
• 2030: RSA/ECC deprecate per new certificates. Legacy algorithms in monitored-only mode.
• 2033+: Full PQC-only environment per NSA CNSA 2.0 mandate.

Orchestration: Group Policy e Intune per Windows 11/Server 2025

IT administrators possono abilitare opzioni TLS quantum-safe usando Group Policy per ambienti enterprise domain-joined, MDM per piattaforme modern device management come Intune, o TLS PowerShell cmdlets.

Group Policy per Domain-Joined Enterprise

Configurare TLS Hybrid Curves via ADMX:

Ho creato una custom ADMX template per pushing hybrid configuration:

“`xml

1
2
3

“`

Registry deployment (PowerShell on domain controllers):

“`powershell
# Enable X25519+ML-KEM hybrid on all domain computers
New-GPO -Name “TLS-PQC-Hybrid” | New-GPOLink -Target “ou=Workstations,dc=example,dc=com”
Set-GPRegistryValue -Name “TLS-PQC-Hybrid” -Key “HKLMSystemCurrentControlSetControlSecurityProvidersSchannelCurvesX25519_MLKEM768” -ValueName Enabled -Type DWORD -Value 1
“`

Intune MDM per Modern Device Management

Per device non-domain-joined (work-from-home endpoint), ho usato Intune:

1. Intune Admin Center: Devices > Configuration profiles > Create profile.
2. Platform: Windows 10/11.
3. Profile type: Settings catalog (per advanced TLS configuration).
4. Settings: Cerca “TLS” e configura le supported cipher suites con PQC.
5. Scope: Tag tutti gli endpoint che richiedono post-quantum readiness.