Build Conditional Access for 5 Scenarios

Conditional access is where identity and device posture turn into an actual allow/deny decision. A conditional-access policy has a simple shape: conditions (who, what device, where, what risk) combined with a grant control (allow, require MFA / step-up, allow with limits, or block). Designing good policies is the capstone skill of this phase — it ties together Phase 2 identity with this phase's device posture and encryption controls.

For each scenario below, choose the conditional-access policy that best balances security and the business need. Every scenario has one best answer, and the explanations walk through the reasoning you will use when designing real policies. Watch for two recurring failure modes: policies so strict they break legitimate work (and get disabled), and policies so loose they do not actually constrain the risk.

When your new policy locks out the whole company — including you

The shape of a policy

Read each scenario as: IF [these users/groups] access [this resource] from [this device/location/risk state] THEN [grant / require step-up / limit / block]. Also remember to plan the break-glass path: every block-heavy policy needs an emergency-access account excluded from it, or you risk locking the whole company out of its own tenant.

Scenario 1: Production admin console

Quick check

Access to the cloud production admin console (the highest-blast-radius resource) needs a conditional-access policy. What is the strongest appropriate design?

Require a correct password only — admins are trusted employees

Require phishing-resistant MFA AND a managed, compliant, encrypted device; block access from unmanaged or non-compliant devices entirely

Require MFA from any device, managed or not

Allow from the corporate office IP range with no other conditions

Scenario 2: Contractor on a personal (BYOD) laptop

Quick check

Contractors must use an internal web app from their own unmanaged laptops. The company will not manage personal devices. What conditional-access design fits?

Require the contractors to fully enroll and submit their personal laptops to company management and wipe capability

Allow browser-only access with session controls (no download, shortened session lifetime, app-enforced restrictions) for unmanaged devices, plus MFA — granting limited access without taking over the personal device

Block all contractor access since their devices are unmanaged

Allow full access with password and MFA, treating contractor laptops the same as corporate ones

Scenario 3: Risky / anomalous sign-in

Quick check

The identity provider flags a sign-in as high-risk (impossible-travel: a login from a new country minutes after one from the home office). What conditional-access response is appropriate?

Ignore risk signals; if the password and MFA are correct, allow it

On high sign-in risk, require step-up (re-authenticate with phishing-resistant MFA) or block until the risk is cleared, rather than silently allowing the session

Permanently block the user account at the first risk signal, with no recovery path

Email the user a warning but allow the session to continue uninterrupted

Scenario 4: Legacy app that can't do modern auth

Quick check

A legacy internal application only supports basic authentication (username/password) and cannot enforce MFA or evaluate device posture. Leadership wants it accessible. What is the most defensible approach?

Expose it to the internet with basic auth, since the business needs it

Restrict it behind controls the app cannot enforce itself: require access only from managed/compliant devices via a proxy or network boundary (and/or VPN/ZTNA), limit to specific users, monitor closely, and plan to retire or modernize it

Leave it open internally with no additional controls because it is not internet-facing

Allow it for everyone with password-only since adding MFA is impossible

Scenario 5: Break-glass emergency access

Quick check

You are rolling out strict block-based conditional-access policies across the tenant. What must you design alongside them to avoid catastrophe?

Nothing extra — strict policies should apply to absolutely everyone, including all admins, with no exceptions

A break-glass (emergency access) account excluded from the conditional-access policies, with a long complex credential stored securely, strong monitoring/alerting on its use, and a documented procedure — so a misconfigured policy or IdP outage cannot lock the whole organization out

Share the global-admin password with the whole IT team so someone can always get in

Disable conditional access entirely on weekends in case something breaks

Designing policies in practice

The five scenarios trace the real design space. A few principles to carry into actual policy work:

Match strictness to blast radius. Crown-jewel resources (production admin, sensitive data) get the strongest stack — phishing-resistant MFA plus managed/compliant device, unmanaged devices blocked. Lower-sensitivity resources tolerate looser conditions. Tiering is the whole game.
Use posture to enable access safely, not just to forbid it. BYOD and contractor access become possible because conditional access can grant a limited, controlled session rather than all-or-nothing.
Let risk signals interrupt, not just identity verify. Step-up on elevated risk catches sessions that pass password+MFA but smell wrong.
Wrap what apps can't enforce themselves. Legacy systems get protected at the proxy/network layer and put on a retirement path.
Always plan break-glass. Every block-heavy rollout needs a monitored emergency-access exclusion, or you risk locking the organization out of its own tenant.

GRC Engineer's lens

A conditional-access policy set is one of the most powerful and most auditable controls you can point to — it operationalizes least privilege, device trust, and risk-based access in one place. When you document it, capture the policy export (the IF/THEN rules), the device-posture sources feeding it (MDM compliance, EDR risk), and sign-in logs showing the policies actually evaluated — granting, stepping up, and blocking as designed. And always document the break-glass design and its monitoring: an auditor who sees strict policies will immediately ask how you avoid locking yourselves out, and the answer should already be written down.

Phase wrap-up

That completes Endpoint & Device Security. You can now trace the full arc: MDM enrolls and configures devices and reports compliance (Module 3.1); EDR detects and responds to what gets through, and CIS Benchmarks harden the OS to shrink the attack surface (Module 3.2); and BYOD/posture, encryption with key escrow, and conditional access turn device trust into an enforced, evidenced access decision (Module 3.3). Every one of these produces the reports and policy exports that satisfy endpoint and device controls across SOC 2, ISO 27001, and NIST — and they connect directly back to the identity work in Phase 2, because in the end, who you are and what device you are on are evaluated together.