Multi-Factor Authentication (MFA): cos’è, come funziona e come protegge l’azienda
La Multi-Factor Authentication, o MFA, è un sistema di autenticazione che richiede due o più prove indipendenti prima di autorizzare l’accesso a un account, un’applicazione o una risorsa aziendale. Riduce drasticamente il rischio legato a password rubate, riutilizzate o compromesse, ma la sua efficacia dipende dai metodi utilizzati, dalle policy di accesso e dalla capacità dell’organizzazione di gestire eccezioni, recovery e account privilegiati.
Nel 2026 non è sufficiente chiedersi se “la MFA è attiva”. Occorre verificare se gli utenti sono realmente coperti, se gli amministratori usano metodi resistenti al phishing, se esistono protocolli legacy o esclusioni permanenti e se Conditional Access applica requisiti diversi in base alla sensibilità della risorsa.
Cos’è la Multi-Factor Authentication
La Multi-Factor Authentication combina fattori appartenenti a categorie differenti. Una password, da sola, è un segreto che può essere sottratto tramite phishing, malware, password spray o credential stuffing. La MFA aggiunge una seconda prova indipendente: possesso di un dispositivo o di una chiave crittografica, oppure verifica biometrica.
Non tutti i metodi offrono però lo stesso livello di protezione. Un codice SMS migliora la sicurezza rispetto alla sola password, ma non è equivalente a una passkey FIDO2, a Windows Hello for Business o a una chiave di sicurezza FIDO2. Per questo la progettazione moderna deve distinguere tra MFA generica e autenticazione resistente al phishing.
Come funziona la MFA
In un flusso moderno il provider di identità non verifica soltanto una password. Valuta anche la policy assegnata, l’applicazione richiesta, il tipo di dispositivo, la posizione, il ruolo dell’utente e, quando disponibili e correttamente licenziati, i segnali di rischio.
- L’utente avvia l’accesso con password oppure con un metodo passwordless.
- Microsoft Entra ID o il provider di identità verifica il metodo primario e applica le policy.
- Se necessario viene richiesto un secondo fattore oppure una specifica authentication strength.
- L’accesso viene consentito solo se il metodo utilizzato soddisfa i requisiti previsti per quella risorsa.
Il risultato è un controllo adattivo: una normale applicazione può accettare una MFA standard, mentre un portale amministrativo o una risorsa critica può richiedere esclusivamente metodi phishing-resistant.
I fattori di autenticazione
Categoria | Descrizione | Esempi |
Qualcosa che conosci | Informazione nota all’utente | Password, PIN |
Qualcosa che possiedi | Dispositivo o credenziale crittografica sotto il controllo dell’utente | Smartphone registrato, passkey, security key FIDO2, certificato |
Qualcosa che sei | Caratteristica biometrica | Impronta digitale, volto, biometria del dispositivo |
Posizione, indirizzo IP, rischio, conformità del dispositivo e fascia oraria sono segnali contestuali usati dalle policy; non costituiscono automaticamente un fattore di autenticazione indipendente.
Quali metodi MFA scegliere in azienda
Metodo | Resistenza al phishing | Uso consigliato | Valutazione |
Passkey FIDO2 / chiave di sicurezza FIDO2 | Alta | Amministratori, utenti ad alto impatto, risorse sensibili | Preferibile |
Windows Hello for Business | Alta | Postazioni Windows gestite | Preferibile |
Certificate-Based Authentication (CBA) | Alta | Scenari enterprise e identità regolamentate | Molto forte |
Microsoft Authenticator push con number matching | Media | Baseline utenti standard | Buona baseline |
OATH TOTP | Media-bassa | Fallback controllato | Non phishing-resistant |
SMS / chiamata vocale | Bassa | Transizione o emergenza | Da ridurre |
Per ruoli amministrativi, executive, finanza, HR e accessi a risorse ad alto impatto è opportuno privilegiare metodi resistenti al phishing. Per gli utenti standard, Microsoft Authenticator può rappresentare una baseline operativa valida, purché inserita in una strategia di Conditional Access, monitoraggio e formazione.
Passkey FIDO2: il passaggio dalla MFA tradizionale alla phishing-resistant authentication
Le passkey FIDO2 utilizzano crittografia a chiave pubblica e sono legate alla relying party corretta. Questo rende molto più difficile trasferire una credenziale su un sito di phishing rispetto a password, SMS o codici OTP.
Microsoft Entra ID supporta passkey associate al dispositivo e passkey sincronizzate. Le passkey possono essere archiviate, a seconda dello scenario e delle policy aziendali, in chiavi di sicurezza FIDO2, in Microsoft Authenticator o in provider passkey supportati. Le organizzazioni possono utilizzare i profili Passkey per definire tipologia, attestazione e restrizioni sugli authenticator consentiti.
Per le applicazioni sensibili, Conditional Access può applicare una Authentication Strength phishing-resistant e richiedere metodi come passkey FIDO2, Windows Hello for Business o autenticazione basata su certificati.
MFA in Microsoft 365 e Microsoft Entra ID
Negli ambienti Microsoft 365 la protezione MFA viene orchestrata da Microsoft Entra ID. La configurazione moderna si basa sulla Authentication Methods Policy, su Security Defaults oppure su Conditional Access, e sulle Authentication Strengths.
Security Defaults
I Security Defaults forniscono una baseline disponibile anche senza Microsoft Entra ID P1. Sono adatti ai tenant che non richiedono una gestione granulare delle policy. Non vanno combinati con Conditional Access: quando l’organizzazione necessita di controlli differenziati per utenti, applicazioni o contesti, la strategia deve passare a Conditional Access.
Conditional Access
Conditional Access richiede Microsoft Entra ID P1, incluso ad esempio in Microsoft 365 Business Premium e in diversi piani enterprise. Consente di applicare policy in base a utenti, ruoli, applicazioni, posizione, device state e altri segnali.
Le policy basate sul rischio utente o sul rischio di accesso richiedono invece Microsoft Entra ID P2 / Identity Protection. Questa distinzione è importante nella progettazione e nel licensing della baseline.
Authentication Strengths
Le Authentication Strengths specificano quali combinazioni di metodi sono accettabili per una determinata risorsa. Microsoft mette a disposizione livelli predefiniti, tra cui MFA, passwordless MFA e phishing-resistant MFA, oltre a strength personalizzate. Questo permette di evitare una policy uniforme e richiedere autenticazione più forte dove il rischio è maggiore.
Baseline tecnica MFA consigliata
- Copertura MFA per tutti gli utenti, evitando esclusioni permanenti non documentate.
- Policy dedicate ai ruoli amministrativi e agli utenti ad alto impatto.
- Metodi phishing-resistant per accessi privilegiati e risorse critiche.
- Blocco o progressiva eliminazione dei protocolli di autenticazione legacy.
- Riduzione di SMS e chiamate vocali come metodi ordinari.
- Authentication Methods Policy gestita centralmente e coerente con i gruppi target.
- Procedure di onboarding, recovery e sostituzione dispositivo documentate.
- Almeno due account di accesso di emergenza cloud-only, separati dagli account amministrativi ordinari e protetti con metodi phishing-resistant.
- Pilot e modalità report-only prima dell’enforcement generalizzato di Conditional Access.
- Monitoraggio di modifiche ai metodi di autenticazione, accessi anomali e utilizzo degli account di emergenza.
Perché la MFA può non bastare
MFA fatigue: L’attaccante genera richieste push ripetute nella speranza che l’utente ne approvi una. Number matching, policy corrette e formazione riducono il rischio.
Adversary-in-the-Middle: Un proxy di phishing può intercettare la sessione e tentare di sottrarre cookie o token. I metodi FIDO2/passkey sono progettati per offrire una resistenza superiore a questi scenari.
Session token theft: Un malware o un browser compromesso può riutilizzare una sessione già autenticata. Servono endpoint security, controllo dispositivo, session controls e rilevamento del rischio.
SIM swap: SMS e voce dipendono dal numero telefonico e sono esposti a tecniche di trasferimento fraudolento o intercettazione.
Legacy authentication: Protocolli o applicazioni non compatibili con MFA possono creare percorsi di bypass e devono essere censiti, aggiornati, isolati o protetti con controlli compensativi.
Forma gli utenti a riconoscere phishing e richieste MFA anomale
Come implementare la MFA in azienda
- Inventario — Mappare utenti, ruoli privilegiati, account di servizio, applicazioni SaaS, VPN, sistemi legacy, protocolli e device.
- Segmentazione — Definire livelli di protezione differenti per utenti standard, amministratori, executive e applicazioni sensibili.
- Authentication Methods Policy — Abilitare solo i metodi ammessi per i gruppi target e pianificare la riduzione dei metodi deboli.
- Passkey e phishing resistance — Definire quali gruppi devono usare passkey, Windows Hello for Business, security key FIDO2 o CBA.
- Emergency access — Mantenere almeno due account cloud-only dedicati, con credenziali separate e monitoraggio ad alta priorità.
- Pilot — Testare le policy su gruppi rappresentativi e usare report-only dove applicabile.
- Rollout — Estendere progressivamente le policy, documentando eccezioni e fallback.
- Monitoraggio — Controllare sign-in log, metodi registrati, modifiche alle policy, accessi privilegiati e anomalie.
Approfondimento — Microsoft 365 Security Assessment
Estendi MFA, policy adattive e controllo degli accessi anche a sistemi legacy, VPN, RDP e ambienti ibridi.
In Microsoft 365, la MFA viene gestita attraverso Microsoft Entra ID. La configurazione moderna si basa su tre componenti: metodi di autenticazione, Security Defaults o Conditional Access, e criteri che stabiliscono quale livello di autenticazione è richiesto per una specifica risorsa.
Security Defaults
I Security Defaults forniscono una baseline preconfigurata per i tenant che non dispongono di requisiti complessi o licenze Microsoft Entra ID P1. Richiedono la registrazione MFA, proteggono le attività amministrative e bloccano diversi flussi di autenticazione legacy. Sono semplici, ma non consentono esclusioni o logiche granulari.
Conditional Access
Con Microsoft Entra ID P1, le policy di Conditional Access permettono di richiedere MFA o authentication strengths in base a utenti, ruoli, applicazioni, rischio, posizione e stato del dispositivo. È il modello consigliato per le organizzazioni che devono differenziare la protezione tra utenti standard, amministratori e risorse critiche.
Authentication strengths
Le authentication strengths consentono di stabilire quali combinazioni di metodi sono accettate. Una policy può, per esempio, consentire Authenticator per le applicazioni ordinarie e richiedere esclusivamente passkey FIDO2, Windows Hello for Business o autenticazione basata su certificato per i portali amministrativi.
Baseline tecnica minima
- MFA obbligatoria per tutti gli utenti, senza eccezioni permanenti.
- Policy separata e più restrittiva per i ruoli amministrativi.
- Blocco dei protocolli di autenticazione legacy che non supportano MFA.
- Riduzione progressiva di SMS e chiamate vocali.
- Metodi di backup controllati e procedure di recupero account documentate.
- Almeno due account di emergenza dedicati, esclusi dalle policy ordinarie ma monitorati e mai usati per attività quotidiane.
- Pilot e modalità report-only prima dell’applicazione generalizzata delle policy Conditional Access.
Per una visione più ampia della baseline di protezione del tenant, consulta la guida Nexsys sulla sicurezza Microsoft 365 per PMI.
MFA, Conditional Access, identity protection, dispositivi e sicurezza email devono essere progettati come un'unica baseline.
2FA, MFA e passwordless: quali differenze
| Termine | Significato | Esempio |
|---|---|---|
| 2FA | Autenticazione con esattamente due fattori differenti | Password + app Authenticator |
| MFA | Autenticazione con due o più fattori | Password + security key + controllo biometrico |
| Passwordless | Accesso senza digitare una password tradizionale; può soddisfare MFA se combina più fattori | Passkey, Windows Hello for Business |
Passwordless non significa assenza di sicurezza o accesso con un solo elemento. Una passkey può combinare il possesso della credenziale sul dispositivo con un PIN locale o una verifica biometrica. Inoltre, la credenziale è legata al dominio o all’applicazione corretta, riducendo il rischio di phishing.
Perché la MFA può non bastare
Un utente deve sapere che una richiesta MFA non avviata personalmente è un indicatore di possibile compromissione.
Come implementare la MFA in azienda
Un rollout efficace non consiste nell’attivare una policy per tutti senza analisi. Deve essere trattato come un progetto di Identity Security, con inventario, pilot, comunicazione, procedure di emergenza e monitoraggio.
- Inventario - Mappare utenti, amministratori, account di servizio, applicazioni SaaS, VPN, sistemi legacy e protocolli di autenticazione.
- Definizione dei livelli - Stabilire quali utenti possono usare Authenticator e quali devono usare metodi phishing-resistant.
- Preparazione operativa - Configurare metodi consentiti, account di emergenza, procedure di recupero e supporto agli utenti.
- Pilot - Applicare le policy a un gruppo rappresentativo e verificare applicazioni, dispositivi, accessi remoti e scenari di continuità.
- Rollout graduale - Estendere la protezione per gruppi, mantenendo monitoraggio degli errori e comunicazione preventiva.
- Hardening - Bloccare legacy authentication, ridurre metodi deboli, applicare authentication strengths alle risorse sensibili.
- Monitoraggio - Controllare registrazioni MFA, accessi anomali, metodi deboli, approvazioni sospette e modifiche alle policy.
Per verificare lo stato generale dei controlli, delle identità e delle configurazioni, integrare la revisione MFA con un audit di sicurezza aziendale. Per formare il personale tecnico che gestisce il tenant, è disponibile il corso Microsoft 365 Administration.
Indicatore operativo
Una configurazione MFA può essere formalmente attiva ma inefficace se esistono esclusioni permanenti, protocolli legacy, account non coperti, metodi deboli per gli amministratori o procedure di recupero non controllate.
MFA e conformità: NIS2, ISO 27001 e GDPR
L’autenticazione a più fattori supporta i requisiti di controllo degli accessi e riduzione del rischio previsti dai principali framework e normative. Non determina da sola la conformità: deve essere inserita in un sistema che comprenda gestione delle identità, privilegi minimi, logging, formazione, incident response e revisione periodica delle policy.
MFA per ambienti legacy, RDP, VPN e infrastrutture ibride
La copertura MFA non deve fermarsi alle applicazioni SaaS. In molte aziende restano sistemi legacy, VPN, RDP, file server, LDAP e applicazioni che non supportano nativamente i moderni flussi di Microsoft Entra ID. Questi percorsi possono diventare un punto debole dell’architettura di identità.
In questi scenari l’obiettivo non è forzare una sola tecnologia, ma estendere il controllo dell’identità anche alle autenticazioni che avvengono fuori dai normali flussi cloud e integrare MFA, analisi del rischio, monitoraggio e protezione dai movimenti laterali.
Identity Security e MFA universale per ambienti ibridi
MFA, conformità e governance
La Multi-Factor Authentication supporta i controlli di accesso previsti da framework e normative, ma non determina da sola la conformità. Deve essere inserita in un sistema di Identity Security che includa least privilege, logging, gestione degli account privilegiati, incident response, formazione, revisione periodica delle policy e procedure di recovery.
Domande frequenti sulla Multi-Factor Authentication
Cosa si intende per Multi-Factor Authentication?
È un processo di autenticazione che richiede due o più prove indipendenti prima di autorizzare l’accesso. I fattori possono includere conoscenza, possesso e biometria.
Qual è la differenza tra 2FA e MFA?
La 2FA utilizza esattamente due fattori. MFA è il termine più generale e indica l’utilizzo di due o più fattori di autenticazione.
Microsoft Authenticator è resistente al phishing?
Le notifiche push di Microsoft Authenticator con number matching rappresentano una buona baseline MFA, ma non appartengono alla stessa categoria phishing-resistant di passkey FIDO2, Windows Hello for Business o autenticazione basata su certificati. Le passkey in Microsoft Authenticator, invece, sono credenziali FIDO2 resistenti al phishing.
SMS e chiamata vocale sono metodi MFA sicuri?
Offrono più protezione della sola password, ma sono più esposti a SIM swap, intercettazione e social engineering. Per account sensibili è preferibile utilizzare metodi resistenti al phishing.
La MFA impedisce tutti gli attacchi di phishing?
No. Alcuni attacchi Adversary-in-the-Middle possono tentare di sottrarre token o sessioni dopo una MFA tradizionale valida. Per le risorse sensibili è opportuno richiedere metodi phishing-resistant.
Qual è la differenza tra passkey device-bound e passkey sincronizzate?
Le passkey device-bound restano associate a uno specifico dispositivo o autenticatore. Le passkey sincronizzate possono essere rese disponibili su più dispositivi tramite un provider passkey. La scelta dipende dai requisiti aziendali, dalle policy di attestazione e dal livello di controllo richiesto.
Serve una licenza per usare Conditional Access?
Sì. Conditional Access richiede Microsoft Entra ID P1. Le policy basate sul rischio utente o sul rischio di accesso richiedono Microsoft Entra ID P2 e le funzionalità di Identity Protection.
Quanti account di emergenza sono consigliati in Microsoft Entra ID?
Microsoft raccomanda due o più account di accesso di emergenza cloud-only, separati dagli account amministrativi ordinari, con credenziali protette e monitoraggio dedicato.
Come verificare se la MFA aziendale è configurata correttamente?
Occorre verificare copertura degli utenti, metodi registrati, esclusioni, account privilegiati, legacy authentication, Conditional Access, emergency access, procedure di recovery e log di accesso.