Se arrivi da AZ-500, ritirato il 31 agosto 2026, questa parte del programma la riconosci. Quello che SC-500 chiede in più è sapere quando un controllo scatta davvero e quando invece non scatta.

Eligible non significa “meno potente”: significa spento

PIM governa tre superfici distinte — ruoli Microsoft Entra, ruoli delle risorse Azure e PIM per i gruppi — e in tutte e tre la differenza portante è fra assegnazione eligible e active. La documentazione è esplicita: non c’è alcuna differenza nell’accesso concesso a chi ha un’assegnazione permanente rispetto a chi ne ha una eligible; l’unica differenza è che certe persone non hanno bisogno di quell’accesso tutto il tempo. PIM non riduce i privilegi: ne riduce la finestra temporale e li lega a un’azione tracciabile.

La prima trappola è la delega, perché i due mondi non si somigliano. Per i ruoli Entra solo Privileged Role Administrator e Global Administrator gestiscono le assegnazioni altrui, mentre Security Administrator, Global Reader e Security Reader possono solo vederle. Per i ruoli delle risorse Azure servono invece subscription administrator, Owner della risorsa o User Access Administrator — e chi ha Privileged Role Administrator o Security Administrator, per impostazione predefinita, quelle assegnazioni non le vede nemmeno.

Le impostazioni di ruolo: dove il default non basta

Le role settings, che la documentazione chiama anche PIM policies, si definiscono per ruolo; per le risorse Azure anche per risorsa. Qui c’è un dettaglio che costa incidenti: le impostazioni definite a un livello superiore, per esempio la sottoscrizione, non sono ereditate a un livello inferiore come il resource group. Per modificarle servono almeno Privileged Role Administrator sui ruoli Entra, e Owner o User Access Administrator sulle risorse Azure.

ID Governance > Privileged Identity Management > Microsoft Entra roles > Roles > [ruolo] > Role settings
ID Governance > Privileged Identity Management > Azure resources > [risorsa] > Settings

La durata massima di attivazione va da 1 a 24 ore. Il flag “On activation, require multifactor authentication” è quello su cui quasi tutti sbagliano: non garantisce un’autenticazione fresca. Se l’utente si è già autenticato con credenziali forti o ha già fatto MFA prima nella sessione, al momento dell’attivazione non gli viene chiesto nulla. Se il tuo obiettivo è che l’operatore si autentichi adesso, la combinazione giusta è “On activation, require Microsoft Entra Conditional Access authentication context” più una authentication strength, e sul criterio di accesso condizionale che governa quel contesto una sign-in frequency impostata su Every time. Anche così resta una finestra di 10 minuti: chi si è riautenticato per un ruolo può attivarne un altro senza nuovo prompt, e la finestra vale trasversalmente su ruoli Entra, ruoli Azure e PIM per i gruppi.

Esiste un paracadute: se nel tenant non c’è alcun criterio di accesso condizionale che punta all’authentication context configurato in PIM, all’attivazione viene richiesta MFA come se fosse attivo il flag classico. Ma non scatta se il criterio esiste ed è disattivato, se è in report-only o se l’utente eleggibile ne è escluso.

Sulle approvazioni i due mondi divergono ancora: per i ruoli Entra, se non selezioni approvatori specifici diventano approvatori di default i Privileged Role Administrator e i Global Administrator attivi; per i ruoli delle risorse Azure non esiste alcun approvatore di default. Da qui il rischio di lockout: tutti i PRA e i GA solo eligible, approvazione richiesta, nessun approvatore configurato, e il tenant è chiuso — servono account di accesso di emergenza. Il campo del ticket, infine, è puramente informativo: nessuna correlazione viene verificata.

Accesso condizionale: due fasi, tutto in AND

Un criterio è un if-then fra assignments (utenti e gruppi, target resources, network, conditions) e access controls (grant e session). Se più criteri si applicano allo stesso accesso devono essere soddisfatti tutti, e gli assignments interni a un criterio sono combinati in AND. La valutazione ha due fasi: prima si raccolgono i dettagli di sessione, poi si applica. Se un criterio contiene un block, l’applicazione si ferma lì; i session control arrivano solo dopo i grant.

Il dettaglio che tiene insieme PIM e accesso condizionale: i criteri che puntano a ruoli o gruppi sono valutati solo quando viene emesso un token. Un utente aggiunto a un ruolo con un token ancora valido non ricade nel criterio in modo retroattivo — la raccomandazione ufficiale è far scattare la valutazione all’attivazione del ruolo tramite PIM. E l’authentication context vincola l’attivazione, non l’uso successivo: dopo l’attivazione l’utente può usare il ruolo da un altro dispositivo. Servono due criteri, uno sull’authentication context e uno sui directory roles.

Per i grant, il default è “richiedi tutti i controlli selezionati”. “Require multifactor authentication” e “Require authentication strength” non possono convivere nello stesso criterio.

Report-only: che cosa misura e che cosa no

Report-only valuta senza applicare: nessun utente viene bloccato, nessuno riceve il prompt MFA. Gli esiti finiscono nelle schede Conditional Access e Report-only del dettaglio dei sign-in log, con risultati distinti — Success, Failure, User action required, Not applied. Non copre lo scope “User Actions”. E ha un effetto collaterale controintuitivo: i criteri in report-only che richiedono un dispositivo conforme possono comunque chiedere agli utenti macOS, iOS e Android di selezionare un certificato, ripetutamente; escludi quelle piattaforme dai criteri di test. Per il confronto affiancato serve il workbook Conditional Access Insights and Reporting, che richiede Microsoft Entra ID P1 e un workspace Log Analytics; per la vista Policy impact basta Security Reader.