NIST SP 800-63-4: evidenze su password, MFA e passkey

Alle 08:10 di un lunedì, il Chief Information Security Officer (CISO) di una fintech riceve il messaggio che ogni responsabile della sicurezza teme: “Abbiamo accessi sospetti al portale amministrativo dell’area finanziaria. La MFA è stata approvata, ma l’utente afferma di non essere stato lui.”

Alle 08:25, il SOC individua lo schema. L’attaccante non ha violato la cifratura, sfruttato uno zero-day o aggirato un firewall. Ha sottratto una password tramite phishing, ha generato una richiesta push e ha atteso l’affaticamento dell’utente. Una sola approvazione è stata sufficiente. L’account disponeva di accessi elevati agli export di fatturazione dei clienti, ai log di audit e a una dashboard di regolamento di una terza parte.

Alle 09:00, la funzione legale chiede se si tratti di una violazione dei dati personali ai sensi del GDPR. Il team Risk chiede se l’evento attivi obblighi di segnalazione DORA. Il consiglio di amministrazione vuole sapere se l’affermazione aziendale “MFA ovunque” fosse effettivamente vera. L’auditor ISO 27001, già pianificato per il mese successivo, ora richiede evidenze di autenticazione sicura, controllo degli accessi, logging e azioni correttive.

Questo è il motivo per cui NIST SP 800-63-4 è rilevante nel 2026.

Per CISO, responsabili della conformità e owner di business, NIST SP 800-63-4 non è semplicemente un altro documento sull’identità. Sta diventando il riferimento pratico per una moderna politica sulle password, MFA resistente al phishing, passkey, autenticazione passwordless e governance del ciclo di vita degli autenticatori. La vera difficoltà non è leggere la guida. La difficoltà è dimostrarne l’applicazione rispetto alle aspettative di ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 e audit interno.

La posizione di Clarysec è semplice: i controlli di identità falliscono quando sono trattati come impostazioni tecniche e non come governance. Password, MFA, passkey, flussi di ripristino, token di sessione, accessi privilegiati, account di servizio e log di autenticazione devono essere progettati come un unico sistema di controllo in grado di produrre evidenze.

Questa è la prospettiva utilizzata in Zenith Blueprint: roadmap in 30 passi per auditor, nella libreria di politiche Clarysec e in Zenith Controls: la guida alla conformità incrociata. Zenith Controls non crea nuovi controlli. Mappa le aspettative di controllo di ISO/IEC 27001:2022 e ISO/IEC 27002:2022 rispetto ad altri standard, normative e prospettive di audit, in modo che le organizzazioni possano evitare evidenze frammentate e attività di conformità duplicate.

“MFA abilitata” non è una risposta di audit

Molte organizzazioni hanno affrontato gli ultimi anni credendo che l’implementazione della MFA chiudesse la discussione sul rischio identità. Nel 2026, questa ipotesi non è più sicura.

Auditor e autorità di regolamentazione pongono oggi domande più puntuali:

• La MFA è applicata per tutti gli accessi privilegiati, remoti e ad alto rischio?
• L’autenticazione è resistente al phishing dove il rischio lo richiede?
• Le passkey o gli autenticatori FIDO2 sono governati tramite registrazione, ripristino, revoca e ciclo di vita del dispositivo?
• Le password sono verificate rispetto a elenchi di credenziali compromesse e comuni?
• Le modifiche delle password sono attivate da una compromissione anziché da una rotazione periodica arbitraria?
• Gli utenti possono incollare password dai gestori di password?
• Gli eventi degli autenticatori sono registrati e riesaminati?
• I flussi di recupero degli account sono robusti quanto i flussi di accesso?
• I secret API, i token OAuth, le chiavi SSH e le credenziali degli account di servizio sono controllati con la stessa disciplina?

NIST SP 800-63-4 orienta le organizzazioni verso una garanzia dell’identità digitale basata sul rischio, robustezza degli autenticatori ed evidenze del ciclo di vita. Per la modernizzazione delle password, ciò significa abbandonare prassi obsolete, come la modifica periodica forzata delle password in assenza di indicazioni di compromissione, rafforzando al contempo lunghezza, verifica rispetto a password compromesse, limitazione della frequenza delle richieste, archiviazione sicura e controlli di ripristino. Per MFA e passkey, significa concentrarsi sul livello di garanzia dell’autenticatore, sulla resistenza al phishing, sulla registrazione sicura, sull’associazione all’account, sulla revoca e sulla verificabilità.

Zenith Blueprint descrive questo cambiamento in Controls in Action, Step 19, Technological Controls I, trattando l’autenticazione sicura:

L’autenticazione è la prima e più critica linea di difesa tra un attore della minaccia e i vostri sistemi, dati e servizi. Se l’autenticazione è debole, tutto il resto — cifratura, monitoraggio, segmentazione — può essere aggirato. Il controllo 8.5 garantisce che i meccanismi di autenticazione siano progettati in modo sicuro, applicati in modo coerente e resistenti ai metodi di attacco noti.

Questa frase è il cuore dell’audit sull’identità nel 2026. La domanda non è più “Avete password e MFA?”. La domanda è “Potete dimostrare che la vostra architettura di autenticazione è basata sul rischio, resistente ai metodi di attacco noti, applicata in modo coerente e monitorata?”.

Costruire il sistema di controllo attorno a identità, informazioni di autenticazione e autenticazione sicura

Il modo più utile per tradurre NIST SP 800-63-4 in evidenze ISO/IEC 27001:2022 è trattare l’identità come un sistema di controlli connessi.

Attraverso Zenith Controls, Clarysec identifica tre aree di controllo centrali di ISO/IEC 27002:2022 per l’allineamento a NIST SP 800-63-4: 5.16 Identity management, 5.17 Authentication information e 8.5 Secure authentication. Nell’Annex A di ISO/IEC 27001:2022, queste corrispondono a A.5.16, A.5.17 e A.8.5.

La distinzione è importante. A.5.16 chiede: “Chi dispone di un’identità?”. A.5.17 chiede: “Come viene protetta la prova di tale identità?”. A.8.5 chiede: “Come viene eseguita in modo sicuro l’autenticazione nei sistemi?”.

Quando le organizzazioni non superano gli audit, spesso accade perché implementano un livello senza gli altri. Distribuiscono passkey, ma non sono in grado di mostrare evidenze di revoca. Applicano la MFA, ma non a una console amministrativa legacy. Definiscono regole per le password, ma non effettuano la verifica rispetto a password compromesse. Disabilitano un account utente, ma dimenticano sessioni attive o token di recupero.

In Zenith Blueprint, Controls in Action, Step 22, Organizational controls, Clarysec spiega A.5.17 come tema di ciclo di vita:

Se l’identità è la domanda “Chi sei?”, allora l’autenticazione è la prova. Il controllo 5.17 è il punto in cui la teoria incontra la fiducia. Richiede che le informazioni di autenticazione siano gestite in modo sicuro lungo l’intero ciclo di vita, assicurando che i metodi e le credenziali usati per verificare l’identità non diventino a loro volta l’anello più debole.

Una passkey non è conforme solo perché esiste. Diventa difendibile quando è possibile mostrare come viene registrata, associata, protetta, recuperata, revocata, registrata nei log e riesaminata.

Modernizzare le password senza perdere la tracciabilità di audit

Molte aziende hanno ancora politiche sulle password scritte per un modello di minaccia diverso. “Dodici caratteri, simboli, modifica ogni 90 giorni” è una formula familiare, ma la familiarità non equivale alla resilienza.

NIST SP 800-63-4 rafforza un approccio più moderno: password e passphrase più lunghe, verifica rispetto a password compromesse o di uso comune, limitazione della frequenza delle richieste, reset sicuro, nessuna modifica periodica arbitraria salvo sospetta compromissione e controlli orientati all’utente che supportano i gestori di password. Questo non significa che ogni organizzazione debba riscrivere tutte le politiche dall’oggi al domani. Significa che i requisiti relativi alle password devono essere basati sul rischio, applicati tecnicamente e riconciliati con le evidenze ISO 27001.

La libreria di politiche Clarysec per PMI offre alle organizzazioni più piccole una baseline pratica che può essere rafforzata con la maturazione. La Politica di gestione degli account utente e dei privilegi - PMI stabilisce:

Le password devono soddisfare requisiti di complessità (ad esempio, almeno 12 caratteri, alfanumerici con simboli) ed essere modificate almeno ogni 90 giorni.

È un punto di partenza utile e applicabile per le PMI. Tuttavia, un progetto di modernizzazione NIST SP 800-63-4 nel 2026 deve riesaminare se la scadenza fissa a 90 giorni resti appropriata per ciascun sistema, soprattutto quando sono in essere MFA, verifica rispetto a password compromesse, lunghezza robusta delle password e workflow di reset attivati da compromissione. In pratica, molte organizzazioni mantengono la baseline durante la transizione, quindi aggiungono un addendum di modernizzazione delle password approvato tramite trattamento del rischio e Dichiarazione di Applicabilità.

Per gli ambienti enterprise, la Politica di gestione degli account utente e dei privilegi di Clarysec fornisce un punto di aggancio di governance anziché codificare rigidamente ogni regola sulle password:

Tutti gli account utente devono applicare complessità e scadenza delle password in conformità alla Politica sulle password dell’organizzazione.

Questa formulazione consente al CISO di aggiornare la Politica sulle password per allinearla a NIST SP 800-63-4 senza riscrivere l’intero quadro di gestione degli accessi.

Un pacchetto pratico di evidenze per la modernizzazione delle password deve includere:

• Politica sulle password vigente e addendum di modernizzazione approvato.
• Configurazione dell’IdP che evidenzi lunghezza minima, lunghezza massima e caratteri consentiti.
• Evidenza che i gestori di password sono consentiti, inclusa la funzionalità di incolla ove rilevante.
• Configurazione della verifica rispetto a password compromesse, deboli e comuni.
• Politica di limitazione della frequenza delle richieste o di blocco per attacchi di guessing online.
• Workflow di reset password che richiede un’adeguata verifica dell’identità.
• Architettura di archiviazione degli hash delle password per le applicazioni che memorizzano credenziali.
• Registro delle eccezioni per sistemi legacy che non supportano impostazioni moderne.
• Procedura di reset attivata da compromissione con collegamento alla risposta agli incidenti.
• Evidenze di comunicazione e formazione agli utenti.

L’obiettivo non è vincere un dibattito su una specifica lunghezza della password. L’obiettivo è dimostrare che l’autenticazione tramite password è controllata, misurabile e integrata nel SGSI.

Spostare MFA e passkey da “secondo fattore” a livello di garanzia

L’incidente del lunedì mattina è iniziato con affaticamento da MFA. Per questo gli auditor chiedono sempre più spesso se la MFA sia resistente al phishing, non solo se sia presente.

I metodi MFA tradizionali, come SMS, OTP via e-mail, app TOTP e notifiche push, possono ridurre il rischio, ma non sono equivalenti. Le passkey e gli autenticatori FIDO2/WebAuthn offrono una maggiore resistenza al phishing perché l’autenticazione è vincolata all’origine legittima e utilizza crittografia a chiave pubblica. Per utenti ad alto rischio, amministratori privilegiati, approvatori dell’area finanziaria, sviluppatori con accesso all’ambiente di produzione e percorsi di accesso remoto, la MFA resistente al phishing deve essere considerata lo stato target, salvo eccezione documentata e approvata.

La Politica sulle comunicazioni sicure e sull’autenticazione a più fattori (MFA) enterprise di Clarysec definisce la baseline:

Autenticazione a più fattori (MFA): tutti gli accessi alla rete e ai sistemi informativi dell’organizzazione, in particolare gli accessi privilegiati o gli accessi remoti, devono richiedere l’autenticazione a più fattori (MFA) (ad esempio, password più token OTP o fattore biometrico). Le soluzioni di autenticazione a più fattori (MFA) devono essere allineate alle migliori pratiche del settore (ad esempio, codici temporanei basati sul tempo o chiavi hardware) e devono essere configurate per proteggere dagli accessi non autorizzati.

Per le PMI, la Politica di controllo degli accessi - PMI stabilisce:

Gli account privilegiati devono utilizzare l’autenticazione a più fattori (MFA) ove supportata.

La formula “ove supportata” offre alle PMI un percorso di implementazione realistico, ma crea anche un obbligo di audit. Se un sistema privilegiato non supporta la MFA, l’organizzazione deve documentare controlli compensativi quali restrizioni di rete, gestione degli accessi privilegiati, jump host, sessioni più brevi, monitoraggio, uso di vault e piano di migrazione.

Zenith Blueprint, Controls in Action, Step 19, è esplicito sulla direzione da seguire:

Ove possibile, l’autenticazione basata solo su password dovrebbe essere evitata, soprattutto per account amministrativi, console cloud, strumenti di accesso remoto e qualsiasi sistema esposto a Internet. La MFA, con un secondo fattore come una chiave hardware, un’app mobile o la biometria, è ormai una baseline, non un lusso.

Le passkey si inseriscono naturalmente in questa narrativa. Un rollout di passkey non deve essere presentato solo come un aggiornamento tecnologico. Deve essere documentato come un trattamento del rischio per phishing, credential stuffing, affaticamento da MFA, riutilizzo delle password e compromissione degli account.

Il modello di evidenze sulle passkey richiesto dagli auditor

Le passkey possono essere sincronizzabili, vincolate al dispositivo, supportate da hardware, basate su piattaforma o roaming, a seconda dell’autenticatore e dell’ecosistema. Il livello di garanzia dipende da registrazione, fiducia del dispositivo, ripristino, associazione all’account e revoca. Un progetto passkey privo di evidenze può creare ambiguità in audit anche quando la tecnologia è robusta.

Utilizzare questo modello per preparare un rollout di passkey pronto per l’audit.

Questo si allinea direttamente a ISO/IEC 27001:2022. Le clausole da 4.1 a 4.4 richiedono alle organizzazioni di comprendere contesto, parti interessate, campo di applicazione del SGSI e processi operativi. Le clausole da 5.1 a 5.3 richiedono leadership, politica, ruoli organizzativi e responsabilità. Le clausole 6.1.2 e 6.1.3 richiedono un processo ripetibile di valutazione del rischio per la sicurezza delle informazioni e trattamento del rischio, inclusi selezione dei controlli, confronto con l’Annex A, Dichiarazione di Applicabilità e approvazione del rischio residuo da parte del risk owner. La clausola 6.2 richiede obiettivi misurabili per la sicurezza delle informazioni.

Ciò significa che un rollout di passkey deve comparire nel SGSI come:

• Un trattamento del rischio per furto di credenziali e phishing.
• Un obiettivo, ad esempio “migrazione del 90 percento degli accessi privilegiati alla MFA resistente al phishing entro il Q3”.
• Una motivazione nella Dichiarazione di Applicabilità collegata a A.5.16, A.5.17 e A.8.5.
• Un aggiornamento della Politica di controllo degli accessi.
• Un caso d’uso di logging e monitoraggio.
• Un pacchetto di evidenze di audit.

In Zenith Blueprint, fase Risk Management, Step 13, Risk Treatment Planning and Statement of Applicability, Clarysec descrive la SoA come un ponte:

La SoA è di fatto un documento ponte: collega la vostra valutazione/trattamento del rischio ai controlli effettivamente presenti. Completandola, verificate anche di non aver omesso alcun controllo.

Per NIST SP 800-63-4, quel ponte è il punto in cui le decisioni su password, MFA e passkey diventano auditabili.

Mappatura cross-compliance per ISO 27001, NIS2, DORA, GDPR, NIST CSF e COBIT

Le evidenze sull’identità diventano potenti quando un unico insieme di controlli soddisfa più obblighi.

NIS2 Article 21 richiede agli enti essenziali e importanti di implementare misure tecniche, operative e organizzative appropriate e proporzionate, che riflettano rischio, stato dell’arte, costo di attuazione, dimensione e impatto degli incidenti. Article 21(2) include analisi dei rischi, politiche, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sviluppo sicuro, valutazione dell’efficacia dei controlli, igiene informatica e formazione, crittografia, sicurezza HR, controllo degli accessi, gestione degli asset e, ove appropriato, autenticazione a più fattori o continua. Article 20 rende l’approvazione della direzione, la vigilanza e la formazione sulla cibersicurezza un obbligo di governance.

DORA porta lo stesso tema dell’identità nella resilienza operativa digitale finanziaria. Gli enti finanziari soggetti al regolamento devono mantenere un quadro documentato di gestione del rischio ICT con responsabilità dell’organo di gestione, controlli di protezione e prevenzione, controllo degli accessi, autenticazione, monitoraggio, rilevamento delle anomalie, continuità, risposta, ripristino e formazione. Gli Articles da 8 a 10 sono particolarmente rilevanti per identificare asset e dipendenze ICT, proteggere i sistemi ICT, controllo degli accessi, autenticazione forte, monitoraggio e rilevamento. Gli Articles da 17 a 19 collegano le stesse evidenze alla gestione e segnalazione degli incidenti connessi alle ICT.

Il GDPR si applica ovunque siano trattati dati personali nel suo ambito territoriale e materiale. Article 5(1)(f) richiede che i dati personali siano trattati con adeguata sicurezza. Article 5(2) richiede accountability. Article 32 richiede misure tecniche e organizzative adeguate a garantire un livello di sicurezza appropriato al rischio. Una password sottratta o un autenticatore compromesso possono diventare una violazione dei dati personali se causano accesso non autorizzato a dati personali.

NIST CSF 2.0 aggiunge un utile livello di gestione. La sua funzione GOVERN richiede che i requisiti di cibersicurezza legali, normativi e contrattuali, inclusi gli obblighi privacy, siano compresi e gestiti. I CSF Profiles aiutano le organizzazioni a confrontare stato corrente e stato target e a creare piani d’azione prioritizzati.

COBIT 2019 e gli approcci di audit ISACA chiedono se i controlli di identità e accesso supportino gli obiettivi di governance, se le pratiche di gestione siano definite, se la robustezza dell’autenticazione sia coerente con il rischio e se il funzionamento del controllo sia evidenziato.

Lo stesso report di accesso condizionale dell’IdP può supportare il controllo degli accessi ISO 27001, la MFA NIS2, l’autenticazione DORA, l’accountability di sicurezza GDPR e i progressi del profilo target NIST CSF.

Costruire un pacchetto di evidenze sugli autenticatori in un pomeriggio

Un CISO, un responsabile della conformità o un referente IT può creare rapidamente un pacchetto di evidenze ad alto valore concentrandosi su un sistema ad alto rischio, come una console cloud, una piattaforma finanziaria, un portale amministrativo clienti o un ambiente di deployment in produzione.

Per prima cosa, definire l’ambito. Identificare il business owner, la classificazione dei dati, i gruppi utente, i ruoli privilegiati, i percorsi di accesso remoto, gli autenticatori correnti, i dati personali coinvolti e le dipendenze da terze parti. Questo supporta le clausole da 4.1 a 4.4 di ISO/IEC 27001:2022, perché campo di applicazione, requisiti delle parti interessate e dipendenze devono essere compresi.

In secondo luogo, acquisire le impostazioni di autenticazione correnti. Esportare o acquisire screenshot della politica sulle password, dell’applicazione della MFA, della configurazione passkey o FIDO2, delle regole di accesso condizionale, del timeout di sessione, dei metodi di recupero, degli account break glass e dello stato dell’autenticazione legacy. Se il sistema utilizza autenticazione locale, documentarne la motivazione e definire un percorso di migrazione.

In terzo luogo, confrontare rispetto a uno stato target chiaro:

• Password verificate rispetto a credenziali deboli, comuni e compromesse.
• Nessun accesso basato solo su password per sistemi privilegiati, remoti o esposti a Internet.
• MFA resistente al phishing per amministratori e utenti ad alto rischio.
• Registrazione e ripristino sicuri.
• Revoca degli autenticatori durante la cessazione o in caso di smarrimento del dispositivo.
• Logging di autenticazioni riuscite e fallite, uso della MFA e modifiche degli autenticatori.
• Alert per impossible travel, errori ripetuti, nuova registrazione di autenticatore e accessi rischiosi.

In quarto luogo, allegare le evidenze di policy. La Politica di controllo degli accessi - PMI richiede:

Sono richiesti nomi utente univoci; gli account condivisi sono vietati.

Per le evidenze sul ciclo di vita degli account, la Politica di gestione degli account utente e dei privilegi - PMI stabilisce:

I log di creazione degli account, disattivazione degli account e modifiche dei privilegi devono essere conservati in modo sicuro per almeno 12 mesi.

Per la registrazione dell’autenticazione, la Politica di registrazione e monitoraggio - PMI specifica:

Log di autenticazione: tentativi di accesso riusciti e falliti, durata della sessione, utilizzo della MFA

Per le implementazioni enterprise, la Politica di registrazione e monitoraggio richiede la registrazione di:

Tentativi di autenticazione e accesso degli utenti

In quinto luogo, aggiornare la Dichiarazione di Applicabilità. Contrassegnare A.5.16, A.5.17 e A.8.5 come applicabili e aggiungere note quali:

• Supporta le aspettative NIST SP 800-63-4 sul ciclo di vita degli autenticatori.
• Supporta le aspettative NIS2 Article 21 su controllo degli accessi e MFA.
• Supporta i requisiti DORA di gestione del rischio ICT relativi ad autenticazione e monitoraggio.
• Supporta GDPR Article 32 in materia di sicurezza e accountability per l’accesso ai dati personali.
• Eccezione: il portale legacy di regolamento non supporta FIDO2. I controlli compensativi includono restrizione VPN, monitoraggio delle sessioni privilegiate, piano di remediation del fornitore e riesame mensile degli accessi.

Infine, preparare una cartella denominata “Authentication Evidence Pack - Q2 2026” con estratti delle politiche, valutazione del rischio, registrazione del trattamento, estratto della SoA, configurazione dell’IdP, report di copertura MFA e passkey, elenco degli utenti privilegiati, registro delle eccezioni, log di registrazione e revoca, campione di test di cessazione, query SIEM, screenshot degli alert, estratto del playbook di risposta agli incidenti e comunicazione di sensibilizzazione agli utenti.

Questa è la differenza tra “usiamo la MFA” e “possiamo dimostrare la governance dell’autenticazione sicura”.

Come auditor diversi testeranno gli stessi controlli di identità

Un programma di identità maturo anticipa prospettive di audit differenti.

L’auditor ISO 27001 partirà dal sistema di gestione. Chiederà come sono stati valutati i rischi di identità, perché sono stati selezionati determinati controlli, come compaiono nella SoA, se le politiche sono approvate, se le responsabilità sono assegnate e se le evidenze mostrano il funzionamento nel tempo. Verificherà la coerenza tra registro dei rischi, Politica di controllo degli accessi, impostazioni dell’IdP e log.

Zenith Blueprint, fase Controls in Action, Step 19, Audit Checklist for Controls 8.1 to 8.5, descrive la richiesta pratica di audit:

Gli auditor chiederanno informazioni sulle impostazioni di complessità delle password e su come sono applicate (GPO Active Directory, politiche IdP, ecc.). Mostrate documentazione sul deployment della MFA, a chi si applica, dove è applicata e quali sistemi protegge.

Un auditor DORA o NIS2 si concentrerà su governance, resilienza e rischio sistemico. Potrebbe richiedere evidenze di vigilanza del consiglio di amministrazione o dell’organo di gestione, copertura dei sistemi critici, obblighi di autenticazione delle terze parti, test di continuità ed evidenza che le procedure di ripristino possano essere avviate solo da personale autenticato.

Un revisore GDPR si concentrerà sui dati personali. Chiederà se l’autenticazione protegge i dati personali da accessi non autorizzati, se l’accesso è limitato a quanto necessario, se i log supportano la valutazione dell’impatto della violazione e se l’organizzazione può dimostrare accountability.

Un assessor orientato a NIST può utilizzare i NIST CSF 2.0 Profiles per confrontare stato corrente e stato target. Vorrà un piano d’azione prioritizzato che copra governance, politica, controllo degli accessi, rilevamento ed esiti di risposta.

Un auditor COBIT 2019 o ISACA valuterà se le pratiche di identità e autenticazione supportano obiettivi di governance, progettazione del controllo, funzionamento del controllo, separazione dei compiti, accessi privilegiati e monitoraggio. Potrebbe non interessarsi al brand della passkey utilizzata. Gli interesserà che il controllo sia governato, misurato, presidiato e migliorato.

Non dimenticare cessazione, ripristino e identità non umane

Molti programmi di autenticazione appaiono solidi al login e deboli in tutto il resto.

La cessazione è un punto di fallimento comune. La Politica di onboarding e cessazione del personale di Clarysec include specificamente:

revoca di token MFA/SSO, smart card o certificati

Questa clausola deve essere testata. Selezionate tre utenti cessati e dimostrate che account, sessioni, dispositivi MFA, passkey, certificati e metodi di recupero sono stati revocati nei tempi previsti. Se non potete dimostrare la revoca dei token, il vostro controllo di cessazione è incompleto.

Il ripristino è un altro punto debole. Se un helpdesk può reimpostare la MFA dopo due semplici domande, l’attaccante prenderà di mira il recupero tramite helpdesk anziché il login. Le procedure di ripristino devono richiedere verifica robusta, registrazione dei ticket, approvazione per gli utenti privilegiati, notifica all’utente e monitoraggio delle attività successive al ripristino.

L’identità non umana è il terzo punto cieco. Zenith Blueprint Step 22 chiarisce che le informazioni di autenticazione includono “password, PIN, chiavi crittografiche, template biometrici, smart card, token, certificati, token OAuth, chiavi SSH, secret API”. Gli attaccanti utilizzano frequentemente token API, chiavi di account di servizio e concessioni OAuth per mantenere la persistenza. Trattate tali credenziali nell’ambito di A.5.17, con uso di vault, titolarità, rotazione, revoca e logging.

Cosa significa essere adeguati nel 2026

Un ambiente maturo di controlli di identità nel 2026 presenta queste caratteristiche:

• Il consiglio di amministrazione o l’organo di gestione comprende il rischio identità e approva la direzione.
• La politica sulle password è modernizzata, orientata all’utente e applicata tecnicamente.
• L’accesso basato solo su password è eliminato per sistemi privilegiati, remoti ed esposti a Internet.
• Le passkey o gli autenticatori FIDO2 sono prioritari per gli accessi ad alto rischio.
• Le eccezioni MFA sono documentate, approvate, limitate nel tempo e compensate.
• Registrazione, ripristino e revoca degli autenticatori sono controllati.
• La cessazione include revoca di account, token, certificati, sessioni e passkey.
• I log di autenticazione includono successi, fallimenti, uso della MFA, durata della sessione e modifiche degli autenticatori.
• I casi d’uso SIEM rilevano credential stuffing, impossible travel, registrazioni sospette e affaticamento da MFA.
• La SoA spiega perché A.5.16, A.5.17 e A.8.5 si applicano.
• Le mappature NIS2, DORA, GDPR e NIST CSF sono registrate una volta e riutilizzate.
• Le evidenze sono raccolte in modo continuo, non assemblate in emergenza prima dell’audit.

È così che NIST SP 800-63-4 diventa più di un documento di riferimento. Diventa un sistema di controllo vivo che supporta sicurezza, tutela della privacy, resilienza e capacità di dimostrare la conformità.

Trasformare i controlli di identità in evidenze pronte per l’audit

Se la vostra organizzazione sta aggiornando le regole sulle password, distribuendo MFA resistente al phishing, introducendo passkey o preparandosi a domande di audit su ISO 27001, NIS2, DORA o GDPR, non iniziate solo dalla configurazione degli strumenti.

Iniziate dal modello di evidenze.

Clarysec può aiutarvi a:

• Mappare le aspettative NIST SP 800-63-4 su password, MFA e passkey rispetto a ISO/IEC 27001:2022.
• Costruire una politica sul ciclo di vita degli autenticatori e un pacchetto di evidenze.
• Aggiornare le politiche di controllo degli accessi, MFA, logging, onboarding e cessazione.
• Preparare una Dichiarazione di Applicabilità che colleghi il rischio identità ai controlli.
• Utilizzare Zenith Blueprint per strutturare le fasi di implementazione e la capacità di dimostrare la conformità in audit.
• Utilizzare Zenith Controls per mappare in modo incrociato i controlli di identità rispetto a NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT 2019.

Il momento migliore per scoprire un ripristino debole, una revoca mancante delle passkey o un’applicazione incompleta della MFA è prima dell’incidente, prima dell’autorità di regolamentazione e prima che lo chieda l’auditor.

Trasformate il vostro prossimo riesame del controllo degli accessi in un riesame delle evidenze NIST SP 800-63-4. Scaricate le politiche Clarysec pertinenti, esplorate Zenith Blueprint e utilizzate Zenith Controls per trasformare l’implementazione di password, MFA e passkey in un’unica storia di conformità pratica, proporzionata e pronta per l’audit.