Introduzione

#

La direttiva NIS2 (UE 2022/2555) è la principale evoluzione del quadro europeo per la cybersicurezza, recepita in Italia con il D.Lgs. 4 settembre 2024, n. 138 ¹. L’obiettivo è chiaro: aumentare la resilienza dei servizi essenziali imponendo misure proporzionate al rischio, con responsabilità dirette degli organi di amministrazione e poteri di vigilanza e sanzione in capo all’Autorità competente.

Per chi si occupa di IAM, NIS2 non è solo una questione di compliance formale: introduce obblighi concreti su gestione delle identità, autenticazione forte, controllo accessi privilegiati, logging e monitoraggio degli eventi — tutte aree dove una piattaforma come Okta può fare la differenza tra un audit superato e un piano di adeguamento pluriennale.

Questo articolo sintetizza cosa prevede NIS/NIS2, come ACN ha strutturato l’attuazione in Italia, chi è coinvolto, gli obblighi e le scadenze, e propone una mappatura pratica tra i requisiti delle Specifiche di base e le funzionalità Okta (IdP/MFA/SSO/IGA) con esempi, tabelle e indicazioni operative ².

Cos’è NIS/NIS2

#

NIS2 è la direttiva UE 2022/2555 per un livello comune elevato di cybersicurezza, recepita in Italia con D.Lgs. 138/2024, che estende l’ambito settoriale, introduce la distinzione tra soggetti essenziali e importanti e rafforza governance, gestione rischi e regole di notifica degli incidenti significativi ¹.

Obiettivo: aumentare la resilienza di servizi essenziali e attività critiche imponendo misure proporzionate al rischio, con responsabilità specifiche per gli organi di amministrazione e direttivi e poteri di vigilanza e sanzione all’Autorità competente.

Implementazione in Italia (ACN)

#

In Italia l’Autorità nazionale competente è l’Agenzia per la Cybersicurezza Nazionale (ACN), che ha definito termini, modalità e procedimenti per registrazione, aggiornamenti e interlocuzione tramite la piattaforma digitale NIS, oltre a Specifiche di base per misure e incidenti ³.

ACN ha inoltre pubblicato la “Guida alla lettura” delle Specifiche di base, che spiega struttura, approccio basato sul rischio, evidenze documentali e corrispondenza tra misure e l’art. 24(2) del decreto, facilitando l’adozione per i soggetti NIS ².

Aziende coinvolte e ambito

#

Sono in ambito soggetti pubblici e privati che ricadono negli allegati settoriali NIS2 e nei criteri oggettivi del D.Lgs. 138/2024, con classificazione essenziale o importante in funzione della criticità intrinseca del settore/servizio e dei parametri dimensionali, salva identificazione mirata dell’Autorità in casi specifici ¹.

La PA rientra con categorie definite e possibile estensione graduale via DPCM, e l’ambito copre l’intera infrastruttura ICT utilizzata nelle attività o fornitura dei servizi rientranti in NIS2. In pratica, il perimetro non riguarda solo “il team IT”, ma i processi digitali che supportano servizi critici, supply chain e continuità operativa ⁴.

Come capire se sei soggetto essenziale o importante

#

Per una prima autovalutazione interna, usa questa logica in sequenza:

1. Verifica se il tuo settore/servizio rientra negli allegati NIS2 (energia, trasporti, sanità, digitale, PA, ecc.) ¹.
2. Valuta se il servizio ha impatto sistemico o su funzioni critiche (continuità, sicurezza pubblica, filiere strategiche).
3. Applica i criteri dimensionali e organizzativi previsti dal decreto (dimensione aziendale, ruolo nel mercato, dipendenze di terzi) ¹.
4. Verifica se hai ricevuto comunicazioni formali o richieste tramite la piattaforma ACN/NIS ³.
5. Se rimane incertezza, formalizza una valutazione documentata e confrontala con legale/compliance e Autorità competente di settore.

Cosa cambia tra soggetti essenziali e importanti

#

In concreto, per IAM cambia soprattutto il livello di rigore operativo: stessa direzione di controllo, ma maggiore profondità di prova, frequenza di verifica e qualità delle evidenze per i soggetti essenziali.

Soggetti essenziali e servizi cloud: cosa verificare

#

Per i soggetti essenziali non c’è, in generale, un “bollino cloud” unico o un catalogo ACN pubblico di provider automaticamente approvati per la conformità NIS2. L’approccio richiesto è risk-based: valutazione del fornitore, obblighi contrattuali chiari e controlli verificabili nel tempo.

In pratica, quando usi servizi cloud per sistemi rilevanti, conviene formalizzare almeno questi punti:

1. Clausole contrattuali di sicurezza: requisiti minimi su hardening, patching, cifratura, segregazione ambienti, logging, supporto audit.
2. Responsabilità incidenti: chi notifica cosa, entro quali tempi, e con quali evidenze verso il soggetto NIS e verso le Autorità competenti.
3. Continuità e recovery: obiettivi RTO/RPO, piani di failover, test periodici e procedure di ripristino documentate.
4. Resilienza operativa: capacità di garantire il servizio anche in condizioni degradate (fallback, ridondanza, alternative di connettività), senza assumere necessariamente una modalità completamente offline in ogni scenario.
5. Strategia di uscita: portabilità dati/configurazioni, tempi e costi di recesso, riduzione del lock-in.

Obblighi principali e scadenze

#

Gli obblighi “di base” riguardano: responsabilità dei vertici (art. 23), misure di gestione del rischio e misure tecniche/organizzative (art. 24), notifiche di incidenti significativi (art. 25), con tempistiche definite da ACN per l’adozione delle misure e l’avvio degli obblighi di notifica ⁵.

Secondo ACN, l’obbligo di notifica degli incidenti significativi decorre dal 1° gennaio 2026, con pre-notifica entro 24 ore dall’evidenza e notifica completa entro 72 ore. L’adozione delle misure di sicurezza di base ha termine a 18 mesi dalla comunicazione di inserimento nell’elenco NIS, con ulteriori milestone per registrazione e aggiornamenti informativi sulla piattaforma ³.

Specifiche di base: misure

#

Le Specifiche di base organizzano le misure secondo il Framework Nazionale per la Cybersecurity e la Data Protection (FNCDP 2025), con funzioni, categorie e sottocategorie, e requisiti sia organizzativi sia tecnologici, differenziati tra essenziali e importanti in ottica di proporzionalità ⁶. Esempi: governance (GV.*), gestione asset (ID.AM.*), valutazione rischi (ID.RA.*), identità e accessi (PR.AA.*), sicurezza dati (PR.DS.*), piattaforme e patching (PR.PS.*), resilienza rete (PR.IR.*), monitoraggio e logging (DE.CM.*), risposta e ripristino (RS.*, RC.*), con clausole “basate sul rischio” (rilevanza sistemi, esiti risk assessment, ragioni normative/tecniche).

Specifiche di base: incidenti significativi

#

Gli incidenti significativi “di base” includono perdita di riservatezza, perdita di integrità con impatto verso l’esterno e violazione dei livelli di servizio attesi (SL), più l’accesso non autorizzato o con abuso dei privilegi concessi per i soli soggetti essenziali, con definizione di “evidenza” dell’incidente che fa decorrere i termini di pre-notifica (24h) e notifica (72h) ⁶. Gli SL vanno definiti dal soggetto (misurabili) e usati sia per il rilevamento sia per la soglia di significatività.

Piattaforma NIS: registrazione e aggiornamenti

#

ACN disciplina SPID, censimento degli utenti, associazione al soggetto, designazione punto di contatto e sostituto, registrazione annuale (1/1-28/2), verifiche di coerenza, comunicazione dell’inserimento nell’elenco e codice identificativo, aggiornamento annuale (15/4-31/5) e aggiornamento continuo entro 14 giorni da ogni modifica ³. Gli organi di amministrazione sovrintendono e sono responsabili di registrazione e aggiornamenti ai sensi dell’art. 23, con canali, termini e procedimenti vincolati dalla determinazione ACN.

Altre Determinazioni ACN utili

#

• Accordi di condivisione: notifica via piattaforma con testo, denominazione, elenco partecipanti; aggiornamento annuale e continuo entro 14 giorni, inclusi accordi previgenti entro 31/05/2026.
• Tavolo NIS: regole aggiornate per funzionamento, riunioni e adozione spedita (silenzio-assenso) per Determinazioni, a supporto dell’attuazione nazionale ⁵.

Perché interessa l’IAM

#

Le Specifiche di base insistono su identità, autenticazione e controllo accessi (PR.AA.*), crittografia in transito e a riposo (PR.DS.*), privilegio minimo e separazione delle funzioni, MFA commisurata al rischio per i sistemi rilevanti, logging degli accessi remoti e privilegiati, e monitoraggio di eventi e tentativi d’accesso ⁷.

Sono previsti piani e policy approvati dal board per risk management, gestione vulnerabilità, continuità e incident response, con verifiche periodiche e aggiornamenti almeno annuali, rafforzando l’allineamento tra IAM, SecOps e governance.

Mappatura Okta → Requisiti NIS (overview)

#

Di seguito una mappatura pratica tra requisiti NIS e capacità tipiche di un IdP come Okta (SSO, MFA, Adaptive MFA, Lifecycle/IGA, Policy engine, Directory integration, Device posture, Logs/Reports), utile per dimostrare coperture, gap e piani di rimedio in sede di audit o ispezioni ACN ⁷.

Le associazioni assumono l’uso di policy basate sul rischio, MFA per sistemi rilevanti, principi di minimo privilegio, logging centralizzato e integrazione con SIEM per il monitoraggio degli eventi, coerentemente con le Specifiche di base.

Tabella 1 — Accesso, autenticazione, privilegi

#

Tabella 2 — Dati, logging, monitoraggio

#

Tabella 3 — Governance, rischio, supply chain

#

Esempi di configurazione Okta per coprire requisiti chiave

#

• MFA adattiva per app “rilevanti”: fattori phishing-resistant dove possibile (es. FIDO2/WebAuthn), fallback gestiti, geovelocazione e device context per step-up, con eccezioni formalizzate e approvate nel piano di trattamento rischio.
• Least privilege: ruoli admin separati (org admin, app admin, helpdesk), senza condivisione credenziali, con tracciamento dei cambi di ruolo e accessi privilegiati in log centralizzato.
• Joiner-Mover-Leaver: workflow di provisioning/deprovisioning verso app critiche, revoca automatica a cessazione e audit trimestrale delle autorizzazioni per sistemi rilevanti.
• Logging e monitoraggio: inoltro system log a SIEM, dashboard su accessi remoti, MFA denials, azioni admin, alert su comportamenti anomali secondo parametri quali-quantitativi definiti.

Validazione

#

• Evidenze di governance: politiche IAM approvate dagli organi di amministrazione, registro dei riesami annuali, piani di adeguamento e loro avanzamento, in linea con GV.PO e ID.IM.
• Copertura MFA: matrice sistemi/app rilevanti × policy MFA, percentuale di utenze con fattori attivi, liste eccezioni con motivazione tecnica/normativa e compensazioni nel piano rischio.
• Access reviews: esiti delle verifiche periodiche autorizzazioni per utenze privilegiate e accessi remoti, con azioni correttive tracciate.
• Monitoraggio e logging: campioni di log su accessi admin e da remoto, retention policy e integrità dei log, playbook di detection per IS-4 (abuso privilegi) e IS-3 (violazione SL).

FAQ

#

Okta copre l’intero ventaglio di controlli NIS2? Okta copre verticalmente tutte le misure IAM/autenticazione/access management, log e monitoring, e alcune esigenze della governance. Altri controlli (es. backup fisici, supply chain audit, formazione) richiedono strumenti e processi supplementari.

Le evidenze prodotte tramite Okta sono accettate dagli ispettori ACN? Sì, purché siano strutturate secondo la guida ACN: log, report, policy approvate, audit trail, export, screenshot. La chiave è tracciare il mapping tra ogni configurazione Okta e lo specifico requisito delle Specifiche di base.

Ci sono gap noti nella compliance Okta-NIS2? Non sulle misure IAM dirette; vanno però gestiti con attenzione i processi di formazione utenti (PR.AT.*), il procurement IT e il logging “a valle” delle applicazioni federate non native Okta.

Quando scatta l’obbligo di notifica? Dal 1° gennaio 2026 per gli incidenti significativi, con pre-notifica entro 24h e notifica completa entro 72h dall’evidenza dell’incidente ⁵.

Entro quando adottare le misure di base? 18 mesi dalla comunicazione di inserimento nell’elenco NIS da parte di ACN ³.

Cosa approva il board? Le politiche chiave (risk, IAM, data, vulnerability, continuità, incident response), i piani e le accettazioni di rischio, la designazione del punto di contatto, con riesami almeno annuali ⁵.

Conclusioni

#

L’adozione di NIS2 in Italia rappresenta una trasformazione strutturale per la sicurezza cyber di aziende e PA, con effetti concreti già dal 2026 sugli obblighi di notifica e, nel corso del 2025-2027, sull’adozione delle misure di base. Per chi gestisce IAM, questo significa policy approvate dal board, MFA proporzionale al rischio, accesso a privilegio minimo, logging centralizzato e piani di risposta testati.

Okta è un alleato efficace per coprire la maggior parte dei requisiti PR.AA.* e DE.CM.* — ma la compliance non si esaurisce nello strumento: richiede documentazione, audit trail, evidenze strutturate e un processo continuo di revisione. Il punto di partenza è la mappatura: sapere quale controllo Okta copre quale requisito ACN, dove ci sono gap e come gestirli nel piano di trattamento del rischio.

Stai pianificando l’adeguamento NIS2? Quale parte del percorso ti sembra più complessa — la governance, la parte tecnica o la supply chain? Scrivilo nei commenti.