Implementazione delle passkey aziendali: sfide e soluzioni

1. Introduzione: la realtà operativa delle passkey aziendali per i dipendenti#

Le passkey sono arrivate nel mondo del lavoro. La domanda non è più "la tecnologia funziona?". La domanda ora è "come gestiamo tutto questo su larga scala?". I punti di attrito si sono spostati al livello operativo: il problema "dell'uovo e della gallina" della registrazione iniziale (bootstrapping), la differenza tra passkey legate al dispositivo e sincronizzate, l'interoperabilità multipiattaforma e i meccanismi di recupero che non ritornano all'insicurezza di una password.

Questa guida affronta le sfide del mondo reale nell'implementazione delle passkey negli ambienti Microsoft Entra ID, coprendo le insidie di configurazione, i flussi di lavoro operativi e le strategie di recupero. Nello specifico, affronteremo le seguenti domande:

1. Qual è la differenza tra passkey legate al dispositivo e passkey sincronizzate in Entra ID?
2. Come effettuo il bootstrap delle passkey per i nuovi dipendenti senza password?
3. Come recuperano l'accesso gli utenti quando prendono un nuovo telefono e perdono l'accesso al loro autenticatore?
4. Quali errori di configurazione causano i fallimenti nella registrazione delle passkey?
5. Come gestisco gli ospiti B2B quando è richiesta l'MFA resistente al phishing?
6. Dovrei usare chiavi di sicurezza hardware (YubiKey) o passkey mobili?
7. Come gestisco i dispositivi macOS insieme a Windows in un'implementazione di passkey?
8. Quali misure proattive prevengono il sovraccarico dell'helpdesk per la sostituzione dei telefoni?

2. Comprendere le passkey in Microsoft Entra#

In Entra, "passkey" = credenziali FIDO2/WebAuthn. Invece di una password, l'utente dimostra il possesso di una chiave privata archiviata in un autenticatore. È resistente al phishing perché WebAuthn lega la credenziale alla vera origine di accesso (così un sito di phishing molto simile non può replicarla). Consulta la panoramica di Microsoft nella documentazione sui concetti delle passkey (FIDO2).

In pratica, Entra supporta due "modalità" di passkey che si comportano in modo diverso.

2.1 Passkey legate al dispositivo in Entra#

Queste passkey sono legate a un singolo dispositivo fisico (non sincronizzabili). La chiave privata esiste su uno specifico elemento hardware (TPM su un laptop, Secure Element su una YubiKey). Non è esportabile.

In Entra, lo scenario legato al dispositivo si traduce comunemente in:

• Passkey di Microsoft Authenticator
• Passkey Windows Hello o Windows Hello for Business (WHfB) (non sincronizzate a partire da gennaio 2026)
• Chiavi di sicurezza FIDO2 (chiavi hardware come le YubiKey)
• Smartcard

Le linee guida per la configurazione di base di Microsoft per le passkey legate al dispositivo sono disponibili qui: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

Casi d'uso: Accesso con privilegi elevati, account "break-glass", ambienti con workstation condivise. Svantaggio: Alto attrito. La perdita del dispositivo significa perdita delle credenziali. Costo operativo elevato (es. spedizione delle YubiKey).

2.2 Passkey sincronizzate in Entra#

Queste sono passkey archiviate in un ecosistema di provider e sincronizzate tra i dispositivi dell'utente (es. Portachiavi iCloud, Google Password Manager o provider di terze parti). La chiave privata è crittografata e archiviata nel fabric di sincronizzazione di un provider cloud.

A partire da gennaio 2026, in Entra, le passkey sincronizzate sono gestite tramite la funzionalità in anteprima: Passkey sincronizzate (anteprima). Per abilitare e controllare le passkey sincronizzate, Entra utilizza i Profili Passkey (anteprima).

Conformità normativa: Recentemente convalidate dal NIST SP 800-63B Supplement 1 come conformi ai requisiti AAL2. Questa è una massiccia vittoria normativa che convalida che le passkey sincronizzate sono sufficientemente "resistenti al phishing" per l'uso generale della forza lavoro.

Casi d'uso: Knowledge worker, utenti BYOD, comodità per i dirigenti. Svantaggio: Livello di sicurezza "inferiore" rispetto all'hardware. Dipendenza dalla sicurezza del flusso di recupero dell'account del provider cloud.

Di seguito troverai una panoramica dei provider di passkey sincronizzate supportati da Entra:

Nella pagina delle Informazioni di sicurezza di un utente, le passkey sincronizzate e quelle legate al dispositivo sono chiaramente distinte. Di seguito puoi vedere come appaiono una passkey sincronizzata (da 1Password) e una passkey legata al dispositivo (YubiKey 5C NFC):

2.3 Allineamento normativo: Livelli AAL del NIST#

• L'AAL3 storicamente richiedeva autenticatori basati su hardware e legati al dispositivo (come YubiKey o Smart Card) che utilizzano una chiave privata non esportabile.
• L'AAL2 ora può essere ottenuto con passkey sincronizzate secondo le linee guida NIST.
• Sfumatura: Sebbene le passkey sincronizzate (come quelle in iCloud) siano eccellenti per gli utenti standard, potrebbero non soddisfare rigorosamente il requisito di "non esportabilità" dell'AAL3 per i massimi livelli di privilegio. Pertanto, è necessaria una strategia segmentata: Chiavi hardware per gli Amministratori (AAL3), Passkey sincronizzate per la forza lavoro (AAL2).

2.4 Requisiti di idoneità del dispositivo#

Per garantire che i dispositivi siano preparati per l'autenticazione senza password resistente al phishing, devono eseguire queste versioni minime:

I sistemi operativi più vecchi potrebbero richiedere autenticatori esterni (chiavi di sicurezza FIDO2) per supportare l'autenticazione senza password resistente al phishing.

Oltre ai requisiti di versione minima, anche il supporto delle funzionalità lato browser varia in base alla piattaforma. Secondo l'analisi sulle funzionalità dei client WebAuthn del Corbado Passkey Benchmark 2026, il supporto dei browser del Q1 2026 si attesta al 97–100% per Conditional Get e Hybrid Transport, ma solo all'83–92% per Conditional Create su un mix tipico di browser consumer, un vincolo che colpisce duramente Windows perché Windows Hello non è un percorso Conditional Create, ed Edge in modo specifico riporta un supporto molto basso per Conditional Create nello stesso set di dati. Il benchmark copre implementazioni B2C rivolte ai consumatori anziché ambienti di lavoro, ma gli stessi limiti di capacità del browser/OS si applicano comunque ai lanci di Entra ID; popolazioni con una forte presenza di Edge aziendale possono posizionarsi materialmente al di sotto della fascia mista dell'83–92% per Conditional Create.

2.5 Raccomandazioni per le credenziali in base alla persona dell'utente#

Microsoft consiglia un approccio basato sulla persona dell'utente per la distribuzione delle credenziali. Ruoli diversi hanno requisiti di sicurezza e livelli di attrito accettabili diversi:

Credenziali portatili (possono essere utilizzate su più dispositivi):

Credenziali locali (specifiche del dispositivo):

L'obiettivo finale: La maggior parte degli utenti dovrebbe disporre di almeno una credenziale portatile oltre a credenziali locali su ciascun dispositivo informatico.

3. Esperienze da implementazioni live di Passkey#

Parlando con organizzazioni che hanno implementato le passkey si riconoscono alcuni punti di attrito e pattern del mondo reale.

3.1 Cambio operativo#

"Le sfide non sono nello stack tecnologico ma nel livello operativo." Questo conferma che gli ostacoli tecnici come gli errori "Passkey non registrata" o l'invisibilità delle opzioni di Windows Hello sui dispositivi personali non sono anomalie uniche, ma punti di attrito sistemici inerenti all'attuale maturità dell'ecosistema. Per le operazioni aziendali, la chiave è separare gli errori previsti da quelli imprevisti nel monitoraggio. Raggruppa gli errori WebAuthn esplicitamente e traccia NotAllowedError, AbortError e gli errori delle passkey in Credential Manager come segnali distinti. Il nostro playbook di analisi dell'autenticazione fornisce un framework per classificare questi segnali, e l'analisi delle passkey copre i KPI specifici delle passkey come i tassi di attivazione e di accesso.

3.2 Registrazione: il momento "decisivo"#

La registrazione è la fase più difficile dell'implementazione, richiedendo una significativa gestione del cambiamento.

• Complessità della pre-registrazione: L'onboarding di nuovi dipendenti che non hanno credenziali precedenti è il collo di bottiglia principale. La dipendenza dalla registrazione mediata dall'amministratore crea un'esperienza utente disarticolata.
• Frammentazione della piattaforma: "Frustrazione dell'utente per i passaggi" a causa di iterazioni indipendenti di browser, sistemi operativi e gestori di password. Ciò porta a incongruenze temporanee in cui un flusso funziona su Chrome/Windows ma fallisce su Safari/macOS o fallisce su dispositivi personali non gestiti pur avendo successo su quelli aziendali.

3.3 Lacuna nel modello mentale#

"Gli utenti non hanno bisogno di crittografia, hanno bisogno di un modello mentale". La confusione terminologica crea un carico cognitivo:

• Passkey
• Security Key
• Hardware Key
• YubiKey
• passwordless
• Windows Security
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• Phone Sign-in

Per gli utenti non esperti di tecnologia o anche per quelli esperti, le differenze di questi termini non sono sempre ovvie.

Consigliamo di evitare il gergo come "resistente al phishing" o "coppia di chiavi" nelle comunicazioni agli utenti finali. Invece, concentrati sul concetto di "sblocco": "Usa il tuo viso per sbloccare i sistemi aziendali", in modo analogo allo sblocco del loro telefono.

3.4 Limiti della comunicazione#

Una forte adozione all'inizio è fondamentale per il successo, ma la comunicazione non può spingersi oltre un certo limite. Non puoi inviare e-mail regolari chiedendo agli utenti di controllare i loro metodi di autenticazione. In generale, non puoi pianificare bene il comportamento degli utenti. Questa realtà spinge alla necessità di misure tecniche proattive piuttosto che affidarsi esclusivamente all'educazione degli utenti.

4. Analisi approfondita della configurazione di Microsoft Entra ID#

L'implementazione delle passkey in un ambiente aziendale richiede la comprensione e l'impostazione di criteri interdipendenti. Le passkey non sono solo una funzionalità che puoi semplicemente attivare, poiché hanno un impatto enorme su ogni dipendente nel loro lavoro quotidiano.

4.1 Criterio dei metodi di autenticazione#

I vecchi portali MFA e SSPR sono deprecati. Tutta la configurazione FIDO2 deve avvenire nel pannello unificato della Politica dei Metodi di Autenticazione.

• Metodo Chiave di Sicurezza FIDO2: Questo deve essere abilitato e mirato. Consigliamo di mirare a "Tutti gli utenti" per l'abilitazione ma controllando l'applicazione tramite Accesso Condizionato.
• Restrizioni chiave (AAGUID): Ogni dispositivo FIDO2 (es. YubiKey 5 NFC, Microsoft Authenticator su iOS, Google Password Manager) ha un Authenticator Attestation GUID (AAGUID) univoco. Come best practice, per gli ambienti ad alta sicurezza, utilizza l'impostazione "Applica restrizioni chiave" per Consentire solo AAGUID specifici e approvati. Questo impedisce agli utenti di registrare chiavi di sicurezza "grey market" economiche e non verificate.

4.2 Attestazione: il punto di decisione critico#

Una delle decisioni di configurazione più significative è "Applica Attestazione".

• Cosa fa: Costringe l'autenticatore a dimostrare crittograficamente la propria marca e modello a Entra ID durante la registrazione.
• Conflitto: Le Passkey Sincronizzate (archiviate in provider software come Portachiavi iCloud, Bitwarden o Google Password Manager) generalmente non supportano l'attestazione perché sono basate su software e agnostiche rispetto alla piattaforma. Non possono firmare una sfida con un certificato batch hardware.
• Compromesso:
  • Impostato su SÌ: Richiesto per elevata garanzia (AAL3). Assicura che la chiave sia legata all'hardware. Blocca i provider di passkey basati su software.
  • Impostato su NO: Consente le Passkey Sincronizzate. Abbassa leggermente la garanzia (AAL2). Abilita i provider di passkey basati su software.

Non puoi applicare una politica globale "Nessuna Attestazione" se hai amministratori con privilegi elevati che richiedono chiavi hardware. Devi utilizzare i Profili Passkey (Anteprima):

• Profilo A (Amministratori): Applica Attestazione = Sì
• Profilo B (Personale Generale): Applica Attestazione = No

4.3 Profili Passkey spiegati#

Pensa ai Profili Passkey come al meccanismo per definire:

• "Questi utenti possono utilizzare passkey sincronizzate"
• "Questi utenti devono utilizzare solo passkey legate al dispositivo"
• "Attestazione richiesta vs non richiesta" (e quindi: passkey sincronizzate consentite vs escluse)
• "Limita a determinati tipi di autenticatori (restrizioni AAGUID)"

Di seguito puoi vedere la pagina delle impostazioni Passkey (FIDO2) nell'interfaccia di amministrazione di Microsoft Entra in cui configuri i profili passkey:

Quando modifichi un profilo passkey, puoi configurare l'applicazione dell'attestazione, i tipi di destinazione (legati al dispositivo, sincronizzati o entrambi) e specifiche restrizioni AAGUID:

4.4 Accesso condizionato e forze di autenticazione#

L'applicazione può essere gestita tramite politiche di Accesso Condizionato (CA) utilizzando le Forze di autenticazione.

• Forza dell'MFA resistente al phishing: Questa forza integrata richiede FIDO2, Windows Hello for Business (WHfB) o Autenticazione basata su certificati (CBA).
• Trappola del blocco: Se crei un criterio CA che richiede "MFA resistente al phishing" per "Tutte le app cloud" e lo applichi a "Tutti gli utenti", bloccherai immediatamente ogni utente che non ha ancora registrato una passkey. Non saranno nemmeno in grado di accedere per registrarne una.
• Paradosso "Registra Informazioni di sicurezza": Questa è un'Azione utente specifica nella CA. Se richiedi l'MFA resistente al phishing per eseguire l'azione Registra Informazioni di sicurezza, crei una dipendenza circolare (l'uovo e la gallina). Un utente non può registrare la sua prima passkey perché gli serve una passkey per accedere alla pagina di registrazione.

Ecco una panoramica di quali metodi di autenticazione soddisfano quali requisiti di forza:

4.5 Autenticazione preferita dal sistema#

La funzionalità "Autenticazione multifattore preferita dal sistema" di Entra ID costringe il motore di accesso a chiedere all'utente il metodo registrato più sicuro.

Se un utente ha registrato sia SMS che una passkey, il sistema imposterà come predefinita la passkey. Questo spinge l'adozione delle passkey in modo organico senza un'imposizione rigida. In sostanza, "aggiorna" automaticamente il livello di sicurezza dell'utente una volta registrata la credenziale.

Di seguito puoi vedere l'esperienza di accesso con passkey. All'utente viene richiesto di utilizzare "Viso, impronta digitale, PIN o chiave di sicurezza" e può selezionare la propria passkey da un'estensione del browser o dal gestore di credenziali di sistema:

4.6 Considerazioni su macOS: Platform SSO#

Per le organizzazioni con ambienti misti Windows/macOS, macOS Platform SSO fornisce l'equivalente Apple di Windows Hello for Business. Combinato con le soluzioni MDM, puoi ottenere:

• Credenziali legate al dispositivo e vincolate alla Secure Enclave del Mac
• Esperienza SSO su app native e app web
• Autenticazione resistente al phishing che soddisfa i requisiti AAL2/AAL3

Nota: macOS Platform SSO richiede macOS 13+ e un'adeguata configurazione MDM. La configurazione differisce in modo significativo da Windows WHfB, quindi pianifica percorsi di distribuzione separati.

5. Errori di configurazione comuni: perché "funziona solo con Microsoft Authenticator"#

Se il tuo obiettivo sono le passkey sincronizzate su dispositivi non gestiti, ecco i blocchi più comuni:

5.1 Passkey sincronizzate non abilitate/mirate#

Non è sufficiente abilitare solo "FIDO2" in generale in Entra. Per le passkey sincronizzate di solito è necessario:

• Il percorso della funzionalità in anteprima descritto in Passkey sincronizzate (anteprima)
• Una configurazione del profilo utilizzando i Profili Passkey

Se un gruppo non è mirato da un profilo che consente passkey sincronizzate, verrai riportato nel mondo "solo legato al dispositivo".

5.2 Attestazione applicata (blocca le passkey sincronizzate)#

Questo causa la maggior parte delle domande nelle organizzazioni attente alla sicurezza:

• Entra può richiedere l'attestazione per alcuni scenari passkey (aiuta a convalidare il tipo/provenienza dell'autenticatore)
• Le passkey sincronizzate non supportano l'attestazione in Entra, quindi se viene applicata l'attestazione, le passkey sincronizzate non superano la registrazione e ti ritroverai solo con opzioni legate al dispositivo

5.3 Le liste consentite AAGUID bloccano i provider#

Entra ti consente di limitare quali autenticatori sono ammessi (spesso tramite liste di autorizzazione/blocco AAGUID). Se consenti solo Microsoft Authenticator (o una serie limitata di autenticatori), i provider sincronizzati di terze parti potrebbero essere bloccati implicitamente. La parte che genera confusione è che l'autenticazione locale (es. Touch ID, Face ID, scansione biometrica di Windows) funziona, ma la pagina di accesso di Entra visualizza un errore in seguito.

5.4 L'Accesso Condizionato forza determinati tipi di passkey#

Anche se le passkey sono abilitate, l'Accesso Condizionato può di fatto costringere gli utenti verso un sottoinsieme di metodi (es. "Solo Authenticator" o una configurazione di forza che non permette il profilo passkey previsto). In pratica, questo crea la "dipendenza da Authenticator" anche quando il piano prevede passkey sincronizzate.

5.5 Account ospite B2B vs account membro#

Se i partner esterni sono utenti guest B2B in un tenant di risorse, ci sono limitazioni note su dove/come possono registrare i metodi di autenticazione. Questo è spesso il motivo nascosto dietro al "perché non funziona" quando l'intento è "i partner utilizzano le passkey nel nostro tenant".

6. Sfide operative e soluzioni#

6.1 Paradosso del bootstrapping#

Il problema più pervasivo ("La registrazione è la parte più difficile") è il problema del bootstrapping: Come si emette in modo sicuro una credenziale ad alta affidabilità a un utente che attualmente non ha credenziali (o solo credenziali a bassa affidabilità)?

6.1.1 Temporary Access Pass (TAP)#

Il Temporary Access Pass (TAP) è un approccio architetturale per l'onboarding senza password.

• Cos'è: Un codice di accesso limitato nel tempo (es. 1 ora), ad alta entropia, che Entra ID tratta come un metodo di "autenticazione forte". Evita la necessità di una password o di un MFA esistente.
• Flusso di lavoro:
  1. Verifica dell'identità: L'identità del nuovo dipendente viene verificata (es. tramite procedura HR o verifica del manager).
  2. Emissione: Un amministratore (o un'App Logica automatizzata) genera un TAP per l'utente.
  3. Accesso "Magico": L'utente si reca su aka.ms/mysecurityinfo. Inserisce il proprio nome utente e il TAP.
  4. Registrazione: Poiché il TAP soddisfa il requisito di "Strong Auth", l'utente è autorizzato ad accedere al pannello Info di Sicurezza. Fa clic su "Aggiungi metodo" e registra la sua passkey.
  5. Stato Stazionario: Il TAP scade. L'utente ora possiede una credenziale resistente al phishing. Non ha mai digitato una password.

6.1.2 Automazione tramite Graph API#

Per le grandi organizzazioni, l'emissione manuale del TAP non è scalabile. La migliore pratica è quella di automatizzarla tramite Microsoft Graph API.

• Scenario: Un nuovo assunto viene elaborato nel sistema HR (Workday/SuccessFactors).
• Trigger: L'evento di provisioning attiva una Azure Logic App.
• Azione: L'App Logica chiama la Graph API POST /users/{id}/authentication/temporaryAccessPassMethods.
• Consegna: Il TAP viene consegnato in modo sicuro al responsabile delle assunzioni o all'e-mail personale dell'utente (crittografata) per l'accesso il primo giorno.

6.1.3 Microsoft Entra Verified ID per onboarding ad alta affidabilità#

Per l'onboarding remoto o per scenari che richiedono un'elevata garanzia dell'identità, Entra Verified ID di Microsoft con Face Check fornisce un percorso di registrazione che privilegia l'assenza di password:

1. Proofing dell'identità: Il nuovo utente verifica l'identità tramite un partner IDV (scansione di un documento d'identità governativo).
2. Abbinamento biometrico: Face Check confronta un selfie dal vivo con la foto del documento di identità utilizzando Azure AI Vision. Viene condiviso solo un punteggio di confidenza della corrispondenza (nessun dato biometrico grezzo).
3. Emissione della credenziale verificata: L'utente riceve una credenziale Verified ID.
4. Emissione TAP: Al superamento della verifica, il sistema emette un Temporary Access Pass.
5. Bootstrap passkey: L'utente registra la sua prima passkey utilizzando il TAP.

Il flusso Face Check guida gli utenti attraverso tre passaggi: Verify (condividi le credenziali), Confirm (esegui scansione facciale) e Review (visualizza risultato corrispondenza):

Questo flusso consente di avere account veramente senza password fin dal primo giorno. Nessuna password viene mai creata.

6.2 Il problema della sostituzione del telefono (la sfida di scala nascosta)#

Spesso questa è la principale fonte di chiamate all'helpdesk nelle implementazioni delle passkey. Le organizzazioni con ampie popolazioni BYOD (es. più di 10.000 dispositivi) possono registrare un numero enorme di chiamate di supporto solo per utenti che acquistano nuovi telefoni e non conoscono il processo per registrare nuovamente i metodi di autenticazione.

Quando si introducono le passkey nel mix, questo diventa ancora più critico perché:

• Gli utenti installano app (come Outlook) sul loro nuovo telefono
• Queste app richiedono l'autenticazione
• Il prompt MFA appare sul vecchio telefono (che potrebbero aver già permutato o formattato)
• L'utente è bloccato e chiama l'helpdesk

6.2.1 Matrice di scenario per la sostituzione del telefono#

L'obiettivo è spostare il maggior numero possibile di casi nelle prime due righe, minimizzando il coinvolgimento dell'helpdesk.

6.2.2 Trucco di registrazione con Intune#

Un'intuizione intelligente: Richiedere una passkey per la registrazione in Intune obbliga gli utenti a completare la configurazione di Microsoft Authenticator sul loro nuovo telefono immediatamente, prima ancora di poter accedere alle app aziendali.

• Oggi: La registrazione a Intune richiede il potenziamento dell'MFA. Questo significa che se vuoi accedere su un nuovo telefono, installi Outlook lì. Tuttavia, il prompt MFA va al vecchio telefono.
• Con il requisito della passkey: Gli utenti devono prima impostare le passkey di Microsoft Authenticator sul nuovo telefono per completare la registrazione. Questo avviene rapidamente (il giorno del cambio telefono) piuttosto che mesi dopo, quando il vecchio telefono non c'è più.

Questo non risolve il recupero, ma anticipa le tempistiche. Gli utenti registrano il loro nuovo dispositivo mentre hanno ancora accesso al vecchio.

6.3 Le chiavi di sicurezza hardware portano problemi logistici#

Le chiavi hardware (YubiKey, ecc.) vengono a volte presentate come la soluzione universale. In teoria lo sono, tuttavia il mondo reale mostra più sfide:

• Incubo logistico: Le organizzazioni che in passato hanno implementato token fisici (come RSA SecurID) hanno spesso passato anni a cercare di eliminarli. Sostituire un programma di token fisico con un altro non è allettante.
• Spedizione diretta: Yubico può spedire le chiavi direttamente agli utenti e non hanno bisogno di sostituire la batteria ogni pochi anni (a differenza di SecurID). Ma se qualcuno dimentica la sua chiave, non può accedere (per i desktop condivisi).
• Onere per l'IT locale: I supervisori locali non dovrebbero diventare il supporto IT di fatto per le chiavi dimenticate.
• Costo: Le chiavi hardware aggiungono costi per utente che scalano con il numero di dipendenti.

Quando hanno senso le chiavi hardware:

• Amministratori di livello 0: Domain admin, account "break-glass"
• Workstation condivise: Ambienti con kiosk, postazioni di fabbrica, tablet sul campo
• Appaltatori senza BYOD: Utenti esterni che non utilizzeranno dispositivi personali

6.4 Sfide relative ai dispositivi non gestiti#

Molti utenti si lamentano di non poter visualizzare le opzioni di utilizzo delle passkey su un dispositivo personale. Questo è un classico punto di attrito del "dispositivo non gestito".

6.4.1 Analisi dell'errore "Passkey non registrata"#

Gli utenti potrebbero non essere in grado di aggiungere passkey su un dispositivo personale, mentre funziona su un dispositivo aziendale. Questo è probabilmente dovuto ai Criteri di conformità di Intune che interagiscono con il flusso di registrazione.

• Meccanismo: Windows Hello for Business (WHfB) è una credenziale di piattaforma. È legata al TPM dello specifico dispositivo (passkey legata al dispositivo).
• Vincolo: Per registrare WHfB, il dispositivo deve tipicamente essere unito (Entra Joined o Hybrid Joined) al tenant. Un dispositivo personale che è semplicemente "Registrato" (Workplace Joined) potrebbe avere restrizioni di policy applicate tramite Intune che bloccano il provisioning dei container WHfB se il dispositivo non è completamente gestito o conforme. Consulta Requisiti di accesso con chiave di sicurezza FIDO2.
• Opzione "Passkey": Su un dispositivo personale, l'utente dovrebbe tentare di registrare una Chiave di sicurezza FIDO2 (roaming) o una Passkey tra dispositivi (sul proprio telefono), non Windows Hello for Business (a meno che non sia pienamente supportata l'iscrizione BYOD).
• Problema di visibilità di Entra ID: Se "Windows Hello" non appare come opzione, il dispositivo non ha completato la prerequisita iscrizione MDM.

6.4.2 Fallimenti nell'Autenticazione tra dispositivi (CDA)#

Sui dispositivi non gestiti, gli utenti spesso provano il flusso di Autenticazione tra dispositivi (CDA) (scansionando un codice QR sul PC con il loro telefono).

• Dipendenza dal Bluetooth: Il CDA richiede che il Bluetooth sia abilitato sia sul PC che sul telefono. Non hanno bisogno di essere associati, ma devono eseguire un handshake Bluetooth Low Energy (BLE) per dimostrare la prossimità. Consulta le passkey legate al dispositivo in Microsoft Authenticator per i dettagli.
• Blocco del criterio aziendale: Se il Bluetooth è disabilitato sui laptop aziendali tramite BIOS o GPO per motivi di "sicurezza", hai già interrotto il meccanismo principale per le passkey roaming.
• Blocco del Websocket: Il flusso CDA utilizza una connessione websocket a cable.ua5v.com o cable.auth.com. Firewall aziendali aggressivi o configurazioni Zscaler spesso bloccano questi domini, causando il blocco o l'errore silenzioso della scansione del codice QR. Consulta la Documentazione sulle passkey di Microsoft Authenticator.

6.5 B2B e identità esterne#

Un altro punto debole per le imprese è la gestione di consulenti esterni (ospiti B2B).

• Problema: Un consulente cerca di accedere a un sito SharePoint. Il tenant impone un criterio di Accesso Condizionato che richiede un "MFA resistente al phishing".
• Fallimento: Il consulente tenta di registrare una chiave FIDO2 nel tenant della risorsa. Questo fallisce. Entra ID non supporta gli utenti guest che registrano chiavi FIDO2 nel tenant delle risorse.
• Rimedio: Impostazioni di accesso tra tenant
  • Logica: Invece di costringere l'ospite a registrare una credenziale nel tuo tenant, dovresti fidarti della credenziale che utilizza nel suo tenant.
  • Configurazione: Vai su Identità esterne > Impostazioni di accesso tra tenant. Seleziona l'organizzazione partner. Sotto Attendibilità in entrata, spunta "Considera attendibile l'autenticazione a più fattori dai tenant di Microsoft Entra".
  • Risultato: Quando il consulente accede utilizzando una YubiKey nel proprio tenant di origine, il tuo tenant riceve un'attestazione che dice "MFA soddisfatta + Resistente al phishing". L'accesso è concesso senza che l'utente debba registrare nulla. Questo esternalizza la gestione del ciclo di vita delle credenziali al partner, riducendo le tue responsabilità e il carico di lavoro dell'helpdesk.

7. Strategie di recupero#

Spesso le decisioni sul recupero sono ancora in ritardo rispetto all'implementazione effettiva. Esistono molteplici opzioni di recupero a seconda delle esigenze della tua organizzazione.

7.1 Recupero Account Self-Service (SSAR) con Verified ID#

Il nuovo flusso di Recupero Account Self-Service (SSAR) di Microsoft Entra ID (in Anteprima) consente un recupero ad alta garanzia senza l'intervento dell'helpdesk.

1. Trigger: L'utente non riesce ad accedere. Seleziona "Recupera il mio account".
2. Verifica dell'Identità: L'utente viene reindirizzato a un fornitore di verifica dell'identità (IDV) di terze parti (es. Onfido, IDemia).
3. Controllo Documento: L'utente scansiona la sua patente di guida fisica, carta d'identità nazionale o passaporto utilizzando la fotocamera del cellulare.
4. Controllo vivacità: L'utente esegue un Face Check tramite un selfie. Questo viene confrontato con il documento di identità (e potenzialmente con la foto memorizzata in Entra ID). L'abbinamento utilizza le API Face di Azure AI Vision e viene condiviso solo un punteggio di confidenza. Nessun dato biometrico grezzo arriva all'applicazione.
5. Ripristino: In caso di successo, il sistema emette automaticamente un Temporary Access Pass (TAP) all'utente.
6. Nuova Registrazione: L'utente utilizza il TAP per registrare immediatamente una nuova passkey.

Consiglio: Questo percorso di recupero automatizzato e supportato dalla biometria è superiore al "Chiamare l'Helpdesk", che è vulnerabile all'ingegneria sociale (attacchi vocali Deepfake).

7.2 Recupero Assistito dal Manager con My Staff#

Se si desidera ridurre il carico sul Service Desk ma non si può abilitare un self-service completo, Microsoft Entra include una funzione di amministrazione delegata nativa chiamata My Staff (Personale).

• Come funziona: Delega autorizzazioni limitate ai "Team Manager" (tramite le Unità Amministrative in Entra).
• Flusso: Se un utente perde l'accesso, può contattare un amministratore locale delegato, che può utilizzare il portale My Staff per le attività di recupero supportate, come ripristinare una password o aggiornare un numero di telefono.
• Perché aiuta: Sposta il lavoro comune per il recupero degli account dal punto di assistenza centrale e velocizza il supporto.

7.3 Kiosk di recupero self-service (intranet)#

Poiché spesso gli utenti dispongono ancora di un laptop fidato e protetto da WHfB, è possibile creare una semplice pagina intranet "break glass".

• Struttura: Una semplice applicazione web interna che richiede l'accesso tramite WHfB (autenticazione forte).
• Azione: Una volta autenticato, l'utente clicca su "Ho un nuovo telefono". L'app utilizza l'API di Microsoft Graph (servizio in background) per generare un Temporary Access Pass (TAP) di breve durata e lo visualizza sullo schermo.
• Risultato: L'utente digita il TAP nel suo nuovo telefono per inizializzare l'app Microsoft Authenticator. Nessun coinvolgimento dell'helpdesk.

Questa è la leva chiave per ridurre i ripristini dei "metodi di autenticazione in chiaro" senza indebolire la politica. Se hai un robusto meccanismo laptop-come-bootstrap, il tuo onere di comunicazione diminuisce notevolmente poiché gli utenti possono recuperare l'accesso senza conoscere la sequenza perfetta.

8. Consigli per l'implementazione delle Passkey Enterprise#

Struttura il tuo lancio attorno alle Fasi di Maturità. Riconosci l'attrito ("La tecnologia è pronta, le operazioni sono difficili") e applica queste mitigazioni.

8.1 Azioni immediate (Fase "Fix-It")#

1. Controlla Bluetooth e Firewall: Assicurati che i laptop aziendali consentano il Bluetooth (per i controlli di prossimità) e inserisci in whitelist i domini di relay FIDO/WebAuthn (\*.cable.auth.com) per risolvere gli errori tra dispositivi.
2. Abilita l'Attendibilità Tra Tenant: Smetti di cercare di registrare le passkey dei guest. Configura l'Attendibilità In Entrata per l'MFA dei partner chiave per risolvere immediatamente i problemi di accesso B2B.
3. Implementa TAP per l'Onboarding: Rendi obbligatorio l'uso del Temporary Access Pass per l'onboarding di tutti i nuovi utenti per risolvere il blocco della registrazione causato dall'effetto "dell'uovo e della gallina".

8.2 Decisioni strategiche (Fase "Architettura")#

1. Adotta un modello "Hybrid Assurance":
   • Livello 0 (Amministratori): Applica Attestazione e Restrizioni chiave. Sono ammesse solo YubiKey/Hardware (AAL3).
   • Livello 1 (Forza lavoro): Disabilita l'applicazione dell'attestazione tramite Profili Passkey. Consenti le passkey sincronizzate per ridurre l'attrito e i costi (AAL2).
2. Pianifica per macOS: Distribuisci Platform SSO con il tuo MDM come percorso parallelo a Windows WHfB.

8.3 A prova di futuro (Fase "Ottimizzazione")#

1. Pianifica l'SSAR: Inizia un progetto pilota per il Recupero Account Self-Service con Verified ID per eliminare l'helpdesk come vettore di ingegneria sociale.
2. Autenticazione preferita dal sistema: Abilita questa politica per "aggiornare" automaticamente gli utenti alle passkey non appena ne registrano una, spingendo l'adozione senza un mandato rigido.
3. Distribuisci le Opzioni di Recupero: Implementa il TAP Assistito dal Manager tramite My Staff e/o un Kiosk di Recupero Self-Service.
4. Requisito Passkey in Intune: Valuta la possibilità di richiedere una passkey per l'iscrizione a Intune per forzare la registrazione anticipata sui nuovi dispositivi.

8.4 Matrice di risoluzione dei problemi#

9. Monitoraggio dell'implementazione con la Cartella di Lavoro per l'Accesso Senza Password Resistente al Phishing#

Microsoft ha rilasciato una Cartella di lavoro per l'accesso senza password resistente al phishing che le organizzazioni con registri in Azure Monitor possono utilizzare per tracciare i progressi dell'implementazione. Puoi accedervi tramite il centro di amministrazione di Entra sotto Monitoraggio > Cartelle di lavoro:

La cartella di lavoro presenta due sezioni principali:

9.1 Fase di disponibilità per la registrazione#

Usa questa scheda per analizzare i log di accesso e determinare quali utenti sono pronti per la registrazione rispetto a quali potrebbero essere bloccati. Puoi filtrare per piattaforma del sistema operativo (Windows, macOS, iOS, Android) e per tipo di credenziale (Passkey App Authenticator, Chiave di Sicurezza FIDO2, Autenticazione Basata su Certificati):

La cartella di lavoro mostra:

• Coppie Utente/Dispositivo pronte per la registrazione: utenti che possono registrare il tipo di credenziale selezionato
• Coppie Utente/Dispositivo non pronte: utenti che potrebbero riscontrare problemi di registrazione (es. versioni obsolete del sistema operativo)

Puoi esportare liste di utenti che necessitano di interventi correttivi (es. aggiornamenti OS, sostituzioni di dispositivi o opzioni di credenziali alternative).

9.2 Fase di idoneità all'applicazione#

Una volta che gli utenti sono pronti per l'autenticazione basata solo su metodi resistenti al phishing, usa la scheda di Idoneità all'Applicazione (Enforcement Readiness). Inizialmente, crea una politica di Accesso Condizionato Di Sola Segnalazione che richiede l'MFA resistente al phishing. Questo popola i registri di accesso con i dati che mostrano se l'accesso sarebbe stato bloccato se l'applicazione fosse stata attiva.

La dashboard mostra:

• Utenti totali nell'ambito di applicazione
• Successi della Sola Segnalazione - utenti che supererebbero l'applicazione della policy
• Politica non soddisfatta - utenti che verrebbero bloccati (analizza questi casi!)
• Ripartizioni per Stato del Dispositivo, Piattaforma del Dispositivo e App Client

Utilizza la scheda Ulteriore analisi dei dati per indagare sul perché certi utenti verrebbero bloccati. Questi dati ti aiutano a mirare agli utenti per interventi correttivi prima di abilitare l'imposizione delle regole.

9.3 Implementazione a ondate con monitoraggio dell'help desk#

Microsoft raccomanda di eseguire le implementazioni in ondate con intervalli di date flessibili. Monitora il volume dei ticket dell'help desk come segnale:

• Aumento del volume dei ticket: Rallenta implementazioni, comunicazioni e azioni di imposizione
• Diminuzione del volume dei ticket: Incrementa di nuovo le attività

Crea gruppi di sicurezza Microsoft Entra ID per ciascuna ondata e aggiungi progressivamente i gruppi alle tue policy. Questo evita di sopraffare i team di supporto.

10. Checklist per il pilota delle Passkey Sincronizzate#

Se l'obiettivo è utilizzare passkey sincronizzate senza la dipendenza da Microsoft Authenticator, segui questa configurazione per il progetto pilota:

1. Abilita passkey sincronizzate (anteprima) Segui Passkey sincronizzate (anteprima).

2. Utilizza i Profili Passkey (anteprima) e punta al gruppo pilota Crea/assegna un profilo che consenta le passkey sincronizzate come descritto nei Profili Passkey.

3. Non imporre l'attestazione (almeno per il gruppo pilota) L'imposizione dell'attestazione esclude le passkey sincronizzate secondo la documentazione sui concetti delle passkey (FIDO2).

4. Evita whitelist AAGUID troppo rigide all'inizio Inizia in modo permissivo per confermare il flusso, per poi stringere le restrizioni una volta che sai quali provider vuoi consentire. Consulta Abilita passkey (FIDO2).

5. Conferma che l'Accesso Condizionato non imponga Microsoft Authenticator Assicurati che le CA/forze di autenticazione consentano ancora il profilo passkey da te previsto (altrimenti sembra esserci una dipendenza da Microsoft Authenticator).

6. Convalida il modello di identità (membro rispetto a guest) Se gli utenti sono guest, verifica che il supporto atteso sia previsto nel tuo modello di tenant prima di spendere tempo nella messa a punto dei profili.

11. Conclusione#

L'implementazione delle passkey aziendali è operativamente complessa, ma la strada da seguire è ben definita. Ecco le risposte chiave, allineate alle principali domande operative sollevate in precedenza:

1. Passkey legate al dispositivo vs passkey sincronizzate: Le credenziali legate al dispositivo (es. Microsoft Authenticator, Windows Hello, YubiKey, smartcard) sono rigorosamente legate a un singolo dispositivo e soddisfano l'AAL3. Le passkey sincronizzate (es. Portachiavi iCloud, Google Password Manager) funzionano su più dispositivi e soddisfano l'AAL2. La maggior parte delle organizzazioni ha bisogno di entrambe: autenticatori hardware per gli amministratori (AAL3) e passkey sincronizzate per la forza lavoro in generale (AAL2).

2. Bootstrapping per i nuovi dipendenti: Usa il Temporary Access Pass (TAP) per risolvere il problema dell'uovo e della gallina in fase di onboarding. Per le implementazioni su larga scala, automatizzalo tramite l'API Graph. Per i casi d'uso ad alta garanzia, integra l'onboarding con Entra Verified ID e Face Check.

3. Recupero per la sostituzione del telefono: Offri più metodi di recupero: Kiosk di Recupero Self-Service (usa un laptop come dispositivo di bootstrap), TAP Assistito dal Manager tramite My Staff e SSAR (Recupero Account Self-Service) con Verified ID per i casi estremi.

4. Errori di configurazione: I passi falsi più frequenti includono l'imposizione globale dell'attestazione, la mancata abilitazione delle funzionalità in anteprima per le passkey sincronizzate, whitelist AAGUID troppo rigide e politiche di Accesso Condizionato (CA) che creano dipendenze circolari.

5. Ospiti B2B: Evita di registrare direttamente le passkey per i guest B2B nel tuo tenant. Invece, abilita l'Attendibilità di Accesso tra Tenant per convalidare le credenziali dal tenant di origine dell'ospite.

6. Chiavi hardware vs passkey mobili: Le chiavi di sicurezza hardware sono richieste per determinati ruoli ad alta sicurezza (amministratori, postazioni di lavoro condivise) ma presentano ostacoli logistici su larga scala. Le passkey mobili sono generalmente più pratiche per la forza lavoro.

7. macOS affiancato a Windows: Utilizza Platform SSO con JAMF/MDM per abilitare il supporto alle passkey su macOS parallelamente alle implementazioni su Windows. Pianifica i flussi di lavoro specifici per le piattaforme.

8. Misure proattive: Usa Intune per identificare i dispositivi inattivi e sollecitare gli utenti alla risoluzione prima che si verifichi un blocco. Valuta la possibilità di rendere la registrazione della passkey un prerequisito per l'iscrizione a Intune per incoraggiare un'adozione precoce. Crea un flusso di lavoro per il recupero self-service utilizzando i laptop come dispositivi di bootstrap.

La tecnologia è pronta. La sfida principale è l'esecuzione operativa. La pianificazione del recupero deve essere parte integrante fin dal primo giorno, non un pensiero a posteriori. Una volta che l'infrastruttura è solida, concentrati sull'ottimizzazione dell'adozione dell'accesso con passkey per assicurarti che diventino il metodo di autenticazione primario su tutta la tua forza lavoro.

Chi siamo

Corbado è la Passkey Intelligence Platform per i team CIAM che gestiscono l'autenticazione consumer su larga scala. Ti aiutiamo a vedere ciò che i log IDP e gli strumenti di analytics generici non mostrano: quali dispositivi, versioni di OS, browser e gestori di credenziali supportano i passkey, perché gli enrollment non si trasformano in login, dove il flusso WebAuthn fallisce e quando un aggiornamento di OS o browser interrompe silenziosamente il login — tutto senza sostituire Okta, Auth0, Ping, Cognito o il tuo IDP interno. Due prodotti: Corbado Observe aggiunge osservabilità per i passkey e qualsiasi altro metodo di login. Corbado Connect introduce passkey gestiti con analytics integrato (insieme al tuo IDP). VicRoads gestisce i passkey per oltre 5M di utenti con Corbado (+80 % di attivazione passkey). Parla con un esperto di Passkey →

Domande frequenti (FAQ)#

Perché l'abilitazione dell'MFA resistente al phishing in Accesso Condizionato blocca tutti i miei utenti?#

La creazione di un criterio di Accesso Condizionato che richiede MFA resistente al phishing per tutte le app cloud blocca immediatamente qualsiasi utente che non abbia ancora registrato una passkey, bloccando anche l'accesso alla pagina stessa di registrazione delle Informazioni di sicurezza. Questa dipendenza circolare, chiamata paradosso "Registra Informazioni di sicurezza", significa che devi emettere un Temporary Access Pass agli utenti interessati prima di abilitare l'applicazione in modo che possano completare la registrazione iniziale.

Come gestisco gli utenti guest B2B quando il mio tenant richiede MFA resistente al phishing?#

Entra ID non supporta la registrazione di chiavi FIDO2 da parte di utenti guest in un tenant di risorse, quindi il tentativo di applicare la registrazione delle passkey per i guest fallirà. La soluzione corretta consiste nel configurare le Impostazioni di accesso tra tenant in Identità esterne per considerare attendibili le attestazioni MFA dal tenant di origine del guest, il che significa che una YubiKey utilizzata nella propria organizzazione soddisfa il requisito MFA resistente al phishing senza alcuna registrazione nel tuo tenant.

Cosa causa il fallimento silenzioso dell'autenticazione tramite codice QR tra dispositivi durante l'accesso con una passkey?#

L'autenticazione tra dispositivi richiede che il Bluetooth sia abilitato sia sul PC che sul telefono per completare un handshake di prossimità BLE, quindi qualsiasi criterio aziendale che disabilita il Bluetooth interromperà l'intero flusso. Il flusso utilizza anche una connessione WebSocket a cable.auth.com, che i firewall o le configurazioni Zscaler bloccano di frequente, causando il blocco o l'errore della scansione del codice QR senza un chiaro messaggio di errore.

Come posso monitorare quali dipendenti sono pronti per l'applicazione dell'MFA resistente al phishing prima di attivarla?#

La Cartella di lavoro per l'accesso senza password resistente al phishing di Microsoft, accessibile tramite l'interfaccia di amministrazione di Entra in Monitoraggio > Cartelle di lavoro, fornisce una visualizzazione della Disponibilità alla registrazione che mostra quali coppie utente/dispositivo possono effettuare la registrazione per piattaforma e tipo di credenziale. Per verificare l'idoneità all'applicazione, crea un criterio di Accesso Condizionato di sola segnalazione che richiede un'MFA resistente al phishing, in modo che i registri di accesso rivelino quali utenti verrebbero bloccati prima di attivare l'applicazione in tempo reale.

Qual è la migliore strategia di recupero per i dipendenti che acquistano un nuovo telefono e perdono l'accesso alla loro passkey?#

L'approccio consigliato è strutturato a livelli: un Chiosco di recupero self-service che utilizza un laptop protetto da WHfB genera un Temporary Access Pass tramite Graph API e copre la maggior parte dei casi senza l'intervento dell'helpdesk. Per gli utenti senza laptop, il TAP assistito dal manager tramite il portale Personale delega il recupero ai manager diretti, mentre il Recupero account self-service con l'analisi biometrica Face Check di Entra Verified ID gestisce i casi limite che richiedono una nuova verifica completa dell'identità.

Ulteriori letture#

Per approfondimenti sulle implementazioni aziendali FIDO2/passkey, segui esperti come Merill Fernando e Jan Bakker che pubblicano regolarmente guide pratiche sull'autenticazione in Microsoft Entra.