Require Risk Remediation: il vero punto di svolta nelle Conditional Access Policies

Cos’è “Require Risk Remediation”?

Il controllo Require Risk Remediation è un nuovo tipo di grant control per le Conditional Access policies che obbliga un utente ad affrontare e risolvere un rischio prima di ottenere l’accesso. In pratica:

• Non solo blocca l’accesso quando viene rilevato un rischio elevato,

• Ma guida l’utente attraverso un workflow di remediation appropriato, in base al tipo di autenticazione e alla natura del rischio.

Questa funzione è particolarmente utile perché gestisce sia utenti password-based che passwordless con una sola policy, evitando così la proliferazione di policy redundanti o troppo specifiche.

Come funziona nella pratica

Quando un utente si autentica e Microsoft Entra-ID rileva un livello di rischio configurato (es. High), la policy con Require Risk Remediation entra in gioco:

Se l’utente usa password

L’utente viene guidato a:

1. Verificare la propria identità (es. tramite MFA),

2. Cambiare la password in modo sicuro,

3. Dopo il reset, le sessioni attive vengono revocate e l’utente può riprovare ad accedere.

Se l’utente è passwordless

La policy richiede una ri-autenticazione usando il metodo già registrato e valido (authentication strength specificato nella policy). Anche qui, la sessione viene revocata e l’utente deve completare la nuova autenticazione per “chiudere” lo stato di rischio.

Perché è un “game-changer”

Una sola policy, più copertura

In passato, gestire rischi diversi per utenti con e senza password richiedeva spesso più policy distinte. Con Require Risk Remediation, Microsoft gestisce automaticamente il percorso di remediation più appropriato, riducendo complessità operativa.

Maggiore sicurezza, meno attrito

Il vantaggio più evidente è che non si limita a bloccare l’accesso, ma lo fa in modo intelligente:

• Gli utenti possono risolvere da soli i problemi di rischio senza necessariamente coinvolgere l’IT,

• Riduce il carico di ticket di supporto,

• E al tempo stesso mantiene un livello di sicurezza più alto e coerente.

Best practice consigliate

Se stai pianificando di adottare Require Risk Remediation nella tua organizzazione, ecco alcune linee guida utili:

• Test in report-only o audit mode prima dell’applicazione in produzione

• Escludi account di emergenza o “break-glass” per evitare lockout indesiderati

• Non combinare user risk e sign-in risk nella stessa policy, poiché l’AND logico impedisce che si attivi se uno solo dei due segnali è vero.

• Assicurati di avere licenze Microsoft Entra ID P2, poiché queste funzionalità avanzate richiedono il livello P2.

Come abilitare Require Risk Remediation in Conditional Access

La funzionalità Require Risk Remediation è disponibile come Grant control nelle Conditional Access Policies e può essere configurata direttamente dal portale Microsoft Entra.
Di seguito i passaggi consigliati per una configurazione corretta e sicura.

Dal portale di Entra ID andiamo su Conditional Access - Policy - New Policy

Diamo un nome alla nostra policy - Blocca rischio utente elevato - Richiedi correzione e sotto Users or agents selezioniamo All Users (se dovete escludere degli utenti\gruppi inseriteli nella sezione Exclude)

Selezioniamo le risorse interessate - in questo caso All resources (anche in questo caso se ci sono risorse da escludere usate sempre la sezione Exclude)

Nelle Conditions selezioniamo User risk

E impostiamo che livello di rischio deve avere l'utente perchè venga applicata la nostra policy - nel mio caso metterò Medium e High

Nella sezione Grant andiamo a selezionare il controllo che andremo ad applicare

selezionando Require authentication strength e Require risk remediation

Verrà automaticamente abilitata anche la Sign-in Frequency

A questo punto non resta che abilitare la policy in modalità Report-only, monitorarne il comportamento ed effettuare i test necessari; una volta verificato il corretto funzionamento, sarà possibile attivarla definitivamente in modalità On.

Considerazioni su policy legacy

Microsoft sta progressivamente ritirando le vecchie policy di User Risk e Sign-in Risk all’interno di Identity Protection a favore delle Conditional Access Policies basate su rischio. Questo rende ancora più importante migrare verso modelli moderni che includono Require Risk Remediation per mantenere livello di protezione adeguato.

Conclusione

Require Risk Remediation rappresenta un’evoluzione significativa nel modo in cui le Conditional Access policies gestiscono il rischio, semplificando la remediation e rendendo il processo più coerente sia per utenti password-based che passwordless.

È però importante essere consapevoli di un aspetto tecnico: questo controllo revoca esclusivamente i token di sessione (refresh token), mentre non invalida immediatamente i token di accesso già emessi. Di conseguenza, nel caso in cui un aggressore sia già in possesso di un access token valido, potrebbe teoricamente mantenere l’accesso fino alla sua naturale scadenza (tipicamente fino a un’ora), anche dopo che l’utente ha completato la remediation.

Per scenari che richiedono una revoca quasi in tempo reale, è quindi ancora fondamentale affiancare questo meccanismo alla Continuous Access Evaluation (CAE) e, idealmente, a policy di accesso rigorose e ben stratificate.

Detto questo, per la grande maggioranza delle organizzazioni Require Risk Remediation rimane una vera vittoria dal punto di vista amministrativo: riduce drasticamente la complessità delle policy, elimina un limite storico nella gestione del rischio e consente di alzare il livello di sicurezza senza aumentare l’attrito per utenti e team IT.