Una password compromessa può essere cambiata. Un token di accesso rubato, invece, può consentire a un attaccante di entrare in applicazioni e API senza ripetere il login e, in alcuni casi, senza incontrare nuovamente l’autenticazione a più fattori. È uno dei motivi per cui la sicurezza delle identità digitali non può fermarsi alla schermata di accesso.
Il 15 settembre 2026 il NIST, con il contributo della Cybersecurity and Infrastructure Security Agency, ha pubblicato la versione finale del rapporto IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. Il documento nasce per agenzie federali statunitensi e cloud service provider, ma lo stesso NIST sottolinea che le indicazioni possono essere utili a qualsiasi organizzazione che usi token nei propri sistemi di gestione degli accessi.
Non è una nuova norma europea né introduce obblighi automatici per imprese e PA italiane. Offre però una lente molto concreta per valutare SSO, federazioni di identità, servizi SaaS, API e workload cloud: ambienti nei quali un oggetto digitale piccolo e spesso invisibile può diventare la chiave di molti sistemi.
Il token non è una semplice ricevuta di login
Quando un utente accede a un servizio, un identity provider può emettere un token o un’asserzione firmata digitalmente. L’applicazione destinataria verifica firma, emittente, validità e altre informazioni per decidere se concedere l’accesso. Questo meccanismo rende possibili il single sign-on e la federazione: ci si autentica una volta e si utilizzano più servizi senza reinserire continuamente le credenziali.
La comodità ha un rovescio. Se un token legittimo viene sottratto, copiato o riutilizzato fuori contesto, l’attaccante può apparire già autenticato. Se viene compromessa una chiave di firma, il problema può diventare ancora più ampio perché possono essere creati token falsi apparentemente attendibili. La notizia di pubblicazione del NIST ricorda un caso citato dal rapporto nel quale token forgiati, derivati da una chiave commerciale rubata, furono usati per accedere a sistemi di posta elettronica.
Per questo la protezione del token deve comprendere l’intero ciclo di vita: generazione, firma, distribuzione, conservazione, uso, rinnovo, monitoraggio, revoca e distruzione. Concentrarsi solo sull’autenticazione iniziale lascia scoperta la parte più lunga della sessione.
Responsabilità condivisa non significa responsabilità indefinita
Uno dei passaggi più utili dell’IR 8587 riguarda la divisione dei compiti tra fornitore cloud e cliente. Il provider gestisce normalmente infrastruttura, servizi centrali di identità, emissione e firma dei token, protezione delle chiavi e parte della telemetria. Il cliente configura policy IAM, privilegi applicativi, autenticazione, durata delle sessioni, alert, conservazione dei log e risposta agli incidenti.
I confini reali dipendono dal modello di servizio e dal contratto. Dire genericamente “è responsabilità del cloud” o “è responsabilità del cliente” non basta. Occorre una matrice verificabile che indichi chi può rilevare un token anomalo, chi può revocarlo, quali applicazioni ricevono il segnale, quali log sono disponibili e in quanto tempo le parti si coordinano.
Questa chiarezza dovrebbe entrare nella selezione e nel rinnovo dei servizi SaaS. Le domande non riguardano soltanto la presenza di MFA o SSO, ma anche la configurabilità dei tempi di validità, l’esportazione della telemetria, la rotazione delle chiavi, la revoca globale e la capacità di ricostruire le azioni compiute durante una sessione sospetta.
Sei controlli da portare nella pratica
Il primo controllo è ridurre durata e privilegi. Il rapporto indica come riferimento token di identità e accesso con validità non superiore a un’ora, pur chiedendo che la durata sia configurabile in base al rischio. Non è un valore universale da copiare: un’operazione amministrativa e una consultazione a basso impatto non hanno lo stesso profilo. Il principio è evitare token più longevi o più potenti del necessario.
Il secondo è vincolare il token al destinatario e, quando possibile, al mittente. Ogni token dovrebbe dichiarare in modo esplicito l’audience prevista; le applicazioni devono rifiutare audience mancanti o errate. Tecniche come mTLS o DPoP possono inoltre ridurre il rischio che un token rubato venga riutilizzato da un soggetto diverso da quello autorizzato.
Il terzo è proteggere e separare le chiavi di firma. Generazione, conservazione, uso, rotazione e revoca delle chiavi devono essere proporzionati alla criticità del sistema. L’isolamento può essere hardware, virtualizzato o software: ciò che conta è il risultato di sicurezza, la limitazione degli accessi e la possibilità di reagire a una compromissione senza improvvisare.
Il quarto è progettare la revoca prima dell’incidente. Nei sistemi stateless la revoca immediata e globale non è sempre semplice. L’organizzazione deve sapere se può invalidare una singola sessione, tutti i token di un’identità o una chiave compromessa, e quanto tempo impiega il segnale a raggiungere le applicazioni. Senza questa prova, “abbiamo disabilitato l’account” può essere una rassicurazione incompleta.
Il quinto è monitorare il contesto d’uso. Geolocalizzazione, dispositivo, velocità degli spostamenti, sequenze di accesso e cambi improvvisi di privilegi possono rivelare un riuso anomalo. È la continuità del controllo che collega la guida alla logica zero trust descritta dal NIST SP 800-207: nessuna sessione deve diventare affidabile per inerzia.
Il sesto è registrare gli eventi senza trasformare i log in un nuovo archivio di segreti. L’IR 8587 suggerisce di tracciare tipo di token, emittente, scope, identificativi opportunamente offuscati, audience ed eventi come emissione, rinnovo, accettazione, rifiuto e revoca. Il token completo e i dati personali contenuti al suo interno non devono finire nei log. Per le organizzazioni più piccole, la guida CISA sul logging offre un punto di partenza: attivare, centralizzare e monitorare gli eventi ad alto rischio.
Dalla configurazione al test di crisi
Una revisione efficace non si chiude con uno screenshot del pannello IAM. Serve un test end-to-end. Si può partire da una sessione di prova, revocarla e osservare se l’accesso viene davvero negato su posta, documenti, amministrazione cloud e API. Poi occorre verificare che l’evento raggiunga il sistema di monitoraggio, che un alert venga generato e che il team sappia ricostruire le azioni compiute.
Lo stesso vale per il cambio di ruolo e l’uscita di una persona dall’organizzazione. Disabilitare l’account nel directory service non dimostra automaticamente che tutti i token, i refresh token, le sessioni mobili e le integrazioni siano cessati. Il processo di offboarding deve includere una prova della revoca e una verifica delle applicazioni più critiche.
Anche i contratti devono sostenere il test: disponibilità dei log, tempi di notifica, assistenza forense, modalità di rotazione delle chiavi e responsabilità in caso di compromissione non possono emergere per la prima volta durante un incidente.
Agenti AI e crittografia post-quantum: due cantieri da seguire
La versione finale introduce considerazioni di alto livello sugli agenti AI e sulla migrazione post-quantum, ma non pretende di risolvere entrambi i temi. Gli agenti software usano sempre più spesso token per accedere a dati, strumenti e API. La pagina NCCoE dedicata a identità e autorizzazione degli agenti AI evidenzia il rischio legato a sistemi capaci di compiere azioni con supervisione limitata.
La domanda operativa diventa quindi: quale identità ha l’agente, chi gli ha delegato l’autorità, quali scope possiede, per quanto tempo e come si interrompe l’accesso? Usare un token personale o un segreto condiviso per alimentare un agente rende più difficile separare responsabilità, revocare selettivamente e attribuire le azioni.
Sul fronte post-quantum, invece, il punto è inventariare algoritmi, chiavi, librerie e dipendenze che sostengono firma e verifica dei token. Non significa sostituire tutto immediatamente, ma rendere possibile una migrazione governata quando standard, prodotti e profilo di rischio lo richiederanno.
Il controllo delle identità continua dopo il login
La lezione dell’IR 8587 è concreta: SSO e cloud semplificano l’esperienza, ma concentrano fiducia in token, chiavi e servizi di identità. La sicurezza nasce dalla capacità di limitare quella fiducia, osservarla e ritirarla rapidamente.
Posso aiutarti a mappare i flussi di identità, verificare configurazioni e responsabilità tra azienda e fornitori e costruire test di revoca e monitoraggio coerenti con il rischio. Contattami, seguimi o scrivimi per approfondire il tema con un approccio operativo.
Nota di trasparenza: questo contenuto, sia testuale sia visivo, è stato realizzato in parte con l’ausilio di strumenti di intelligenza artificiale, con revisione e controllo umano.