Il ciclo di vita dell’identità come superficie d’attacco

Il Multi-Factor Authentication (MFA), o autenticazione a più fattori, diventato un requisito essenziale in molti contesti, copre solo una piccola parte del ciclo di vita di un’identità digitale.

Le fasi di enrollment, recovery e sessione dipendono da controlli di natura diversa e proprio su queste si sta concentrando l’attenzione degli attaccanti. Ecco la gap analysis, le contromisure applicabili e ciò che NIS2, DORA ed eIDAS 2.0 richiedono concretamente in termini di requisiti di compliance.

Un errore di categoria

Nel mondo aziendale, l’adozione dell’MFA è ormai uno standard e questo è già un buon risultato.

Non lo è, invece, l’interpretazione che si è consolidata attorno a questo risultato. Il claim amr: [“mfa”] all’interno di un token, o la colonna “MFA satisfied” in un report di conditional access, vengono letti come prova dell’identità dell’utente e come garanzia che la sessione sia legittima.

Il meccanismo di autenticazione non supporta nessuna delle due affermazioni.
Un’autenticazione riuscita attesta che qualcuno ha dimostrato di avere il controllo degli authenticator associati a un account nell’istante in cui la verifica è avvenuta.

La corrispondenza tra la persona in questione e l’utente per cui l’account è stato creato dipende da un legame stabilito in precedenza in fase di enrollment e che potrebbe essere stato impostato in modo errato o modificato successivamente.

Inoltre, il fatto che la sessione emessa resti sotto il controllo dello stesso soggetto dipende da un insieme di condizioni completamente diverso.

Le criticità emerse in fase di esercizio sono tre: la prima riguarda l’identità della persona, ovvero con quale rigore la sua identità reale sia stata verificata e associata all’account; la seconda riguarda il controllo degli authenticator richiesti, a cui risponde l’MFA; la terza riguarda il comportamento dell’identità dopo il login e nessun sistema di autenticazione è in grado di gestirlo.

È quindi opportuno riformulare la domanda operativa. “L’utente ha superato l’MFA?” è una verifica dello stato e, in quanto tale, fornisce una risposta stabile nel tempo.
Quella di cui abbiamo bisogno in esercizio è di altro tipo: Quanto possiamo fidarci, in questo momento, che dietro l’identità ci sia ancora la persona legittima? Le due formulazioni della domanda conducono a controlli e telemetrie differenti.

La tassonomia del NIST SP 800-63-4

Le Digital Identity Guidelines del NIST hanno abbandonato il modello del Level of Assurance unico già con la revisione 3 del 2017; la rev. 4, pubblicata a luglio 2025, conferma e migliora la struttura dell’assurance su tre dimensioni ortogonali: IAL (Identity Assurance Level), che misura il rigore con cui è stata verificata l’identità reale e associata all’account (SP 800-63A-4); AAL (Authenticator Assurance Level), che misura la resistenza della procedura di autenticazione (SP 800-63B-4); FAL (Federation Assurance Level), relativo alla robustezza delle asserzioni negli scenari federati (SP 800-63C-4).

L’ortogonalità ha una conseguenza pratica che spesso sfugge in fase di progettazione. Un sistema può operare con AAL3 e IAL1, ovvero applicare un authenticator hardware resistente al phishing a un’identità di cui nessuno ha mai verificato la corrispondenza con una persona reale.

La configurazione non è incompatibile, e infatti nessun controllo automatico la segnala.

La crittografia (per FIDO2 esiste persino un’analisi di sicurezza dimostrabile: Barbosa et al., CRYPTO 2021) protegge in modo impeccabile un binding che potrebbe essere errato.

Inoltre la rev. 4 introduce metriche di continuous evaluation, trattando l’assurance come una grandezza da riesaminare nel tempo anziché come un valore assegnato inizialmente e valido finché l’account esiste.

La superficie d’attacco si è spostata

Lo scenario di difesa più diffuso prevede che l’attaccante si trovi al di fuori del confine di autenticazione con l’obiettivo di romperlo.

Gli attaccanti più sofisticati hanno smesso di provare a superare l’authenticator e cercano piuttosto di ottenerne uno.

Recovery come percorso di downgrade

La principale evidenza di questo fenomeno è riscontrabile nell’advisory CISA/FBI AA23-320A, aggiornato a luglio 2025 con TTP raccolte fino a giugno precedente.

Il modello di attacco ricorrente non richiede l’uso di exploit, in quanto gli aggressori si fingono dipendenti dell’azienda presso l’help desk per ottenere il reset delle credenziali e il trasferimento dell’MFA su un dispositivo sotto il loro controllo.

Inoltre, in seguito, registrano i propri token MFA (T1556.006, T1606) per consolidare la persistenza.

In alcune campagne è stato aggiunto un identity provider federato al tenant SSO della vittima, con account linking automatico (T1484.002), ottenendo la possibilità di autenticarsi come qualunque utente.

Si tratta di un attacco che opera interamente al livello FAL e che nessun controllo AAL è in grado di intercettare.

A queste tecniche si affiancano quelle di aggiramento, dal push bombing (T1621) al SIM swap per intercettare gli OTP (T1111).

Questa tecnica è già stata dimostrata: Ulqinaku e altri (USENIX Security ’21) hanno condotto un esperimento in cui hanno verificato che l’immunità al phishing garantita da FIDO può essere compromessa se l’utente viene indotto a utilizzare un metodo alternativo.

Nel loro studio, il 55% dei partecipanti è caduto vittima di phishing in tempo reale e un ulteriore 35% si è rivelato potenzialmente vulnerabile agli attacchi di downgrade.

La ragione è strutturale, dal momento che quasi tutti i deployment mantengono percorsi di fallback (nel 2021, tutti i primi 100 siti per traffico che supportavano FIDO2 consentivano di scegliere un metodo di autenticazione alternativo).

Gli studi

I ricercatori Kunke, Wiefling, Ullmann e Lo Iacono hanno testato dodici strategie di recupero dell’account per l’autenticazione senza password FIDO2, senza trovarne nessuna pienamente soddisfacente e rilevando, fra l’altro, che diverse reintroducono la password.

Ghorbani Lyastani (IEEE S&P 2020) aveva già individuato il recovery at scale come il principale ostacolo all’adozione.

Uno studio successivo ha rilevato che oltre il 60% degli intervistati considera l’account recovery come il gap più serio nell’integrazione di FIDO2.

Regola di progettazione da inserire nelle policy

Da questi esempi si ricava una regola di progettazione che andrebbe inserita nelle policy.

La resistenza dell’insieme coincide con quella del percorso più debole che consente di sostituire l’authenticator.

Un tenant che opera in modalità passwordless e che mantiene attivo il reset via SMS, dal punto di vista dell’assurance reale, opera al livello dell’SMS.

Si aggiunge un caso limite spesso trascurato. Lo studio di Sudhodanan e Paverd sull’account pre-hijacking (USENIX Security ’22) mostra che il binding può essere compromesso prima ancora dell’enrollment legittimo, sfruttando le vulnerabilità del processo di creazione dell’account.

Anche in questo scenario, l’autenticazione successiva funziona come previsto.

Le contromisure sul lifecycle

In questa fase, le contromisure più efficaci sono di tipo organizzativo e architetturale. Il reset deve essere collegato a una nuova verifica dell’identità che non si basi su fattori di conoscenza.

Le informazioni come la data di nascita, il numero di matricola, l’ultimo cedolino e il nome del responsabile, infatti, possono essere ricavate tramite OSINT o da un precedente data breach.

Per gli account privilegiati, ha senso effettuare una verifica documentale con liveness detection o un riconoscimento su un canale video già registrato. I fallback deboli devono essere chiusi anche quando restano attivi solo in modalità di recupero.

Semplicemente, un metodo non accettabile per l’accesso non può essere utilizzato per riottenerlo.

È opportuno consentire la registrazione di nuovi authenticator solo da endpoint gestiti e conformi, bloccando le registrazioni provenienti da ASN o geolocalizzazioni anomale e attivandole in modo differito, con notifica sui canali già registrati, in modo che il titolare legittimo disponga di un lasso di tempo utile per rifiutare.

Dal punto di vista organizzativo, chi esegue un reset non deve poter elevare i propri privilegi; i tier amministrativi richiedono una doppia approvazione e gli script di verifica non devono poter essere aggirati invocando l’urgenza.

Il personale dell’help desk deve ricevere lo stesso trattamento riservato alle utenze privilegiate: MFA resistente al phishing e privilegi non permanenti.

Gap post-autenticazione

Il secondo fattore di rischio è temporale. L’autenticazione stabilisce un rapporto di fiducia immediato, mentre la sessione che ne deriva può durare ore o giorni.

Tra le tecniche di attacco, il furto di cookie di sessione (T1539), il replay di token di accesso applicativi (T1550.001), il phishing di autorizzazioni OAuth e gli infostealer che esfiltrano cookie da endpoint compromessi, consentono all’attaccante di ottenere una sessione già autenticata senza che venga emesso alcun ulteriore prompt MFA.

Dal punto di vista dell’IdP non c’è nulla da autenticare, perché la verifica è avvenuta con successo.

Tre famiglie di controlli sotto il profilo difensivo

Dal punto di vista difensivo, si combinano tre famiglie di controlli.

La prima lega il token al detentore. Il passaggio da bearer token a proof-of-
possession azzera il valore del token rubato tramite DPoP (RFC 9449), access token mTLS-bound o implementazioni proprietarie di token protection device-bound.

Tra le contromisure elencate, questa offre il miglior rapporto tra efficacia e complessità, pertanto è consigliabile darle la priorità per le applicazioni che espongono dati critici.

La seconda riduce la durata utile del token. TTL brevi hanno senso solo se il refresh comporta una rivalutazione delle condizioni, dato che un refresh token a lunga scadenza rinnovato senza policy evaluation annulla il beneficio.

Invece, la terza propaga gli eventi di rischio, ed è il tassello che fino a poco tempo fa mancava nel panorama degli standard.

Specifiche finali della OpenID Foundation

Nel settembre 2025, la OpenID Foundation ha approvato come specifiche finali lo Shared Signals Framework (SSF) 1.0, il Continuous Access Evaluation Profile (CAEP) 1.0 e il RISC 1.0. SSF definisce il trasporto asincrono dei Security Event Token fra transmitter e receiver, mentre CAEP definisce i tipi di evento che descrivono cambiamenti delle sessioni attive, fra cui session-revoked, credential-change e device-compliance-change.

Storicamente i sistemi federati non disponevano di alcun canale per ricevere
aggiornamenti di sicurezza dopo il login iniziale.

L’IdP poteva revocare l’autorizzazione, ma la relying party continuava a gestire la sessione.

CAEP chiude quel canale e l’infrastruttura che rende possibile l’autenticazione continua, come previsto dalle normative europee.

Al di sopra di questi controlli si colloca il livello di correlazione, che il mercato
etichetta come Identity Threat Detection and Response. Raramente il segnale forte è rappresentato da un singolo evento.

Un reset presso l’help desk seguito, entro pochi minuti, dalla registrazione di un nuovo authenticator, da un login proveniente da un dispositivo sconosciuto, dal consent grant di un’applicazione OAuth di terze parti e dalla creazione di una regola di inoltro sulla casella di posta elettronica costituisce una firma di account takeover, anche se ogni singolo evento, preso singolarmente, risulta legittimo e frequente.

Le detection rule efficaci, piuttosto che concentrarsi sul singolo predicato, descrivono quindi la finestra temporale e la concatenazione degli eventi.

Cosa chiede la compliance europea

Le tre principali norme che insistono sul perimetro dell’identità provengono da direzioni diverse e, nel loro insieme, rispondono a tutte e tre le domande iniziali.

NIS2

L’articolo 21, paragrafo 2, lettera j) della Direttiva (UE) 2022/2555 richiede, se
del caso, l’uso di soluzioni di autenticazione a più fattori o di autenticazione continua, nonché di comunicazioni vocali, video e testuali protette e di sistemi di comunicazione di emergenza protetti.

La disgiunzione tra i primi due termini è comunemente interpretata come una facoltà di scelta, tuttavia, nel contesto dell’approccio all-hazards e risk-based dell’intero articolo 21, è più difendibile interpretarla come due controlli che coprono finestre temporali diverse.

Il Regolamento di esecuzione (UE) 2024/2690 traduce l’elenco in controlli verificabili per gli operatori del settore digitale e la prassi di vigilanza converge sull’autenticazione resistente al phishing per gli accessi remoti e amministrativi.

DORA

L’articolo 9 del Regolamento (UE) 2022/2554 impone l’autenticazione forte. I
dettagli prescrittivi sono contenuti nell’RTS (Regolamento delegato (UE) 2024/1774), in vigore dal 15 luglio 2024 e successivamente rettificato con un corrigendum il 15 maggio 2025.

L’articolo 20 impone l’adozione di politiche di gestione dell’identità che garantiscano l’identificazione univoca e l’autenticazione delle persone fisiche e dei sistemi, nonché la gestione dell’intero ciclo di vita e la conservazione dei record di tutte le assegnazioni di identità.

Inoltre, l’articolo 21 disciplina il controllo degli accessi, imponendo l’autenticazione forte per gli accessi privilegiati e per i sistemi a supporto di funzioni critiche o importanti e includendo nel perimetro di protezione anche gli account di servizio.

Infine, l’articolo 20 si riferisce più a un processo e alla relativa documentazione che all’attivazione di un controllo di accesso.

In sede ispettiva, la domanda non riguarda l’attivazione dell’MFA, ma chi ha ottenuto quale identità, su approvazione di chi, con quale metodo di verifica e quando è stata eventualmente revocata, con quale SLA.

eIDAS 2.0

Il Regolamento (UE) 2024/1183 è l’unico dei tre a incidere sulla prima delle tre domande.

Gli Stati membri devono rendere disponibile almeno un EUDI Wallet certificato entro la fine del 2026, ma i livelli di readiness nazionale sono molto diversi tra loro, mentre i soggetti privati dei settori regolamentati dovranno accettarlo l’anno successivo.

L’architettura tecnica è definita dall’Architecture and Reference Framework e da una serie di atti di esecuzione.

Per chi progetta IAM, il Wallet metterà a disposizione, per la prima volta su scala europea, uno strumento di identity proofing ad alto livello di garanzia, utilizzabile anche nei flussi di recovery e re-enrollment, proprio dove oggi si ricorre a fattori di conoscenza e al giudizio di un operatore telefonico. Integrarlo come ennesimo metodo di accesso significherebbe sprecare la sua caratteristica più interessante.

Un modello operativo: l’assurance tarata sull’evento

La sintesi implementabile consiste nel considerare l’identity confidence come una funzione del tempo e degli eventi, collegando le soglie di assurance alla criticità dell’operazione anziché alla sessione che la ospita.

Durante la fase di onboarding, il livello IAL di riferimento per la popolazione considerata viene stabilito mediante la verifica dei documenti, la liveness detection e la validazione delle prove.

Si tratta del momento in cui il costo di una verifica rigorosa è giustificato, in quanto su di essa si basa tutto il resto.

L’enrollment di un authenticator è un’estensione di quel proofing: può essere ammesso solo a partire da un’identità già verificata e da un endpoint gestito e conforme, e richiede un audit trail dedicato, distinto da quello degli eventi di login.

Per il login ordinario è necessario AAL2 come soglia minima e un authenticator resistente al phishing (la resistenza al phishing è un requisito di AAL3, ma nulla vieta di adottarla come standard anche per i livelli inferiori).

Sono inoltre necessari FIDO2/WebAuthn e i fallback deboli devono essere disattivati, inclusi quelli raggiungibili solo in modalità di recupero. L’elevazione dei privilegi e l’accesso ai dati critici richiedono una reautenticazione step-up e, quando possibile, un token legato all’utente tramite DPoP o mTLS.

Il trattamento più rigido spetta ai due eventi che il modello classifica come routine amministrativa.

Il reset della password o dell’MFA deve essere gestito come un nuovo proofing, con verifica out-of-band e doppia approvazione sui tier privilegiati, e non come un controllo sui fattori di conoscenza.

La registrazione di un nuovo dispositivo prevede la notifica al titolare sui canali già registrati e l’attivazione differita, in modo che una registrazione fraudolenta possa essere contestata prima di diventare operativa.

Un segnale di rischio ricevuto a sessione aperta deve infine essere trattato come motivo di revoca.

Il re-prompt che l’attaccante può soddisfare, perché controlla già l’authenticator che ha registrato, non riduce il rischio in alcun modo: è per questo che CAEP prevede la session-revoked fra i tipi di evento propagabili alle relying party.

Implicazioni per la detection e l’incident response

Durante l’analisi post-incidente, spesso emerge una conseguenza pratica.

I log di autenticazione, presi singolarmente, non permettono di ricostruire un caso di takeover dell’account, in quanto mostrano un login conforme alla policy da parte di un utente valido.

La ricostruzione richiede la correlazione di sorgenti che spesso presentano owner, formati e tempi di conservazione differenti: audit trail degli eventi relativi al ciclo di vita dell’authenticator (registrazione, sostituzione, eliminazione), ticket dell’help desk temporalmente correlati agli eventi dell’IdP, log di registrazione dei dispositivi e di conformità, autorizzazioni OAuth, modifiche alle policy di accesso condizionale e alla configurazione di federazione, binding e riuso dei token di sessione.

Da tutto ciò conseguono tre suggerimenti: la retention di queste fonti deve essere allineata a quella prevista per i record di identità, considerando che l’RTS ne impone la conservazione anche dopo la fine del rapporto contrattuale.

Per i ticket dell’help desk è necessario un export in un formato correlabile per timestamp e user principal name, in quanto la prova di social engineering risiede in questi ticket e non nell’IdP.

Infine, è opportuno verificare in sede di esercitazione che la timeline di un ATO simulato sia effettivamente ricostruibile con le fonti raccolte; nella maggior parte dei casi, la prima esercitazione dimostra il contrario.

Il ciclo di vita per l’identità digitale come superficie d’attacco

L’MFA assolve bene il compito per cui è stato progettato, ovvero verificare che qualcuno controlli gli authenticator richiesti.

Tuttavia, non è in grado di stabilire se la persona che controlla gli authenticator sia stata correttamente identificata al momento del binding, se un processo di recovery sia stato manipolato o se la sessione emessa a valle si trovi ancora nelle mani di chi l’ha ottenuta.

La soluzione operativa a questo limite non è complessa, in quanto il perimetro scoperto può essere mappato.

La base da cui partire è rappresentata dall’inventario dei percorsi che permettono di aggiungere o sostituire un authenticator: il recovery self-service, le procedure di help desk, i portali di enrollment, il provisioning MDM.

Per ciascuno di essi, si annota quale verifica dell’identità ipotizza e quale livello di autenticazione consente di raggiungere; i punti in cui il secondo valore supera il primo rappresentano le strade che un attaccante proverà per prime.

Contromisure

Tra le priorità immediate, alcune contromisure danno risultati nel breve periodo: la chiusura dei fallback deboli anche nei soli flussi di recovery, l’attivazione differita con notifica per ogni nuovo dispositivo, uno script di verifica per l’help desk in grado di reggere alla pressione dell’urgenza e il passaggio a token con proof-of-possession per le applicazioni più esposte.

Nessuna di queste misure richiede l’utilizzo di nuove piattaforme e ciascuna di esse elimina una tecnica documentata nell’advisory AA23-320A.

A lungo termine, l’investimento che offre il rendimento migliore è la telemetria: elevare l’identity confidence a metrica interna, alimentata dagli eventi del ciclo di vita, e misurare il tempo che intercorre tra un segnale di rischio e la revoca effettiva delle sessioni.

La propagazione dei segnali fra domini, con le specifiche SSF e CAEP ormai definitive e il supporto dimostrato dall’interoperabilità, possiede i requisiti per diventare un progetto pianificabile.

Un progetto pilota che coinvolga un Identity Provider (IdP) e due o tre applicazioni Software as a Service (SaaS) di punta è sufficiente per uscire dal modello binario senza dover attendere la piena maturità dell’ecosistema.

Inoltre, chi sta ridisegnando i processi di recovery e re-enrollment ha interesse a prevedere fin d’ora il punto di innesto dell’EUDI Wallet che, entro la fine del 2026, consentirà di ottenere un elevato livello di garanzia per l’identity proofing su scala europea.

La dimensione organizzativa

Il ciclo di vita dell’identità rientra nel registro dei rischi e nei playbook di incident response.

Gli obblighi europei sopra descritti fissano una soglia minima e lasciano all’organizzazione l’onere di motivare le proprie scelte: superarla, quando il rischio lo giustifica, per esempio adottando la resistenza al phishing come standard anche sotto AAL3, oggi costa meno di quanto costerebbe dopo il primo incidente.

Il rischio per chi progetta e gestisce infrastrutture di identità è quello di chiedere all’MFA risposte al di fuori del suo ambito e di costruire su queste risposte una fiducia che l’attaccante ha imparato a sfruttare.

Riferimenti

• NIST SP 800-63-4, Digital Identity Guidelines, e volumi 63A-4, 63B-4, 63C-4, luglio 2025.
• Direttiva (UE) 2022/2555 (NIS2), art. 21; Regolamento di esecuzione (UE)
  2024/2690.
• Regolamento (UE) 2022/2554 (DORA), art. 9; Regolamento delegato (UE)
  2024/1774, artt. 20 e 21.
• Regolamento (UE) 2024/1183 (eIDAS 2.0) e Architecture and Reference
  Framework.
• OpenID Foundation, Shared Signals Framework 1.0, Continuous Access
  Evaluation Profile 1.0, RISC 1.0, Final Specifications, settembre 2025.
• IETF RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP).
• CISA/FBI, advisory AA23-320A, aggiornamento luglio 2025.
• E. Ulqinaku, H. Assal, A. Abdou, S. Chiasson, S. Capkun, “Is Real-time Phishing Eliminated with FIDO? Social Engineering Downgrade Attacks against FIDO Protocols”, USENIX Security Symposium, 2021.
• J. Kunke, S. Wiefling, M. Ullmann, L. Lo Iacono, “Evaluation of Account
  Recovery Strategies with FIDO2-based Passwordless Authentication”, Open Identity Summit 2021, pp. 59-70.
• S. Ghorbani Lyastani, M. Schilling, M. Neumayr, M. Backes, S. Bugiel, “Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless Authentication”, IEEE Symposium on Security and Privacy, 2020.
• A. Sudhodanan, A. Paverd, “Pre-hijacked Accounts: An Empirical Study of
  Security Failures in User Account Creation on the Web”, USENIX Security
  Symposium, 2022.
• M. Barbosa, A. Boldyreva, S. Chen, B. Warinschi, “Provable Security Analysis of FIDO2”, CRYPTO 2021.
• D. Kuchhal, M. Saad, A. Oest, F. Li, “Evaluating the Security Posture of Real-
  World FIDO2 Deployments”, ACM CCS 2023, pp. 2381-2395.
• M. Kepkowski, M. Machulak, I. Wood, D. Kaafar, “Challenges with Passwordless FIDO2 in an Enterprise Setting: A Usability Study”, IEEE Secure Development Conference (SecDev), 2023, arXiv:2308.08096.