Cisco Duo Legacy AD Protection è un componente di Cisco Duo che aggiunge l'autenticazione a più fattori (MFA) alle autenticazioni di Active Directory, installandosi sui controller di dominio: chiede la seconda verifica quando Windows controlla la password, quindi anche per Desktop remoto, cartelle condivise, PowerShell e applicazioni che non supportano l'MFA. Richiede l'edizione Duo Advantage o superiore ed è disponibile in versione stabile dal 25 agosto 2026. Lo abbiamo provato per due giorni nel laboratorio Nexsys: qui raccontiamo cosa copre, cosa non copre, come si comporta quando il cloud non risponde e quali requisiti normativi aiuta a soddisfare.
Le password da sole non bastano più. Quello che si dice meno è che la seconda verifica, quella sul telefono, spesso protegge le applicazioni cloud ma si ferma davanti ad Active Directory: il cuore della rete aziendale, dove passano gli accessi ai server, alle cartelle e a quel gestionale vecchio che nessuno ha il coraggio di toccare. Per i concetti di base (fattori, metodi, differenza tra MFA e passwordless) rimandiamo alla guida alla Multi-Factor Authentication; per la piattaforma nel suo insieme, al nostro articolo su Cisco Duo: MFA, passwordless e controllo degli accessi.
Il problema: Active Directory è la chiave di tutto
In una rete Windows, Active Directory decide chi può entrare e dove. Chi riesce a rubare una sola password, magari con un messaggio di posta ben costruito, può usarla per aprire un computer, poi un server, poi le cartelle dell'amministrazione. Mettere la verifica sul telefono sui servizi cloud è un passo importante, ma lascia scoperti molti accessi interni: il Desktop remoto, le condivisioni di rete, gli script di amministrazione, le applicazioni scritte quando l'autenticazione a più fattori ancora non esisteva.
Proteggerli uno per uno significherebbe intervenire su ogni applicazione, e molte non si possono modificare. L'idea di Duo è diversa: mettere il controllo nel punto in cui tutti questi accessi passano, cioè nel controller di dominio, il server che verifica le password. È lo stesso principio della messa in sicurezza di Active Directory: prima di aggiungere un controllo conviene sapere chi si autentica, con quali account e con quali protocolli.
Cos'è Cisco Duo, in poche righe
Cisco Duo è un servizio in cloud che aggiunge una seconda verifica alla password: di solito una notifica sul telefono da approvare, detta push, ma anche passkey o chiavi fisiche. Non sostituisce la directory che l'azienda già usa: si appoggia ad Active Directory o a Microsoft Entra ID, e gli utenti restano dove sono. Fa parte del portafoglio di sicurezza di Cisco.
Il prodotto si vende in quattro edizioni (Free, Essentials, Advantage e Premier) con prezzi di listino USA, consultati il 16 ottobre 2026, di 0, 3, 6 e 9 dollari per utente al mese; i prezzi per l'Italia non sono pubblici. Ogni edizione comprende la precedente: Essentials aggiunge Single Sign-On, passwordless, Trusted Endpoints e la sincronizzazione con Active Directory ed Entra ID; Advantage aggiunge Cisco Identity Intelligence, Duo Passport, l'autenticazione basata sul rischio e Active Directory Defense; Premier aggiunge l'accesso alle risorse interne senza VPN e il controllo completo del dispositivo. Le edizioni a pagamento hanno una prova gratuita di 30 giorni.
Il componente di cui parliamo qui richiede almeno l'edizione Advantage: Essentials non lo include. Dal 6 febbraio 2026 Cisco lo vende sotto il nome commerciale Active Directory Defense, che raggruppa Legacy AD Protection, Windows Command Line Protection, Cisco Identity Intelligence collegato ad Active Directory e l'integrazione con BloodHound Enterprise per l'analisi dei percorsi di attacco. Il nome "Legacy" richiama i protocolli classici di Active Directory, Kerberos e NTLM, quelli che le applicazioni più vecchie usano ancora; il componente è invece recente, disponibile in versione stabile dal 25 agosto 2026 (versione 1.0.1, che corregge le push doppie in Desktop remoto).
Perché adottarlo: quattro motivi
Protegge accessi che molte altre soluzioni non vedono
Il filtro di Legacy AD Protection chiede la seconda verifica nel momento in cui Windows controlla la password: dalla console, in Desktop remoto, verso una cartella condivisa, con PowerShell. Non serve modificare le applicazioni.
Si introduce con calma
Si installa spento, in sola registrazione: per giorni scrive nel registro chi sarebbe stato chiamato, senza bloccare nessuno. Solo quando il quadro è chiaro lo si accende, e per spegnerlo basta un interruttore.
Lascia le prove
Ogni richiesta finisce in un registro, sul server e nel pannello di Duo, con l'utente, l'ora e l'esito. In un audit questo conta quanto la misura stessa.
I suoi limiti sono chiari e si possono gestire
Non è una soluzione magica: più avanti raccontiamo cosa non protegge e dove si comporta in modo sorprendente.
Quali normative aiuta a rispettare, e come
Una premessa necessaria: nessun prodotto è conforme da solo. Le norme riguardano l'organizzazione, i suoi processi, la valutazione dei rischi. Duo è uno strumento che permette di soddisfare un requisito preciso, quello dell'autenticazione a più fattori (nel linguaggio di DORA, dell'autenticazione forte). Ecco dove compare.
| Normativa | Cosa chiede | Come aiuta Duo |
|---|---|---|
| NIS2 Direttiva (UE) 2022/2555, art. 21, par. 2, lett. j. In Italia: D.Lgs. 138/2024, art. 24, comma 2, lett. l | "Soluzioni di autenticazione a più fattori o di autenticazione continua", ove opportuno. Le specifiche di base dell'ACN (determina 164179/2025, misura PR.AA-03) le richiedono almeno per i sistemi informativi e di rete rilevanti, in base alla valutazione del rischio. Le misure di base vanno adottate entro 18 mesi dalla comunicazione di inserimento nell'elenco dei soggetti NIS. | Aggiunge l'autenticazione a più fattori agli accessi ad Active Directory, ai server e alla riga di comando, e lascia i registri che documentano l'adozione. Scadenze e adempimenti nella guida NIS2 per le PMI. |
| DORA Regolamento (UE) 2022/2554, art. 9, par. 4, lett. d | Politiche e protocolli per meccanismi di autenticazione forte per le entità finanziarie, basati su standard pertinenti. Il regolamento si applica dal 17 gennaio 2025. | La seconda verifica sul telefono, con la possibilità di usare metodi più robusti, come le passkey. Che i meccanismi scelti bastino lo decide l'entità, in base agli standard pertinenti. Per i fornitori ICT delle entità finanziarie: DORA e clausole contrattuali. |
| PCI DSS 4.0.1 Requisito 8.4.2 | Autenticazione a più fattori per gli accessi all'ambiente dei dati delle carte di pagamento, obbligatoria dal 31 marzo 2025. Lo standard prevede eccezioni (per esempio gli account di sistema che eseguono funzioni automatiche): il perimetro esatto va letto sul testo, che il Consiglio PCI rilascia previa accettazione di una licenza. | Può proteggere gli accessi ai server e agli account di dominio che arrivano a quell'ambiente. |
| ISO/IEC 27001:2022 Allegato A, controllo 8.5 (autenticazione sicura) | Tecnologie e procedure di autenticazione adeguate alla sensibilità delle informazioni. Il controllo non nomina l'MFA; nella pratica degli audit è l'evidenza che di solito si presenta per gli accessi privilegiati e remoti (è una valutazione professionale, non il testo della norma). | Fornisce la misura e le prove: registri e rapporti delle autenticazioni. |
| GDPR Regolamento (UE) 2016/679, art. 32 | Misure tecniche e organizzative adeguate al rischio. Non nomina l'MFA. | È uno dei modi concreti per dimostrare adeguatezza nella protezione degli accessi ai dati personali. |
Da notare "ove opportuno" e "in base alla valutazione del rischio": la NIS2 non impone la seconda verifica ovunque, ma chiede di decidere dove serve e di poterlo giustificare. Un buon progetto parte da lì.
Vuoi capire quali accessi al tuo dominio sono oggi senza MFA? Parliamone in una call di 30 minuti
Richiedi la callI componenti che abbiamo provato nel laboratorio Nexsys
Nel laboratorio abbiamo ricostruito una piccola rete aziendale: un controller di dominio, un server con SQL Server, un client Windows e un telefono. Per due giorni abbiamo installato e provato, uno dopo l'altro, i componenti della famiglia Duo per Windows.
Legacy AD Protection
Il filtro sul controller di dominio (un sub-authentication filter, DuoSubAuthFilter). Quando Active Directory ha verificato la password di un logon Kerberos o NTLM, il filtro chiede la push e completa il logon solo dopo l'approvazione. Non cambia lo schema di Active Directory, le applicazioni né i client. Chiede la seconda verifica a chi è nel gruppo Enforce, lascia fuori chi è nel gruppo Bypass, e parte in sola registrazione. Si installa su tutti i controller: uno scoperto sarebbe una strada senza controlli.
Requisiti e comportamento, dalla documentazione Duo: Windows Server 2019, 2022 o 2025, controller in scrittura e in sola lettura; uscita TCP 443 con TLS 1.2 o superiore; utenti già iscritti in Duo, perché il filtro non iscrive al primo accesso; solo Duo Push e telefonata come metodi; riavvio del controller a ogni installazione e aggiornamento. Il controllo avviene alla richiesta iniziale (Kerberos AS-REQ o NTLM), non dentro una sessione già aperta; gli account computer e gli account locali del controller sono esentati in automatico. Per tornare indietro basta
EnableDuo=0, oppure la disinstallazione e un riavvio.Authentication Proxy
Un servizio installato in sede, che fa da ponte fra i sistemi locali e Duo. Nel LAB lo usiamo per sincronizzare gli utenti di Active Directory. Duo sconsiglia di metterlo sul controller di dominio e sul server NPS, perché usano la stessa porta RADIUS: da noi sta su un server membro. Usa un solo core, quindi si scala con più proxy dietro un bilanciatore; la sincronizzazione legge fino a 400 gruppi, in sola lettura, senza password, e il nome utente (sAMAccountName) non si può cambiare dopo la prima sincronizzazione.
Windows Logon
Si installa sul server o sul PC da proteggere e mostra una finestra di Duo dopo la password, anche per l'elevazione dei privilegi. A differenza del filtro, l'utente vede cosa sta aspettando. Copre console, Desktop remoto e, dalla versione 4.1, le elevazioni UAC con credenziali; non copre "Esegui come altro utente", PowerShell remoto, servizi e attività pianificate. Con la policy "Block access", consigliata da Duo, chi non è iscritto a Duo non entra nel server, amministratori compresi: gli account necessari vanno iscritti prima. L'opzione "Protect User Elevation only" spegne l'MFA sull'accesso locale e in Desktop remoto: da non attivare se si vuole proteggere anche l'accesso.
Command Line Protection
Aggiunge la seconda verifica a PowerShell remoto e a SSH verso un server Windows: il punto da cui gli amministratori, e purtroppo anche gli attaccanti, lavorano di più. Copre PowerShell Remoting (WinRM), OpenSSH e SFTP su Windows 10, 11 e Server 2019-2025; richiede Advantage o Premier. Chi non è in Duo non entra, e uno script non presidiato fallisce allo scadere del tempo di attesa: le automazioni vanno censite prima.
Identity Intelligence
Non aggiunge la seconda verifica: controlla gli account. Segnala quelli inattivi, con troppi privilegi, di servizio. È compresa in Advantage e Premier. Per i dati di Active Directory usa uno script PowerShell firmato da Duo, eseguito su un server membro con un account in sola lettura, una volta al giorno: non invia hash di password, ma invia a Cisco i dati personali degli utenti (nome, e-mail, telefono, reparto, responsabile, gruppi), con un'anteprima locale da rivedere prima dell'invio; gli endpoint del nostro tenant sono europei. Per un'azienda è un trattamento da mettere nell'informativa, non un dettaglio tecnico. Al momento di scrivere stiamo completando la verifica sui dati di Active Directory.
Studiati, non provati: Entra ID, Linux e i servizi Microsoft in sede
Letti sulla documentazione ufficiale, non messi alla prova.
Microsoft Entra ID. Duo può essere registrato come external authentication method: l'utente inserisce la password in Entra, il criterio di Conditional Access chiede l'MFA, l'utente approva su Duo. Serve Entra ID P1 o P2 per ogni utente (incluso in Microsoft 365 Business Premium, E3, E5 e F3). Due limiti da conoscere: le authentication strengths, compresa l'MFA resistente al phishing, non vengono soddisfatte da un metodo esterno, quindi il criterio deve usare "Require multifactor authentication"; e protegge gli accessi a Entra, non il logon a Windows. Per gli errori tipici della configurazione MFA lato Microsoft, vedi 5 errori da evitare con la MFA di Entra ID.
Servizi Microsoft in sede. Esistono integrazioni per RD Gateway (con limiti: disattiva i criteri CAP e RAP, solo push e telefonata), RD Web (solo il login al portale), AD FS, Outlook Web App e VPN RRAS tramite Authentication Proxy. AD FS e OWA, se Duo non risponde, bloccano l'accesso per impostazione predefinita.
Linux. Command Line Protection funziona solo su Windows. Per SSH e accessi locali Linux c'è Duo Unix (modulo pam_duo): si configura server per server, senza gestione centralizzata, e il fail open è il predefinito.
Come si vede dal lato utente
Per l'utente la differenza si riduce a un gesto: dopo la password, compare una richiesta sul telefono. Con Windows Logon compare anche una finestra sul server, che mostra il dispositivo e i metodi disponibili; con il solo filtro sul controller, invece, sullo schermo non appare niente, e l'utente deve sapere di guardare il telefono.
Cosa ci ha sorpreso nelle prove
La parte più utile di un laboratorio sono le sorprese. Quelle che seguono sono risultati delle nostre prove, con le versioni indicate (Legacy AD Protection 1.0.1, Windows Logon 6.0.0, Command Line Protection 1.0.0), non caratteristiche garantite dal prodotto: vanno verificate sul proprio ambiente, e conviene conoscerle prima di partire.
- Il Desktop remoto chiede due approvazioni. Una al controllo d'ingresso, una all'apertura del desktop. Con Windows Logon e il filtro installati insieme, siamo arrivati a cinque richieste per un solo accesso. Gli utenti vanno avvisati.
- Con un vecchio protocollo, una richiesta per ogni connessione. Un database SQL Server senza il suo nome Kerberos (SPN) registrato ripiega su NTLM, e ogni connessione fa partire una richiesta. Con Kerberos configurato bene ne basta una. È uno dei motivi per cui conviene ridurre l'uso di NTLM prima di introdurre l'MFA sul dominio.
- Anche stampanti e gestionali ne risentono. Se un apparato controlla gli utenti con un collegamento LDAP semplice, il filtro lo intercetta e chiede la verifica. Gli account usati da apparati e servizi vanno esclusi con cura.
- Un accesso rifiutato dà un messaggio generico. Windows dice che ci sono "restrizioni sull'account", senza nominare Duo: per l'assistenza il problema sembra altrove.
- Gli accessi nativi di SQL Server restano fuori. I login con utente e password di SQL,
sacompreso, non passano da Active Directory, e Duo non li vede: nessuna push e nessuna riga nel registro. - Il secondo fattore si paga una volta, al rilascio del ticket Kerberos. Dopo il logon, cartelle condivise, PowerShell remoto con il proprio ticket e SQL con Kerberos si aprono senza nuove richieste. Il ticket si rinnova da solo, senza approvazione: una sessione lasciata aperta può restare valida fino a sette giorni. Se l'azienda vuole l'MFA ogni giorno servono regole di blocco dello schermo o chiusura delle sessioni, oppure ticket più brevi.
- Un "Nega" segnalato come frode spegne le notifiche. Duo silenzia le push di quell'utente per circa 20 minuti: "non mi arriva la richiesta" può voler dire questo. Nei test si preme "Nega" senza segnalare la frode.
- Il registro cresce in fretta. Centinaia di righe in pochi minuti anche per gli utenti esclusi. Un account molto attivo messo in Enforce farebbe partire push a raffica. Su 26 prove previste ne abbiamo eseguite 22; tre, sull'accesso offline, le abbiamo saltate perché troppo rischiose anche in laboratorio.
Prima di installare Duo sui controller di dominio, confrontati con un sistemista Nexsys su account di servizio, apparati e protocolli
Parla con un sistemistaSe Duo non risponde: fail open o fail closed
La domanda che ogni responsabile IT si fa: e se Duo non è raggiungibile? Nel LAB abbiamo tolto la connessione a Internet e visto che i componenti si comportano in modo opposto. Il filtro sul controller di dominio fa passare tutti, senza avvisi (fail open); Windows Logon e Command Line Protection, di base, chiudono la porta (fail closed). Per Windows Logon è così dalla versione 4.3.0 del programma di installazione; fino alla 4.2.2 il predefinito era l'opposto, e l'aggiornamento con il programma di installazione riporta alla chiusura.
La nostra posizione: il fail closed lo sconsigliamo come scelta predefinita. Se in emergenza il token dell'autenticatore non funziona, si resta fuori dai server proprio quando serve entrare. Meglio, di norma, il fail open con il registro sorvegliato e l'accesso offline come complemento; dove il rischio giustifica il fail closed, servono accessi di emergenza provati. La scelta va fatta server per server, con la stessa logica degli account break-glass lato cloud. Il rovescio del fail open: chi riesce a isolare un controller da Internet spegne l'MFA senza che nessuno se ne accorga, quindi la riga Bypass_Fail_Open nel registro del filtro va sorvegliata.
Come si introduce, in quattro passi
Il percorso che abbiamo seguito, e che proponiamo ai clienti, è graduale: si prepara, si configura, si installa e solo alla fine si accende. Il filtro nasce spento, e per un po' si limita a raccontare cosa farebbe.
Una scelta che conta molto è quella dei gruppi. Un gruppo indica chi riceve la seconda verifica, un altro chi ne è escluso, per esempio gli account di servizio. Con un solo accorgimento: un account presente in entrambi i gruppi riceve comunque la verifica, perché Enforce vince su Bypass. L'impostazione che proponiamo: Enforce vuoto, così la verifica vale per tutto il dominio compresi gli utenti futuri, e in Bypass gli account di servizio, gli apparati che usano LDAP, le attività pianificate e un account amministrativo di emergenza. Da evitare "Domain Users" in Enforce (gli account di servizio finirebbero in entrambi i gruppi) e l'esclusione per computer (nel registro compare il controller, non il client). Le modifiche ai gruppi arrivano al filtro entro pochi minuti, al massimo un'ora.
Prima di partire: la lista di controllo
- Censire gli account di servizio, gli apparati e gli amministratori, e decidere per ognuno cosa succede.
- Verificare Kerberos sui server che usano database o servizi di rete, per evitare richieste moltiplicate.
- Installare su tutti i controller di dominio, non solo su uno.
- Preparare le emergenze: due amministratori con dispositivi diversi, una procedura per il telefono perso o cambiato, un account di emergenza custodito e provato. Un telefono per utente: due utenti con lo stesso numero condividono l'attivazione.
- Scegliere un solo livello per l'accesso ai server (filtro sul controller oppure Windows Logon), o accettare e spiegare agli utenti le approvazioni multiple.
- Decidere il fail open o il fail closed per ogni server e, per le sessioni lunghe, blocco dello schermo o ticket più brevi.
- Formare utenti e help desk: guardare il telefono, non approvare ciò che non si riconosce, cosa fare se la push non arriva, cosa significa il messaggio generico dopo un rifiuto.
- Osservare per una settimana prima di accendere, poi partire da un gruppo pilota ed estendere.
Cosa non abbiamo ancora chiarito
Alcune domande sono aperte con Cisco al momento della pubblicazione, e le riportiamo perché pesano sulla progettazione: se esiste un avviso nativo quando il filtro lavora in fail open; per quanto tempo vale il riuso di un esito recente e ogni quanto il filtro rilegge i gruppi; se i gruppi annidati in Enforce e Bypass vengono letti; cosa succede al rinnovo del ticket Kerberos dopo i sette giorni; se la segnalazione di frode può arrivare anche a un amministratore. Aggiorneremo l'articolo quando avremo le risposte.
Quando scegliere Duo, e quando no
Legacy AD Protection ha senso dove l'azienda usa già Cisco Duo per VPN, applicazioni o Windows Logon e vuole estendere la stessa policy alle autenticazioni di dominio, accettando un componente sui domain controller e l'edizione Advantage. Dove invece l'esigenza è coprire tutte le autenticazioni Active Directory, compresi protocolli e servizi, senza installare agent sui server e senza legarsi a un'unica piattaforma MFA, la strada che proponiamo è la protezione delle identità con MFA universale. In molte aziende le due soluzioni convivono su perimetri diversi: la scelta nasce dall'inventario degli accessi, non dal catalogo.
In conclusione
Duo non è una bacchetta magica, ma è uno strumento concreto per portare la seconda verifica dove oggi manca: negli accessi ad Active Directory e ai server, senza riscrivere le applicazioni. Aiuta a dare risposta a requisiti che la normativa europea e italiana rende sempre più precisi, a patto di accompagnarlo con una valutazione del rischio e con un progetto che consideri le emergenze, gli account di servizio e gli utenti.
Se vuoi capire cosa significherebbe nella tua azienda, parliamone: in una call di 30 minuti vediamo insieme quali accessi al tuo dominio sono oggi senza seconda verifica e se Duo è la strada giusta.
Chiedi una call di 30 minuti: inventario degli accessi, scelta tra Duo e MFA universale, piano di introduzione
Chiedi la callDomande frequenti su Cisco Duo Legacy AD Protection
Cosa protegge Cisco Duo Legacy AD Protection?
Le autenticazioni che passano dal controller di dominio Active Directory: logon ai PC, Desktop remoto, cartelle condivise, PowerShell, applicazioni che usano Kerberos o NTLM. Non protegge i login nativi di SQL Server, che non passano da Active Directory.
Quale edizione di Duo serve?
Almeno Duo Advantage. Il componente è disponibile in versione stabile dal 25 agosto 2026 e va installato su tutti i controller di dominio.
Cosa succede se Duo non è raggiungibile?
Il filtro sul controller di dominio lascia passare gli accessi senza avvisi (fail open); Windows Logon e Command Line Protection, con le impostazioni predefinite, li bloccano (fail closed). Il comportamento va scelto server per server, con accessi di emergenza provati.
Gli utenti devono cambiare abitudini?
Dopo la password ricevono una notifica sul telefono. Con il solo filtro sul controller non compare nulla sullo schermo; con Windows Logon compare una finestra. In Desktop remoto le approvazioni possono essere due o più, quindi gli utenti vanno avvisati.
Per quanto tempo vale un'approvazione?
Il controllo avviene al rilascio del ticket Kerberos. Finché il ticket resta valido, e si rinnova da solo fino a sette giorni in una sessione aperta, cartelle, PowerShell e database con Kerberos non chiedono altre approvazioni. Con NTLM, invece, ogni connessione ne chiede una.
Copre anche i server Linux?
No. Legacy AD Protection e Command Line Protection sono componenti Windows. Per SSH e accessi locali Linux Duo offre Duo Unix, che si configura server per server e parte in fail open.
Duo basta per essere conformi a NIS2?
No. La NIS2 chiede l'autenticazione a più fattori "ove opportuno", in base alla valutazione del rischio; Duo è uno strumento che soddisfa quel requisito sugli accessi ad Active Directory e lascia i registri che lo documentano. La conformità riguarda l'organizzazione e i suoi processi.
Fonti
- Direttiva (UE) 2022/2555 (NIS2), art. 21: eur-lex.europa.eu
- D.Lgs. 4 settembre 2024, n. 138, art. 24, e ACN, Linee guida NIS, specifiche di base (settembre 2025), determina 164179 del 14 aprile 2025: acn.gov.it
- Regolamento (UE) 2022/2554 (DORA), art. 9, par. 4: eur-lex.europa.eu
- PCI Security Standards Council, PCI DSS v4.0.1, requisito 8.4.2: pcisecuritystandards.org
- ISO/IEC 27001:2022, Allegato A, controllo 8.5: iso.org
- Regolamento (UE) 2016/679 (GDPR), art. 32: eur-lex.europa.eu
- Documentazione Cisco Duo: Legacy AD Protection (note di rilascio), Windows Logon, Command Line Protection, sincronizzazione con AD, edizioni e prezzi
Le prove nel laboratorio Nexsys sono del 19 e 20 ottobre 2026 e sono state condotte da Marco Moserle, sistemista Nexsys. Le citazioni normative sono sintetiche: per il testo completo si rimanda alle fonti ufficiali. I prezzi sono di listino USA; quelli per l'Italia non sono pubblici.
Il 31 ottobre 2026 è il termine entro cui le organizzazioni inserite nell'elenco NIS nel 2025 devono avere operative le misure di sicurezza di base definite dall'Agenzia per la Cybersicurezza Nazionale. Da quel momento ACN può avviare le attività di verifica.
Se la tua azienda non rientra nel perimetro NIS, è facile pensare che la scadenza non ti riguardi. Tra le misure di base, però, c'è la sicurezza della catena di approvvigionamento: i tuoi clienti soggetti NIS devono valutare il rischio legato ai propri fornitori e dimostrare di averlo fatto. Lo strumento con cui lo fanno è il contratto, accompagnato da questionari e richieste di evidenze.
In pratica, nei prossimi mesi molte PMI riceveranno domande precise sulla propria sicurezza informatica, spesso con tempi di risposta stretti. Questo articolo spiega cosa cambia per un fornitore, quali richieste ricorrono più spesso e quali evidenze puoi produrre partendo dagli strumenti che probabilmente usi già, a cominciare da Microsoft 365.
Perché il 31 ottobre riguarda anche chi non è in elenco NIS
Il D.Lgs. 138/2024, che recepisce in Italia la direttiva NIS2, richiede ai soggetti essenziali e importanti di adottare misure di gestione del rischio che includano la sicurezza della catena di approvvigionamento, compresi i rapporti con i fornitori diretti e i fornitori di servizi. La Determinazione ACN 379907/2025 traduce questo obbligo in misure concrete: 37 misure e 87 requisiti per i soggetti importanti, 43 misure e 116 requisiti per i soggetti essenziali.
Essere fornitore di un soggetto NIS non ti rende automaticamente un soggetto NIS. L'obbligo resta in capo al cliente, che lo trasferisce a te per via contrattuale. Questo ha due conseguenze pratiche: non hai obblighi diretti verso ACN, ma hai obblighi verso il cliente. E se non rispondi in modo convincente, la tua fornitura rischia di essere classificata come ad alto rischio, con richieste aggiuntive o una revisione del contratto.
Attenzione ai fornitori di servizi IT
Le aziende che offrono servizi gestiti ICT ad altre imprese possono rientrare direttamente nel perimetro NIS2 se superano le soglie dimensionali. In quel caso non sei solo un fornitore: sei un soggetto NIS. Se hai dubbi, la guida NIS2 in 7 step aiuta a capire se la tua azienda è coinvolta. Se lo è, scopri come funziona la nostra consulenza NIS2.
Il fornitore rilevante: chi riceverà le richieste più approfondite
Le determinazioni ACN hanno introdotto il concetto di fornitore rilevante: un fornitore che costituisce un elemento sistemico della catena di approvvigionamento di uno o più soggetti NIS. Rientrano tipicamente in questa categoria i fornitori di servizi cloud, chi gestisce infrastrutture IT, chi sviluppa software critico, gli outsourcer tecnologici e chi si occupa della manutenzione dei sistemi.
La regola pratica è semplice: se accedi ai sistemi del cliente, ne gestisci i dati o eroghi un servizio da cui dipende la sua operatività, aspettati un questionario dettagliato e richieste di evidenze documentali.
Un approccio basato sul rischio, non uguale per tutti
Le FAQ ACN sulla sicurezza della catena di approvvigionamento, aggiornate a luglio 2026, chiariscono che la gestione dei fornitori segue un modello basato sul rischio. Non tutti i fornitori riceveranno le stesse domande: chi fornisce materiale di consumo e chi amministra il tenant Microsoft 365 del cliente avranno livelli di verifica molto diversi.
Le 10 richieste più frequenti nei questionari di sicurezza fornitori
I questionari variano da cliente a cliente, ma le aree coperte sono ricorrenti. La tabella riassume le domande che incontrerai più spesso, l'evidenza che il cliente si aspetta e dove si trova nella maggior parte delle aziende che usano Microsoft 365.
| # | Area | Domanda tipica | Evidenza da preparare | Dove si trova |
|---|---|---|---|---|
| 1 | Autenticazione | Usate l'autenticazione a più fattori per tutti gli accessi? | Policy di accesso condizionale e report di registrazione MFA | Microsoft Entra ID |
| 2 | Account privilegiati | Come gestite gli account amministrativi? | Elenco ruoli admin, account separati, account di emergenza documentati | Entra ID, Active Directory |
| 3 | Dispositivi | I dispositivi aziendali sono gestiti e aggiornati? | Report di conformità e stato degli aggiornamenti | Microsoft Intune |
| 4 | Protezione endpoint | Avete una soluzione EDR attiva? | Copertura dei dispositivi e gestione degli avvisi | Microsoft Defender |
| 5 | Cifratura | I dati sui portatili sono cifrati? | Report BitLocker e custodia delle chiavi di ripristino | Intune, Entra ID |
| 6 | Backup | Fate backup e testate il ripristino? | Policy di backup, report dei job, verbale dell'ultimo test di restore | Soluzione di backup dedicata |
| 7 | Log | Conservate i log di accesso e delle attività? | Audit log attivo e periodo di conservazione | Microsoft Purview, Entra ID |
| 8 | Vulnerabilità | Eseguite vulnerability assessment periodici? | Report dell'ultimo assessment e piano di rimedio | Assessment esterno, Defender |
| 9 | Incidenti | Entro quanto ci notificate un incidente? | Procedura con referenti, canali e tempi di notifica | Documento interno |
| 10 | Formazione | Il personale è formato sulla sicurezza? | Registro della formazione ed esiti delle simulazioni di phishing | Piattaforma formativa |
A queste si aggiunge spesso una domanda specifica per chi lavora sui sistemi del cliente: con quali strumenti accedete da remoto e come tracciate le sessioni? Un accesso tramite software di controllo remoto non concordato è uno dei punti che un cliente NIS tende a non accettare. Ne abbiamo parlato nell'articolo sui rischi degli RMM non autorizzati.
Sai già quali di queste evidenze puoi produrre oggi?
Con il Microsoft 365 Security Assessment verifichiamo configurazione di identità, dispositivi, log e backup del tuo tenant e ti consegniamo un report con lo stato di ciascun controllo e le priorità di intervento.
Richiedi il Security AssessmentCome dimostrarlo con Microsoft 365: le evidenze area per area
Il punto non è dichiarare di avere un controllo, ma poterlo dimostrare con un report, una configurazione esportata o un documento datato. Molte di queste evidenze sono già disponibili nei portali di amministrazione Microsoft, a patto che i controlli siano configurati.
Identità e accessi
È l'area su cui i clienti insistono di più, perché la compromissione delle credenziali resta il punto di ingresso più comune. Le evidenze utili sono le policy di accesso condizionale in Entra ID che impongono l'MFA, il report di registrazione dei metodi di autenticazione e l'elenco aggiornato degli utenti con ruoli amministrativi. Gli account di emergenza esclusi dalle policy vanno documentati, con il motivo dell'esclusione e le modalità di controllo.
Nelle infrastrutture ibride non basta guardare il cloud: Active Directory on-premises resta spesso la fonte delle identità, e un dominio con troppi amministratori o configurazioni deboli vanifica i controlli di Entra ID. Un assessment e hardening di Active Directory fornisce un'evidenza documentata dello stato del dominio. Per la protezione delle credenziali privilegiate, vedi anche le soluzioni di Identity Security.
Dispositivi, aggiornamenti e cifratura
Con Microsoft Intune puoi produrre in pochi minuti il report di conformità dei dispositivi: sistema operativo aggiornato, BitLocker attivo, antivirus funzionante. Se Intune non è ancora in uso, la domanda del cliente è un buon motivo per partire: trovi una spiegazione completa nella guida su cos'è Microsoft Intune e quando è incluso nelle licenze.
Se non riesci a rispondere con certezza a domande come "quanti PC sono cifrati?", probabilmente sei in una delle situazioni descritte nell'articolo sui segnali di PC aziendali fuori controllo.
Backup e ripristino
È la risposta in cui si sbaglia più spesso. Microsoft 365 garantisce la disponibilità del servizio, ma non sostituisce un backup indipendente con cui ripristinare dati cancellati, sovrascritti o cifrati da un ransomware. Al cliente servono tre cose: la policy di backup, i report dei job e soprattutto il verbale di un test di ripristino recente. Un backup mai testato non è un'evidenza. Se vuoi affidare la gestione a un servizio esterno, vedi la Data Protection as a Service.
Log e monitoraggio
Il cliente vuole sapere se, in caso di incidente, sarai in grado di ricostruire cosa è successo. Verifica che l'audit log di Microsoft Purview sia attivo e annota il periodo di conservazione previsto dalla tua licenza, così come quello dei log di accesso di Entra ID. Se i log non vengono analizzati da nessuno, valuta un servizio di monitoraggio continuo come il SOC as a Service.
Vulnerabilità
Alla domanda sulle verifiche periodiche la risposta più solida è un report di vulnerability assessment recente, accompagnato dal piano di rimedio e dallo stato delle correzioni. Se non hai mai svolto un assessment, l'articolo Vulnerability Assessment: cos'è, come funziona e cosa rileva spiega cosa aspettarti. Per una verifica sulla tua infrastruttura, vedi il servizio di vulnerability assessment per aziende.
Incidenti e persone
Due evidenze spesso trascurate: una procedura scritta di gestione degli incidenti, con referenti e tempi di notifica al cliente, e la prova che il personale è formato. Per la prima, puoi partire dal nostro protocollo di emergenza ransomware. Per la seconda, una campagna di phishing simulation produce un risultato misurabile da allegare al questionario.
Gli errori che fanno perdere credibilità al fornitore
Rispondere "sì" senza evidenze
Il cliente deve dimostrare ad ACN di aver valutato i fornitori: una risposta non documentata non gli serve.
Usare formule generiche
"Adottiamo le best practice di settore" non risponde a nessuna domanda specifica.
Confondere cloud e backup
Dire che i dati "sono su Microsoft" non risponde alla domanda sul ripristino.
Accedere ai sistemi del cliente con strumenti non concordati
Ogni accesso remoto deve essere autorizzato, tracciato e revocabile.
Non avere un referente per la sicurezza
Il cliente ha bisogno di un nome e di un contatto da chiamare in caso di incidente.
Da dove partire: un piano in tre tempi
Nella prossima settimana
- Raccogli i questionari e le clausole contrattuali già ricevuti e nomina un referente interno per le risposte.
- Esporta le evidenze già disponibili: policy MFA, elenco amministratori, report Intune, report di backup.
Entro un mese
- Confronta le tue risposte con le 10 aree della tabella e individua i controlli mancanti.
- Esegui un vulnerability assessment e scrivi la procedura di gestione degli incidenti.
- Documenta la valutazione dei rischi con il template gratuito per l'analisi del rischio informatico.
Nei prossimi sei mesi
- Interventi strutturali su identità e Active Directory, monitoraggio continuo dei log, formazione periodica del personale.
- Per chi deve guidare il progetto internamente, il corso NIS2 copre requisiti, governance e implementazione.
Hai ricevuto un questionario di sicurezza da un cliente NIS2?
Lo analizziamo insieme, individuiamo le evidenze che hai già e quelle da costruire, e definiamo le priorità. Siamo a Bussolengo (VR) e lavoriamo con aziende di Verona e di tutta Italia.
Parla con uno specialistaDomande frequenti sui fornitori NIS2
Se sono fornitore di un'azienda NIS2 devo registrarmi sulla piattaforma ACN?
No, essere fornitore di un soggetto NIS non comporta di per sé l'obbligo di registrazione. Gli obblighi ti arrivano dal cliente attraverso il contratto. Verifica però se la tua azienda rientra direttamente nel perimetro per settore e dimensioni: è il caso, ad esempio, di alcuni fornitori di servizi ICT gestiti.
Esiste una certificazione NIS2 per i fornitori?
Non esiste una certificazione ufficiale di conformità NIS2. Certificazioni come la ISO/IEC 27001 sono evidenze utili e molti clienti le apprezzano, ma non sono obbligatorie: ciò che conta è dimostrare con documenti e report i controlli richiesti.
Cosa succede se non rispondo al questionario di sicurezza del cliente?
Il cliente deve comunque gestire il rischio legato alla tua fornitura. Può chiederti misure aggiuntive, rivedere le condizioni contrattuali o, nei casi più critici, valutare fornitori alternativi.
Microsoft 365 basta per essere in regola con le richieste dei clienti NIS2?
No. Microsoft 365 offre strumenti utili per autenticazione, gestione dei dispositivi, log e protezione, ma la configurazione, il backup indipendente, le procedure e la formazione restano a carico dell'azienda.
Quali evidenze conviene preparare per prime?
Le policy di autenticazione a più fattori, l'elenco degli account amministrativi, la policy di backup con un test di ripristino recente e la procedura di gestione degli incidenti. Sono le aree richieste in quasi tutti i questionari.
Ogni quanto vanno aggiornate le evidenze?
Almeno una volta l'anno e ogni volta che cambia in modo significativo l'infrastruttura. Molti contratti con clienti NIS prevedono una revisione periodica delle misure del fornitore.