A compromised Microsoft 365 password should never be enough to open the door to enterprise data. That is the entire point of this guide to Microsoft conditional access: to decide, for each login attempt, whether access is legitimate, sufficiently protected and compatible with the level of risk accepted by your organization.
Conditional access transforms Microsoft Entra ID into a control point for your cloud security. Instead of trusting an identity because it knows its password, you cross-reference the context: user, requested application, device used, location, risk level and authentication method. This approach directly limits the impact of phishing, session hijacking and unmanaged devices.
What conditional access actually controls
A conditional access policy does not replace endpoint protection, user awareness or active monitoring. It complements these defenses by preventing risky access before it becomes an incident. It is a particularly decisive control for Microsoft 365 environments, where email, SharePoint, OneDrive and Teams concentrate critical operational information.
A conditional access rule is based on simple logic: if a user or application meets certain criteria, Microsoft applies a decision. This decision can require multi-factor authentication, enforce a compliant device, request a password change, restrict a session or block access.
The choice of condition should always correspond to a concrete risk scenario. Requiring MFA for all users is a useful baseline. Blocking connections from unmanaged devices may be relevant for an administrative position, but far less so for a field team using personal devices. Effective security is not about applying the maximum restrictions everywhere: it is about reducing risk without unnecessarily disrupting operations.
Prerequisites before creating the first policy
Before any deployment, establish an inventory of identities, applications and work modes. Identify privileged accounts, service accounts, external collaborators, managed devices and applications that still use legacy authentication. A poorly prepared policy can block a business application or prevent an IT team from intervening when it needs to most.
Licensing also matters. Conditional access policies generally require Microsoft Entra ID P1. Controls based on sign-in risk or user risk rely on advanced capabilities, often associated with Entra ID P2. The features available in your tenant should therefore be validated before defining a security architecture.
Also create at least two emergency accounts, sometimes called "break glass" accounts. They must be strongly protected, monitored and precisely excluded from certain critical policies to preserve an administration path in case of MFA failure, federation issues or configuration errors. Excluding them does not mean forgetting them: any use of these accounts must trigger an alert and be subject to immediate review.
Finally, document your initial state. How many users use MFA? Which devices are enrolled and compliant? Which applications still accept legacy protocols? Without this visibility, you will not be able to measure progress or explain any potential impact to the business.
Guide to Microsoft Conditional Access: deployment order
Deployment should be gradual. Starting with a global and aggressive policy is tempting, but exposes the enterprise to costly blockages. It is better to move in waves, with a representative pilot group, monitoring of sign-in logs and clear communication with affected users.
1. Block legacy authentication
Legacy authentication protocols often bypass modern protections, particularly MFA. POP, IMAP or authenticated SMTP may remain necessary in some cases, but they frequently constitute an avoidable attack surface. Start by identifying actual usage in the logs, then block these protocols with a dedicated policy.
Plan limited, justified and reviewed exceptions. A permanent exception for a printer, application or legacy equipment quickly becomes a blind spot. If immediate modernization is not possible, isolate the requirement, reduce permissions and set a retirement date.
2. Enforce phishing-resistant MFA
MFA greatly reduces password-related risk, but not all methods are created equal. Notifications to validate on smartphone remain vulnerable to MFA fatigue: the user may accept a repeated fraudulent request. For administrative accounts and sensitive access, prioritize phishing-resistant methods such as FIDO2 security keys, passkeys or Windows Hello for Business depending on your environment.
A policy can initially target administrators, then users accessing cloud applications. Define authentication strengths adapted to your needs rather than a uniform rule. An executive traveling, a factory operator and a Microsoft 365 administrator do not have the same exposure profile or access constraints.
3. Require managed devices for sensitive data
A compliant device is one whose security posture meets enterprise requirements: encryption enabled, patches applied, antivirus or EDR operational, no known compromise and management rules followed. By combining Microsoft Intune and conditional access, you can reserve your most sensitive data for devices that meet these criteria.
This policy is particularly relevant for SharePoint, OneDrive and Exchange Online. When access from a personal device remains necessary, session restrictions can offer a compromise: browser-only access, limited downloads or application protection for mobile uses. The right balance depends on data value, user role and the enterprise's actual ability to manage its device fleet.
4. Secure administrative roles without exception
Accounts with elevated privileges must be subject to distinct rules. Require phishing-resistant MFA, block access from non-compliant devices and limit sessions where possible. If your organization uses just-in-time privilege management, combine it with conditional access to reduce the duration during which an account has elevated rights.
Do not mix administrators and standard users in the same protection logic. An incident on an administrative account can modify policies, create identities or access data at scale. The level of requirements should reflect this risk.
Test before applying: a continuity rule
Microsoft offers a report-only mode. Use it systematically to observe what a policy would have blocked or required without affecting users. Analyze results over several days, including outside business hours, to detect automated services, shared devices and nomadic access that may have been overlooked.
Sign-in logs are your source of truth. They show the policy evaluated, the control applied, device state and the reason for a failure. An increase in denials does not necessarily indicate better security: it can signal misconfigured policies or degraded user experience.
After moving to production, maintain a period of enhanced monitoring. Prepare a support channel for users, a rollback procedure and a clearly identified person to validate exceptions. Every exception must have an owner, business justification, limited scope and a review date.
The mistakes that weaken the strategy
The first mistake is deploying policies without emergency accounts or recovery procedures. The second is settling for enabling MFA without addressing legacy authentication, administrative privileges and device compliance. The third is creating too many overlapping policies: their combination becomes difficult to understand, maintain and audit.
Also avoid exclusions based solely on IP address or so-called "trusted" location. An internal network address is not proof that a device or user is legitimate. Named locations can help reduce friction in specific cases, but they should not become a bypass for essential controls.
Conditional access must evolve with your enterprise's changes: new SaaS application, remote work, merger, vendor change or security incident. A quarterly review of policies, exclusions and logs helps maintain a defense adapted to operational reality.
A well-constructed policy gives teams the freedom to work without giving attackers the same freedom. For an enterprise, the value of conditional access is measured less by the number of rules created than by its ability to maintain operations when every connection counts.