La Multi-Factor Authentication (MFA) è il controllo che, da sola, blocca la stragrande maggioranza degli attacchi basati su credenziali compromesse. Da amministratore di identità non basta “attivarla”: devi sapere quali metodi rendere disponibili, con quale robustezza relativa, e soprattutto come applicarla in modo governabile. In Microsoft Entra ID questo significa distinguere tra la configurazione dei metodi (Authentication methods policy) e l’enforcement (Conditional Access o Security Defaults).

I metodi di autenticazione e la loro robustezza

Non tutti i secondi fattori offrono la stessa protezione. In ordine di robustezza decrescente:

  • Passkey (FIDO2) e Windows Hello for Business: phishing-resistant perché legati crittograficamente al dominio del servizio; il segreto non lascia mai il dispositivo. Sono il target ideale per gli amministratori.
  • Certificate-Based Authentication (CBA): phishing-resistant, tipica di scenari con smart card o PKI aziendale.
  • Microsoft Authenticator push con number matching: robusto e ampiamente diffuso. Il number matching (ormai comportamento predefinito) obbliga l’utente a digitare nell’app il numero mostrato a schermo, neutralizzando gli attacchi di MFA fatigue / prompt bombing. Il passwordless phone sign-in con Authenticator è un ulteriore passo avanti.
  • OATH TOTP (Authenticator in modalità codice o token hardware): codici a tempo a 6 cifre; solidi ma non phishing-resistant, perché l’utente può digitare il codice su un sito fraudolento.
  • SMS e chiamata vocale: da considerare fallback deboli. Vulnerabili a SIM swapping, intercettazione SS7 e phishing in tempo reale. Non sono phishing-resistant e Microsoft ne sconsiglia l’uso come metodo primario.

La logica architetturale è: privilegiare i metodi phishing-resistant per i ruoli privilegiati, spingere Authenticator per l’utenza generale, e relegare SMS/voce a scenari residuali (es. dispositivi legacy).

Perché l’enforcement moderno passa da Conditional Access

Storicamente l’MFA si abilitava per-utente (lo stato Enabled/Enforced nella pagina legacy “per-user MFA”). Questo approccio è binario e privo di contesto: richiede il secondo fattore sempre, ovunque, senza considerare rischio, dispositivo, localizzazione o applicazione.

L’enforcement moderno usa le Conditional Access policy, che valutano segnali (utente/gruppo, app, piattaforma, stato del dispositivo, rischio di sign-in con Identity Protection, localizzazione) e concedono l’accesso solo se sono soddisfetti dei grant control, come Require multifactor authentication o Require authentication strength. Le Authentication Strengths permettono di esigere non “un” MFA qualsiasi, ma una combinazione specifica (es. solo metodi phishing-resistant per gli admin). Questo dà granularità, tracciabilità e coerenza — impossibili con il modello per-utente.

Conditional Access richiede però una licenza Entra ID P1 (P2 per le policy basate sul rischio).

Security Defaults: la baseline per i tenant senza P1

Per i tenant privi di licenza P1, Microsoft offre i Security Defaults: un set preconfezionato e gratuito che impone la registrazione MFA a tutti gli utenti (tipicamente via Authenticator entro 14 giorni), richiede MFA per i ruoli amministrativi, blocca l’autenticazione legacy (protocolli come POP, IMAP, SMTP AUTH che aggirano l’MFA) e protegge le operazioni privilegiate.

Il compromesso è la rigidità: Security Defaults non è configurabile (nessuna esclusione, nessun contesto). È tutto-o-niente. Nel momento in cui servono policy mirate — locations attendibili, esclusioni per account break-glass, requisiti di forza differenziati — si passa a P1 e si disattivano i Security Defaults per adottare Conditional Access.

Trappole tipiche d’esame

  • Scenario: hai attivato Security Defaults ma devi escludere un account break-glass dall’MFA. → Risposta: impossibile, i Security Defaults non ammettono esclusioni; disattivali e usa una Conditional Access policy con esclusione (richiede P1).
  • Scenario: alcuni utenti hanno per-user MFA impostato su Enforced e vuoi introdurre Conditional Access. → Risposta: i due sistemi coesistono male e generano prompt duplicati/conflitti; riporta lo stato per-utente a Disabled e gestisci tutto tramite Conditional Access.
  • Scenario: gli utenti subiscono attacchi di prompt bombing e approvano push per errore. → Risposta: abilita/verifica il number matching in Authenticator (già default), non passare a SMS.
  • Scenario: policy che richiede protezione phishing-resistant per gli amministratori. → Risposta: usa un grant control con Authentication Strength che ammette solo FIDO2/passkey, Windows Hello for Business o CBA — non SMS o voce.
  • Scenario: gli utenti aggirano l’MFA via IMAP/SMTP. → Risposta: blocca la legacy authentication (automatico con Security Defaults, oppure con una specifica CA policy che blocca i client legacy).