Ritiro Policy di Rischio Entra ID Ottobre 2026 Migrazione Accesso Condizionale: Nessun Percorso Automatico

Ritiro Policy di Rischio Entra ID Ottobre 2026 Migrazione Accesso Condizionale: Nessun Percorso Automatico

Il Ritiro Policy di Rischio Entra ID Ottobre 2026 Migrazione Accesso Condizionale è un taglio netto per i controlli originali di risposta al rischio in Entra ID Protection. Secondo Microsoft Learn, le policy legacy di rischio utente e rischio di accesso — quelle configurate direttamente nella dashboard di Identity Protection, non tramite l'Accesso condizionale — «saranno ritirate il 1° ottobre 2026». Il tracker delle deprecazioni Microsoft 365 di admindroid riporta la stessa data con la stessa formulazione: «L'interfaccia della policy di rischio utente o di rischio di accesso in Entra ID Protection (in precedenza Identity Protection) sarà ritirata il 1° ottobre 2026».

Nessuna delle due fonti descrive alcuna conversione automatica. Le indicazioni di migrazione di Microsoft sono interamente manuali: gli amministratori devono costruire da soli policy equivalenti basate sul rischio nell'Accesso condizionale, convalidarle, attivarle, e solo dopo tornare a disabilitare quelle precedenti. Nulla nella documentazione sposta automaticamente la configurazione esistente delle policy di rischio di un tenant verso l'Accesso condizionale.

Perché "nessuna migrazione automatica" è la parte che fa male

La risposta basata sul rischio è uno dei pochi controlli di Entra ID Protection che agisce sui segnali di compromissione dell'identità senza intervento umano — è ciò che trasforma il rilevamento di un "utente a rischio" o di un "accesso a rischio" in una vera sfida multifattore, un cambio password forzato o un blocco. Un tenant che dipende ancora dall'interfaccia della policy legacy e non fa nulla prima del ritiro non viene migrato gratuitamente: perde quella risposta automatizzata nel momento in cui la policy legacy smette di funzionare, a meno che un equivalente in Accesso condizionale non sia già attivo.

Questo è un problema più circoscritto e più netto di "le rilevazioni di rischio esistono ma nessuno agisce di conseguenza" (la lacuna più generale di Identity Protection che EtcSec ha già trattato separatamente). Qui, un tenant può avere oggi una policy di rischio funzionante e applicata, e comunque ritrovarsi con zero applicazione basata sul rischio il 2 ottobre 2026 — non perché qualcuno abbia cambiato qualcosa, ma perché nessuno lo ha fatto.

Rilevamento: dipendete ancora dalla policy legacy?

Ci sono due cose da controllare, e la guida di migrazione di Microsoft Learn indica esattamente dove guardare:

1. Policy di rischio legacy. Nel centro di amministrazione Microsoft Entra, andare su ID Protection → Dashboard, e aprire i riquadri di policy Rischio utente e Rischio di accesso. Se uno dei due mostra Applica policy: Attivato, quel tenant dipende ancora dal tipo di policy in fase di ritiro.
2. Copertura basata sul rischio nell'Accesso condizionale. Andare su Entra ID → Accesso condizionale → Policy e verificare se qualche policy usa Condizioni → Rischio utente o Condizioni → Rischio di accesso. Se non ne esiste nessuna — o le uniche presenti sono ancora in Solo report — non esiste ancora un sostituto funzionante, indipendentemente da ciò che mostra la dashboard legacy.

Un tenant può fallire indipendentemente in uno dei due controlli: alcuni hanno già creato policy di rischio nell'Accesso condizionale e hanno semplicemente dimenticato di ritirare quelle legacy (ridondante, non urgente); altri non hanno né l'una né l'altra, il che è la combinazione che porta a zero applicazione basata sul rischio alla data di ritiro.

Rimedio: migrare prima del 1° ottobre 2026

Microsoft Learn documenta un percorso di migrazione specifico in tre passaggi:

1. Costruire prima gli equivalenti in Accesso condizionale, in modalità solo report. Creare una policy basata sul rischio utente e una policy basata sul rischio di accesso nell'Accesso condizionale (manualmente, o a partire da un modello di Accesso condizionale), rivolgendosi a Tutti gli utenti con gli account di accesso di emergenza (break-glass) esclusi. Se si parte da un modello, aggiungere da soli questa esclusione una volta creata la policy: i modelli di Microsoft escludono solo l'account che crea la policy, non gli account break-glass del tenant. Lasciare inizialmente Abilita policy su Solo report.
2. Convalidare, poi attivare le policy. Usare le informazioni in modalità solo report dell'Accesso condizionale per confermare che le nuove policy si attivino come facevano quelle precedenti, prima di passare Abilita policy da Solo report ad Attivato.
3. Disabilitare le policy legacy. Tornare in ID Protection → Dashboard, aprire ogni policy legacy di Rischio utente e Rischio di accesso, e impostare Applica policy su Disabilitato — le indicazioni di Microsoft si fermano prima dell'eliminazione, chiedono solo di disabilitarle.

Per i tenant che necessitano di assistenza diretta, Microsoft Learn documenta un percorso specifico di richiesta di supporto: aprire una Nuova richiesta di supporto, descrivere il problema come "Migrate legacy ID Protection policy" [Migrare la policy legacy di ID Protection], e selezionare Accesso Microsoft Entra e autenticazione a più fattori → Configurazione impostazioni policy nuove o esistenti.

Vale la pena controllare due argomenti correlati insieme a questa migrazione: le policy di rischio — di accesso e utente, che provengano da ID Protection o dall'Accesso condizionale — rientrano tra le funzionalità che Microsoft riserva a Entra ID P2 o alla Microsoft Entra Suite e non sono disponibili in Free o P1, e ogni nuova policy dovrebbe seguire la stessa disciplina di convalida in modalità solo report che si applica a ogni altro rollout di Accesso condizionale — una policy lasciata indefinitamente in modalità solo report offre la stessa totale assenza di applicazione di nessuna policy. Vale anche la pena rivedere la copertura di base dell'Accesso condizionale già che ci si è dentro, dato che un tenant che migra le proprie policy di rischio è un tenant che sta già verificando la propria postura di Accesso condizionale.

Questo ritiro si aggiunge a una serie di scadenze Entra datate nel 2026 — l'applicazione di SSPR limitata ai soli metodi registrati a novembre è un'altra, con un taglio netto e nessun ripiego silenzioso — e la lezione operativa è sempre la stessa: un avviso "sarà ritirato" di Microsoft è un compito da fare, non una migrazione in background.

Come lo rileva EtcSec

L'audit Azure di EtcSec misura ciò che rimane dopo il ritiro: se una policy di Accesso condizionale abilitata porta effettivamente una condizione di rischio. CA_NO_RISK_BASED_USER e RISK_NO_USER_RISK_POLICY scattano entrambi quando nessuna policy di Accesso condizionale abilitata imposta livelli di rischio utente; CA_NO_RISK_BASED_SIGNIN e RISK_NO_SIGNIN_RISK_POLICY scattano entrambi quando nessuna imposta livelli di rischio di accesso. Tutti e quattro leggono l'insieme delle policy di Accesso condizionale del tenant — nessuno legge il pannello legacy delle policy ID Protection.

Due conseguenze meritano di essere dette con precisione. Primo, un tenant la cui risposta al rischio vive solo nell'interfaccia legacy di ID Protection fallisce questi controlli già oggi, non il 2 ottobre 2026 — il riscontro è già presente nell'audit, ed è esattamente il compito di migrazione che questa scadenza crea. Secondo, i controlli contano una policy solo nello stato enabled: una policy di Accesso condizionale basata sul rischio ancora parcheggiata in solo report non li supera, il che è la stessa realtà di applicazione descritta sopra.