MFA su Microsoft 365: le configurazioni che contano davvero

L'autenticazione multi-fattore su Microsoft 365 non è una raccomandazione — è un requisito operativo. Non nel senso che qualcuno ve lo chiede: nel senso che senza MFA qualsiasi account con una password debole o rubata può essere compromesso in pochi minuti. Il problema non è decidere se abilitarla. È come farlo nel modo giusto, senza creare eccezioni che annullano tutta la protezione e senza una settimana di utenti bloccati.

Perché il MFA è obbligatorio — non negoziabile

Le credenziali vengono rubate. Attraverso phishing, credential stuffing con liste di password esposte in violazioni di altri servizi, keylogger, social engineering. Non è una questione di quanto siano sicure le password — le password da sole non sono sufficienti.

Il MFA aggiunge un secondo fattore che l'attaccante, anche con la password corretta, non ha: un codice temporaneo sull'app del telefono, una notifica da approvare, una chiave hardware fisica. Anche in caso di password compromessa, l'accesso non riesce senza il secondo fattore.

MFA per-utente vs Conditional Access: la differenza che conta

Esistono due meccanismi distinti in Microsoft 365 per applicare il MFA. La differenza non è solo tecnica — è strategica.

MFA per-utente (legacy)

Il MFA per-utente si configura in aka.ms/mfasetup o nel portale legacy di Entra ID. È una casella di spunta per account: l'utente ha MFA abilitato o non ce l'ha. Non dipende dal contesto di accesso — l'utente viene sempre sfidato, dall'ufficio come dall'estero, da un dispositivo managed come da un computer pubblico.

Il MFA per-utente è l'approccio legacy. Funziona, ma non è flessibile e non scala bene. Non permette di fare eccezioni intelligenti (es. non richiedere MFA dentro la rete aziendale) né di combinare il MFA con altri controlli (es. dispositivo compliant).

MFA tramite Conditional Access (raccomandato)

Il Conditional Access gestisce il MFA come una delle condizioni da soddisfare per accedere. Invece di abilitare MFA sull'account, si crea una policy: tutti gli utenti che accedono a tutte le applicazioni devono soddisfare MFA. Il risultato finale è lo stesso — l'utente viene sfidato — ma il motore che decide quando è Conditional Access, non un attributo fisso sull'account.

I metodi di autenticazione: cosa abilitare e cosa disabilitare

Non tutti i metodi di MFA hanno lo stesso livello di sicurezza. Questa è la gerarchia, dalla più sicura alla meno sicura:

• Chiavi FIDO2 / passkey: il metodo più sicuro. Una chiave hardware fisica (YubiKey, ecc.) o passkey registrata sul dispositivo. Non è phishable — l'autenticazione è legata al dominio dell'applicazione.
• Microsoft Authenticator (numero matching): l'app mostra un numero a due cifre che l'utente deve trovare nella notifica e selezionare. Resiste all'MFA fatigue (attacchi che bombardano l'utente di notifiche sperando che ne approvi una).
• Microsoft Authenticator (notifica push semplice): notifica "Approva?" senza verifica aggiuntiva. Efficace contro phishing standard, vulnerabile all'MFA fatigue.
• App authenticator con codice TOTP: codice a 6 cifre generato dall'app (Google Authenticator, Authy, ecc.). Non phishable in modo semplice, ma non protegge da proxy AiTM avanzati.
• SMS / chiamata telefonica: il metodo meno sicuro. SIM swapping, intercettazione SMS, numeri VoIP condivisi. Meglio di niente, ma da considerare come fallback e non come metodo primario.

La configurazione raccomandata per la maggior parte dei tenant M365:

• Abilitare: Microsoft Authenticator con number matching, passkey/FIDO2
• Mantenere come fallback: codici TOTP da app di terze parti
• Disabilitare: SMS come metodo primario (mantenere solo come fallback di emergenza), chiamata telefonica

Come fare il rollout senza una ondata di ticket

Il rollout del MFA genera resistenza non perché gli utenti non vogliano sicurezza, ma perché spesso si trovano a configurare il secondo fattore nel momento sbagliore — mentre stanno cercando di accedere a qualcosa di urgente.

Il processo che riduce i ticket al minimo:

1. Comunicare prima

Avvisare gli utenti con almeno una settimana di anticipo. Spiegare cosa cambierà, cosa devono fare (scaricare Microsoft Authenticator, registrare il secondo fattore) e quando. Non lanciare il MFA di sorpresa — anche se tecnicamente funziona, crea una cattiva esperienza e genera ticket inutili.

2. Aprire un periodo di registrazione autonoma

Prima di attivare l'obbligo, aprire una finestra in cui gli utenti possono registrare volontariamente il loro secondo fattore. Usare la funzione di "registrazione combinata" di Entra ID (aka.ms/mysecurityinfo) che guida l'utente nella configurazione.

3. Attivare in Report-only prima del go-live

Come descritto nell'articolo su Conditional Access: attivare la policy in Report-only per una settimana, verificare nei log chi avrebbe problemi, risolvere i casi edge prima dell'attivazione reale.

4. Rollout per gruppo

Attivare prima per il team IT, poi per i manager, poi per il resto. Avere sempre disponibile qualcuno che possa aiutare gli utenti che si bloccano nelle prime ore.

I casi edge: account di servizio, sale riunioni, VIP

Alcuni account pongono sfide specifiche per il MFA:

Account di servizio

Gli account usati dalle integrazioni di terze parti (sincronizzazioni, automazioni, connettori) spesso non supportano MFA interattivo. La soluzione corretta non è escluderli dal MFA — è passare a metodi di autenticazione non interattivi (client credentials, certificati, managed identity). Se un'integrazione richiede username e password senza supporto MFA, è il momento di aggiornarla o sostituirla.

Account di sala riunioni (Room mailbox)

Le room mailbox di Exchange Online non sono account utente nel senso tradizionale — sono account di risorse. Non vengono usati per l'accesso interattivo e non richiedono MFA. Vanno gestiti correttamente come resource account in Entra ID, non come utenti standard.

Utenti VIP e resistenza al cambiamento

Il CEO che dice "io non uso il telefono per queste cose" è un caso classico. È anche il caso più delicato: un account executive compromesso ha accesso a informazioni critiche. Non si può esentare dal MFA in base al ruolo aziendale — se mai, il contrario. La conversazione va fatta a livello di rischio per l'organizzazione, non di preferenze personali.

Security Defaults vs Conditional Access: quando usare uno o l'altro

Microsoft ha introdotto i Security Defaults per i tenant che non hanno licenze Entra ID P1 o superiori. Sono una serie di impostazioni di sicurezza preconfigurare che includono MFA obbligatorio per tutti, blocco dell'autenticazione legacy e protezione degli account amministrativi.

Security Defaults vs Conditional Access non è una scelta arbitraria — dipende dalle licenze disponibili:

• Usate Security Defaults se avete Business Basic o Business Standard e non avete Entra ID P1. Sono meglio di niente, anche se non sono configurabili.
• Usate Conditional Access se avete Business Premium, E3 o E5. I Security Defaults vanno disabilitati prima di attivare Conditional Access — non usateli insieme.
• Non disabilitate i Security Defaults senza attivare immediatamente Conditional Access. Il periodo di tempo tra la disabilitazione e l'attivazione delle policy CA lascia il tenant senza protezione baseline.

La sequenza corretta per passare da Security Defaults a Conditional Access: creare le policy CA in Report-only → verificare l'impatto → attivare le policy CA → disabilitare i Security Defaults. Mai nell'ordine inverso.