Introduzione: le passkey non bastano da sole
Le passkey rappresentano uno dei passi più significativi nell’evoluzione dell’autenticazione moderna. Basate sullo standard FIDO2, eliminano le password tradizionali sostituendole con coppie di chiavi crittografiche legate al dispositivo e all’identità biometrica dell’utente. Su Microsoft Entra ID, abilitare le passkey è diventato relativamente semplice — il vero problema emerge subito dopo: abilitarle non significa renderle obbligatorie.
Molte organizzazioni configurano le passkey come metodo di autenticazione disponibile e si fermano lì, convinte di aver rafforzato significativamente la loro postura di sicurezza. In realtà, senza un enforcement esplicito tramite Conditional Access, l’utente può ancora scegliere di autenticarsi con password e SMS — esattamente come prima. Questo scenario introduce un rischio spesso sottovalutato: il downgrade attack.
Cos’è un downgrade attack nel contesto dell’autenticazione
Un downgrade attack, nell’ambito dell’autenticazione, non è un attacco sofisticato nel senso tradizionale del termine. È semplicemente la possibilità di utilizzare un metodo di autenticazione meno sicuro rispetto a quello ideale. Dal punto di vista dell’utente, si manifesta come il familiare link “Accedi in un altro modo” nella schermata di login di Microsoft.
Gli attaccanti dispongono di toolkit avanzati — come Evilginx2 o strumenti analoghi — capaci di rilevare automaticamente quali metodi di autenticazione sono disponibili per un determinato account. Se il sistema accetta password + SMS come alternativa alla passkey, l’attaccante sfrutterà il percorso più debole. La passkey registrata diventa di fatto irrilevante dal punto di vista della sicurezza pratica.
Il problema non è tecnico, è organizzativo: manca il tassello dell’enforcement. Ed è qui che entra in gioco Conditional Access insieme alle Authentication Strengths.
Authentication Strengths: il fondamento dell’enforcement
Microsoft Entra ID offre il concetto di Authentication Strength come meccanismo per specificare non solo che si richiede la MFA, ma quali specifici metodi sono accettati. Esistono tre Authentication Strengths predefinite:
- Multifactor authentication — la più permissiva, accetta password + qualsiasi secondo fattore (incluso SMS)
- Passwordless MFA — richiede metodi senza password, come Windows Hello o Microsoft Authenticator
- Phishing-resistant MFA — la più restrittiva, accetta solo certificati, Windows Hello for Business, passkey FIDO2
Il problema è che la maggior parte delle organizzazioni usa ancora la prima categoria — quella meno restrittiva. Alcune sono migrate dalla vecchia grant control “Require MFA”, ma si sono fermate al livello base. Usare Phishing-resistant MFA come Authentication Strength è già un passo corretto, ma la vera potenza arriva con le Custom Authentication Strengths.
Custom Authentication Strengths: controllo granulare
Le Authentication Strengths personalizzate permettono di specificare esattamente quali metodi sono ammessi, incluso il vincolo a specifici tipi di passkey tramite gli AAGUID (Authenticator Attestation GUID). Ogni tipo di passkey certificata — YubiKey 5C NFC, Google Titan, Microsoft Authenticator su iOS — ha il proprio AAGUID. Limitare l’accesso a specifici AAGUID garantisce che solo i dispositivi approvati dall’organizzazione possano autenticarsi.
Questo livello di granularità è particolarmente importante per gli account amministrativi, dove il rischio di compromissione è massimo.
Configurare la policy Conditional Access di baseline
Il punto di partenza consigliato è una policy di Conditional Access che prenda di mira un gruppo pilota di utenti che hanno già registrato una passkey. La policy deve:
- Essere creata inizialmente in modalità report-only per monitorare l’impatto senza bloccare gli accessi
- Targetizzare un security group contenente gli utenti del pilota
- Usare la grant control “Require authentication strength” con l’Authentication Strength appropriata
- Essere attivata in produzione solo dopo aver verificato i log di accesso e confermato che tutti gli utenti del gruppo hanno una passkey funzionante
Man mano che più utenti registrano le passkey, il gruppo viene espanso. Questo approccio graduale riduce il rischio di lockout e costruisce fiducia nelle varie business unit.
Account amministrativi: requisiti più stringenti
Gli account privilegiati richiedono una policy separata e più restrittiva. Le considerazioni principali sono:
- Creare una Custom Authentication Strength dedicata agli amministratori che accetti solo passkey specifiche (con AAGUID approvati)
- La policy Conditional Access per gli admin deve targetizzare esclusivamente le identità amministrative
- Aggiungere condizioni supplementari: accesso solo da reti trusted, dispositivi compliant o hybrid-joined
- Mantenere policy separate per accessi admin e utenti standard: facilita il troubleshooting e riduce la complessità
Un pattern comune negli ambienti Entra è la mancanza di protezioni specifiche per gli account amministrativi. Spesso questi account non hanno policy Conditional Access dedicate, o le policy esistenti si basano su MFA generica anziché su metodi phishing-resistant. Gli account amministrativi sono il bersaglio primario degli attaccanti: una compromissione a questo livello equivale a una compromissione del tenant.
Come usare i Sign-in Logs per verificare l’efficacia
Una volta attivate le policy in report-only, i log di accesso di Entra ID mostrano il risultato teorico della policy per ogni accesso. Per ogni evento di login è possibile vedere quale Authentication Strength è stata valutata, se l’accesso avrebbe soddisfatto i requisiti e quale metodo è stato effettivamente utilizzato.
Filtrando per gli utenti del gruppo pilota è possibile identificare chi ancora non ha registrato una passkey o chi tenta di usare metodi alternativi. Questo permette un’azione proattiva prima di attivare la policy in enforcement completo.
Conclusione: l’enforcement è dove il valore si manifesta
Le passkey sono una tecnologia potente e in rapida evoluzione, soprattutto nell’ecosistema Microsoft. Ma la loro efficacia dipende interamente dall’enforcement. Distribuire passkey senza Conditional Access che ne imponga l’uso equivale a blindare la porta principale lasciando le finestre aperte.
La sequenza corretta è: abilitare le passkey → creare le Custom Authentication Strengths appropriate → configurare le Conditional Access policy in report-only → espandere gradualmente il gruppo → attivare l’enforcement. Gli account amministrativi richiedono attenzione immediata e policy separate con requisiti più stringenti, incluso il binding a AAGUID specifici.
In un contesto di minacce sempre più sofisticate — con phishing kit come Tycoon 2FA che aggirano la MFA tradizionale — i metodi phishing-resistant non sono più un’opzione premium: sono il requisito minimo per chi gestisce identità critiche nel cloud Microsoft.
Fonte: Passkeys Aren’t Enough: Why Enforcement Matters in Entra ID — Petri IT Knowledgebase, Brandon Colley (TrustedSec)