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 1. 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 2.
Le interpretazioni normative e le mappature alle specifiche ACN contenute in questo articolo riflettono la mia analisi personale dei testi ufficiali e della documentazione pubblica disponibile. Non sono un avvocato e nulla di quanto segue costituisce consulenza legale. Prima di prendere decisioni di conformità NIS2, consulta sempre consulenti legali e di cybersicurezza qualificati.
Inoltre, alcune funzionalità dei vendor citati possono evolvere nel tempo o richiedere configurazioni specifiche. Verifica sempre disponibilità, limiti e applicabilità nel tuo contesto organizzativo e regolatorio.
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 1.
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 3.
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 2.
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 1.
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 4.
Come capire se sei soggetto essenziale o importante #
Per una prima autovalutazione interna, usa questa logica in sequenza:
- Verifica se il tuo settore/servizio rientra negli allegati NIS2 (energia, trasporti, sanità, digitale, PA, ecc.) 1.
- Valuta se il servizio ha impatto sistemico o su funzioni critiche (continuità, sicurezza pubblica, filiere strategiche).
- Applica i criteri dimensionali e organizzativi previsti dal decreto (dimensione aziendale, ruolo nel mercato, dipendenze di terzi) 1.
- Verifica se hai ricevuto comunicazioni formali o richieste tramite la piattaforma ACN/NIS 3.
- Se rimane incertezza, formalizza una valutazione documentata e confrontala con legale/compliance e Autorità competente di settore.
Gli esempi sotto sono orientativi e non sostituiscono la classificazione ufficiale dell’Autorità.
| Esempio organizzazione | Settore | Possibile classificazione | Perché |
|---|---|---|---|
| Gestore nazionale rete elettrica | Energia | Essenziale | Impatto diretto su servizio critico nazionale e alta dipendenza infrastrutturale |
| Ospedale metropolitano con pronto soccorso | Sanità | Essenziale | Continuità clinica e impatto immediato su salute pubblica |
| Provider cloud regionale per enti pubblici | Digitale/ICT | Importante o essenziale (caso specifico) | Dipende da scala, clienti serviti e criticità dei servizi ospitati |
| Azienda manifatturiera media con forte automazione | Industria critica/supply chain | Importante | Impatto rilevante su filiera, ma generalmente minore centralità sistemica rispetto ai soggetti essenziali |
| Operatore telecom nazionale | Telecomunicazioni | Essenziale | Elevato impatto su connettività e servizi abilitanti trasversali |
Cosa cambia tra soggetti essenziali e importanti #
| Aspetto | Soggetto importante | Soggetto essenziale |
|---|---|---|
| Vigilanza | Supervisione proporzionata | Supervisione più intensa e strutturata |
| Incidenti significativi | Obblighi di notifica secondo regole ACN | Obblighi analoghi con maggiore attenzione su impatti sistemici |
| Governance | Board accountability richiesta | Board accountability rafforzata con aspettative di maturità più elevate |
| Evidenze e audit | Evidenze documentali obbligatorie | Evidenze più granulari e verifiche potenzialmente più frequenti |
| IAM/SecOps | Baseline robusta e tracciabile | Baseline + maggiore profondità su privilegi, monitoraggio e risposta |
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:
- Clausole contrattuali di sicurezza: requisiti minimi su hardening, patching, cifratura, segregazione ambienti, logging, supporto audit.
- Responsabilità incidenti: chi notifica cosa, entro quali tempi, e con quali evidenze verso il soggetto NIS e verso le Autorità competenti.
- Continuità e recovery: obiettivi RTO/RPO, piani di failover, test periodici e procedure di ripristino documentate.
- 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.
- Strategia di uscita: portabilità dati/configurazioni, tempi e costi di recesso, riduzione del lock-in.
Sul cloud, la domanda corretta non è “il provider è nel catalogo?”, ma “ho documentato in modo difendibile rischio residuo, misure compensative e responsabilità operative?”.
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 5.
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 3.
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à 6.
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) 6. 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 3. 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 5.
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 7.
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) #
Le mappature che seguono sono interpretative e non costituiscono validazione ufficiale da parte di ACN o di altre Autorità. L’Identity è una componente fondamentale della compliance NIS2, ma non copre da sola tutti gli obblighi: supply chain, continuità operativa, gestione vulnerabilità, formazione e governance richiedono processi e controlli aggiuntivi.
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 7.
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 #
| Requisito NIS | Come aiuta Okta | Evidenze operative |
|---|---|---|
| PR.AA-01: censimento utenze, robustezza credenziali, verifiche periodiche autorizzazioni | Directory unificata e SSO centralizzato, criteri password policy per app gestite, access reviews periodiche con gruppi/profili | Export utenti/gruppi/assegnazioni; report controlli periodici; policy password; workflow di revoca su cessazione |
| PR.AA-03: autenticazione commisurata al rischio; MFA sui sistemi rilevanti | MFA/Adaptive MFA con fattori moderni (phishing-resistant dove possibile), policy per app/rischio/contesto | Matrice app × policy MFA; evidenze fattori abilitati; eccezioni motivate e documentate (ragioni tecniche/normative) |
| PR.AA-05: minimo privilegio e separazione delle funzioni | Ruoli amministrativi granulari, gruppi per profili di accesso, least-privilege sugli admin IdP | Elenco ruoli/assegnazioni admin; SoD tra admin e business; change log ruoli |
| PR.AA-06: controllo accessi fisici sui sistemi rilevanti (in ambito ICT/OT) | Non coperto direttamente dall’IdP; integrazione con soluzioni fisiche e enforcement Zero Trust lato app | Piano di compensazione e integrazioni; policy di accesso remoto e segmentation |
Tabella 2 — Dati, logging, monitoraggio #
| Requisito NIS | Come aiuta Okta | Evidenze operative |
|---|---|---|
| PR.DS-02: cifratura “in transito” per sistemi/servizi rilevanti | Enforcement SSO su protocolli sicuri (OIDC/SAML su TLS), controlli moderni di session e token | Configurazioni app, metadata SAML/OIDC, TLS posture; elenco app esterne |
| PR.PS-04: logging accessi remoti e privilegiati; conservazione sicura e centralizzata | System log su autenticazioni, fattori, amministrazioni; connettori SIEM per retention e correlazione | Inoltro a SIEM; policy retention; report accessi admin e da remoto |
| DE.CM-01/09: strumenti di rilevazione, parametri quali-quantitativi, endpoint protection | Segnali di rischio (rischio utente/sessione), integrazione con EDR/UEBA/SIEM; controlli su anomalie d’accesso | Playbook di correlazione; soglie e alert; evidence su incidenti e triage |
Tabella 3 — Governance, rischio, supply chain #
| Requisito NIS | Come aiuta Okta | Evidenze operative |
|---|---|---|
| GV.PO-01/02: politiche e riesami annuali | Policy catalog per accesso/identità, standard MFA per classi di app, processi di review | Politiche IAM approvate dal board; verbali riesami; registro esiti revisioni |
| ID.RA-05/06: valutazione e trattamento rischio | Risk-based access; mapping degli asset applicativi IdP nel risk register | Valutazione rischio IdP/SSO; piano trattamento; rischi residui approvati |
| GV.SC-01/05/07: requisiti contrattuali, valutazione fornitori, verifiche | Clausole di sicurezza IAM verso application owners/ISV; controllo federazioni e app catalog | Inventario fornitori/app; security addendum; test integrazione e deprovisioning |
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 5.
Entro quando adottare le misure di base? 18 mesi dalla comunicazione di inserimento nell’elenco NIS da parte di ACN 3.
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 5.
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.