Microsoft Entra ID: PIM, Conditional Access, MFA…

Why identity is where SC-500 starts

Simple explanation

Identity is the new perimeter. In the old days, the security boundary was the corporate firewall — anything inside the network was “trusted”. That world is gone. Users sign in from coffee shops, AI agents act on behalf of users, contractors are on personal laptops. The thing every request now has in common is an identity, so the new perimeter is the sign-in.

Microsoft Entra ID is the identity provider that sits at that perimeter. SC-500 expects you to know three layers on top of it:

Privileged Identity Management (PIM) — turn standing admin access into just-in-time. An admin requests a role for, say, 2 hours, approves themselves (or waits for approval), and the role drops away on its own.
Conditional Access — every sign-in is evaluated against a policy. “If the user is in this group AND the app is this one AND the device is unmanaged, require MFA.” Or block. Or require a compliant device.
Authentication methods — what the user actually proves with. MFA (something you know + something you have), then the passwordless ladder: Authenticator push, passkeys, Windows Hello for Business, FIDO2 security keys.

If you nail these three on SC-500, you’ve already covered a large slice of Domain 1.

Privileged Identity Management (PIM)

PIM is Microsoft Entra’s just-in-time role assignment service. Two key shifts it makes:

Eligible vs Active. Instead of permanently assigning Global Administrator to a person, you assign them as eligible. They are not Global Admin until they activate. Activation grants the role for a configurable maximum time (defaults to 8 hours), after which it drops.
Approvals + justification + MFA on activation. You can require MFA, a written business justification, and explicit approval from a designated approver before the activation is granted.

Standing role assignments vs PIM eligible assignments — why PIM exists
Feature	Standing assignment	PIM eligible assignment
When access is live	Always — 24/7 from the moment of assignment	Only after explicit activation, for a limited window
Activation MFA	No — already in the role	Configurable per role: yes by default for high-privilege
Approval workflow	No — admin can act immediately	Configurable per role — single or multi-approver
Business justification	Not captured	Required free-text reason logged with the activation
Audit signal	You see who has the role, not when they used it	Every activation is a discrete event with reason, time, IP, MFA proof
Default max duration	Forever	8 hours (configurable, max 24h for most roles)

PIM settings you must know

For each role in PIM, there are role settings you can configure. These show up routinely on the exam:

Activation maximum duration — typically 1–24 hours, set per role.
Require MFA on activation — on by default for sensitive roles like Global Administrator.
Require justification on activation — captures free-text “why” for audit.
Require approval to activate — turns activation into a workflow with named approvers (users or groups).
Require ticket information on activation — captures a change ticket ID.
Notifications — emails on eligible assignment, activation, and role completion.
Access reviews — scheduled review of eligible/active assignments; reviewers (often the user themselves, their manager, or a named reviewer) confirm whether each assignment is still needed.

What PIM covers (and doesn't)

PIM in SC-500 scope governs:

Microsoft Entra roles (Global Administrator, Security Administrator, Privileged Role Administrator, Conditional Access Administrator, etc.) — all the directory-level admin roles.
Azure resource roles (Owner, Contributor, User Access Administrator, custom RBAC roles) — at any scope (management group, subscription, resource group, resource).
PIM for Groups — assignment to security groups can be made just-in-time (useful when downstream apps grant access via group membership).

PIM does NOT govern:

Service principal / application permissions — those are covered separately under app identity (next module).
Standing assignments on individual subscriptions or resources outside PIM management — until you bring them under PIM, they remain standing.

Conditional Access

Conditional Access (CA) is Microsoft Entra’s policy engine for “should we let this sign-in through, and under what conditions?” Every CA policy has two halves:

Assignments — who the policy applies to: which users/groups, which target cloud apps, and under what conditions (device platform, location, sign-in risk, user risk, client app type, filter for devices).
Access controls — what the policy does when matched:
- Grant controls — block access, or grant access requiring one or more of: MFA, device compliance (Intune-managed and compliant), Hybrid Azure AD joined, approved client app, app protection policy, password change, terms of use.
- Session controls — App Enforced Restrictions, Conditional Access App Control (via Defender for Cloud Apps), sign-in frequency, persistent browser session, customise continuous access evaluation, disable resilience defaults.

How signals stack

Conditional Access shines because signals stack. A single policy can say: “If the user is in Finance, signing in to Office 365, from an unfamiliar location, on an unmanaged device, AND sign-in risk is medium or above — require MFA AND require compliant device.”

Conditional Access signals — what's available and what they're for
Signal type	Source	Used for
User and group	Entra ID directory	Targeting policies to populations (Finance, Contractors, etc.)
Target resources (cloud apps)	Service principals in Entra	Which apps the policy applies to (specific app, all cloud apps, app filters)
User actions	Entra protocols	Register security info, register/join device — for self-service flows
Authentication context	Tagged by apps via API	Step-up auth for specific actions (e.g. accessing sensitive SharePoint sites)
Sign-in risk	Entra ID Protection (atypical travel, anonymous IP, malware-linked IP, unfamiliar sign-in properties, leaked credentials)	Trigger MFA or block when risk is elevated
User risk	Entra ID Protection (compromised credential indicators)	Force password change when user is at risk
Device platform / state	Intune compliance, hybrid join	Require managed compliant device for access
Location	IP-based named locations, country list	Trusted IPs, country block lists
Client apps	Modern auth vs legacy (basic) auth	Block legacy auth, restrict to specific client app types

What CA can’t do

CA evaluates at sign-in time (and continuously with Continuous Access Evaluation for supported scenarios). It can require MFA, require a compliant device, or block — but it cannot reach inside an application to enforce per-action authorisation. That belongs to the application’s own RBAC, or to Authentication Context + per-action policies in apps that support it.

Authentication methods (the passwordless ladder)

Microsoft Entra ID supports a spectrum of authentication methods. SC-500 expects familiarity with the authentication methods policy (the modern way to configure them — replaces the legacy MFA registration policy and the per-method settings under Security):

Authentication methods on the passwordless ladder — phishing resistance and intended use
Method	Phishing-resistant?	Typical use
Password	No	Legacy primary factor — always paired with a second factor
Microsoft Authenticator (push notification)	No (push)	Most common second factor; supports number-matching to mitigate MFA fatigue
Microsoft Authenticator (passwordless sign-in)	Mostly — passwordless mode binds device	Sign-in without password using approve-on-phone
FIDO2 security key (hardware)	Yes — phishing-resistant by design	Highest-assurance external-key sign-in (USB, NFC, BLE)
Passkeys (synced + device-bound)	Yes (device-bound passkeys)	Phishing-resistant passwordless via WebAuthn, including in Microsoft Authenticator
Windows Hello for Business	Yes	On-device biometric / PIN unlocks an Entra-bound credential
Certificate-based authentication (CBA)	Yes (when cert is bound to hardware)	Smart cards or hardware-backed certs — common in regulated and government settings
SMS / Voice	No — phishable, SIM-swappable	Use only as fallback; cannot satisfy phishing-resistant MFA

Authentication strengths — the modern way to require 'real' MFA

Conditional Access has a control called Require authentication strength. Authentication strengths are policy objects that say “the user must satisfy this sign-in with a method that meets at least this assurance level”. Microsoft ships three built-in strengths:

Multifactor authentication — any combination of two factors (password + Authenticator push, password + SMS, etc.).
Passwordless MFA — must satisfy with a passwordless method (Authenticator passwordless, passkeys, Windows Hello, FIDO2).
Phishing-resistant MFA — must satisfy with a phishing-resistant method (FIDO2 hardware, passkeys, Windows Hello for Business, CBA on hardware).

You can also define custom authentication strengths combining specific methods (e.g. “Microsoft Authenticator phone sign-in” OR “Temporary Access Pass”). The exam routinely tests the difference between “require MFA” (any second factor) and “require phishing-resistant MFA” (hardware-bound) — the latter is what real high-assurance scenarios call for.

Scenario: Esme’s privileged-access lockdown at Northwind Bank

Esme at Northwind Bank is closing a finding from her last audit: the auditor flagged 14 named users with permanent Global Administrator. Here’s how she fixes it with the three layers in this module:

PIM — converts all 14 to eligible Global Administrator. Sets activation max to 4 hours, requires MFA on activation, requires written justification, requires single-approver from a 3-person rotating approver group. Adds a quarterly access review.
Conditional Access — creates a policy targeting the Global Administrator role (via authentication context tagged on the role activation flow): block access unless device is Intune-compliant AND the user satisfies the Phishing-resistant MFA authentication strength.
Authentication methods policy — ensures all 14 admins have at least one phishing-resistant method registered (Windows Hello for Business or a FIDO2 key). Disables SMS as a permitted method for the Privileged Admins group.

After the change, no one is Global Admin at rest. Activation requires an approval, MFA on a hardware-bound credential, and a compliant device. Every activation is an audit-grade event with justification. The auditor finding closes.