Microsoft 365 Conditional Access: Beyond Basic MFA for Production Workloads

Microsoft 365 Conditional Access is the policy engine that decides which sign-ins may proceed, which controls must be satisfied and which sessions should be blocked. MFA is one control inside that decision. A production design also considers the user, role, application, device state, client type, location and risk signal, then tests the result in report-only mode before enforcement.

This guide is for administrators who have moved past a tenant-wide “require MFA” rule and need repeatable policy patterns. The examples are design patterns, not copy-and-paste instructions. Microsoft changes names, licensing and portal behaviour, so verify every control against current Microsoft documentation and the licences in your tenant before deployment.

Why MFA alone is not a security boundary

MFA reduces the value of a stolen password, but it does not answer every access question. A user can complete MFA from an unmanaged device. A phished session can be abused after authentication. An administrator can sign in from an unexpected network. A legacy client may use an authentication path that does not support modern controls.

Conditional Access evaluates a sign-in and applies access or session controls. The security boundary comes from the combination of identity protection, device management, application permissions, session handling and monitoring. A model that simply says “MFA enabled” hides too much.

Conditional Access policy anatomy

A policy has assignments and access controls. Read it as a sentence: for these users, accessing these resources, under these conditions, grant access only if these controls are satisfied, or block it.

Users, groups and workload identities

Scope policies to named groups or roles rather than relying on an unmaintained list of individuals. Administrative roles deserve stricter controls. Guest users and service identities need deliberate treatment. Do not assume a policy designed for a human interactive sign-in will correctly protect an application identity.

Keep at least two emergency access accounts under a documented and monitored process, following current Microsoft guidance. Exclusions should be narrow, visible and alerted on. An excluded account is a deliberate exception, not a place to hide rollout problems.

Target resources

Choose the cloud applications or actions the policy protects. Broad “all resources” policies are useful for baseline controls, but application-specific policies may be needed for stronger device or session requirements. Microsoft can change how resource dependencies behave, so use sign-in logs and the What If tool to validate the effective path.

Conditions

• User and sign-in risk: signals from Microsoft Entra ID Protection, subject to licensing and available detections.
• Device platform and filter: operating system or device attributes, with care for unknown or spoofable inputs.
• Locations: named IP ranges or countries. Location is context, not identity.
• Client apps: browser, mobile/desktop clients and legacy authentication clients.
• Device state: compliance and join information when integrated with the relevant management controls.

Grant and session controls

Grant controls can require authentication strength, a compliant device, a hybrid joined device or an approved application, depending on the resource and current feature support. A policy can require one selected control or all selected controls. That single choice can materially change access.

Session controls can limit browser behaviour, sign-in frequency or persistent sessions, and can integrate with other Microsoft security capabilities where licensed. Treat session settings as part of the user experience and test them with the real clients your organisation supports.

Production pattern 1: block legacy authentication

Legacy authentication clients may not support MFA and modern policy controls. Create a policy that targets the relevant users and resources, uses the legacy authentication client condition and blocks access. Roll it out after identifying remaining dependencies.

Do not describe OAuth itself as a legacy flow that bypasses MFA. OAuth is used by modern authentication. The target is legacy client behaviour such as older Basic authentication paths and other clients classified by Microsoft under the legacy authentication condition.

Implementation sequence

1. Review Entra sign-in logs for legacy client use over a representative business period.
2. Identify the user, application, protocol, device and business owner for each dependency.
3. Upgrade or reconfigure supported clients. Replace dependencies that cannot use modern authentication.
4. Create the block policy in report-only mode and monitor the projected impact.
5. Pilot with a controlled group, communicate the change and prepare support instructions.
6. Enable broadly, then alert on attempted legacy sign-ins.

Shared mailboxes, scanners, line-of-business systems and old scripts are common places to investigate. Do not add permanent user exclusions simply to make the dashboard quiet.

Production pattern 2: require a compliant device for Exchange Online and SharePoint

This pattern limits access to business email and files from devices that meet your organisation’s compliance policy. It normally depends on Microsoft Intune or another supported device-management integration and appropriate licences. Compliance only means the device met the rules you configured, so those rules need substance.

Define supported platforms and enrolment first. Decide what browser access from an unmanaged device should look like. Some organisations block it; others use restricted web sessions for selected scenarios. Confirm current feature and licensing requirements before promising a particular experience.

Design considerations

• Separate employee devices, shared devices, guests and emergency access.
• Set compliance rules for supported versions, encryption and threat state according to your risk model.
• Plan enrolment, replacement devices and the first-day experience for new staff.
• Test native Outlook, browsers, mobile applications and file synchronisation clients.
• Provide a controlled recovery route when a device becomes non-compliant.

A compliant-device rule is not a substitute for least privilege. It tells you something about the endpoint; it does not make every user permission or application safe.

Production pattern 3: protect administrative roles with managed devices and stronger authentication

Administrative access should not rely on the same conditions as ordinary productivity access. Target directory roles or a tightly governed administrator group. Require an appropriate phishing-resistant authentication strength where your licences and hardware support it, and require a managed, compliant device dedicated or hardened for administration.

Be cautious with corporate-network requirements. A named location based on public IP can add context, but it is not proof that the device or person is trusted. Remote administration, cloud outages and emergency access also need a documented design.

Controls to combine

• Separate administrator accounts from daily email accounts.
• Use least-privilege roles and time-bound elevation where available.
• Require managed-device access for privileged portals and management APIs where supported.
• Apply stronger authentication to privileged roles.
• Monitor emergency account use and privileged sign-ins.
• Block unsupported client types and unnecessary locations according to the risk assessment.

Test non-interactive administration tooling separately. Scripts and automation should use supported application identities, managed identities or certificate-based methods as appropriate, with their own permission and Conditional Access design. Never “fix” a broken automation by excluding a broad administrator group.

Production pattern 4: risk-based step-up and remediation

Risk-based policies use Entra ID Protection signals to respond to detected user or sign-in risk. A common design requires stronger authentication or secure password change at selected risk levels, while high-risk conditions may be blocked or routed for investigation. The exact controls and licence requirements must be verified against the current Microsoft plan.

Do not use “require MFA only when risk is medium or high” as your entire MFA strategy. Risk detections are useful but cannot observe every attack. Maintain an appropriate baseline authentication policy, then add risk-based response for suspicious events.

Define what happens after a risk event. Who reviews it? Which evidence is checked? When is the user contacted? How is a false positive resolved? A policy without an operating procedure creates lockouts or ignored alerts.

Common Conditional Access misconfigurations

Overlapping policies with misunderstood outcomes

Applicable policies are evaluated together. Grant requirements can accumulate, while one applicable block policy blocks access. Administrators often read policies one at a time and miss the effective combination. Test the full policy set for representative personas.

Broad exclusions that become permanent bypasses

An exclusion added during rollout can remain for years. “Exclude everyone except the pilot group” is valid during a controlled test only if the change is tracked and reversed. Use named groups, owners, expiry dates and regular access reviews for exceptions.

Using trusted locations as a substitute for MFA

IP addresses can be shared, changed or reached through a compromised internal device. A named location may reduce friction in a narrow use case, but it should not silently remove strong authentication from privileged work.

Skipping report-only mode

Direct enforcement can block legitimate work before the support team understands the dependency. Report-only mode shows how the policy would apply without enforcing its grant or block decision. It does not replace a pilot, because projected results do not reproduce every user interaction.

Targeting the wrong resources

A policy may protect one front door while a dependent service or management endpoint remains outside scope. Use current Microsoft guidance for resource dependencies and inspect sign-in logs for the actual resources contacted by your clients.

Ignoring service accounts and workload identities

Human sign-in policies do not automatically solve application identity risk. Inventory automation, remove embedded user credentials and design application permissions separately. Where Conditional Access for workload identities is available and licensed, evaluate it as part of the workload security model.

Testing with the What If tool

The What If tool estimates which policies apply to a chosen scenario. Test at least these personas:

• ordinary employee on a compliant managed device;
• employee on an unmanaged browser;
• remote employee from a new location;
• guest user;
• privileged administrator;
• emergency access account;
• supported mobile client;
• legacy client attempt.

Vary the resource, client app, device state, location and risk condition. Save expected results in the change record. The tool is an estimate, so validate with controlled real sign-ins and the sign-in logs.

Read the sign-in logs like an effective-policy trace

For each pilot sign-in, inspect the Conditional Access tab and authentication details. Confirm which policies applied, which did not and why. Look for “not applied” caused by scope, exclusions or an unmatched condition. Check the client application, device identifiers and resource.

Export or retain evidence according to your logging policy. Build alerts for high-value conditions such as emergency account use, legacy authentication attempts, repeated policy failures and risky privileged sign-ins. Tune alerts with an owner and response procedure rather than sending everything to an unattended mailbox.

Small-team implementation checklist

1. Inventory users, roles, guests, service accounts, applications, devices and supported clients.
2. Confirm Entra ID, Intune and related licence requirements against current Microsoft documentation.
3. Create and monitor emergency access accounts before enforcing broad policies.
4. Define baseline MFA and authentication-strength requirements.
5. Block legacy authentication after dependency discovery and remediation.
6. Design device compliance and unmanaged-browser behaviour.
7. Apply stronger policies to administrative roles.
8. Add risk-based response where licensed, with an investigation process.
9. Build policies in report-only mode and test personas with What If.
10. Pilot real sign-ins, inspect logs and document support steps.
11. Enable in stages, monitor failures and keep rollback criteria.
12. Review exclusions, groups, applications and policy ownership quarterly.

Conditional Access is an operating system for access decisions

A production Conditional Access design is not a pile of policies. It is a set of explicit access decisions with owners, tests, evidence and exception handling. MFA remains essential, but it works best inside a policy model that also controls devices, clients, resources, privileged roles, risk and sessions.

Start with report-only visibility, remove legacy dependencies and protect administrators first. Then add device and risk controls with licensing and user experience verified in the real tenant. The safest policy is not the most complicated one. It is the one your team can explain, test and operate.