1 04/11/2026 8 min

Abilitare una chiave FIDO2 in Azure Portal

Se vuoi usare una chiave di sicurezza FIDO2 per l’accesso ad Azure, il punto giusto da controllare non è solo la registrazione del dispositivo: conta anche come è configurato Microsoft Entra ID (l’ex Azure AD), quali metodi di autenticazione sono consentiti e se la tua organizzazione ha imposto policy che bloccano il flusso. In pratica, la chiave funziona bene solo quando tre livelli sono allineati: tenant, utente e dispositivo/browser.

La procedura qui sotto copre sia il caso in cui devi abilitare il metodo FIDO2 a livello tenant, sia il caso in cui devi registrare la chiave per un utente e verificare che poi venga accettata in fase di login. Dove serve, indico anche i controlli minimi per capire se il problema è nella policy, nel browser o nella registrazione del dispositivo.

Prerequisiti da verificare prima di iniziare

Prima di toccare il portale, conviene verificare alcune condizioni basilari. In molti casi il fallimento non dipende dalla chiave, ma da un requisito mancato che blocca la registrazione o l’uso successivo.

  • L’utente deve avere un account valido nel tenant Microsoft Entra ID e il metodo FIDO2 deve essere consentito dalla policy di autenticazione.
  • La chiave deve essere FIDO2/WebAuthn compatibile; non tutte le chiavi USB/NFC sono equivalenti, e alcune supportano solo scenari parziali.
  • Il browser deve supportare WebAuthn e deve poter accedere ai dispositivi di sicurezza locali o NFC, senza blocchi imposti da estensioni o policy del browser.
  • Se l’organizzazione usa Conditional Access, verifica che non ci siano regole che impongono un metodo diverso o che escludono il dispositivo/browser usato per la registrazione.

Se uno di questi punti è incerto, non andare avanti “a tentativi”: apri prima il portale di amministrazione e controlla la configurazione del metodo di autenticazione. È il modo più rapido per evitare una registrazione apparentemente riuscita ma inutilizzabile al login.

Abilitare FIDO2 nel tenant Microsoft Entra ID

La chiave FIDO2 non si abilita solo per singolo utente: in genere va resa disponibile come metodo di autenticazione nel tenant. Il percorso può cambiare leggermente nel tempo, ma il punto di partenza resta il portale di amministrazione di Microsoft Entra.

  1. Accedi al Microsoft Entra admin center con un account amministrativo.
  2. Vai in Protection o Security, quindi cerca la sezione dedicata ai Authentication methods.
  3. Apri la policy relativa a FIDO2 Security Key.
  4. Imposta il metodo su Enabled.
  5. Decidi se consentire l’uso a All users o solo a gruppi specifici. In ambienti controllati è quasi sempre meglio limitare a gruppi pilota o gruppi di sicurezza dedicati.
  6. Salva la configurazione e attendi la propagazione della policy.

La scelta tra “tutti” e “gruppi” non è una formalità: se abiliti il metodo per l’intero tenant senza una fase pilota, rischi di scoprire troppo tardi che una parte degli utenti ha browser non compatibili, device non supportati o policy di accesso che richiedono un secondo metodo alternativo. In ambienti reali conviene sempre partire con un gruppo ristretto.

Se vuoi un controllo più fine, verifica anche eventuali impostazioni avanzate legate alla registrazione della chiave, come i parametri di attestation o i vincoli sui modelli supportati. Non sempre serve spingere su questi dettagli, ma in contesti regolamentati possono essere rilevanti.

Registrare la chiave FIDO2 per un utente

Una volta che il metodo è abilitato nel tenant, l’utente deve registrare la chiave nel proprio profilo di sicurezza. Il flusso standard passa dalla pagina delle informazioni di sicurezza dell’account Microsoft Entra.

  1. Apri https://mysignins.microsoft.com/security-info con l’account dell’utente interessato.
  2. Se richiesto, completa l’autenticazione con il metodo già disponibile, ad esempio password e MFA esistente.
  3. Seleziona Add sign-in method o il pulsante equivalente.
  4. Scegli Security key.
  5. Seleziona il tipo di chiave: USB, NFC o altro supporto disponibile, in base all’hardware reale.
  6. Segui la procedura guidata del browser: inserimento della chiave, eventuale tocco del sensore, creazione del PIN se richiesto e conferma finale.
  7. Assegna un nome descrittivo alla chiave, per esempio il tipo di dispositivo o il suo utilizzo, così da riconoscerla in futuro.

Il passaggio del PIN è importante: molte chiavi FIDO2 moderne richiedono la creazione di un PIN locale al momento della registrazione o al primo utilizzo. Se il PIN non viene impostato correttamente, l’utente può vedere la chiave registrata ma fallire al momento dell’accesso. In quel caso il problema non è Azure, ma lo stato della chiave o la sua inizializzazione incompleta.

Se la chiave non compare tra le opzioni disponibili, i casi più frequenti sono tre: il metodo non è stato davvero abilitato nel tenant, il browser non supporta il flusso WebAuthn usato dal portale, oppure una policy di sicurezza blocca il dispositivo di autenticazione. Prima di cambiare configurazioni, conviene testare con un browser differente e con una finestra pulita, senza estensioni invasive.

Verifica del login con la chiave FIDO2

Dopo la registrazione, il controllo vero è il login. La chiave deve comparire come metodo disponibile nella schermata di accesso di Microsoft, sia nel portale Azure sia nei servizi collegati al tenant.

  1. Esci dall’account oppure usa una finestra privata per evitare che sessioni già aperte falsino il test.
  2. Vai alla pagina di accesso Microsoft e inserisci l’account dell’utente registrato.
  3. Quando compare la scelta del metodo, seleziona Security key.
  4. Inserisci la chiave, toccala se richiesto e completa l’autenticazione.
  5. Verifica che l’accesso arrivi a destinazione senza passare da metodi non previsti o da fallback indesiderati.

Se il login fallisce ma la registrazione risulta presente, guarda prima il messaggio restituito dal portale. La differenza tra “chiave non riconosciuta”, “PIN errato”, “metodo non consentito” e “accesso bloccato da policy” è fondamentale: ogni errore punta a un livello diverso della catena.

Per un controllo lato amministrativo, puoi verificare anche i log di accesso in Microsoft Entra, dove l’evento di autenticazione mostra il metodo usato e l’eventuale motivo del fallimento. È il modo più pulito per distinguere un problema di dispositivo da un problema di autorizzazione o di policy.

Problemi tipici e come isolarli rapidamente

Quando qualcosa non funziona, la tentazione è cambiare subito impostazioni a caso. Meglio no: in questo tipo di scenario la diagnosi più veloce è quasi sempre quella che separa il problema in tre strati, in ordine: tenant, browser, chiave.

  • La chiave non appare tra i metodi: controlla la policy FIDO2 nel tenant e l’eventuale assegnazione a gruppi. Se il metodo non è consentito, il portale non lo mostra o lo rende inutilizzabile.
  • La registrazione parte ma si interrompe: prova con un browser diverso, disabilita temporaneamente estensioni di sicurezza o privacy che possono interferire con WebAuthn e verifica che il dispositivo sia riconosciuto dal sistema operativo.
  • Il login fallisce dopo la registrazione: controlla il PIN della chiave, la presenza di eventuali policy Conditional Access e i log di accesso in Entra per capire se il metodo è stato rifiutato o semplicemente non proposto.

Un test utile è provare la stessa chiave su un secondo browser supportato o su un secondo dispositivo autorizzato. Se funziona altrove, il problema è locale al browser o alla workstation; se fallisce ovunque, il sospetto si sposta su policy, registrazione o stato della chiave.

Buone pratiche operative per ambienti aziendali

In produzione, la parte più delicata non è “far funzionare la chiave”, ma farlo senza creare dipendenze fragili. Alcune scelte rendono la gestione molto più solida nel tempo.

  • Avvia con un gruppo pilota: limita il metodo a pochi utenti, verifica la compatibilità e solo dopo estendi l’abilitazione.
  • Non rimuovere subito i metodi alternativi: tieni un canale di accesso di emergenza, almeno per gli amministratori e per i casi di recovery.
  • Documenta la procedura di sostituzione: se la chiave viene persa o danneggiata, l’utente deve sapere come rimuovere il vecchio metodo e registrare il nuovo in modo sicuro.
  • Controlla il numero di chiavi per utente: quando possibile, prevedi una chiave primaria e una di backup, soprattutto per gli account con privilegi elevati.
  • Monitora i log di accesso: i fallimenti ripetuti su FIDO2 possono indicare problemi di usabilità, browser non allineati o policy troppo restrittive.

Per gli account amministrativi, il principio più sensato è ridurre il rischio di lockout. Una chiave unica senza fallback è elegante sulla carta, ma operativamente fragile se viene persa, rotta o scollegata dal dispositivo su cui era stata inizializzata.

Quando serve un controllo più profondo

Se la chiave è compatibile, la policy è corretta e il browser è aggiornato, ma il flusso continua a fallire, il controllo successivo è sui dettagli del tenant: metodi di autenticazione, Conditional Access, eventuali restrizioni legacy e stato dell’utente. In alcuni casi la registrazione è stata fatta correttamente, ma il login viene comunque respinto perché una regola di accesso richiede un percorso diverso, per esempio un metodo forte aggiuntivo o un dispositivo conforme.

Se hai accesso amministrativo, conviene verificare anche che non ci siano policy che bloccano l’uso di chiavi di sicurezza per specifici gruppi, ruoli o applicazioni. In ambienti grandi è facile dimenticare un’esclusione ereditata da una policy precedente. Qui la documentazione interna fa la differenza: senza sapere quale regola governa davvero l’accesso, si rischia di inseguire il sintomo sbagliato.

Checklist finale operativa

  • FIDO2 abilitato nella policy dei metodi di autenticazione del tenant.
  • Utente incluso nel gruppo corretto o autorizzato dalla policy.
  • Chiave registrata in security-info con nome riconoscibile.
  • PIN della chiave impostato e funzionante.
  • Browser compatibile e testato senza estensioni interferenti.
  • Accesso verificato dai log di Microsoft Entra in caso di errore.

Assunzione operativa: la procedura descritta vale per un tenant Microsoft Entra ID con configurazione standard e con accesso amministrativo al portale; se ci sono policy personalizzate o vincoli di sicurezza più rigidi, il punto di verifica resta comunque lo stesso, ma i passaggi possono cambiare leggermente.