How Do Conditional Access and PIM Actually Stop Attacks?

Password policies stop guessing attacks. They do nothing against a stolen session token, a phished MFA prompt, or a standing admin account that's been sitting there with Global Administrator rights for two years. Conditional Access and Privileged Identity Management (PIM) are the two Azure AD / Entra ID controls that actually address those gaps, and they work best together.

What Conditional Access is doing under the hood

Conditional Access is an if-this-then-that engine evaluated at sign-in time. The "if" side (signals) includes user/group membership, device compliance state, network location, sign-in risk (from Identity Protection), application being accessed, and client app type (browser vs. legacy protocol). The "then" side (controls) includes: require MFA, require a compliant device, require an approved client app, block access entirely, or require a terms-of-use acceptance.

A policy that matters in almost every tenant: block legacy authentication. Protocols like POP, IMAP, and older SMTP don't support modern MFA challenges, so they're the first thing credential-stuffing tools try. Check sign-in logs filtered by "Client App = Other clients" before you block — you'll often find one legacy scanner or an old multifunction printer still authenticating with basic auth.

A second one worth having from day one: require MFA for all users, scoped with an exclusion group for break-glass accounts only. Don't scope MFA to "just admins." Compromised standard user accounts are how attackers get their first foothold before privilege escalation even starts.

Sign-in risk vs. user risk — different signals, different responses

Identity Protection (part of Entra ID P2) generates two separate risk scores and it's easy to conflate them:

• Sign-in risk — this specific authentication attempt looks anomalous (impossible travel, anonymous IP, unfamiliar sign-in properties).
• User risk — this account has been flagged for a reason tied to the identity itself (leaked credentials found in a breach corpus, confirmed compromise activity).

A Conditional Access policy responding to sign-in risk should typically challenge with MFA — if the real user can complete the challenge, let them through. A policy responding to user risk should force a password reset, because MFA alone doesn't help if the credential itself is already burned.

Why standing admin access is the bigger problem

Even with airtight Conditional Access, an account that holds Global Administrator permanently is a target sitting in plain sight in the directory. Anyone who compromises it inherits full tenant control with no additional step required. PIM removes the "permanent" part.

With PIM, admin roles are assigned as eligible rather than active. The user has to explicitly activate the role, which triggers a required justification, optional approval workflow, MFA re-confirmation, and a time-bound window — commonly 1 to 8 hours — after which the role automatically deactivates. Nobody, including the account owner, has standing Global Admin unless they're actively using it.

A minimum PIM configuration that's actually usable

• Every role above Helpdesk Administrator: eligible, not permanent.
• Global Administrator and Privileged Role Administrator: require approval from a second admin, not just self-activation.
• Activation MFA required, no exceptions.
• Maximum activation duration of 4 hours forces people to reactivate for genuinely separate work sessions, which also produces cleaner audit trails.
• Access reviews every 90 days on all eligible assignments — accounts get added for one project and never removed otherwise.

Where teams get this wrong

The most common failure isn't policy design, it's the exclusion list. A Conditional Access policy with an ever-growing "exclude these users because the app doesn't support MFA" group eventually excludes half the tenant. Track exclusions as a backlog item with an owner and a removal date, not a permanent bucket.

The second failure is break-glass accounts that aren't actually tested. Two emergency accounts, excluded from Conditional Access and PIM, with long random passwords stored offline and alerting on any sign-in — and someone should try logging into them quarterly to confirm they still work.

Conditional Access and PIM aren't a checkbox for a compliance audit. They're the difference between a phished credential being an inconvenience and it being a full tenant compromise. If you're mapping out identity controls as part of a Blue Team build-out, Korra Studio's Cloud and Blue Team segments cover the detection side — what Identity Protection risk events actually look like in Sentinel and how to alert on impossible PIM activation patterns.