L1. Privileged Identity Management and Conditional Access: Just-in-Time Roles & Risk-Based Policies

Why Standing Privileged Access Is a Risk

An account that is permanently a Global Administrator is a permanent target. If it's compromised, the attacker inherits full tenant control with no extra step required. Privileged Identity Management (PIM) removes that standing risk by making privileged roles *eligible* rather than *active* by default.

Eligible vs Active Assignments

PIM introduces two assignment types for Microsoft Entra roles and Azure resource roles:

An eligible assignment carries zero standing privilege. The user must activate it, and that activation can be gated behind justification text, an MFA challenge, and a required approver.

Activation Requirements You Can Enforce

When configuring a PIM role setting, you can require any combination of:

• A written justification for the activation
• Multifactor authentication at activation time, even if the user already satisfied MFA earlier that session
• Approval from one or more designated approvers before the role becomes active
• A maximum activation duration (commonly 1-8 hours), after which the role automatically deactivates

PIM for Groups

PIM isn't limited to directory and Azure roles. PIM for Groups lets you make membership in a Microsoft Entra group itself eligible/time-boxed. This is useful when a group's membership grants access to an application, SharePoint site, or Azure role assignment through the group, since it applies just-in-time principles to any access path that flows through group membership.

Access Reviews

Eligible assignments left unchecked for a year are just as dangerous as standing access. Access reviews in PIM require a designated reviewer (the user, their manager, or a role admin) to periodically confirm continued need. Auto-apply settings can automatically remove access when a review isn't completed or is explicitly denied.

Conditional Access: the Gate in Front of Everything

Conditional Access (CA) policies are if-then statements evaluated at sign-in: if these assignment conditions are true, then apply these grant and session controls. Assignments define who and what the policy targets:

• Users and groups (with exclusions for break-glass accounts)
• Cloud apps or actions
• Conditions: sign-in risk level, user risk level, device platform, location (named locations), client apps

Grant controls decide what's required to complete sign-in:

• Require MFA
• Require a compliant device (Intune) or Microsoft Entra hybrid joined device
• Require an approved client app or app protection policy
• Require terms of use acceptance
• Block access entirely

Session controls constrain the session after sign-in:

• Sign-in frequency (force re-authentication after N hours)
• Persistent browser session (allow or disable "stay signed in")
• App-enforced restrictions (passed to the app, e.g. SharePoint limiting downloads on unmanaged devices)

Conditional Access for Workload Identities

CA can also apply to service principals and managed identities, not just human users, using Conditional Access for workload identities. This targets a specific application by its service principal, evaluates conditions like source IP location, and can block sign-ins from unexpected networks, protecting non-interactive automation accounts from credential theft.

Report-Only Mode and Break-Glass Accounts

Always pilot a new policy in report-only mode first. It logs what *would* have happened without enforcing it, letting you validate against real sign-in traffic before flipping it to "On." Every tenant should also maintain at least two break-glass (emergency access) accounts excluded from Conditional Access policies, with strong unique credentials, so a misconfigured policy can never lock out every administrator simultaneously. Exam tip: SC-500 tests the combination of PIM (removing standing privilege, requiring activation) with Conditional Access (gating sign-in itself with risk and device conditions). Expect scenario questions asking which single control (PIM activation approval vs. CA sign-in risk policy vs. CA for workload identities) solves a specific access risk.