Autenticazione multifattore NIS2: 5 classi di accesso obbligate

L'articolo 21 della direttiva (UE) 2022/2555 elenca le misure di cibersicurezza che ogni soggetto NIS2 deve attuare. Il punto (j) ne nomina esplicitamente una: l'autenticazione multifattore. Diciotto mesi dopo l'entrata in vigore, l'autenticazione multifattore NIS2 ha abbandonato il piano della «buona pratica» per quello dell'obbligo di legge — e il Regolamento di Esecuzione (UE) 2024/2690 ha chiarito quali fattori supereranno un'ispezione e quali no.

Lo spostamento non sta nel sostantivo. Sta nell'aggettivo. L'allegato del regolamento di esecuzione allinea NIS2 al consenso di vigilanza post-2023 condiviso da ENISA, ANSSI e BSI: il multifattore è necessario ma non è più sufficiente. Il riferimento diventa l'autenticazione resistente al phishing — una categoria che la direttiva non nomina, ma sulla quale il regolamento di esecuzione, le autorità nazionali e la prassi di vigilanza convergono. I consigli che approveranno un piano dell'articolo 21 nel 2026 ereditano questo giudizio.

1. Cosa impone realmente l'articolo 21(2)(j)

L'articolo 21(2)(j) richiede «soluzioni di autenticazione multifattore o di autenticazione continua, comunicazioni vocali, video e testuali protette». La formulazione è breve e il perimetro ampio. Si applica a ogni soggetto dei diciotto settori coperti dalla direttiva, non solo a chi tratta dati personali, non solo a chi espone un servizio al pubblico.

Due espressioni caricano l'obbligo. Autenticazione continua — il regolamento di esecuzione precisa che si tratta di una nuova validazione a livello di sessione, non solo dell'accesso iniziale. Soluzioni — al plurale, segnale che un metodo unico non copre tutte le classi di accesso. La decisione MFA non è una casella nella console IAM. È un programma che mappa la forza del fattore sul livello di rischio, sull'intera superficie di accesso del soggetto.

Lo stesso articolo rende l'organo di gestione — vale a dire il consiglio — responsabile dell'approvazione della politica che ne deriva. Si veda le cinque responsabilità del consiglio che gli amministratori non possono delegare per l'inquadramento di governance.

2. Le cinque classi di accesso che devono portare MFA

Il Regolamento di Esecuzione 2024/2690 non elenca letteralmente «cinque classi». Il suo allegato costruisce il requisito combinando i principi dell'articolo 21 con la base tecnica. Tradotto nella superficie che un CISO difende davvero:

1. Accesso amministrativo — amministratore di dominio, root del cloud, hypervisor, CLI di apparati di rete. Ogni sessione privilegiata, su ogni sistema, ad ogni accesso. Nessuna deroga per «reti fidate» — la segmentazione è un controllo di contenimento, non un controllo di autenticazione.
2. Accesso remoto — VPN, RDP, jump host, SSH dall'esterno del perimetro del soggetto. L'ondata di vigilanza 2024 di ANSSI e BSI singola questa categoria — la maggior parte dei ransomware che si chiudono in una notifica a 72 ore è entrata da un accesso remoto non protetto.
3. Accesso ad applicazioni esposte — webmail, portali clienti con funzioni amministrative o finanziarie, interfacce di servizio pubblico. Clienti e cittadini, non solo dipendenti.
4. Accesso a dati sensibili — basi di dati di produzione, sistemi finanziari, cartelle sanitarie, repository di codice sorgente. Il confine non è «la rete interna» — è il confine di ruolo dell'applicazione.
5. Interfacce CI/CD e infrastructure-as-code — Git sull'orchestratore di build, chiavi di deploy, gestore di segreti. Categoria più giovane e meno codificata, ma un attacco alla catena di approvvigionamento riuscito vi entra sempre più spesso. La stessa logica che giustifica le clausole NIS2 nei contratti dei fornitori critici si estende alle pipeline interne.

Quando un'autorità chiede «dove è applicato l'MFA?», la risposta deve essere un elenco, non «ovunque». L'elenco è l'artefatto di audit.

3. Perché SMS e TOTP non bastano più da soli

L'allegato del regolamento di esecuzione non nomina né SMS né TOTP. Rinvia la specifica tecnica allo «stato dell'arte», formula che la direttiva usa di proposito per restare attuale. Letto nel 2026, lo stato dell'arte per le classi di accesso ad alto rischio è l'autenticazione resistente al phishing: chiavi di sicurezza FIDO2 / WebAuthn, autenticatori di piattaforma con attestation (Windows Hello for Business, Touch ID di macOS con attestation, Android recente con strong-box) e passkey sincronizzate via cloud attestati dal fornitore.

Multifattore è la parola della direttiva. Resistente al phishing è la parola di ogni linea-guida di vigilanza pubblicata dal 2023. I soggetti NIS2 devono pianificare sulla seconda.

Le raccomandazioni di autenticazione di ANSSI (Recommandations relatives à l'authentification multifacteur, 2023), il controllo ORP.4.A23 di IT-Grundschutz del BSI e le pubblicazioni di ENISA sulla gestione dell'identità convergono: i codici SMS sono vulnerabili a SIM swap e intercettazione SS7; le app TOTP proteggono dal phishing solo se l'utente nota un dominio errato. Per gli accessi amministrativi e remoti, nessuno dei due fattori raggiunge l'asticella implicita «stato dell'arte» che un'autorità applicherà nel 2026.

La conseguenza pratica: il piano di rollout eredita un'architettura obiettivo. Resistente al phishing per le prime tre classi (amministrativo, remoto, applicazioni amministrative esposte), TOTP tollerato come controllo transitorio per la quarta (accesso ai dati sensibili da parte dei dipendenti non privilegiati), SMS fuori dal perimetro entro la fine del prossimo ciclo di bilancio. La SP 800-63B Digital Identity Guidelines del NIST — formalmente uno standard statunitense ma il riferimento internazionale per i livelli di garanzia di autenticazione — fornisce la granularità per documentare queste scelte.

4. La pista di audit che un'autorità legge

Un'ispezione NIS2 raramente chiede di vedere la configurazione del provider di identità. Chiede la pista di audit. Tre artefatti compaiono con regolarità nei resoconti d'ispezione pubblicati da BSI e ACN:

• La policy di autenticazione approvata dal consiglio. Un documento — non una pagina di wiki — che definisce la forza del fattore per classe di accesso, elenca le deroghe e i loro controlli compensativi, firmato alla data dell'ultima revisione.
• Il registro di iscrizione dei fattori. Un elenco, per sistema, degli account con un fattore MFA iscritto, il tipo di fattore e la data di iscrizione. Il registro risponde a «l'MFA è davvero attivo?» — non a «è richiesto?», cosa che una policy da sola non può dimostrare.
• Il registro delle deroghe. Ogni sistema in cui l'MFA non è applicato — terminali industriali ereditati, account di servizio con autenticazione a certificato — è nominato, con la motivazione, il controllo compensativo e la data di ritiro pianificata. Le deroghe aperte da più di dodici mesi sono un segnale rosso per la vigilanza.

Il rinvio a la revisione indipendente annuale del programma di sicurezza nella nostra guida alle 21 misure dell'articolo 21 chiude il cerchio — il revisore legge questi tre documenti e riferisce le risultanze al consiglio. Senza di essi, il controllo tecnico è invisibile al regolatore.

5. Rollout senza rompere l'esercizio

Il modo di fallimento di un rollout MFA non è la scelta del fattore. È il blocco — un account privilegiato che perde l'accesso al secondo fattore nel momento peggiore. Tre misure dalle guide pubblicate riducono questo rischio:

• Due fattori di due tipi diversi per ogni account amministrativo, il secondo fattore conservato offline e accessibile al team di risposta agli incidenti entro due ore.
• Iscrizione a fasi, per classe di accesso, non per popolazione di utenti. Accesso amministrativo per primo (popolazione piccola, impatto alto), applicazioni esposte poi, accesso ai dati sensibili per ultimo. La checklist di autovalutazione NIS2 indica l'ordine implicato dalla matrice di classificazione del regolatore.
• Procedure di break-glass pre-allestite, documentate e testate ogni anno. L'account break-glass stesso è monitorato a ogni uso; un uso non coincidente con una variazione pianificata è trattato come un incidente significativo ai sensi dell'articolo 23 e notificato.

Il quadro di vigilanza osservato nel 2026 non è punitivo sulla velocità di rollout — purché la documentazione esista. I soggetti che nel 2027 continueranno a usare SMS per gli accessi amministrativi avranno una conversazione diversa.

Com'è quando è ben fatto

Tre segnali compaiono nei resoconti d'ispezione pubblicati dalle autorità nazionali che hanno condiviso la propria metodologia di esecuzione:

1. Una policy di autenticazione approvata dal consiglio — versionata, datata, firmata in attuazione dell'articolo 20 della direttiva, che distingue la forza del fattore per classe di accesso con le deroghe nominate.
2. Un registro di iscrizione vivo — esportato dal provider di identità nella piattaforma GRC del soggetto, aggiornato almeno mensilmente, con copertura del 100 % degli account amministrativi e di accesso remoto.
3. Un piano di ritiro dei fattori deboli — date di dismissione di SMS e TOTP non attestato impegnate per iscritto, con un rapporto trimestrale di avanzamento al consiglio.

Nessuno di questi documenti richiede nuova tecnologia. Richiedono che i controlli già in produzione siano messi per iscritto — prima che il regolatore li chieda.

Fonti

1. Direttiva (UE) 2022/2555, articolo 21(2)(j) (misure di gestione dei rischi di cibersicurezza).
2. Regolamento di Esecuzione (UE) 2024/2690 della Commissione del 17 ottobre 2024 (requisiti tecnici e metodologici).
3. ENISA — Identity Management for Electronic Identification (citato per nome).
4. ANSSI — Recommandations relatives à l'authentification multifacteur et aux mots de passe (2023).
5. BSI — IT-Grundschutz-Kompendium, controllo ORP.4.A23 (autenticazione multifattore per accesso amministrativo).
6. NIST — Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management.