Migrazione post-quantum — il playbook dell'inventario crittografico

Usa questo playbook quando sei un operatore regolamentato che deve produrre un piano di migrazione post-quantum difendibile sull'orologio di un'autorità: un'entità essenziale o importante NIS2, un'entità finanziaria DORA, un soggetto del settore pubblico UE dentro la roadmap coordinata, un'agenzia o un fornitore federale statunitense sotto l'Executive Order 14412, o qualsiasi organizzazione che detiene segreti la cui confidenzialità deve sopravvivere all'arrivo di un quantum computer crittograficamente rilevante.

Il deliverable che questo playbook produce sono due cose che un regolatore può leggere: un inventario crittografico (spesso chiamato CBOM — una cryptography bill of materials) e un piano di migrazione sequenziato mappato sulle scadenze che ti vincolano.

Cosa non rientra qui: la scelta tra gli algoritmi in sé — quella decisione (ML-KEM, ML-DSA, SLH-DSA sotto FIPS 203/204/205) è trattata nella definizione di post-quantum cryptography. Gli estate solo simmetrici (AES-256, SHA-384) richiedono una revisione di configurazione, non questo programma — la migrazione difficile, quella asimmetrica, è ciò che questo playbook sequenzia.

A differenza di un playbook di incidente, l'orologio post-quantum si misura in anni — ma il primo gate è già dentro il tuo orizzonte di pianificazione.

• Fine 2026 — roadmap coordinata UE, Milestone 1. La Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography si aspetta che ogni Stato membro abbia gettato le fondamenta: identificato gli stakeholder, costruito inventari degli asset crittografici e mappe delle dipendenze inclusa la supply chain, e avviato un programma nazionale di sensibilizzazione. Questa è la scadenza dell'inventario — ed è quest'anno.
• Fine 2030 — casi d'uso ad alto rischio. La stessa roadmap stabilisce che i meccanismi a chiave pubblica quantum-vulnerable non devono essere usati stand-alone dopo il 2030 per i casi d'uso ad alto rischio. Il NIST IR 8547 è allineato: gli algoritmi a chiave pubblica a sicurezza 112-bit (RSA-2048, ECDSA P-256) sono deprecati dopo il 2030.
• Fine 2030 / 2031 — governo federale USA. L'Executive Order 14412 (firmato il 22 giugno 2026) impone alle agenzie federali di migrare i sistemi high-value e high-impact al key establishment post-quantum entro la fine del 2030 e le firme digitali entro la fine del 2031.
• 2035 — il backstop. La roadmap UE punta ai casi d'uso a rischio medio entro il 2035; il NIST IR 8547 vieta del tutto la crittografia a chiave pubblica quantum-vulnerable dopo il 2035.

Sopra tutte queste c'è l'orologio harvest-now-decrypt-later, che non ha una data pubblicata perché è già partito: un avversario che registra oggi il tuo traffico cifrato lo decifra retroattivamente quando un quantum computer esisterà. Per qualsiasi segreto la cui confidenzialità deve sopravvivere fino ad allora, la migrazione è già in ritardo. Sequenzia di conseguenza.

Obiettivo: un inventario crittografico completo e strutturato (CBOM). Non puoi fare risk-ranking o migrare ciò che non hai trovato.

Enumera la crittografia ovunque risieda — non solo gli ovvi certificati TLS:

• Trasporto: endpoint TLS (pubblici e interni), gli algoritmi di key exchange e firma che ciascuno negozia, coppie mutual-TLS, tunnel VPN (IKE/IPsec, WireGuard), chiavi SSH host e utente.
• PKI e firma: certificate authority interne ed esterne, root e intermediate CA, chiavi di code-signing, chiavi di document-signing, chiavi di firmware-signing — i trust anchor a vita lunga sono i più difficili da ruotare e i target di harvest di maggior valore.
• Dati a riposo: cifratura di database e dischi, cifratura dei backup, chiavi custodite in KMS/HSM, gerarchie di envelope-encryption.
• Embedded in applicazione: crittografia hard-coded o configurata dentro le tue applicazioni e librerie, firma dei token JWT/OIDC, firma delle richieste API.
• Terze parti e supply chain: la crittografia che i tuoi fornitori SaaS, i cloud provider e i fornitori embedded/IoT usano per tuo conto — la roadmap richiede esplicitamente che la mappa delle dipendenze arrivi fin dentro la supply chain.

Per ogni voce, registra: algoritmo e dimensione della chiave, scopo, team proprietario, dove risiede il materiale della chiave, la vita utile di confidenzialità del dato che protegge, e se il sistema è crypto-agile (il suo algoritmo può essere sostituito senza re-engineering?).

Automatizza la discovery dove puoi — scansione di rete per TLS/SSH, crawling dei certificate store, scansione del codice e delle dipendenze — ma aspettati lacune: firmware embedded, sistemi air-gapped e applicazioni legacy di solito richiedono un'attestazione manuale dai rispettivi owner.

Obiettivo: trasformare l'inventario piatto in un piano sequenziato. Il principio di ordinamento è la vita utile di confidenzialità rispetto al time-to-CRQC, non la facilità di migrazione.

Fasce di urgenza:

• Alta: segreti a vita lunga e trust anchor — root e code-signing CA, dati classificati o regolamentati con ritenzione pluridecennale, proprietà intellettuale, cartelle cliniche, comunicazioni statali. Questi sono il bersaglio dell'harvest-now-decrypt-later; qui la migrazione è già in ritardo.
• Media: dati con confidenzialità pluriennale ma limitata — record finanziari dopo il regolamento, comunicazioni interne soggette a piani di ritenzione.
• Bassa: dati di sessione a vita breve e traffico transitorio il cui valore scade prima che un quantum computer sia plausibile.

Valutazione di crypto-agility: per ogni voce alta e media, decidi la modalità di migrazione — ibrida (esegui insieme un algoritmo classico e uno post-quantum, così sei al sicuro se regge uno dei due), sostituzione diretta (dove l'architettura già astrae l'algoritmo), o re-engineering a fasi (sistemi legacy ed embedded con crittografia hard-coded e vita utile sul campo di 10-20 anni — gateway VPN, firmware IoT, root CA).

Esegui pilot per il caso d'uso a rischio più alto e per uno rappresentativo a rischio medio prima di impegnare l'intero estate — la roadmap si aspetta progetti pilota in questa fase, e fanno emergere le rotture di integrazione (chiavi più grandi, firme più grandi, latenza di handshake, incompatibilità di protocollo) che un piano sulla carta nasconde.

Obiettivo: eseguire la migrazione in ordine di priorità e produrre evidenza del progresso a ogni gate.

• Prima il key establishment ibrido. Per gran parte dell'infrastruttura TLS e VPN, distribuisci un key exchange ibrido ML-KEM + classico. L'ibrido protegge sia da una rottura quantistica dell'algoritmo classico sia da una debolezza ancora non scoperta in quello nuovo. È la mossa a maggior leva contro l'harvest-now-decrypt-later perché protegge la confidenzialità da subito.
• Poi le firme. Migra le firme di code-signing, firmware-signing e dei certificati verso ML-DSA (o SLH-DSA dove per i trust anchor a vita lunga è opportuno un backup conservativo hash-based). Le firme proteggono l'integrità, non la confidenzialità passata, quindi seguono il key establishment in priorità.
• Sostituzione diretta dove un'architettura crypto-agile ti permette già di cambiare l'algoritmo per configurazione.
• Re-engineering a fasi per la coda legacy ed embedded — mettila a budget come un progetto pluriennale, non come una patch.

A ogni passo, registra cosa si è spostato e quando. La domanda del regolatore nel 2027 e oltre non sarà "sei completamente migrato" — nessuno lo sarà — sarà "mostrami il tuo inventario, il tuo risk-ranking e il progresso documentato rispetto al piano". Una migrazione che non puoi documentare è, per un'autorità, una migrazione che non è avvenuta.

Tieni questi artefatti aggiornati, firmati ed esportabili (non ricostruiti la settimana prima di un audit):

• L'inventario crittografico / CBOM, con un timestamp di ultimo aggiornamento e il metodo di discovery per ogni voce.
• La mappa delle dipendenze, inclusa l'estensione alla supply chain che la roadmap UE richiede.
• La motivazione del risk-ranking: perché ogni sistema sta nella sua fascia di urgenza, legata alla vita utile di confidenzialità del dato.
• Il piano di migrazione sequenziato con date obiettivo per sistema mappate sui gate 2026 / 2030 / 2031 / 2035.
• I risultati dei pilot e i problemi di integrazione che hanno fatto emergere.
• Lo stato di migrazione per sistema nel tempo — la linea del progresso documentato.
• Le attestazioni di crypto-agility dei fornitori per i sistemi di terze parti ed embedded.
• Il verbale di approvazione dell'organo di amministrazione — sia la roadmap UE sia l'articolo 21 NIS2 ne fanno una responsabilità dell'organo di governo, non puramente tecnica.

La parte difficile non è produrre questo pack una volta; è tenerlo aggiornato e difendibile attraverso ogni framework che oggi si aspetta evidenza di crypto-agility, mentre l'estate cambia sotto di te. È qui che si inserisce il pilastro di compliance automatica di Zero Hunt: mappa i tuoi controlli di migrazione su 34 framework regolatori in tutto il mondo con cross-framework control mapping e scoring severity-weighted, ed esporta un evidence pack firmato ECDSA con catena di custodia dal Trust Center — così il report di progresso che un'autorità chiede è un export, non una settimana/uomo di riconciliazione — mentre le sue campagne scheduled e change-triggered mantengono viva la fotografia degli asset esterni, così un endpoint appena esposto che negozia ancora key exchange quantum-vulnerable emerge come finding invece di uscire dall'inventario in silenzio, e il red team AI autonomo verifica se quell'endpoint è davvero raggiungibile e se il key exchange legacy è ancora negoziabile, trasformando una riga dell'inventario in una priorità ordinata per sfruttabilità. L'engine gira interamente on-premise su modelli privati, così l'inventario dei tuoi segreti a vita lunga più sensibili non lascia mai l'apparato.

1. Trattare l'inventario come un progetto una tantum. L'inventario crittografico è un asset vivo, non un deliverable 2026 che archivi e dimentichi. Ogni nuovo servizio, certificato e fornitore lo cambia. Senza rediscovery continua o change-triggered, l'inventario è obsoleto entro un trimestre e il primo spot-check dell'autorità trova un endpoint che non hai mai elencato.

2. Dimenticare i trust anchor a vita lunga. I team inventariano i certificati TLS e si perdono le root CA, le chiavi di code-signing e di firmware-signing con validità di 10-20 anni. Sono i più difficili da ruotare e i target di harvest di maggior valore — vanno in cima al piano, non in fondo.

3. Perimetrare solo l'estate internet-facing. TLS interno, mTLS di service-mesh, cifratura dei database, cifratura dei backup e SSH sono tutti in scope. Chi è già dentro decifra anche il traffico interno.

4. Fidarsi dell'etichetta "quantum-safe" di un fornitore senza validarla. Un prodotto marcato post-quantum può comunque negoziare di default un handshake solo classico, o offrire la modalità post-quantum solo in una configurazione che non hai abilitato. Richiedi la crypto-agility nei contratti e valida gli algoritmi effettivamente negoziati, non la scheda tecnica.

5. Migrare le firme prima del key establishment. Le firme proteggono l'integrità; non fanno nulla per la confidenzialità del traffico già in corso di harvest. Se la capacità è finita, il key establishment ibrido sui canali a confidenzialità più alta viene prima.

6. Ignorare la coda di performance e compatibilità. Chiavi e firme post-quantum sono più grandi; gli handshake possono crescere e alcuni dispositivi vincolati, middlebox e protocolli legacy si rompono. I pilot della Fase B esistono per scoprirlo prima che diventi un incidente in produzione.

La migrazione post-quantum è un obbligo mondiale che converge da più direzioni insieme, e un solo inventario le alimenta tutte:

• UE: la roadmap coordinata fissa i milestone 2026 / 2030 / 2035; l'articolo 21 NIS2 richiede già politiche e procedure sull'uso della crittografia e, ove opportuno, della cifratura come misura di sicurezza di base, che le autorità leggono sempre più come comprensiva di un piano di crypto-agility.
• USA: l'Executive Order 14412 e il NIST IR 8547 fissano i gate federali 2030 / 2031 / 2035; i fornitori federali li ereditano via procurement.
• Finanza: il framework di gestione del rischio ICT di DORA (articolo 9) richiede controlli crittografici solidi e aggiornati, e un piano post-quantum documentato è ormai parte di una risposta difendibile.
• Guidance nazionali: l'ENISA a livello UE e le autorità nazionali (il BSI tedesco, l'ANSSI francese, la CNSA 2.0 della NSA statunitense per i sistemi di sicurezza nazionale) pubblicano timeline di migrazione che possono vincolarti prima delle date di testata — verifica quella per la tua giurisdizione e il tuo settore.

In ogni caso il lavoro di fondo è lo stesso: un inventario, un risk-ranking, un piano di migrazione documentato, esportato per regime. Costruirlo una volta e tenerlo aggiornato è la differenza tra una roadmap che puoi difendere e un foglio di calcolo che era vero nel 2026.