MFA ai sensi dell'Articolo 21(2)(j) NIS 2
La NIS 2 fa dell'autenticazione a più fattori un obbligo a sé stante. L'Articolo 21(2)(j) è dove risiede l'obbligo, il CIR (UE) 2024/2690 §11.7 indica dove e quanto robusta, e il §30(2)(10) BSIG lo trasferisce nel diritto tedesco.
La versione breve
L'MFA non è facoltativa e non è solo un optional. L'Articolo 21(2)(j) la inserisce nell'elenco delle dieci misure di cibersicurezza che ogni soggetto essenziale e importante è tenuto a porre in essere. La stessa formulazione copre anche le comunicazioni vocali, video e testuali sicure e, ove rilevante, le comunicazioni di emergenza sicure all'interno della tua organizzazione.
Il CIR (UE) 2024/2690 §11.7 completa il quadro. Gli utenti devono autenticarsi con più fattori o con l'autenticazione continua quando lo richiede la classificazione dell'asset a cui accedono. La robustezza dell'autenticazione deve essere commisurata a tale classificazione. I gioielli della corona richiedono un'autenticazione più robusta di un portale del menù del bar.
Il CIR §11.3.2 pone poi una soglia minima inderogabile per gli account privilegiati. Procedure robuste di identificazione, autenticazione e autorizzazione (l'autenticazione a più fattori è l'esempio che il CIR cita) devono essere in essere per impostazione predefinita per gli account privilegiati e di amministrazione di sistema. La Germania trasferisce l'obbligo tramite il §30(2)(10) BSIG con una formulazione pressoché identica.
Articolo 21(2)(j) Direttiva NIS 2 (2022/2555)
l'uso di soluzioni di autenticazione a più fattori o di autenticazione continua, di comunicazioni vocali, video e testuali protette e di sistemi di comunicazione di emergenza protetti all'interno del soggetto, ove opportuno.
Il punto (j) nell'elenco delle dieci misure di cibersicurezza. Fa due cose contemporaneamente: indica l'MFA (o l'autenticazione continua) come standard di controllo degli accessi e fa rientrare nello stesso obbligo le comunicazioni interne sicure vocali, video, testuali e di emergenza.
CIR (UE) 2024/2690, Allegato §11.7 e §11.3
I soggetti interessati garantiscono che gli utenti siano autenticati mediante più fattori di autenticazione o meccanismi di autenticazione continua per accedere ai sistemi informatici e di rete dei soggetti interessati, ove opportuno, conformemente alla classificazione dell'asset a cui si deve accedere.
Il §11 è il capitolo del CIR dedicato al controllo degli accessi e copre congiuntamente l'Articolo 21(2)(i) e (j). Il §11.7 è la sotto-sezione specifica dell'MFA. Il §11.3.2(a) si spinge oltre per gli account privilegiati e di amministrazione: sono richieste procedure robuste di identificazione, autenticazione (l'MFA è citata come esempio) e autorizzazione. Poiché il CIR è un regolamento, costituisce diritto UE direttamente vincolante per i settori indicati nel suo Allegato.
§30(2)(10) BSIG (Germania)
l'uso di soluzioni di autenticazione a più fattori o di autenticazione continua, di comunicazioni vocali, video e testuali protette e di sistemi di comunicazione di emergenza protetti all'interno del soggetto, ove opportuno.
La Germania ricopia il testo UE quasi parola per parola. L'operatività pratica in Germania rimanda al baustein IT-Grundschutz ORP.4 (Gestione delle identità e degli accessi), che è il catalogo di riferimento del BSI per impostare correttamente l'autenticazione in fase operativa.
MFA adeguata alla classificazione dell'asset
Gli utenti si autenticano con più fattori o con l'autenticazione continua per l'accesso ai tuoi sistemi informatici e di rete, calibrata sulla classificazione dell'asset che stanno raggiungendo. La precondizione implicita: hai classificato i tuoi asset. Senza una classificazione non puoi soddisfare la regola.
Account privilegiati: MFA per impostazione predefinita
Per gli account privilegiati e per gli account di amministrazione di sistema, identificazione, autenticazione e autorizzazione robuste sono obbligatorie. Il CIR cita l'autenticazione a più fattori come esempio applicato. Questo è l'unico punto in cui l'MFA cessa di essere condizionata alla classificazione e diventa lo stato predefinito.
La robustezza dell'autenticazione è commisurata alla classificazione
La robustezza dell'autenticazione deve essere adeguata alla classificazione dell'asset a cui si accede. È la seconda verifica. L'MFA non è una cosa sola. SMS, TOTP basato su app, approvazione push, chiavi hardware FIDO2 e autenticazione basata su certificati si collocano su gradini molto diversi. Più alta è la classificazione, più alto è il gradino che ti serve.
Comunicazioni sicure, non solo MFA (Articolo 21(2)(j))
Il punto (j) è più ampio della sola autenticazione. Indica le comunicazioni vocali, video e testuali sicure e i sistemi di comunicazione di emergenza all'interno del soggetto, ove opportuno. Una sola implementazione di MFA non esaurisce l'obbligo. Le videoconferenze interne, la messaggistica e qualsiasi canale di emergenza fuori banda rientrano nello stesso obbligo.
La classificazione dell'asset determina la profondità (Articolo 21(1))
L'Articolo 21(1) richiede misure adeguate e proporzionate. Il CIR lo traduce in una verifica concreta per l'MFA: la classificazione dell'asset stabilisce la robustezza. Un piccolo Stadtwerk non ha bisogno di chiavi hardware FIDO2 per ogni portale interno. Un jump host di un sistema di controllo è un discorso diverso. La leva è la classificazione, non le sole dimensioni dell'impresa.
BSI / §30(2)(10) BSIG
La Germania ricopia la formulazione UE quasi alla lettera nel §30(2)(10) BSIG. Il riferimento attuativo del BSI è il baustein IT-Grundschutz ORP.4 (Gestione delle identità e degli accessi), che fornisce requisiti concreti per l'emissione delle credenziali, l'MFA, la separazione degli account privilegiati e l'accesso d'emergenza. Se implementi correttamente ORP.4, rientri nell'obbligo del §30(2)(10).
ENISA Technical Implementation Guidance
La TIG dell'ENISA per il CIR esamina il §11 in linguaggio operativo semplice e lo mappa su ISO/IEC 27001:2022, NIST CSF 2.0, ETSI EN 319 401 e CEN/TS 18026:2024. Se già gestisci ISO 27001 (controlli A.5.16, A.5.17, A.8.5), sei a buon punto. La TIG elenca anche le prove che gli auditor si aspettano: politica MFA, classificazione degli account, registri di iscrizione, registro delle eccezioni.
Leggi nazionali di recepimento
Ogni Stato membro ha il proprio recepimento della NIS 2 (Paesi Bassi: Cyberbeveiligingswet, Austria: NISG, Belgio: NIS2-Wet). L'obbligo MFA in sé è identico perché risiede nella direttiva e nel CIR. Ciò che differisce tra i paesi: il catalogo di riferimento (Grundschutz in Germania, BIO nei Paesi Bassi, nessun catalogo formale altrove), il canale di segnalazione e l'autorità di vigilanza.
Abbiamo l'MFA sulla VPN, quindi abbiamo finito.
L'MFA sulla VPN è un solo percorso di accesso. Il CIR §11.7 riguarda l'accesso agli asset in funzione della loro classificazione, non un singolo dispositivo perimetrale. Se un utente privilegiato può raggiungere un domain controller, una console di backup, una console di amministrazione cloud o un tenant SaaS senza MFA, l'obbligo non è soddisfatto. La verifica è la classificazione dell'asset dietro la porta, non la porta da cui sei entrato.
L'MFA via SMS va bene per tutti.
Il CIR §11.7.2 stabilisce che la robustezza dell'autenticazione deve essere commisurata alla classificazione. L'OTP via SMS e via voce è il fattore più debole: SIM swap, intercettazione SS7 e phishing lo sconfiggono tutti. Per l'accesso interno ordinario l'auditor può accettarlo. Per i gioielli della corona (console di amministrazione, sistemi di controllo, provider di identità) serve un'autenticazione resistente al phishing (FIDO2 / WebAuthn / smartcard). La robustezza deve crescere con la classificazione.
Gli account di servizio e di sistema non hanno bisogno di MFA.
Il CIR §11.3.2(a) copre espressamente gli account privilegiati e gli account di amministrazione di sistema. Gli account di servizio esulano dall'ambito dell'MFA umana solo se sono classificati correttamente e usano un diverso controllo robusto (identità gestite, credenziali a breve durata, certificati firmati, segreti emessi da vault con rotazione). "Account di servizio, non può fare MFA, esente" non è una difesa. O è guidato da un essere umano (allora MFA), oppure è guidato da una macchina (allora un modello di credenziali macchina documentato).
La maggior parte dei team del Mittelstand tedesco parte dallo stesso punto: prima l'MFA su ogni account amministratore (console di amministrazione cloud, domain admin, hypervisor, backup, apparati di rete, tenant SaaS), poi l'MFA sulla posta elettronica, poi l'MFA sul provider di identità per tutti gli utenti umani. Questo copre la soglia minima del §11.3.2 e le righe ad alta classificazione in un'unica mossa. Il resto viene esteso a tutti gli utenti umani sugli asset classificati entro il primo anno.
Cosa aprono effettivamente gli auditor: l'elenco di classificazione degli asset, il report di iscrizione MFA del tuo provider di identità e il registro delle eccezioni. Se questi tre coincidono, l'obbligo è soddisfatto. La lacuna singola più profonda che vediamo non è tecnica, è documentale: manca la classificazione degli asset, quindi non c'è alcuna regola su quali asset richiedano quale robustezza di autenticazione. Sistema prima la classificazione, poi l'implementazione dell'MFA si legge da sé dall'elenco.
Il modulo ACC (controllo degli accessi) della piattaforma porta l'obbligo del §11 dall'inizio alla fine. Registri gli asset con la loro classificazione, elenchi quali gruppi di utenti necessitano dell'accesso e documenti la robustezza dell'autenticazione per ciascuna riga. La stessa tabella risponde sia alla verifica del §11.7.1 (MFA ove opportuno) sia a quella del §11.7.2 (robustezza commisurata alla classificazione), e fa emergere separatamente le righe degli account privilegiati del §11.3.2.
L'approvazione dell'inventario del controllo degli accessi avviene per nome. Le eccezioni (il sistema legacy che non può ancora fare MFA, l'integrazione che deve usare un account di servizio) risiedono nello stesso record con un controllo compensativo documentato e una data di revisione. La traccia di audit e l'esportazione delle prove della piattaforma forniscono all'auditor gli artefatti indicati dalla TIG dell'ENISA: politica, classificazione, registro di iscrizione, registro delle eccezioni, tutto in un unico posto.
- Direttiva (UE) 2022/2555 (NIS 2), Articolo 21(2)(j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regolamento di esecuzione (UE) 2024/2690 della Commissione (CIR), Allegato §11.3 e §11.7 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Legge sul BSI (BSIG), §30(2)(10) come modificato dalla legge di attuazione della NIS2 e di rafforzamento della cibersicurezza
- BSI IT-Grundschutz, Baustein ORP.4 'Identitäts- und Berechtigungsmanagement'
- ENISA Technical Implementation Guidance per il CIR (UE) 2024/2690 (aggiornata a maggio 2026)