Conditional Access

On December 2, 2026, Sunil Rao opened the Conditional Access page in the Microsoft Entra admin center for the first time with Ama Boateng beside him. Harrow & Finch had bought Microsoft Entra ID P1 licenses as part of its Microsoft 365 plan years earlier but had never used the feature; the tenant still relied on security defaults. "This is the policy engine from lesson 2," Sunil said. "Everything we decided about Zero Trust turns into rules here. And because a bad rule can lock out the whole company, we're going to be very careful about how we test them."

Microsoft Entra Conditional Access evaluates signals about each sign-in and applies the organization's policies to decide whether to allow access, require something more, or block it. It is one of the most important capabilities in the SC-900 Entra domain. This lesson explains how a policy is built, how policies combine, and how Harrow & Finch planned its first set.

If this, then that

A Conditional Access policy is easiest to understand as an if-then statement. *If* a user who matches the assignments signs in to a matching application under matching conditions, *then* apply these access controls. For example: if any user signs in to any cloud app from outside the company's known locations, then require multifactor authentication. Or: if anyone signs in from a country where the company has no staff, then block access.

Conditional Access is evaluated after the first factor of authentication is completed. It is not a replacement for authentication; it is the decision step that follows, using what Microsoft Entra ID now knows about the user and the request. Policies are enforced for sign-ins to Microsoft Entra ID, which means they apply to every application that uses Entra ID for single sign-on: Microsoft 365, Azure management, SaaS apps and the company's own apps such as StockLine.

Assignments: who and what

The first part of a policy defines its scope. Users, groups and roles can be included or excluded: all users, specific groups, directory roles such as Global Administrator, guests and external users, or workload identities such as service principals, which need the Microsoft Entra Workload ID license. Target resources define what the policy protects: all cloud apps, specific applications such as Office 365 or the Microsoft Azure management portal, or user actions such as registering security information.

A key design rule is to exclude emergency access accounts, sometimes called break-glass accounts, from policies that could lock everyone out. These are a small number of highly protected cloud-only accounts kept for the situation where normal administrator sign-ins stop working, for example if a policy is misconfigured or an MFA service fails. They must be monitored closely, because any sign-in with them is unusual by design.

Conditions: under what circumstances

Conditions narrow when a policy applies, using signals about the sign-in. Network or locations use IP address ranges and countries; administrators define named locations, such as Harrow & Finch's head office and store internet addresses, and can mark them as trusted. Device platforms distinguish Windows, macOS, iOS, Android and Linux. Client apps distinguish browsers, modern mobile and desktop apps, and legacy authentication clients, older protocols that cannot perform MFA and are a common route for password-spraying attacks. Sign-in risk and user risk, calculated by Microsoft Entra ID Protection, are available with a P2 license and are described in lesson 12. A device filter can target devices by attributes, such as shared store tablets.

Access controls: what happens

When a policy applies, its access controls decide the outcome. Block access denies the sign-in. Grant access allows it, optionally with requirements: require multifactor authentication; require an authentication strength, such as phishing-resistant MFA only; require the device to be marked as compliant by Microsoft Intune; require a Microsoft Entra hybrid joined device; require an approved client app or an app protection policy on mobile devices; require a password change when user risk is high; or require acceptance of terms of use. When several grant requirements are selected, the policy can require all of them or any one of them.

Session controls shape what happens after access is granted. Sign-in frequency sets how often users must sign in again, which is useful for unmanaged devices. Persistent browser session decides whether users stay signed in after closing the browser. App-enforced restrictions let services such as SharePoint Online limit what users can do from unmanaged devices, such as viewing but not downloading files. Conditional Access App Control, provided through Microsoft Defender for Cloud Apps, can monitor and control sessions in real time, for example blocking downloads of labeled files.

How policies combine

Organizations usually have many policies, and several can apply to the same sign-in. Microsoft Entra ID evaluates all policies that apply, not just the first one. If any applicable policy blocks access, the sign-in is blocked: block always wins. Otherwise, the user must satisfy the grant requirements of every applicable policy. There is no priority order to configure. If no policy applies, access is allowed based on authentication alone, which is why many organizations add a baseline policy for all users and all apps.

Ama wrote a simulation of that logic to check the team's understanding before they touched the real tenant. It evaluates a set of simplified policies against several sign-ins and collects every requirement that applies.

policies = [
    {"name": "Block legacy authentication", "users": "all", "when": lambda s: s["client"] == "legacy", "action": "block"},
    {"name": "MFA for all users", "users": "all", "when": lambda s: True, "action": {"mfa"}},
    {"name": "Admins need phishing-resistant MFA", "users": "admins",
     "when": lambda s: True, "action": {"phishing-resistant"}},
    {"name": "Payroll needs compliant device", "users": "all",
     "when": lambda s: s["app"] == "payroll", "action": {"compliant device"}},
    {"name": "Block countries with no staff", "users": "all",
     "when": lambda s: s["country"] not in ("CA", "US"), "action": "block"},
]
def evaluate(s):
    needs = set()
    for p in policies:
        if p["users"] == "admins" and not s["admin"]:
            continue
        if s["user"] == "breakglass":          # emergency access accounts are excluded
            continue
        if p["when"](s):
            if p["action"] == "block":
                return "BLOCK (" + p["name"] + ")"
            needs |= p["action"]
    return "allow after: " + (", ".join(sorted(needs)) if needs else "nothing extra")

signins = [
    {"user": "store14.manager", "admin": False, "app": "email", "client": "browser", "country": "CA"},
    {"user": "payroll.clerk", "admin": False, "app": "payroll", "client": "browser", "country": "US"},
    {"user": "theo.admin", "admin": True, "app": "azure portal", "client": "browser", "country": "CA"},
    {"user": "old.scanner", "admin": False, "app": "email", "client": "legacy", "country": "CA"},
    {"user": "store14.manager", "admin": False, "app": "email", "client": "browser", "country": "RO"},
]
for s in signins:
    print(f"{s['user']:16s} {s['app']:13s} -> {evaluate(s)}")

store14.manager  email         -> allow after: mfa
payroll.clerk    payroll       -> allow after: compliant device, mfa
theo.admin       azure portal  -> allow after: mfa, phishing-resistant
old.scanner      email         -> BLOCK (Block legacy authentication)
store14.manager  email         -> BLOCK (Block countries with no staff)

The simulation showed the rules working together: the payroll clerk needs both MFA and a compliant device, the administrator needs both ordinary MFA and the phishing-resistant strength (which satisfies both), and the sign-in from a country with no staff is blocked regardless of anything else. The same pattern would have stopped the October attacker twice over.

Testing safely: report-only and What If

Because Conditional Access affects every sign-in, mistakes are costly. Microsoft provides two tools to reduce risk. Report-only mode lets a policy run without enforcing it: Microsoft Entra ID evaluates the policy for each sign-in and records what would have happened in the sign-in logs, without blocking or prompting anyone. Administrators can review the results, often with the Conditional Access insights workbook, and switch the policy on once they are confident. The What If tool lets an administrator describe a hypothetical sign-in, such as a particular user, app, location and device, and see which policies would apply and what the result would be.

Microsoft also provides policy templates for common scenarios, such as requiring MFA for administrators or blocking legacy authentication, and creates some Microsoft-managed policies in tenants automatically, starting in report-only mode, to help organizations adopt recommended protections. Administrators can review, adjust or turn off those policies.

Keeping policies manageable

Conditional Access configurations can grow messy. Microsoft recommends a clear naming convention, so each policy's purpose is obvious from its name, and a small set of baseline policies that apply broadly, with specific policies added for sensitive apps and roles. Ama proposed names such as CA01-AllUsers-AllApps-RequireMFA, so that anyone reading the list would know the scope and the control at a glance.

Theo Marchand raised a practical concern about policy 2. The head office had an old multifunction printer that sent scanned documents by email using legacy authentication. Report-only mode confirmed it: the printer was the only legacy sign-in in two weeks of logs. Rather than exclude it from the policy, the team scheduled the printer's replacement for January and moved scanning to a modern method in the meantime.

Conditional Access and the wider picture

Conditional Access connects many of the ideas in this course. It uses identities and groups from lesson 7, authentication methods and strengths from lesson 9, device states from Microsoft Intune, risk from ID Protection in lesson 12 and locations from the organization's network. It also connects to products covered in MSAZ-131, such as Microsoft Defender for Cloud Apps for session control. Microsoft Entra's network access products, Internet Access and Private Access, extend Conditional Access to network traffic, so that the same identity and device checks can govern access to private applications without a traditional VPN.

Renata Kowal summed up the December plan for the Skylight steering group: "For the first time, we'll be able to say exactly who can get into what, from where and on which devices, and we'll have the logs to prove it." Dana Whitcombe asked one question: would store staff notice? Ama's answer was that most would see an MFA prompt only occasionally, from outside store and office locations, while the attacker from October would never have got in.