Microsoft Entra ID Protection è il componente di Entra ID che assegna un livello di rischio a ogni accesso e a ogni utente. Lo calcola da segnali come credenziali finite in un data breach, indirizzi IP anonimi o token con caratteristiche anomale. Poi passa quel livello all'Accesso condizionale, che può chiedere l'MFA, imporre un cambio password sicuro o bloccare.
C'è però uno scenario che i rilevamenti, da soli, coprono male: l'attaccante che ha già una password valida e la usa per registrare il proprio metodo MFA sull'account della vittima. Da quel momento l'autenticazione a più fattori lavora per lui. Capita soprattutto con gli account appena creati e con chi non ha mai completato la registrazione.
In questo articolo vediamo quali rischi Entra ID Protection riconosce, cosa cambia tra le licenze P1 e P2 e come si configurano le policy basate sul rischio, ora che Microsoft ha fissato al 1° ottobre 2026 il ritiro di quelle legacy. Nella seconda parte vediamo come chiudere la porta della registrazione MFA.
Cos'è Entra ID Protection e come ragiona
Entra ID Protection lavora su due livelli di rischio distinti, e confonderli è l'errore più comune quando si scrivono le policy.
La probabilità che una singola richiesta di autenticazione non arrivi dal legittimo proprietario dell'account. Riguarda quel login, in quel momento.
La probabilità che l'identità nel suo insieme sia compromessa. Si accumula nel tempo, per esempio quando le credenziali compaiono in un breach.
Ogni rischio ha un livello basso, medio o alto. Alcuni rilevamenti sono calcolati in tempo reale, durante l'accesso; altri offline, analizzando i log a posteriori, e possono comparire con un certo ritardo.
ID Protection calcola il rischio, ma è l'Accesso condizionale a decidere cosa succede: senza una policy, il rischio resta un dato in un report.
L'amministratore lavora su tre report: Rilevamenti di rischio, Accessi a rischio e Utenti a rischio. Gli stessi dati si possono esportare verso un SIEM come Microsoft Sentinel, per conservarli più a lungo e correlarli con il resto dei log.
Un limite da tenere presente: Entra ID Protection valuta gli accessi che passano da Entra ID. Un logon RDP o un'autenticazione Kerberos verso un domain controller on-premises restano fuori dal suo campo visivo. Per quel perimetro serve un livello diverso, come la protezione delle identità su Active Directory e sistemi legacy.
I rilevamenti di rischio che contano davvero
Microsoft documenta una trentina di rilevamenti; per un'azienda conviene leggerli per fase dell'attacco, perché ognuno racconta un momento diverso. Questi sono quelli da conoscere per primi in un tenant aziendale.
| Rilevamento | Cosa segnala | Rischio | Licenza minima |
|---|---|---|---|
| Credenziali trapelate (Leaked credentials) | Credenziali valide trovate in un breach e verificate sugli hash attuali del tenant. È sempre a rischio alto | Utente | Free / P1 |
| Password spray | La stessa password provata su molti account. Scatta solo se la password di un utente è stata davvero indovinata | Accesso | P2 |
| Proprietà di accesso non familiari | IP, ASN, dispositivo o browser mai visti per quell'utente. I nuovi account restano almeno cinque giorni in apprendimento | Accesso | P2 |
| Viaggio atipico | Due accessi da luoghi lontani in tempi incompatibili con lo spostamento | Accesso | P2 |
| Indirizzo IP anonimo | Accessi da Tor o da VPN anonime | Accesso | Free / P1 |
| Token anomalo | Token di sessione o di refresh con durata o provenienza insolita: possibile replay. Ai livelli basso e medio dà più falsi positivi | Accesso e utente | P2 |
| Attacker in the Middle | Sessione collegata a un reverse proxy malevolo che intercetta credenziali e token | Utente | Microsoft 365 E5 + EMS E5 |
| Approvazione MFA sospetta | Richiesta e approvazione MFA arrivano da posizioni e dispositivi incoerenti tra loro. Usa la telemetria di Microsoft Authenticator | Accesso | P2 |
| Attività sospetta segnalata dall'utente | L'utente rifiuta un prompt MFA che non ha avviato e lo segnala. Richiede la funzione “Segnala attività sospette” attiva | Utente | P2 |
| Aggiunta sospetta di credenziali | Un nuovo metodo di autenticazione aggiunto all'account in circostanze sospette | Utente | P2 |
| Regole di inoltro o manipolazione della posta | Inoltro di tutta la posta verso l'esterno, regole che spostano o cancellano messaggi | Accesso | P2 + Defender for Cloud Apps |
| Traffico API sospetto | Chiamate Microsoft Graph anomale o enumerazione della directory: ricognizione dopo l'accesso | Utente | P2 |
Non segnala i tentativi falliti: quando compare, la password di quell'utente è già nota all'attaccante.
È il rilevamento più vicino all'attacco alla registrazione MFA che vediamo più avanti.
Senza licenza P2 i rilevamenti premium non spariscono: compaiono come un generico “Rilevato rischio aggiuntivo” (Additional risk detected). Sai che è successo qualcosa, ma non cosa.
P1 o P2: cosa vedi davvero con ciascuna licenza
Con Entra ID P1, incluso in Microsoft 365 Business Premium ed E3, capisci che qualcosa non va ma non perché, e non puoi usare le policy basate sul rischio. Per quelle serve P2.
| Funzione | Free | P1 | P2 / Entra Suite |
|---|---|---|---|
| Policy sul rischio utente e sul rischio di accesso | No | No | Sì |
| Report Utenti a rischio | Solo rischio medio e alto, senza dettagli né cronologia | Come Free | Completo |
| Report Accessi a rischio | Senza livello né dettaglio del rischio | Come Free | Completo |
| Report Rilevamenti di rischio | No | Limitato, senza dettagli | Completo |
| Avvisi sugli utenti a rischio e riepilogo settimanale | No | No | Sì |
| Policy di registrazione MFA di ID Protection | No | No | Sì |
| Report di rischio via Microsoft Graph | No | No | Sì |
P2 arriva con Microsoft 365 E5, con Entra ID P2 o Entra Suite acquistati a parte, oppure con il componente aggiuntivo Microsoft Defender Suite for Business Premium, che lo include. Alcuni rilevamenti dipendono anche da segnali Defender (Defender for Cloud Apps, Defender for Office 365, Defender for Endpoint), che Microsoft 365 E5 copre tutti.
Prima di comprare licenze conviene capire cosa il tenant già permette. Nel Microsoft 365 Security Assessment partiamo dalle licenze attive: se una protezione richiede una licenza che manca, indichiamo le alternative con quelle che hai e cosa cambierebbe con l'upgrade. Per il confronto tra i piani c'è anche la nostra guida su cosa include Microsoft 365 Business Premium.
Dalle detection alle policy: rischio utente e rischio di accesso
Le policy basate sul rischio trasformano un livello di rischio in un'azione automatica, e oggi si configurano nell'Accesso condizionale. Servono due policy separate: Microsoft sconsiglia di mettere rischio utente e rischio di accesso nella stessa.
La raccomandazione di Microsoft è il controllo “Richiedi la correzione del rischio” (Require risk remediation) quando il rischio è alto. Entra ID sceglie da solo il percorso giusto:
L'utente supera l'MFA e poi fa un cambio password sicuro, che chiude le sessioni precedenti.
Le sessioni vengono revocate e l'utente deve autenticarsi di nuovo.
L'oggetto dispositivo in Entra viene disabilitato e le sessioni revocate.
Questo controllo aggiunge in automatico il requisito di forza dell'autenticazione e la frequenza di accesso “ogni volta”. Non funziona per utenti guest ed esterni, perché per loro Entra ID non può revocare le sessioni.
Qui si chiede l'MFA quando il rischio è medio o alto, con la frequenza di accesso “ogni volta”. Il rischio di accesso si corregge solo con un'autenticazione forte, a qualunque livello.
Applicare le policy solo al rischio alto riduce le interruzioni, ma lascia passare i rischi bassi e medi che un attaccante può comunque sfruttare. Configurare correttamente le posizioni di rete attendibili aiuta a ridurre i falsi positivi.
Prima di attivarle servono alcune condizioni:
Chi non ha un metodo registrato quando scatta la policy viene bloccato e serve l'intervento dell'amministratore.
Microsoft lo richiede perché gli utenti sincronizzati da Active Directory possano completare il cambio password sicuro: ne parliamo nella guida al reset password self-service e al writeback.
Serve se vuoi che il rilevamento delle credenziali trapelate copra anche le password on-premises.
Esclusi da tutte le policy, e monitorati: vedi la nostra guida agli account breakglass in Entra ID.
Per qualche giorno, prima di passare a “Attivato”.
Microsoft ha fissato al 1° ottobre 2026 il ritiro delle policy di rischio utente e di rischio di accesso configurate nella console di ID Protection. Se nel tuo tenant le policy di rischio sono ancora quelle, è il primo punto da controllare.
La migrazione segue tre passi:
Crei le policy equivalenti nell'Accesso condizionale in modalità solo report.
Verifichi l'impatto e le attivi.
Disattivi le vecchie dal dashboard di ID Protection.
Il workbook “Impact analysis of risk-based access policies” mostra quante policy legacy sono ancora presenti.
Il passaggio porta anche qualcosa in più: una sola console, la modalità solo report, policy diverse per gruppi diversi e la possibilità di combinare il rischio con posizione o dispositivo. Se vuoi farti affiancare, è un intervento tipico della nostra consulenza Microsoft 365.
L'attacco che i rilevamenti non fermano: la registrazione della MFA
Chi ha una password valida e trova la registrazione aperta può aggiungere il proprio numero di telefono, la propria app Authenticator o la propria chiave FIDO2. Da lì in poi supera l'MFA come se fosse l'utente.
La password arriva dalle solite strade: un password spray riuscito, credenziali riutilizzate e finite in un breach, una pagina di phishing con proxy che intercetta anche il token di sessione. Di queste ultime tecniche parliamo nell'articolo l'MFA è ancora sicura? Rischi reali e bypass.
I bersagli preferiti sono prevedibili:
Con l'account già creato e nessun metodo registrato.
Gli utenti che hanno sempre rimandato la registrazione.
Account a cui l'help desk ha appena azzerato i metodi, per esempio dopo la perdita del telefono.
Il punto delicato è la persistenza. Cambiare la password non rimuove i metodi di autenticazione registrati: il fattore dell'attaccante resta valido. Se il reset self-service accetta quel metodo, l'attaccante può perfino reimpostare la password da solo.
C'è un effetto collaterale che si nota poco. L'autocorrezione del rischio si fida dei metodi registrati: se il metodo l'ha aggiunto l'attaccante, il cambio password sicuro richiesto dalla policy lo può completare lui. Per questo la registrazione va protetta prima di affidarsi alle policy di rischio.
Entra ID Protection aiuta con il rilevamento Aggiunta sospetta di credenziali, che con P2 alza il rischio dell'utente in tempo reale. Forzare tutti a registrare l'MFA, come spieghiamo nei 5 errori comuni con l'MFA di Entra ID, riduce la finestra di esposizione. Nessuna delle due cose, però, controlla chi sta registrando e da dove.
Come mettere in sicurezza la registrazione delle informazioni di sicurezza
La registrazione si protegge a strati: una policy di Accesso condizionale sull'azione di registrazione, un Temporary Access Pass per chi non ha ancora un metodo, condizioni su dispositivo e rischio, e uno sguardo regolare ai log.
Una policy sull'azione “Registra informazioni di sicurezza”
L'Accesso condizionale permette di proteggere l'azione utente “Registra informazioni di sicurezza” (Register security information) come se fosse un'applicazione. Copre la registrazione combinata di MFA e reset password self-service, l'accesso all'app Authenticator e l'attivazione dell'accesso da telefono senza password. Microsoft la mette tra i modelli della categoria “Secure foundation”.
La configurazione tipica, con licenza P1:
- utenti: tutti, esclusi guest ed esterni (che vanno gestiti con una policy a parte) e gli account break-glass;
- condizione di posizione: qualunque posizione, escluse quelle attendibili;
- controllo di concessione: forza dell'autenticazione, scegliendo anche quella resistente al phishing; se usi metodi di autenticazione esterni, “Richiedi MFA”, perché oggi non sono compatibili con la forza dell'autenticazione;
- stato: solo report, poi attivato.
Così, fuori dalla rete aziendale, per aggiungere un metodo bisogna prima dimostrare chi si è con un metodo già registrato.
Temporary Access Pass per nuovi assunti e telefoni persi
Chi non ha ancora nessun metodo, però, non può soddisfare quella policy. La soluzione è il Temporary Access Pass (TAP): un codice a tempo emesso dall'amministratore, che vale come MFA per l'Accesso condizionale e permette di registrare i metodi da qualunque dispositivo e posizione.
Due accortezze. Il TAP va impostato a uso singolo e con durata breve: un TAP riutilizzabile che finisce nelle mani sbagliate permette di registrare altri metodi per tutta la sua validità. E va consegnato solo dopo aver verificato l'identità della persona, di persona o in videochiamata. Il TAP non funziona per gli utenti guest.
La rete aziendale non è una prova d'identità
Escludere le posizioni attendibili è comodo, ma un attaccante già dentro la rete o la VPN aziendale passa senza ostacoli. Conviene aggiungere una condizione sul dispositivo: registrazione consentita solo da dispositivi conformi in Intune o aggiunti a Microsoft Entra in modalità ibrida.
Intune è incluso in Microsoft 365 Business Premium; dove le licenze non lo prevedono ci sono alternative, come raccontiamo nella pagina sulla gestione degli endpoint. Per il primo giorno del nuovo assunto, quando il PC non è ancora registrato, resta il TAP.
Niente registrazione per gli utenti a rischio
Con P2 si può aggiungere la condizione sul rischio utente a una policy che protegge la registrazione, con controllo “Blocca accesso”. Un account già segnalato come a rischio non può aggiungere metodi finché il rischio non viene corretto. Includere anche il livello basso è più restrittivo, ma aumenta i casi in cui l'help desk deve intervenire.
Windows Hello for Business e Platform SSO: cosa cambia dal 6 luglio 2026
Dal 6 luglio 2026 le policy che proteggono la registrazione si applicano anche alla registrazione di Windows Hello for Business e di Platform SSO su macOS. Prima questi flussi chiedevano l'MFA predefinita ma ignoravano i controlli della policy.
Ora l'utente deve soddisfare anche quei controlli, per esempio forza dell'autenticazione o posizione attendibile. Se la tua policy è molto restrittiva, verifica in modalità solo report che la preparazione dei nuovi PC non si blocchi.
Guardare i log di registrazione
Nel centro di amministrazione di Microsoft Entra, nella sezione Metodi di autenticazione, ci sono le attività di registrazione e reset (data, utente, metodo, esito) e il dettaglio di quali metodi ha ogni utente. I segnali da cercare:
Registrazioni fuori orario o da paesi in cui l'azienda non opera
Più metodi aggiunti allo stesso account in pochi minuti
Lo stesso numero di telefono registrato su più utenti
Una registrazione subito dopo un accesso a rischio
Entra non invia di serie un avviso per ogni nuova registrazione. Si può inviare il log di audit a un workspace Log Analytics e costruire una regola in Microsoft Sentinel, che ha anche il connettore per ID Protection. Se in azienda nessuno ha il tempo di guardare questi segnali, il monitoraggio continuo è il lavoro di un SOC as a Service.
Ultimo dettaglio, a costo zero: attiva “Segnala attività sospette” nelle impostazioni MFA. Un utente che rifiuta un prompt che non ha avviato alimenta il rilevamento corrispondente.
Se un account risulta compromesso: le prime azioni
Quando un utente è compromesso, l'ordine delle azioni conta più della velocità con cui si cambia la password.
Nel report Utenti a rischio: il rischio dell'utente passa ad alto e, se la policy sul rischio utente è attiva, si applica al prossimo accesso.
E fai reimpostare la password in modo sicuro.
Dell'utente, ed elimina quelli che non riconosce: il cambio password non li tocca.
Regole di inoltro verso l'esterno, regole che spostano o cancellano messaggi.
Di accesso e di audit degli ultimi giorni, per capire da dove è entrato e cosa ha toccato.
Se l'account aveva privilegi amministrativi o ci sono segni di movimento verso altri sistemi, non si tratta più di un reset: è un incidente, e va gestito con un processo di Incident Response.
Da dove partire in un tenant PMI
In un tenant di piccole o medie dimensioni si parte da sei verifiche, in quest'ordine:
Quali licenze Entra hai davvero, P1 o P2, e quali segnali Defender.
Se ci sono ancora policy di rischio legacy in ID Protection da portare nell'Accesso condizionale.
La policy sulla registrazione delle informazioni di sicurezza, prima in solo report e poi attiva.
Il TAP monouso dentro il processo di onboarding dei nuovi assunti.
Gli account break-glass, esclusi da tutte le policy e sotto controllo.
“Segnala attività sospette” attivo, e una persona o un servizio che guardi davvero il report Utenti a rischio.
Vuoi sapere cosa vede oggi il tuo tenant?
Nel Microsoft 365 Security Assessment controlliamo Accesso condizionale, registrazione MFA, policy di rischio e account break-glass sulle licenze che hai già. Ricevi un piano di remediation con le azioni in ordine di priorità, presentato al tuo IT, e il retest finale è incluso. La proposta è a corpo, dopo una breve call di scoping.
Richiedi il Security AssessmentPreferisci che sia il tuo team IT a configurare tutto?
Copre identità, Accesso condizionale e ID Protection.
Un percorso più mirato.
Domande frequenti
Entra ID Protection è incluso in Microsoft 365 Business Premium?
No. Business Premium include Entra ID P1, che mostra solo informazioni limitate sugli utenti a rischio e non permette le policy basate sul rischio. Per quelle serve Entra ID P2, incluso in Microsoft 365 E5 e nel componente aggiuntivo Defender Suite for Business Premium.
Che differenza c'è tra rischio di accesso e rischio utente?
Il rischio di accesso riguarda un singolo login e si corregge con un'autenticazione forte, come l'MFA. Il rischio utente riguarda l'identità nel suo insieme, per esempio credenziali trapelate, e si corregge con un cambio password sicuro o con la revoca delle sessioni.
Cosa succede alle policy di rischio configurate in ID Protection dopo il 1° ottobre 2026?
Microsoft ha fissato per quella data il ritiro delle policy legacy di rischio utente e di rischio di accesso configurate in ID Protection. Vanno ricreate come policy di Accesso condizionale, verificate in modalità solo report e poi attivate, disattivando le vecchie.
Cambiare la password basta a togliere l'accesso a chi ha registrato la propria MFA?
No. Il cambio password non rimuove i metodi di autenticazione registrati. Bisogna revocare le sessioni, eliminare i metodi che l'utente non riconosce e verificare cosa l'attaccante ha fatto nel frattempo.
Come si protegge la registrazione MFA dei nuovi assunti?
Con una policy di Accesso condizionale sull'azione “Registra informazioni di sicurezza” e un Temporary Access Pass monouso, consegnato dopo aver verificato l'identità della persona. Il TAP vale come MFA per la policy e permette di registrare il primo metodo in sicurezza.