Non-Human Identity (NHI) secondo NIS2 e D.Lgs. 138/2024

Per ogni dipendente registrato a libro paga, un’organizzazione gestisce mediamente ottantadue identità digitali non umane: chiavi API, service principal, OAuth grant, certificati TLS, secret applicativi, account di agenti autonomi. Il dato proviene dal CyberArk 2025 Identity Security Landscape, indagine internazionale su organizzazioni pubbliche e private di almeno 500 dipendenti, ora confluita nel perimetro Palo Alto Networks.

Il rapporto ottantadue a uno non è una curiosità statistica. È l’ammissione, nel linguaggio delle proporzioni, che il perimetro di sicurezza che CISO e Direzioni Sistemi Informativi pensano di governare è una frazione minoritaria del perimetro reale. E che il cost center delle identità, finora dimensionato sulla popolazione degli account utente, è sottostimato di quasi due ordini di grandezza nel momento esatto in cui il D.Lgs. 4 settembre 2024, n. 138, le determinazioni ACN del dicembre 2025 e il pacchetto di determinazioni di aprile 2026 sono entrati a regime e iniziano a generare obblighi probatori vincolanti.

Il Verizon 2026 DBIR, pubblicato il 20 maggio su un campione di oltre 22.000 violazioni confermate in 145 Paesi, registra un incremento del 60% anno su anno dei breach veicolati da terze parti, che oggi rappresentano il 48% del totale; nello stesso report Verizon raccomanda esplicitamente di:

“prestare particolare attenzione agli account di servizio e di macchina, perché sono quelli che verranno probabilmente sfruttati nel nostro potenziale futuro di AI agentica”.

Che cosa intendiamo per non-human identity

Una non-human identity (NHI) è qualsiasi credenziale digitale che autentica un soggetto non persona fisica all’interno di un sistema informativo. Le categorie operative consolidate nella letteratura di settore, e in particolare nella OWASP NHI Top 10 del 2025, sono cinque.

Le chiavi API sono stringhe statiche emesse da una piattaforma per autenticare chiamate verso le proprie application programming interface. Vengono spesso incorporate nel codice, conservate in variabili d’ambiente o, nei casi peggiori, in repository pubblici.

I service principal sono identità organizzative che impersonano applicazioni o servizi all’interno di un directory aziendale (Microsoft Entra ID, AWS IAM, Google Cloud IAM). Hanno ruoli e permessi propri, possono detenere credenziali (segreti, certificati) e operare con privilegi non di rado superiori a quelli degli amministratori umani.

Gli OAuth grant sono autorizzazioni emesse da un Identity Provider a un’applicazione terza affinché quest’ultima acceda a risorse per conto di un utente. La compromissione di un singolo OAuth token può aprire l’accesso a interi ambienti SaaS senza interagire con MFA o policy condizionali, come dimostrato dagli incidenti documentati nel 2025 sulla supply chain Salesloft-Drift.

I workload identity e i certificati machine-to-machine (mTLS, certificati di container, spiffe ID) autenticano nodi infrastrutturali: cluster Kubernetes, microservizi, pipeline CI/CD.

Le agent identity sono la categoria emersa nell’ultimo anno con l’adozione di agenti autonomi: ogni agente AI capace di leggere CRM, generare report, eseguire transazioni opera con una propria identità digitale che invoca tool, scrive in database, comunica con altri agenti.

La caratteristica comune a queste cinque categorie è dirompente per la governance: non hanno manager, non firmano contratti, non vengono iscritte alle visite mediche, non ricevono comunicazioni di offboarding. Si moltiplicano per clonazione, ereditano permessi per copy-paste di configurazioni, sopravvivono al dipendente che le ha create. Una porzione non trascurabile di esse, secondo le analisi periodiche dei principali fornitori di identity security, dispone di privilegi paragonabili a quelli di un amministratore di sistema.

Il quadro normativo: art. 24 e l’inventario degli asset come prerequisito probatorio

Il D.Lgs. 138/2024, che recepisce in Italia la direttiva (UE) 2022/2555, all’articolo 24, comma 2, impone a soggetti essenziali e importanti l’adozione di misure tecniche, operative e organizzative adeguate e proporzionate alla gestione dei rischi per la sicurezza dei propri sistemi informativi e di rete. La norma elenca dieci ambiti minimi, fra cui la sicurezza nell’acquisizione, sviluppo e manutenzione dei sistemi, la gestione delle vulnerabilità, la gestione degli incidenti, le politiche sui controlli di accesso e la gestione degli asset.

La traduzione operativa è contenuta nella Determinazione ACN n. 379907/2025 del 19 dicembre 2025, applicabile dal 15 gennaio 2026, che abroga e sostituisce la precedente Determinazione n. 164179/2025. Il provvedimento dispone, per i soggetti importanti, 37 misure articolate in 87 requisiti (Allegato 1) e, per i soggetti essenziali, 43 misure in 116 requisiti (Allegato 2). Le misure sono sviluppate in coerenza con il Framework Nazionale per la Cybersecurity e la Data Protection (edizione 2025), che a sua volta deriva dal NIST Cybersecurity Framework 2.0.

Per le non-human identity il fulcro normativo è nei due gruppi di misure ID.AM e PR.AA.

ID.AM-01 prescrive il mantenimento di un inventario aggiornato degli apparati fisici (hardware) che compongono i sistemi informativi e di rete, inclusi dispositivi IT, IoT, OT e mobili. ID.AM-02 estende l’inventario al software, ai servizi e ai sistemi gestiti dall’organizzazione. La parola “servizi” non è ornamentale: una chiave API che autentica un microservizio, un service principal che orchestra una pipeline CI/CD, un OAuth grant concesso a un’applicazione terza sono, in tutta evidenza, servizi che vanno inventariati e tracciati nel tempo.

PR.AA-01 dispone che le identità e le credenziali “degli utenti, dei servizi e dell’hardware autorizzati sono gestite dall’organizzazione”. Si tratta di una formulazione chiave: la determinazione ACN tratta esplicitamente i “servizi” come soggetti di identità autonoma, alla pari di utenti e dispositivi. PR.AA-03 impone che utenti, servizi e hardware siano autenticati. PR.AA-05 introduce i principi del minimo privilegio e della separazione dei compiti per permessi, diritti e autorizzazioni di accesso, definiti in policy, gestiti, applicati e periodicamente rivisti.

Si aggiunge, sul piano sovranazionale, il documento ENISA Technical Implementation Guidance del giugno 2025, sviluppato per il Regolamento di esecuzione (UE) 2024/2690. ENISA è esplicita su due punti che riguardano direttamente le NHI: occorre un inventario completo, accurato e continuamente aggiornato degli asset, preferibilmente alimentato da strumenti di discovery automatizzati; le organizzazioni devono mantenere un registro di tutti i diritti di accesso concessi, includendo identità privilegiate e identità di servizio. Il commento depositato in consultazione pubblica dalla OpenID Foundation ha rilevato la necessità di esplicitare la nozione di service identity nelle linee guida ENISA, segno che la categoria sta entrando nel vocabolario regolatorio europeo, ma non ne è ancora cuore.

Il quadro si è ulteriormente densificato ad aprile 2026 con tre nuove determinazioni ACN che incidono sull’organizzazione dell’inventario NHI in modo indiretto ma sostanziale.

La Determinazione 127434/2026 del 13 aprile fissa il calendario degli adempimenti per i soggetti inseriti per la prima volta nel 2026.

La Determinazione 127437/2026, della stessa data, introduce l’obbligo, per tutti i soggetti NIS, di comunicare ad ACN l’elenco dei fornitori rilevanti, identificati anche tramite codici CPV: una porzione significativa delle NHI di un soggetto NIS è generata, esposta o gestita attraverso integrazioni con questi fornitori, e il loro censimento porta nel perimetro NIS catene di OAuth grant e chiavi API finora opache.

La Determinazione 155238/2026 del 20 aprile, applicabile dal 1° maggio 2026, definisce il modello di categorizzazione di attività e servizi: dieci macro-aree, quattro categorie di rilevanza (“impatto minimo”, “impatto basso”, “impatto medio”, “impatto alto”) da attribuire tramite una Business Impact Analysis semplificata nella finestra annuale 1° maggio – 30 giugno.

È una categorizzazione di funzioni di business, non di asset tecnologici: ma proprio per questo orienterà, nei prossimi mesi, la priorità con cui le diverse non-human identity andranno tracciate, autorizzate e monitorate. ACN ha già annunciato che, sulla base di questa categorizzazione, definirà entro fine 2026 le “misure di sicurezza a lungo termine”, evoluzione proporzionata e graduale delle attuali misure di base della Determinazione 379907/2025. Per il CISO, il messaggio operativo è inequivocabile: l’inventario NHI deve essere agganciato alla categorizzazione dei servizi a cui quelle identità accedono.

L’impatto pratico per il CISO di un soggetto NIS è inequivocabile. Dal 15 gennaio 2026 il regime di notifica al CSIRT Italia è pienamente operativo; entro ottobre 2026 le misure di sicurezza di base devono essere adottate. Se un incidente significativo coinvolge una chiave API condivisa, un service principal sovra-privilegiato o un OAuth grant mai revocato, l’ispezione ACN potrà legittimamente chiedere dove fossero mappati nell’inventario ID.AM-02, come fossero gestiti ai sensi di PR.AA-01, perché non fossero stati disattivati. La risposta “non sapevamo di averli” non costituisce difesa: equivale a confessare la mancata implementazione di misure di base.

Il gap: ottanta identità non inventariate ogni cento

Quanto è ampio lo iato fra obbligo regolatorio e realtà operativa? Il Gravitee 2026 State of AI Agent Security Report, basato su 919 fra dirigenti e tecnici, fornisce numeri che dovrebbero costituire l’agenda di lavoro di ogni CISO italiano nei prossimi mesi.

Il 45,6% delle organizzazioni utilizza chiavi API condivise per autenticare comunicazioni agent-to-agent: una sola credenziale è esposta a più agenti, rendendo strutturalmente impossibile l’attribuzione delle azioni, l’isolamento di un agente compromesso e la revoca selettiva richiesta da PR.AA-01.

Il 44,4% ricorre a generic token nella stessa funzione; solo il 17,8% impiega mTLS, l’unico meccanismo che assicura mutua autenticazione crittografica fra processi.

Il 27,2% gestisce l’autorizzazione fra agenti tramite logica hardcoded nei server, condizione che rende verifiche e revisioni periodiche dei diritti (PR.AA-05) impraticabili.

Il 22,5% non dispone di alcun catalogo formale di agenti AI e Model Context Protocol server; il 25,4% si affida a fogli di calcolo manuali, prassi esplicitamente sconsigliata dalla guida ENISA del giugno 2025.

Solo il 21,9% tratta gli agenti AI come entità identitarie indipendenti con scope e audit trail propri. Il restante 78% li tratta come estensioni di utenti umani o account di servizio generici, configurando di fatto la violazione di PR.AA-03 in tutti quei casi in cui un’azione tracciata nel SIEM non sia attribuibile a un’identità univoca.

Il 25,5% degli agenti dispiegati può creare e impartire istruzioni ad altri agenti, generando catene di delegazione autonome che il modello classico di autorizzazione RBAC non è in grado di rappresentare. Il modello di ruoli assume implicitamente che l’utente sia stabile; l’agente che genera altri agenti non lo è.

Solo il 23,7% delle organizzazioni utilizza il proprio sistema IAM/IdP aziendale come authorization server per l’infrastruttura agentica MCP. Negli altri casi la gestione delle identità degli agenti vive in silos separati rispetto all’identity directory su cui ruotano le misure NIS2 della famiglia PR.AA.

Sommando le quattro dimensioni (inventario, identità, autorizzazione, audit) l’88% delle organizzazioni intervistate da Gravitee ha riportato incidenti di sicurezza confermati o sospetti riconducibili ad agenti AI nei dodici mesi precedenti la rilevazione; nel comparto sanitario il dato sale al 92,7%. Sotto il regime NIS2, ciascuno di questi incidenti, se significativo ai sensi degli Allegati 3 e 4 della Determinazione 379907/2025, deve essere notificato al CSIRT Italia con preallarme entro 24 ore, notifica entro 72 ore e relazione finale entro un mese.

Il confronto con le linee guida AgID: ciò che SPID copre, ciò che resta scoperto

Per chi opera nel pubblico o nel parapubblico, il riferimento storico in materia di identità digitali è il corpus di linee guida AgID sull’identità digitale, in particolare le Linee Guida per il rilascio dell’identità digitale per uso professionale (Determinazione AgID n. 318/2019) e l’insieme dei regolamenti SPID. Si tratta di un impianto giuridicamente solido che, però, è stato concepito per identità di persone fisiche con qualifiche professionali, non per non-human identity in senso tecnico.

L’attributo Purpose dello SPID per uso professionale veicola l’appartenenza di una persona fisica a un’organizzazione; non rappresenta un servizio software che agisce autonomamente per conto di quell’organizzazione. Le linee guida SPID definiscono ruoli (gestore dell’identità, fornitore di servizi, persona giuridica) e processi (rilascio, revoca, riemissione) che ruotano attorno a una catena umana riconducibile a un titolare anagrafico.

In altre parole: le linee guida AgID coprono il dipendente, l’amministratore, il professionista. Non coprono il service principal che ogni notte estrae dati da quattordici banche dati, non coprono la chiave API che muove file fra un sistema documentale e un data lake in cloud, non coprono l’agente che riconcilia fatture sul gestionale. È un vuoto coerente con lo scopo dell’AgID (regolare l’identità digitale dei cittadini e dei professionisti italiani nel rapporto con la PA) ma diventa critico nell’organizzazione NIS quando il perimetro da inventariare passa, di colpo, da poche migliaia di utenti umani a centinaia di migliaia di entità servizio.

La conseguenza è strutturale. Il CISO di un soggetto essenziale non può estendere meccanicamente la governance SPID alle NHI: deve costruire un secondo binario, parallelo e tecnicamente più impegnativo, fondato su standard distinti (SPIFFE/SPIRE per i workload, OAuth 2.1 con sender-constrained token per le applicazioni, FIDO2 per i pochi casi residui di interazione umana sui secret) e ricondotto, per via probatoria, alle stesse misure ID.AM e PR.AA della Determinazione 379907/2025.

Sul piano operativo, l’unico ponte istituzionale fra i due mondi è oggi la Piattaforma Digitale Nazionale Dati (PDND), che per l’interoperabilità fra PA fa uso di accordi di adesione, voucher di autorizzazione e e-service con autenticazione client mutuamente verificata. La PDND, ai fini NIS2, è un caso di scuola: ogni e-service è una non-human identity in piena regola, soggetta agli obblighi di inventario, gestione del ciclo di vita e revisione dei privilegi che PR.AA-01 e PR.AA-05 prescrivono.

Checklist operativa per il CISO di un soggetto essenziale o importante

La sequenza che segue è una traduzione del combinato disposto D.Lgs. 138/2024 articolo 24, Determinazione ACN 379907/2025 (Allegati 1 e 2), ENISA Technical Implementation Guidance giugno 2025 e OWASP NHI Top 10 in dieci azioni verificabili. È pensata per arrivare a ottobre 2026 con un sistema documentale e tecnico difendibile in sede ispettiva.

1. Discovery delle NHI. Inventariare tutte le chiavi API, service principal, OAuth grant, certificati, workload identity e identità di agenti, su ambienti cloud (Entra ID, AWS IAM, GCP IAM), SaaS (Salesforce, ServiceNow, Microsoft 365), repository (GitHub, GitLab, Bitbucket), pipeline (Jenkins, GitLab CI, GitHub Actions) e ambienti on-premise. Strumenti di discovery automatizzati, non fogli di calcolo: lo prescrive ENISA. Riferimento: ID.AM-02.
2. Classificazione e ownership. A ogni NHI inventariata, assegnare un proprietario umano (un dipendente con manager, badge, data di uscita), una funzione di business, una classe di rischio coerente con la criticità dei sistemi cui accede. Senza ownership non c’è offboarding, e l’NHI1 della OWASP Top 10 (Improper Offboarding) diventa la prima vulnerabilità per esposizione. Riferimento: GV.RR-02 e ID.AM-02.
3. Eliminazione delle credenziali a vita lunga. Sostituire ovunque possibile chiavi API statiche e segreti permanenti con short-lived token (durata oraria o giornaliera) emessi dinamicamente da workload identity provider tipo SPIFFE/SPIRE, AWS IAM Roles Anywhere, Azure Managed Identity. È la contromisura diretta a NHI7 (Long-Lived Secrets). Riferimento: PR.AA-01.
4. Mutua autenticazione delle comunicazioni machine-to-machine. Imporre mTLS per le comunicazioni agent-to-agent e service-to-service; vietare l’uso di chiavi API condivise (il 45,6% censito da Gravitee) come metodo di autenticazione fra processi. La differenza non è cosmetica: l’mTLS è un’identità crittograficamente univoca, la chiave condivisa è un password riutilizzato. Riferimento: PR.AA-03.
5. Minimo privilegio enforced, non dichiarato. Per ogni NHI, calcolare i permessi effettivamente utilizzati negli ultimi 90 giorni e ridurre lo scope a quelli; rivedere trimestralmente; integrare nei processi di change management la valutazione dei diritti delle identità di servizio coinvolte. Contromisura a NHI5 (Overprivileged NHI). Riferimento: PR.AA-05.
6. Secret management centralizzato. Vault dedicati (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk Conjur) con rotazione automatica, audit log di accesso, integrazione nelle pipeline. Vietare in policy aziendale la presenza di segreti in codice sorgente; introdurre pre-commit hook di secret scanning (gitleaks, trufflehog) come gate di build. Contromisura a NHI2 (Secret Leakage). Riferimento: PR.DS-01 e PR.DS-02.
7. Lifecycle automatizzato. Procedura formalizzata di emissione, rotazione (almeno annuale per i casi in cui i token a vita breve non siano applicabili), revoca e disattivazione. Joiner-mover-leaver anche per le non-human identity: quando un servizio viene dismesso, le sue identità vanno revocate entro un Service Level Agreement documentato (tipicamente 24 ore). Riferimento: ID.IM-04 e PR.AA-01.
8. Monitoraggio continuo e anomaly detection. Le NHI non hanno orari di lavoro, ma hanno pattern di comportamento (orari tipici, sistemi tipici, volumi tipici). Configurare il SIEM perché le tratti come prima classe, con regole specifiche per agenti AI capaci di azione multi-step. La frequenza di audit deve essere continua, non periodica: il Gravitee 2026 segnala che solo il 7,7% delle organizzazioni audita giornalmente, contro il 37,5% mensile. Per soggetti essenziali NIS è obiettivo minimo realistico l’audit settimanale. Riferimento: DE.CM-01 e DE.AE-02.
9. Notifica integrata al CSIRT. Includere nei runbook di incident response gli scenari NHI-driven (compromissione chiave API, OAuth token theft, service principal hijack, agente AI deviante). Pre-classificare quali di questi scenari, in base agli Allegati 3 e 4 della Determinazione 379907/2025, integrano un incidente significativo da notificare al CSIRT Italia con preallarme 24h, notifica 72h, relazione finale entro un mese. Riferimento: RS.MA-04 e art. 25 del Decreto.
10. Documentazione probatoria. Tutto quanto sopra deve essere documentato in policy approvate dagli organi di amministrazione (art. 23 del Decreto), riesaminate almeno biennalmente o a fronte di incidenti significativi o mutamenti dell’esposizione al rischio. L’esistenza del documento, la sua approvazione formale, la sua revisione periodica, l’evidenza di esecuzione (log, ticket, report) costituiscono la base probatoria che un’ispezione ACN si attende di trovare. La regola non scritta, ma uniformemente confermata dalla prassi nei regimi di compliance maturi, è semplice: se non è scritto, non è stato fatto; se non è verificabile, non è documentato.

La posta in gioco

Le identità non umane non sono una metafora retorica. Per ciascun full time equivalent di organico, ottantadue entità digitali accedono a banche dati, eseguono transazioni, possono esfiltrare informazioni o propagare lateralmente un attacco. Dal 15 gennaio 2026 l’ordinamento italiano le considera, a tutti gli effetti, asset da inventariare e governare ai sensi dell’articolo 24 del D.Lgs. 138/2024. Per le oltre ventimila organizzazioni che ACN sta progressivamente censendo all’interno del perimetro NIS, la scadenza di ottobre 2026 implica non l’adozione di nuovi paradigmi cybersecurity, ma l’estensione di paradigmi già noti (inventario, classificazione, minimo privilegio, ciclo di vita, monitoraggio) a una popolazione di entità che, da sola, vale ottantadue volte gli utenti tradizionali.