Passkey FIDO2 in Microsoft Entra ID: rollout pratico senza password

Le passkey FIDO2 sono una delle contromisure più efficaci contro phishing, password spray e furto di credenziali nei tenant Microsoft 365. Non sono semplicemente una password più comoda: l’autenticazione usa una coppia di chiavi crittografiche, lega la risposta al dominio corretto e non espone al servizio un segreto riutilizzabile. Per un SysAdmin il vantaggio concreto è ridurre sia il rischio di compromissione sia le richieste di reset password.

La tecnologia, però, non sostituisce un progetto di rollout. Attivarla per tutti senza inventario dei dispositivi, metodo di bootstrap e account di emergenza può produrre utenti bloccati e procedure di supporto improvvisate. Questa guida propone un’adozione graduale per tenant piccoli e medi, applicabile anche a un laboratorio Microsoft 365.

Quale passkey stiamo distribuendo

In Entra ID le credenziali FIDO2 possono risiedere in una chiave di sicurezza hardware oppure, dove supportato, nel dispositivo dell’utente. La chiave privata resta nell’autenticatore; Entra conserva la chiave pubblica. Lo sblocco locale avviene con PIN o biometria, ma questi dati non vengono inviati al tenant.

Prima di scegliere, distinguere tre scenari:

chiavi hardware FIDO2 per amministratori, postazioni condivise e ruoli sensibili;
passkey legate al dispositivo per notebook e smartphone aziendali gestiti;
passkey sincronizzate, se ammesse dalle policy e coerenti con il modello di rischio aziendale.

La decisione non deve essere lasciata al singolo utente. Per gli amministratori privilegiati preferisco due chiavi hardware registrate, custodite separatamente: è un costo modesto rispetto a un incidente sul tenant.

Prerequisiti da verificare

Serve accedere al portale Entra con un ruolo adeguato alla gestione dei metodi di autenticazione. Conviene inoltre avere gruppi dedicati, dispositivi e browser supportati, registrazione delle informazioni di sicurezza disponibile e almeno due account di emergenza esclusi dalle normali policy di Conditional Access.

La checklist iniziale è breve:

creare un gruppo SG-Auth-Passkey-Pilot con assegnazione manuale;
censire sistema operativo, browser e tipo di autenticatore;
controllare la policy Authentication methods e dismettere le vecchie policy MFA solo dopo aver verificato le dipendenze;
preparare Temporary Access Pass per il bootstrap controllato;
documentare revoca, smarrimento e sostituzione della credenziale;
abilitare audit e accesso ai Sign-in logs.

Temporary Access Pass, o TAP, è particolarmente utile per un nuovo assunto o per il recupero di un utente: fornisce una credenziale temporanea con cui registrare un metodo passwordless senza comunicare una password permanente. Durata e utilizzo singolo devono seguire una procedura interna, non una scelta estemporanea dell’help desk.

Configurazione della policy

Nel centro di amministrazione Microsoft Entra aprire Protection > Authentication methods > Policies e selezionare Passkey (FIDO2). Abilitare inizialmente soltanto il gruppo pilota. Le etichette del portale possono cambiare, quindi va sempre confrontata l’interfaccia con la documentazione Microsoft aggiornata.

Nelle opzioni avanzate valutare:

Enforce attestation: limita la registrazione agli autenticatori di cui Entra può verificare i metadati. Aumenta il controllo, ma può escludere modelli non compatibili.
Key restrictions: consente o blocca specifici AAGUID, gli identificatori dei modelli di autenticatore. È utile quando l’azienda approva un catalogo ristretto di chiavi.
Self-service setup: deve essere accompagnato da istruzioni chiare e da un metodo di bootstrap robusto.

Non estendere la policy a “All users” nello stesso giorno. Inserire prima IT e security, poi un piccolo gruppo trasversale, infine procedere per reparti. Ogni fase deve durare abbastanza da osservare accessi reali, sostituzioni di device e casi di recupero.

Registrazione e test

L’utente registra la passkey dalla pagina delle informazioni di sicurezza del proprio account Microsoft. Durante il pilot va testato almeno questo percorso:

accesso iniziale con TAP o metodo già autorizzato;
registrazione della chiave o passkey;
logout completo e nuova autenticazione in finestra privata;
accesso a portale Microsoft 365, applicazione sensibile e client desktop;
prova controllata di revoca dal portale amministrativo;
nuova registrazione con la procedura di recovery.

Nei Sign-in logs verificare metodo usato, risultato, applicazione, device, indirizzo IP e dettaglio della Conditional Access. Il fatto che l’accesso abbia avuto successo non dimostra da solo che sia stata usata FIDO2: il log deve confermarlo.

Per gli amministratori, eseguire anche una prova da una postazione pulita e una simulazione di chiave smarrita. Una credenziale di riserva non dovrebbe stare nella stessa borsa della primaria. Registrare almeno due metodi resistenti al phishing evita che il recupero dipenda da SMS o telefonate facilmente manipolabili.

Conditional Access senza chiudersi fuori

Le passkey danno il massimo quando una policy richiede un’authentication strength resistente al phishing per ruoli amministrativi e applicazioni critiche. Creare la policy in modalità report-only, includere il gruppo pilota ed escludere esplicitamente gli account break-glass. Analizzare i risultati prima dell’enforcement.

Un ordine prudente è:

richiedere phishing-resistant MFA agli amministratori pilota;
monitorare almeno un ciclo operativo completo;
correggere account di servizio e flussi non interattivi;
estendere ai ruoli privilegiati;
applicare gradualmente agli utenti standard dove il rischio lo giustifica.

Gli account di servizio non vanno “risolti” aggiungendo eccezioni generiche. Dove possibile, sostituire credenziali utente con managed identity, workload identity o certificati. Ogni esclusione residua deve avere proprietario, motivazione e data di revisione.

Recovery e gestione del ciclo di vita

Una passkey persa va rimossa immediatamente dai metodi dell’utente; se il dispositivo è compromesso, revocare anche sessioni e token e valutare il reset delle credenziali correlate. Il supporto deve verificare l’identità con un processo definito prima di emettere un TAP. La sola conoscenza di dati anagrafici non è una verifica sufficiente.

Integrare il processo con onboarding, cambio dispositivo e offboarding. In uscita dall’azienda, disabilitare l’account, revocare sessioni, rimuovere i metodi registrati e recuperare le chiavi hardware inventariate. Una revisione trimestrale di gruppi target, eccezioni e autenticatori ammessi mantiene la configurazione coerente.

Checklist finale

Pilot limitato e rappresentativo completato.
Due account break-glass testati e monitorati.
Almeno due metodi robusti per ogni amministratore.
TAP con durata minima e procedura di identificazione.
Conditional Access prima in report-only, poi applicata.
Sign-in logs controllati per confermare FIDO2.
Recovery, revoca e offboarding documentati.
Eccezioni con proprietario e scadenza.

Una migrazione passwordless riuscita non si misura dal numero di passkey registrate, ma dalla capacità di autenticare, recuperare e revocare in modo prevedibile. Il risultato corretto è un tenant più resistente al phishing senza trasformare ogni cambio dispositivo in un’emergenza.