PQC StatusL'Articolo 21(2)(h) della NIS2 impone ai soggetti essenziali e importanti di dotarsi di politiche e procedure relative all'uso della crittografia e, ove opportuno, della cifratura. La direttiva non prescrive alcun modello, alcun elenco di algoritmi né alcuna scadenza, quindi la qualità del documento dipende da voi. Questo articolo propone uno schema sezione per sezione da copiare, collega ogni sezione alle evidenze che un valutatore richiederà e mostra con precisione dove collocare le disposizioni per la transizione post-quantistica.
Cosa richiede l'Articolo 21(2)(h), e cosa non richiede
La Directive (EU) 2022/2555 elenca, all'Articolo 21(2), le misure minime di gestione del rischio di cibersicurezza che i soggetti interessati devono adottare. La lettera (h) è una sola riga: politiche e procedure relative all'uso della crittografia e, ove opportuno, della cifratura. Il testo è disponibile su EUR-Lex (data.europa.eu/eli/dir/2022/2555/oj). L'Articolo 21(1) inquadra tutte queste misure come proporzionate al rischio affrontato e fondate sullo stato dell'arte.
Ne derivano tre conseguenze. Primo, l'obbligo è documentale e procedurale: serve una policy scritta più le procedure che la applicano, non una specifica cipher suite. Secondo, poiché la direttiva non indica alcun algoritmo né alcuna lunghezza di chiave, è la policy stessa a dover contenere questo elenco e a dover stabilire come l'elenco evolve nel tempo. Terzo, l'espressione ove opportuno significa che la decisione di non cifrare qualcosa deve essere una scelta documentata e basata sul rischio, non un'omissione. La nostra pagina di riferimento sull'Articolo 21(2)(h) della NIS2 raccoglie il testo e le relative scadenze.
Questo articolo ha carattere informativo e non costituisce consulenza legale. Sono la legge nazionale di recepimento, il vostro settore e la vostra autorità competente a stabilire cosa sia sufficiente nella pratica.
Lo schema di policy da copiare
La struttura seguente è uno schema operativo, non un requisito normativo. È ordinata in modo che un lettore che parte dalla sezione 1 arrivi a una decisione sugli algoritmi approvati entro la sezione 5, e in modo che ogni sezione successiva produca un elemento che un valutatore possa esaminare. Una policy di otto-quindici pagine, con i parametri tecnici in un allegato che potete rivedere senza dover riapprovare l'intero documento, è di norma sufficiente.
| # | Sezione | Cosa stabilisce |
|---|---|---|
| 1 | Finalità e base giuridica | Che il documento attua l'Articolo 21(2)(h) della NIS2 come recepito a livello nazionale, ed elenca ogni altro regime applicabile (DORA, PCI DSS, Cyber Resilience Act, norme settoriali). |
| 2 | Ambito di applicazione | Entità, controllate, ambienti (produzione, test, cloud, OT), classi di dati e servizi di terze parti coperti. Esclusioni nominative e relative motivazioni. |
| 3 | Ruoli e responsabilità | Chi è titolare della policy, chi approva le modifiche agli algoritmi, chi approva le eccezioni, chi ricopre i ruoli di custode delle chiavi, e il coinvolgimento dell'organo di gestione previsto dalla NIS2. |
| 4 | Rischio e classificazione dei dati | Come viene assegnata la durata di riservatezza a ciascuna classe di dati. È questo l'input che decide quali sistemi migrare per primi. |
| 5 | Algoritmi e parametri approvati | L'elenco consentito con i parametri minimi, per caso d'uso: dati in transito, dati a riposo, firme, hashing, derivazione delle chiavi, generazione di numeri casuali. |
| 6 | Algoritmi deprecati e vietati | Cosa non può più essere implementato, cosa resta tollerato solo per la verifica di elementi legacy, e la data di rimozione per ciascuno. |
| 7 | Baseline di protocolli e configurazioni | Versione minima di TLS, ordine dei gruppi e delle cipher suite, accordo di chiave SSH, impostazioni VPN e database. Una baseline per ogni famiglia di piattaforme. |
| 8 | Gestione delle chiavi | Generazione, distribuzione, conservazione, rotazione, escrow, archiviazione e distruzione, con i requisiti hardware per ogni classe di chiavi. |
| 9 | Gestione dei certificati | Autorità di emissione, validità massima, automazione del rinnovo, revoca, e un registro dei certificati con i relativi responsabili. |
| 10 | Inventario crittografico | Cosa viene inventariato (algoritmo, parametri, libreria e versione, sistema, responsabile, classe di dati), come viene raccolto e con quale frequenza viene aggiornato. |
| 11 | Agilità crittografica e transizione post-quantistica | Le condizioni di attivazione, la sequenza di migrazione e le date obiettivo. Si veda la sezione successiva. |
| 12 | Requisiti per fornitori e approvvigionamenti | Clausole richieste a fornitori e cloud provider: dichiarazione degli algoritmi in uso, supporto dello scambio di chiavi ibrido, preavviso delle modifiche crittografiche. |
| 13 | Eccezioni | Formato della richiesta, livello di accettazione del rischio richiesto, controlli compensativi, data di scadenza obbligatoria, registro centrale. |
| 14 | Monitoraggio, test e revisione | Frequenza delle scansioni esterne e interne, rilevamento delle derive di configurazione, e ciclo di revisione della policy stessa. |
| 15 | Gestione degli incidenti crittografici | Cosa fare in caso di compromissione di una chiave, emissione errata di un certificato o pubblicazione di un attacco pratico contro un algoritmo approvato, compresi i collegamenti con il processo di notifica degli incidenti NIS2. |
Sezione 5: cosa deve contenere l'elenco approvato
Indicate gli standard definitivi e specificate i parametri. Per l'incapsulamento di chiavi, ML-KEM è standardizzato nel NIST FIPS 203, pubblicato come standard definitivo il 13 agosto 2024, insieme a ML-DSA nel FIPS 204 e SLH-DSA nel FIPS 205 (csrc.nist.gov/pubs/fips/203/final). Per la protezione simmetrica, AES-256 è preferibile per i dati a lunga durata: gli algoritmi simmetrici e le funzioni di hash non sono violati dall'algoritmo di Shor, e l'algoritmo di Grover è il motivo per cui si sceglie la dimensione di chiave maggiore. Se operate in Germania, la BSI TR-02102-1 (versione 2026-01, pubblicata il 23 gennaio 2026) è una linea guida tecnica che raccomanda l'accordo di chiave ibrido post-quantistico e RSA di almeno 3000 bit, e raccomanda l'accordo di chiave solo classico unicamente fino alla fine del 2031, o alla fine del 2030 per esigenze di protezione molto elevate. Linee guida di questo tipo sono raccomandazioni, non obblighi, a meno che la vostra legge nazionale o un contratto non le renda vincolanti.
Sezione 6: cosa vietare esplicitamente
RC4 è vietato in TLS dalla RFC 7465. MD5 e SHA-1 sono obsoleti per le firme. DSA non è più approvato per la generazione di firme secondo il FIPS 186-5 e può essere usato solo per verificare firme legacy. I gruppi TLS Kyber pre-standard, come X25519Kyber768Draft00 al codepoint 0x6399, sono obsoleti e dovrebbero essere rimossi a favore dei gruppi ML-KEM registrati. Aggiungete una data di rimozione a ogni riga, altrimenti la sezione diventa una lista di buone intenzioni.
Sezione 11: le disposizioni per la transizione post-quantistica
La NIS2 non menziona la crittografia post-quantistica. Il motivo per includerla comunque è lo scenario harvest now, decrypt later (raccogli ora, decifra dopo): il traffico registrato oggi è protetto soltanto dallo scambio di chiavi che lo ha negoziato, quindi una sessione catturata adesso potrebbe essere decifrata in futuro se lo scambio di chiavi è vulnerabile ai computer quantistici. Per questo lo scambio di chiavi ibrido viene per primo, mentre firme e certificati possono migrare in seguito. Si noti che COM(2026) 13, pubblicata il 20 gennaio 2026, è una proposta della Commissione di modifica della NIS2 affinché le strategie nazionali includano una politica di transizione post-quantistica. Si tratta di una proposta, non è stata adottata, e riguarda le strategie degli Stati membri anziché imporre un obbligo diretto ai soggetti (EUR-Lex CELEX 52026PC0013).
Inserite quattro elementi in questa sezione. Primo: l'obbligo di inventario, aggiornato con una frequenza dichiarata, perché non si può migrare ciò che non si sa elencare. Secondo: la sequenza, lo scambio di chiavi prima delle firme, i servizi esposti all'esterno prima di quelli interni, i dati a lunga riservatezza per primi. Terzo: le date di riferimento a cui scegliete di allinearvi, qualificate per ciò che sono. La EU Coordinated Implementation Roadmap v1.1 (pubblicata il 23 giugno 2025) è un orientamento coordinato per gli Stati membri, non un regolamento vincolante per le imprese: fissa come primi passi un inventario crittografico e roadmap nazionali entro la fine del 2026, la migrazione dei casi d'uso ad alto rischio entro la fine del 2030 e di quelli a rischio medio entro la fine del 2035, con quelli a basso rischio per quanto possibile (la nostra sintesi e la scheda nella biblioteca della Commissione). NIST IR 8547 resta una bozza pubblica iniziale, pubblicata il 12 novembre 2024: propone di deprecare gli algoritmi vulnerabili ai computer quantistici con sicurezza a 112 bit dopo il 2030 e di non consentire più alcun algoritmo a chiave pubblica vulnerabile ai computer quantistici dopo il 2035. Citatela come bozza. Quarto: la clausola di agilità, ossia le condizioni tecniche e contrattuali alle quali potete cambiare algoritmo senza riprogettare il sistema.
La baseline da inserire nell'allegato è breve. Gruppo ibrido per primo, fallback classico mantenuto, test in staging prima della produzione:
# OpenSSL 3.5 or later is required for the ML-KEM TLS groups
# openssl.cnf, ssl_conf section: hybrid first, classical fallback retained
Groups = X25519MLKEM768:SecP256r1MLKEM768:X25519:P-256X25519MLKEM768 è registrato dalla IANA a 0x11EC (4588), SecP256r1MLKEM768 a 0x11EB (4587) e SecP384r1MLKEM1024 a 0x11ED (4589); il registro IANA dei parametri TLS fa fede (iana.org). La RFC 10024 (agosto 2026) specifica l'accordo di chiave ibrido post-quantistico e tradizionale per TLS 1.3. Le versioni attuali di Chrome, Edge e Firefox offrono già X25519MLKEM768 per impostazione predefinita, quindi abilitarlo è normalmente invisibile per gli utenti. Sul versante SSH, OpenSSH 10.0 (9 aprile 2025) ha reso mlkem768x25519-sha256 l'accordo di chiave predefinito, e OpenSSH 10.1 (6 ottobre 2025) emette un avviso quando una connessione negozia un accordo di chiave non post-quantistico.
Dalla clausola della policy all'evidenza
Un valutatore legge la policy, poi chiede la prova che venga applicata. Definire l'elemento probatorio al momento della stesura costa meno che ricostruirlo in seguito. La colonna di destra qui sotto rappresenta la nostra interpretazione delle buone pratiche, non un requisito letterale dell'Articolo 21(2)(h).
| Clausola della policy | Evidenza da conservare |
|---|---|
| Algoritmi e parametri approvati | Policy firmata con cronologia delle versioni e verbale di approvazione dell'ultima modifica. |
| Inventario crittografico | Estrazione datata dell'inventario con il responsabile del sistema per ogni voce. Un CBOM (cryptographic bill of materials) è un modo pratico per produrlo, come descritto nella nostra nota su cos'è un CBOM. |
| Baseline dei protocolli | Registrazioni del configuration management più i risultati delle scansioni esterne per ogni endpoint pubblico. |
| Gestione di chiavi e certificati | Registro delle chiavi, log di rotazione e un registro dei certificati con date di scadenza e responsabili. |
| Eccezioni | Registro delle eccezioni con accettazione del rischio, controllo compensativo e data di scadenza. |
| Frequenza di revisione | Verbale dell'ultima revisione e conseguente elenco delle modifiche. |
| Transizione post-quantistica | Piano di migrazione con responsabili e date obiettivo, e un rapporto sullo stato di avanzamento rispetto al piano. |
La NIS2 non stabilisce alcuna frequenza di revisione. Se rientrate anche nell'ambito di PCI DSS v4.0.1, il requisito 12.3.3 impone che le cipher suite e i protocolli in uso siano documentati e rivisti almeno ogni 12 mesi, compresa una strategia documentata per i cambiamenti previsti nelle vulnerabilità crittografiche, obbligatorio dal 31 marzo 2025. Adottare una cadenza di dodici mesi per l'intera policy è una baseline unica difendibile. Le entità finanziarie dovrebbero allineare lo stesso documento con DORA: l'Articolo 6 del Commission Delegated Regulation (EU) 2024/1774 richiede una policy di cifratura e controlli crittografici che includa disposizioni per aggiornare o modificare la tecnologia crittografica in base agli sviluppi della crittoanalisi, e l'Articolo 7 richiede la gestione delle chiavi lungo l'intero ciclo di vita più un registro dei certificati per gli asset ICT a supporto di funzioni critiche o importanti. La nostra guida alla policy di cifratura DORA ai sensi dell'Articolo 6 tratta la formulazione più prescrittiva, e un unico documento può soddisfare entrambi i regimi se la sezione sull'ambito di applicazione è esplicita.
Recepimenti nazionali e cosa evitare
La NIS2 è una direttiva, quindi produce effetti attraverso la legge nazionale. Gli atti di recepimento, gli orientamenti delle autorità nazionali e gli atti di esecuzione possono aggiungere dettagli: una struttura obbligatoria della policy, linee guida nazionali di riferimento specifiche, frequenze di revisione o formati di notifica determinati. Il dettaglio varia per Stato membro e per settore, quindi verificate gli orientamenti pubblicati dalla vostra autorità nazionale prima di consolidare il documento. Non date per scontato che il minimo previsto dalla direttiva sia il vostro tetto massimo.
Vale la pena segnalare quattro debolezze frequenti. Una policy che elenca gli algoritmi ma nessuna data di rimozione non può essere sottoposta ad audit. Una policy senza processo di gestione delle eccezioni spinge i team verso una non conformità silenziosa. Una policy che indica un prodotto commerciale anziché una famiglia di algoritmi non regge alla migrazione successiva. E una policy che dichiara la prontezza post-quantistica senza un inventario non può dimostrare quali sistemi siano interessati. Mantenete accurate le cautele anche nel documento: uno standard in bozza è una bozza, e una raccomandazione di un'agenzia nazionale non è un obbligo, a meno che il vostro ambito non la renda tale. L'ANSSI, ad esempio, afferma che l'ibridazione è obbligatoria nel proprio ambito regolamentato (qualificazione dei prodotti, ambito della difesa, SAIV e SIIV), mentre le sue raccomandazioni post-quantistiche più generali non sono ancora obblighi regolamentari altrove.
Prossimo passo: misurare ciò che la vostra policy dichiara
La sezione 7 dello schema è l'unica parte della policy che una terza parte può verificare dall'esterno, quindi verificatela prima voi. Scansionate il vostro dominio con PQC Status per vedere le versioni TLS, le cipher suite, il supporto dei gruppi ibridi ML-KEM e la catena di certificati che i vostri endpoint pubblici negoziano effettivamente, quindi allegate il risultato all'allegato delle baseline come evidenza datata per quella clausola. Una scansione descrive solo la configurazione TLS visibile dall'esterno: non è una certificazione né un'attestazione di conformità. Eseguitela su ogni hostname pubblico, registrate le lacune nel registro delle eccezioni con una data di scadenza, e la sezione post-quantistica della vostra policy smetterà di essere un'aspirazione.