Conditional Access can stop a compromised password becoming a business-wide incident. It can also lock out every employee if it is rushed. Knowing how to configure conditional access properly means treating it as a controlled security change, not a switch to flick in the Microsoft Entra admin centre.
For organisations running Microsoft 365, Conditional Access provides the decision-making layer between a sign-in attempt and access to company data. It assesses signals such as the user, application, device, location and sign-in risk, then applies a response. That response may require multi-factor authentication, demand a compliant device, restrict a session or block access altogether.
The objective is straightforward: give legitimate users appropriate access while making unauthorised access materially harder. The work lies in applying that principle without disrupting staff, contractors, mobile teams or critical business applications.
Before creating policies, document how people actually work. A construction supervisor checking drawings from a managed tablet on site has different access needs from a finance employee processing payments from a desktop in the office. Both need protection, but a blanket rule can create unnecessary friction or encourage workarounds.
Start by identifying the applications that hold sensitive data, the user groups with elevated permissions, and the devices accessing Microsoft 365. Confirm whether devices are enrolled in Microsoft Intune, whether they meet your compliance requirements, and whether staff use personal mobiles for email or Teams.
You should also understand your licensing position. Most Conditional Access capabilities require Microsoft Entra ID P1. Risk-based policies, including controls based on user or sign-in risk, require Entra ID P2. Licensing is not an administrative detail – it determines which controls can be applied legitimately and consistently.
A practical planning exercise should cover four areas:
This baseline turns Conditional Access from a collection of generic Microsoft recommendations into a policy set that reflects your actual operating environment.
Every Conditional Access rollout needs at least two cloud-only emergency access accounts. These are sometimes called break-glass accounts. They should use strong, unique passwords stored securely, have tightly controlled access, and be monitored for any sign-in activity.
Exclude these accounts from Conditional Access policies. This may feel counterintuitive, but it protects the business if an incorrect policy, identity service issue or multi-factor authentication failure prevents normal administrators from signing in. Without an emergency path, a simple configuration error can become an extended outage.
Do not use these accounts for daily administration. Test them periodically, record the test, and review their permissions. The exclusion is a recovery control, not a shortcut around security.
In the Microsoft Entra admin centre, create Conditional Access policies one at a time. Give each policy a clear, operational name that explains its purpose, such as Require MFA for privileged roles or Block legacy authentication. A readable naming convention makes future reviews faster and reduces the chance of overlapping rules.
For each policy, work through the same sequence: assignments, target resources, conditions, access controls and session controls. The settings matter, but so does the interaction between policies. A user can be subject to several policies during one sign-in, and the strictest applicable requirement generally wins.
Legacy authentication protocols do not support modern multi-factor authentication and are frequently targeted in password-spray attacks. Blocking them is usually one of the highest-value Conditional Access controls available.
Before enforcing the block, check sign-in logs for applications, printers, scanners or older mail clients that still rely on legacy protocols. Some organisations find a forgotten multifunction device sending scan-to-email is the only remaining dependency. Replace or reconfigure that dependency before enforcement rather than creating a permanent exception.
Administrative accounts have the greatest potential impact if compromised. Create a policy that targets directory roles rather than relying solely on a manually maintained user group. Require multi-factor authentication for access to all cloud applications, with your emergency access accounts excluded.
For higher-risk roles, consider phishing-resistant authentication methods such as passkeys or FIDO2 security keys. The right choice depends on the role, workforce and available hardware, but SMS should not be the long-term standard for privileged access.
Next, require MFA for the broader workforce. Begin in report-only mode where possible, then review the resulting sign-in data. This shows who would have been challenged or blocked without changing their access yet.
Report-only mode is valuable, but it is not a substitute for testing. Run a small pilot group first, including people who work remotely, use mobile devices, access shared mailboxes or rely on line-of-business applications. Ask them to complete normal tasks, not just sign in once. Their experience will expose gaps that a policy review alone may miss.
When moving to enforcement, communicate the change in plain English. Explain what staff need to do, when it starts, what authentication method they will use and where to get help. Good communication reduces support tickets and makes it less likely users will approve unexpected MFA prompts out of confusion.
A compliant-device requirement is one of the strongest ways to protect sensitive information, but it only works if endpoint management is mature. Intune compliance policies should confirm basics such as supported operating systems, encryption, antivirus, screen lock and acceptable device risk levels before you rely on them for access decisions.
Apply this control first to high-value applications or sensitive user groups. Finance systems, SharePoint sites containing confidential documents and administration portals are common starting points. For personal mobiles, an app protection policy may be more appropriate than requiring full device enrolment. This allows protected access to approved work apps without giving the business broad management of an employee’s personal device.
The trade-off is clear: stronger device controls reduce risk but can slow down contractors, casual staff and BYOD users. Define an approved path for each group rather than making exceptions ad hoc.
Named locations can help identify trusted office networks or block sign-ins from countries where your organisation has no legitimate business activity. However, location alone is not a reliable security boundary. Users travel, mobile networks route unpredictably, and attackers can use compromised devices from trusted locations.
Use location as an additional signal, not your only control. If your licences support it, risk-based Conditional Access can require password changes for high user risk or MFA for medium and high sign-in risk. Review the impact before enforcement, particularly for users who travel or use privacy tools that may trigger unusual sign-in detections.
Conditional Access is not finished when every policy is switched on. Review Microsoft Entra sign-in logs regularly to understand blocked attempts, MFA failures, non-compliant devices and repeated access issues. Look for patterns: a particular device type, office network or application may indicate a configuration problem that needs a proper fix.
Keep exclusions narrow and time-bound. A broad exclusion for a user group might resolve an immediate complaint, but it can quietly create a permanent security gap. Record why every exception exists, who approved it and when it must be reviewed.
It is also worth reviewing policies after major changes, including Microsoft 365 migrations, Intune deployments, acquisitions, staff restructuring or the introduction of a new cloud application. Access rules that suited a small office can become inappropriate when employees work across sites, use managed mobiles or access information from the field.
For many organisations, the best outcome is a layered policy set: MFA for everyone, stronger controls for administrators, compliant-device requirements for sensitive data, and closely managed exceptions. It is measurable, practical and easier to support than a single overly aggressive rule.
Conditional Access should make secure behaviour the normal path, not create a daily obstacle course. When policies are planned, tested and reviewed with the same discipline as any other business-critical system, they protect Microsoft 365 access without getting in the way of work.