Microsoft Entra ID Conditional Access: Real-World Design Patterns

In Microsoft 365 tenants, Conditional Access is a primary enforcement point for Zero Trust. Entra ID evaluates signals such as user, group, role, device state, application, location, client app, risk, authentication strength, and session controls during sign-in and token issuance. Continuous Access Evaluation can shorten exposure for supported apps and events, but Conditional Access is still only as strong as the policy design.

Risk accumulates when tenants grow policies organically: 12 to 40 policies, emergency exclusions, broad trusted locations, pilot groups that became permanent, and legacy policies no one wants to change because they might affect executives, frontline workers, or service accounts.

Common gaps include MFA required for Microsoft 365 but not Azure management; guests excluded from controls after a project; legacy authentication or SMTP AUTH left enabled for a small group; admins protected except synchronized service accounts; SharePoint protected by device compliance while Teams file access is not tested; and trusted locations based on ISP ranges instead of owned egress IPs.

Good design is not more policies. It is fewer, clearer policies mapped to attack paths. Every identity type needs a control model. Every exception needs an owner and expiry date. Every privileged action needs stronger protection than everyday productivity access.

Start with access tiers, not with a generic MFA policy. Most organizations can use three tiers.

Tier 0 is control-plane access: Global Administrator, Privileged Role Administrator, Exchange Administrator, SharePoint Administrator, Intune Administrator, Security Administrator, roles that can change authentication methods, roles that can change device compliance, and emergency access accounts. If an attacker owns Tier 0, they can usually own the tenant.

Tier 1 is business data access: Exchange Online, SharePoint, OneDrive, Teams, Power BI, Dynamics 365, and line-of-business SaaS apps using Entra ID for single sign-on. This is where token theft, unmanaged device access, and OAuth consent abuse create data exposure.

Tier 2 is constrained access: kiosk scenarios, training portals, low-risk apps, or limited guest collaboration where data exposure is intentionally narrow.

Do not mix these tiers into one broad policy called Require MFA for all users. That may satisfy a superficial audit request, but it does not give admins phishing-resistant authentication, tighter session controls, or clean incident response boundaries.

Use separate policy sets. Admin access should require phishing-resistant authentication where possible, restrict persistent sessions, and use compliant devices, Microsoft Entra hybrid joined devices, or privileged access workstations where operationally feasible. Business data access should require MFA plus device or session controls based on data sensitivity. Low-impact access can use lighter controls only after the app and data are classified.

Licensing affects the design. Microsoft Entra ID P1 includes Conditional Access. Microsoft Entra ID P2 adds Identity Protection risk signals for user and sign-in risk in Conditional Access, plus capabilities such as Privileged Identity Management and access reviews. For frequent travel, high-value mailboxes, exposed executives, or weak password hygiene, risk-based controls are often operationally important, not optional polish.

Generic MFA is not enough for privileged access. Push fatigue, adversary-in-the-middle phishing kits, session cookie theft, and helpdesk social engineering changed the baseline. The admin plane should use phishing-resistant methods where possible: FIDO2 security keys, Windows Hello for Business, or certificate-based authentication when the organization can operate it securely.

Use Conditional Access authentication strengths for privileged roles. Target directory roles rather than only static admin groups, because role membership changes. Require a phishing-resistant authentication strength for privileged access. Block legacy authentication. Use shorter sign-in frequency for admin work. Avoid persistent browser sessions for privileged administration.

Exclude only emergency access accounts from normal privileged-access Conditional Access controls. Keep at least two emergency access accounts cloud-only, assigned the required emergency privilege, protected by long unique passwords, excluded from dependencies that could fail during an outage, monitored aggressively, and tested at least quarterly. One can stay password-only for a true MFA outage; the other can use a FIDO2 key that does not depend on the control you might need to bypass.

Separate admin identities from daily productivity identities. A CFO who is also a billing admin should not use the same account for email and tenant administration. If the mailbox is phished, the attacker should not inherit administrative rights that can modify authentication methods, add federation, grant app consent, change Conditional Access, or create broad mailbox rules.

Requiring a compliant device for everything often breaks contractors, mobile access, acquisitions, Linux users, emergency access, and executive travel. Then exclusions pile up and the policy becomes weaker than the original design.

Apply device trust where data can leave the tenant. For SharePoint, OneDrive, Exchange Online, and Teams file access, unmanaged devices should receive restricted access where supported: browser-only access, no download, no sync, no persistent session, and app-enforced restrictions or Microsoft Defender for Cloud Apps session controls when licensed and supported. Managed and compliant devices can receive full access. Test Teams scenarios specifically because Teams files are stored in SharePoint and OneDrive, but user experience varies by client and policy combination.

For endpoint-managed organizations, require compliant devices or Microsoft Entra hybrid joined devices for sensitive apps and administrative portals. For BYOD-heavy organizations, combine Conditional Access with Intune app protection policies, approved client apps, and session controls for mobile access. Do not design as if every device can be managed when the business model says otherwise.

Use this audit question: can a user download regulated data from SharePoint or OneDrive to a personal device after satisfying MFA? If yes, MFA is being used as a data-loss control. It is not. MFA improves confidence in the user at sign-in; it does not make the endpoint trustworthy.

Every Conditional Access deployment needs exceptions. The risk is permanent exceptions with no owner, no compensating control, and no review cycle.

Most dangerous exclusions start with reasonable requests: a scanner sending mail, a warehouse device that cannot handle MFA, an executive assistant workflow, a vendor integration, a travel issue, or a migration window. Months later, the requester changed roles, the account still exists, and its access is broader than anyone remembers.

Use a formal exception record. Each exclusion needs a business owner, technical owner, reason, affected policy, compensating control, review date, and expiration date. If an account is excluded from MFA, it should not also have mailbox access and administrative rights. If an automation account cannot use interactive MFA, move it to a supported workload identity pattern such as managed identities, workload identity federation, certificate-based app authentication, or another modern authentication design appropriate to the workload.

Apply the same discipline to named locations. Trusted locations should generally be owned, documented egress IPs, not broad geographies or consumer ISP ranges. Country blocking can reduce noise, but it is not identity proof. Attackers use residential proxies, VPNs, and cloud infrastructure inside allowed countries.

Set hard targets: no human user excluded from baseline MFA without an expiry date; no admin excluded from privileged-access controls except tested emergency access accounts; no trusted location unless it is owned, documented, and reviewed.

Many designs still assume the attacker has a password and must complete MFA. Modern attacks often target tokens, sessions, and consent. Adversary-in-the-middle kits can capture session tokens. OAuth consent attacks can create durable access. Compromised endpoints can reuse browser sessions.

Limit what a stolen session can do and how long it remains useful. For privileged access, use phishing-resistant authentication, shorter sign-in frequency, no persistent browser sessions, and device requirements where feasible. For standard users, combine MFA, risk-based Conditional Access when licensed, Continuous Access Evaluation for supported apps, and session controls for unmanaged devices.

Monitor attack-path indicators: authentication method changes followed by risky sign-ins; inbox rule creation after unfamiliar sign-ins; impossible travel followed by successful authentication; new app consent grants; legacy protocol attempts against executives; repeated MFA denials followed by approval; device compliance changes shortly before access to sensitive apps; and sign-ins from unfamiliar networks, ISPs, or autonomous system numbers.

Conditional Access is enforcement. Logs prove whether enforcement works. Use the What If tool before policy changes, then validate with sign-in logs, audit logs, Identity Protection detections, Conditional Access insights, and real access tests for the scenarios the business depends on.

Report-only mode is for impact analysis, not indefinite deferral. Use it to find affected users, fix identity hygiene, adjust exclusions, and then enforce.

A practical rollout sequence is: inventory current policies and exclusions; classify apps and identity tiers; protect privileged roles; enforce baseline MFA and legacy authentication blocking; add device and session controls for data apps; introduce risk-based policies if licensed; document exceptions; validate logging and alerting.

Use pilot groups, but set short decision windows. A well-scoped policy often needs days or a few weeks in report-only, not a quarter. If a policy stays in report-only for 90 days, either the organization has not accepted the control or the policy is too broad.

Before enforcement, test business-critical scenarios: payroll from a managed device, executive travel, guest access to Teams, mobile access with app protection policies, helpdesk password reset, emergency access account sign-in, Azure portal access, service account or workload authentication, and Microsoft Purview compliance tasks. The goal is not zero disruption. The goal is to find disruption before attackers find the gap.

Measure the rollout with numbers the tenant already produces: MFA registration coverage, legacy authentication attempts per week, the count of Conditional Access exclusions and how many carry an expiry date, sign-ins from unmanaged devices to data apps, privileged role activations, risky sign-ins left unremediated, external forwarding exceptions, and anonymous sharing links created. The Conditional Access Policy Review and Break-Glass Validation service ($2,450 per project) produces that baseline and tests the emergency accounts.

Conditional Access decides who gets a token. The next question is what that token can do once an attacker holds it. Five controls limit the damage, and none of them is a Conditional Access policy.

Exchange Online. Disable automatic external forwarding in the outbound spam policy and allow it only by documented exception. Alert on new inbox rules that forward, delete, or move mail into folders such as RSS Feeds, because that is the first thing a phished mailbox is used for. Keep SMTP AUTH off at the tenant level and enable it per mailbox only for the device that needs it.

SharePoint and OneDrive. Do not leave Anyone links as the default link type. Scope external sharing by site: finance, legal, board, HR, and client-data sites get stricter sharing settings, an allowed-domain list where practical, a sensitivity label, and a named owner who reviews external users.

Data loss prevention. Start Microsoft Purview DLP narrow: high-confidence policies for financial data, identity documents, health records, and source code, in the locations where they live. A broad policy that produces thousands of false positives gets switched off; a narrow one that blocks a specific risky action and alerts the right owner gets kept.

Application consent. Turn off user consent to applications and run the admin consent workflow, so every new OAuth grant has a reviewer, a publisher check, and a business owner. Review existing enterprise applications and app registrations for permissions that reach past one user: Mail.ReadWrite, Files.ReadWrite.All, Sites.ReadWrite.All, Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, and anything with offline_access. Each needs an owner and a purpose; remove the rest.

Standing privilege. Keep Global Administrator rare, split the workload admin roles by job, and move the rest to eligible assignments in Privileged Identity Management with justification, MFA, and a short activation window. PIM needs Microsoft Entra ID P2 or a suite that includes it.

Conditional Access is a Microsoft Entra ID P1 feature, and P1 is included in Microsoft 365 Business Premium ($22 per user per month) and Microsoft 365 E3 ($39). Risk-based policies, Identity Protection, Privileged Identity Management, and access reviews need Microsoft Entra ID P2, included in Microsoft 365 E5 ($60). Standalone, at Microsoft list price, October 2026 price list, per user per month on an annual commitment:

License P2 only for the users who need risk-based policies. Microsoft subscription prices are always your own; IT Partner sells them at list. Our Entra ID P1 vs P2 guide covers the split in detail.

Do we need Microsoft Entra ID P2 for Conditional Access?

No. Conditional Access, named locations, device-based grants, and authentication strengths are Microsoft Entra ID P1 features, included in Business Premium and E3. P2 ($10 per user per month standalone) adds sign-in and user risk conditions, Identity Protection, Privileged Identity Management, and access reviews. License P2 for the people who need risk-based policies, not the whole tenant.

What do we do with a scanner or application that cannot do MFA?

Record it as an exception with an owner and an expiry date, and move it off interactive sign-in: SMTP AUTH enabled only for that mailbox, a dedicated account with no other access, or a managed identity or certificate-based app authentication where the workload supports it.

Does Conditional Access replace our VPN?

Not by itself. Conditional Access controls access to cloud apps that use Entra ID; private applications behind a VPN still need a path. Microsoft Entra Private Access can put those apps behind the same policies, which is the subject of our Entra Private Access vs VPN guide.