Il modello moderno: una sola policy per tutti i metodi
In Microsoft Entra ID la configurazione dei metodi di verifica vive in un unico posto: la Authentication methods policy (Entra admin center → Protection → Authentication methods). Ha sostituito i due contenitori legacy che l’esame ama ancora citare:
| Contenitore legacy | Cosa gestiva | Stato oggi |
|---|---|---|
| Legacy MFA service settings | metodi MFA per tenant, app password, trusted IPs | consolidato nella policy moderna |
| SSPR → Authentication methods | metodi per il reset password | consolidato nella policy moderna |
| Per-user MFA (Enabled/Enforced/Disabled) | stato MFA sul singolo utente | da abbandonare: si usa Conditional Access |
La regola operativa da ricordare: abilitare un metodo si fa nella policy, richiedere MFA si fa in Conditional Access. La policy dice cosa l’utente può registrare, la Conditional Access dice quando deve usarlo.
Ogni metodo si abilita con ambito per gruppo (include/exclude), che è la leva pratica per i rollout a ondate: security key solo al gruppo Kiosk-Users, passkey al gruppo pilota, e così via.
Scegliere il metodo in base al requisito
| Requisito / scenario | Metodo consigliato | Perché |
|---|---|---|
| Utente kiosk o di reparto senza smartphone | FIDO2 security key (o token hardware OATH) | non richiede telefono né SIM, funziona su dispositivi condivisi |
| Dirigente in viaggio, bersaglio di phishing | passkey (FIDO2) o Windows Hello for Business + CA con authentication strength Phishing-resistant MFA | l’associazione crittografica al dominio blocca i proxy AiTM |
| Nuovo assunto, primo giorno, nessun dispositivo registrato | Temporary Access Pass (TAP) | credenziale a tempo che consente il bootstrap di WHfB/passkey senza password |
| Dipendente con PC aziendale Entra joined | Windows Hello for Business | MFA implicita al sign-in (qualcosa che hai + PIN/biometria) |
| Utente standard con mobile | Microsoft Authenticator push con number matching e contesto aggiuntivo | forte, gratuito, con protezioni anti-fatigue |
| Fallback residuale | SMS / chiamata vocale | ammesso, ma è il metodo più debole |
Temporary Access Pass merita due parole in più: si configura nella policy (durata minima/massima, lunghezza, uso singolo o multiplo) e si emette per utente da Entra ID → Authentication methods dell’utente. È la risposta corretta a qualunque scenario di onboarding, sostituzione di un telefono smarrito o utente che deve registrare una security key da remoto.
Governare l’adozione
- Registration campaign: intercetta chi si autentica via SMS o voce e lo invita a passare a Microsoft Authenticator, con possibilità di posticipo limitato (snooze).
- System-preferred MFA: Entra propone automaticamente all’utente il metodo più forte fra quelli registrati — non è una policy di blocco, è un riordino della presentazione.
- Authentication strengths in Conditional Access: invece di “richiedi MFA” generico, si impone quale combinazione di metodi è accettabile (per esempio solo phishing-resistant per chi ha il ruolo Global Administrator).
- Report Authentication methods activity: mostra registrazioni e utilizzo per metodo, utile per verificare la copertura prima di irrigidire le policy.
Security Defaults vs Conditional Access
Security Defaults è l’MFA chiavi in mano per i tenant senza licenze: MFA obbligatoria per tutti entro 14 giorni, MFA sempre per i ruoli privilegiati, blocco dell’autenticazione legacy. Non è personalizzabile: niente esclusioni, niente trusted location, niente break-glass account.
Conditional Access richiede Microsoft Entra ID P1 (incluso in Microsoft 365 E3/E5 e Business Premium) e dà granularità per utente, app, rischio, dispositivo e location. I due sistemi non possono coesistere: per creare policy di Conditional Access occorre prima disattivare Security Defaults.
Trappole tipiche d’esame
- Scenario: il tenant ha Security Defaults attivi e vi si chiede di escludere un account break-glass dall’MFA → risposta giusta: non è possibile con Security Defaults; disattivarli e implementare una policy di Conditional Access con l’account escluso. Non esiste un’esclusione nativa in Security Defaults.
- Scenario: gli utenti si lamentano di dover digitare due cifre nell’app Authenticator e chiedono di tornare all’approvazione con un semplice tap → risposta giusta: il number matching non è disattivabile, è enforced a livello di servizio. Si può solo modulare il contesto aggiuntivo (nome applicazione, geolocalizzazione).
- Scenario: un dirigente in viaggio subisce un attacco AiTM e la sessione MFA via SMS viene proxata → risposta giusta: passare a un metodo phishing-resistant (passkey FIDO2 o Windows Hello for Business) e imporlo con una authentication strength in Conditional Access. SMS resta vulnerabile a SIM swap e intercettazione ed è il metodo più debole in assoluto.
- Scenario: nuovo assunto in remoto che deve registrare una security key ma non ha ancora credenziali forti → risposta giusta: emettere un Temporary Access Pass, non resettare la password né disattivare temporaneamente l’MFA.
- Scenario: un utente ha MFA “Enforced” nel portale per-user mentre le policy di Conditional Access sono già attive → risposta giusta: lo stato per-user prevale e chiede MFA a ogni accesso, generando doppie richieste; va riportato a Disabled e la protezione va delegata interamente alla Conditional Access.