Ogni identità aziendale attraversa tre momenti: entra, cambia ruolo, esce. È il modello joiner-mover-leaver, noto da anni a chiunque si occupi di gestione degli accessi. Nella pratica operativa, però, le tre fasi non ricevono la stessa attenzione. L’ingresso è curato, perché una persona che non riesce a lavorare il primo giorno genera un ticket immediato. Il cambio di ruolo è gestito a metà: i nuovi permessi si aggiungono, i vecchi restano. L’uscita è il momento peggiore, perché nessuno protesta se un accesso resta aperto.
Nei nostri assessment presso aziende italiane la verifica di questo punto produce quasi sempre lo stesso risultato: account attivi che non dovrebbero più esserlo. Ex dipendenti, consulenti che non collaborano più con l’azienda, contratti scaduti, utenze tecniche create per una migrazione finita due anni fa.
Perché l’accesso residuo è il rischio che non si vede
Un accesso residuo è una credenziale ancora valida che non ha più una ragione di esistere. La sua pericolosità sta proprio nella normalità: per i sistemi è un’utenza legittima, autenticata, autorizzata. Non fa scattare alcun allarme. Non rallenta nessuno, non genera ticket, non compare in nessun report finché qualcuno non va a cercarlo.
Il contesto rende il problema più serio. Gli attacchi basati sull’identità sono in forte crescita: il furto di credenziali resta la porta d’ingresso più sfruttata, e le campagne di phishing sono diventate molto più efficaci da quando l’AI generativa produce messaggi credibili e personalizzati. In Italia la crescita degli incidenti gravi è stata a doppia cifra nell’ultimo anno, con manifattura, trasporti e logistica tra i settori più colpiti. Un attaccante che entra con credenziali valide non deve forzare nulla: si muove come un utente autorizzato.
Gli account orfani sono il bersaglio ideale in questo schema. Nessuno li usa, quindi nessuno si accorge se qualcun altro comincia a usarli.
Dove si rompe il ciclo di vita: tre scenari ricorrenti
Il primo è la cessazione non propagata. Le dimissioni vengono registrate in HR, ma la revoca degli accessi passa da una comunicazione manuale all’IT. Se la comunicazione arriva in ritardo, o si ferma su un sistema secondario, l’accesso resta. Nella maggior parte delle organizzazioni la disattivazione avviene sui sistemi principali e si perde su quelli di nicchia: applicazioni verticali, ambienti di test, strumenti adottati da un singolo reparto.
Il secondo è il cambio di ruolo senza revoca. Una persona passa da un reparto all’altro e riceve i permessi della nuova posizione. I precedenti restano, perché toglierli richiede una decisione esplicita che nessuno prende. Ripetuto negli anni, questo produce il privilege creep: utenti con permessi stratificati che nessuno saprebbe più giustificare.
Il terzo riguarda le terze parti. Consulenti, fornitori, system integrator ricevono accessi per la durata di un progetto. Ma il progetto finisce con una data ufficiale e una data reale, e le utenze quasi mai vengono chiuse alla scadenza contrattuale. È l’area in cui, secondo la nostra esperienza sul campo, si concentra il maggior numero di sorprese quando si fa un inventario serio.
Con gli AI agent il problema cambia scala
Alle identità umane si è aggiunta negli ultimi anni una categoria nuova: gli AI agent. Copilot integrati nei flussi di lavoro, automazioni che operano sui gestionali, assistenti collegati a basi dati interne, custom GPT costruiti sui dati di produzione.
Aggravano il quadro per una ragione strutturale: nascono in fretta e non hanno una data d’uscita naturale. Un agente creato per un progetto pilota resta attivo anche dopo la fine del progetto, perché disattivarlo non è compito di nessuno in particolare. Un’integrazione autorizzata mesi fa con un consenso OAuth continua a leggere i dati aziendali, e spesso nessuno ricorda chi l’ha attivata.
Il dato di riferimento è netto: il 91% delle aziende usa già AI agent, ma solo il 10% ha una strategia strutturata per gestirli come identità (Okta, AI at Work 2025). Tradotto in termini di ciclo di vita, per gli agenti il joiner-mover-leaver nella maggior parte delle organizzazioni non esiste proprio: c’è l’ingresso, non c’è l’uscita.
Cosa chiede NIS2, e cosa cambia il 31 ottobre 2026
Per i soggetti in perimetro NIS2 la gestione del ciclo di vita degli accessi non è una buona pratica facoltativa: è un requisito da dimostrare con evidenze. Le domande a cui bisogna saper rispondere sono quattro, e sono sempre le stesse: chi ha accesso, da quando, autorizzato da chi, e con quale processo di revoca.
Sulla data vale una precisazione che spesso sfugge. Il 31 ottobre 2026 non è il giorno in cui si diventa conformi: è il giorno da cui l’Agenzia per la Cybersicurezza Nazionale può avviare le verifiche ispettive. Finisce la fase in cui le organizzazioni vengono accompagnate nell’adeguamento e inizia quella del controllo. Per chi è già iscritto in elenco, le misure di sicurezza di base devono essere operative, con evidenze documentali, entro quella data. Chi viene iscritto nel corso del 2026 ha un termine posticipato.
Va aggiunto un punto che riguarda i vertici aziendali. Il decreto italiano attribuisce agli organi di amministrazione una responsabilità diretta e non delegabile sulle misure di gestione del rischio. La delega operativa resta possibile, la responsabilità no. È il motivo per cui il tema esce dal perimetro IT ed entra nelle discussioni di consiglio.
Le quattro evidenze da preparare
Chi si prepara a una verifica dovrebbe arrivarci con quattro cose pronte, ricavabili dal sistema e non ricostruite a mano.
- Inventario completo delle identità con accesso ai sistemi rilevanti, umane e non umane, ciascuna con un responsabile assegnato.
- Matrice dei privilegi: chi può fare cosa, e in base a quale autorizzazione.
- Processo di revoca documentato, con i tempi effettivi tra la cessazione e la disattivazione.
- Audit trail consultabile, che permette di ricostruire chi ha avuto accesso a cosa e quando.
La differenza tra un’organizzazione pronta e una impreparata non sta nell’avere queste informazioni, ma nel poterle produrre in tempi rapidi e in modo verificabile.
Come si automatizza il ciclo di vita
La risposta operativa è il lifecycle management automatizzato. Il principio è semplice: il sistema di identità viene collegato alle fonti autorevoli, così che ogni evento si propaghi da solo. Per le persone la fonte è il sistema HR: un’assunzione crea le utenze e i permessi del ruolo, un cambio di reparto li ricalcola, una cessazione li revoca ovunque, lo stesso giorno. Per gli AI agent la fonte è un inventario in cui ogni agente ha un proprietario umano esplicito.
Con Okta Identity Governance questo si traduce in alcune capacità concrete. Il Lifecycle Management gestisce provisioning e de-provisioning automatici su tutte le applicazioni collegate, eliminando gli account orfani. L’Access Certification apre campagne periodiche in cui i responsabili confermano o revocano i permessi, con remediation automatica e con l’evidenza che ne deriva. L’Entitlement Management applica il privilegio minimo in modo dimostrabile. Le Access Requests con approvazione e scadenza governano gli accessi di fornitori e consulenti, che scadono da soli invece di sopravvivere al progetto. L’audit trail nativo produce la prova documentale senza dover riconciliare sistemi diversi.
Per gli AI agent la stessa logica si applica con una variante importante: al posto dei token a lunga durata, che oggi sono la norma, si usano credenziali brevi e contestuali che scadono da sole. È il modo più semplice per evitare che un agente dimenticato resti attivo per anni.
Da dove iniziare, in pratica
Non serve un progetto formale per fare i primi passi. Il primo è l’inventario: elencare le identità attive sui sistemi principali, comprese le utenze tecniche e gli agenti, e assegnare a ciascuna un responsabile. Il secondo è un controllo mirato sulle uscite degli ultimi dodici mesi, confrontando le cessazioni registrate in HR con gli account ancora attivi. Il terzo è la verifica delle credenziali in uso: quante sono permanenti e quante hanno una scadenza. Il quarto è la scelta di una frequenza di revisione degli accessi e il rispetto di quella cadenza, anche se all’inizio il processo è parzialmente manuale.
Questi quattro passi non risolvono il problema, ma dicono con precisione quanto è grande. Ed è l’informazione che serve per decidere quanto investire.
Domande frequenti
Che cos’è il modello joiner-mover-leaver
È il modello che descrive il ciclo di vita di un’identità aziendale nelle sue tre fasi: ingresso, cambio di ruolo, uscita. A ogni fase corrispondono azioni sugli accessi: creazione, ricalcolo, revoca.
Che cos’è un account orfano
È un’utenza ancora attiva che non ha più un titolare o una ragione d’uso: tipicamente appartiene a un ex dipendente, a un’azienda esterna che non collabora più o a un progetto chiuso.
Perché il de-provisioning è più critico del provisioning
Perché un errore nel provisioning si manifesta subito, con una persona che non riesce a lavorare, mentre un errore nel de-provisioning resta invisibile fino a quando qualcuno non sfrutta l’accesso rimasto aperto.
Il ciclo di vita vale anche per gli AI agent
Sì. Un AI agent accede a dati e sistemi con permessi propri, quindi va censito, assegnato a un responsabile, limitato nei privilegi e disattivato quando non serve più, esattamente come un’utenza umana.
Cosa bisogna dimostrare per NIS2
In sintesi: chi ha accesso, da quando, autorizzato da chi, con quale processo di revoca, e con un audit trail consultabile a supporto.
In sintesi
Il ciclo di vita delle identità è un tema poco appariscente e molto concreto. Non riguarda tecnologie nuove, riguarda un processo che in molte organizzazioni funziona a metà. Automatizzarlo riduce la superficie d’attacco più sfruttata, alleggerisce il lavoro dell’IT e produce, come effetto collaterale, esattamente le evidenze che le verifiche NIS2 richiederanno.
Per capire da dove partite, in Factor-y, primo partner Okta in Italia, mettiamo a disposizione un assessment di 30 minuti, gratuito: una fotografia del vostro ciclo di vita degli accessi, con i punti aperti e le priorità in vista del 31 ottobre 2026.
