In Microsoft environments, Conditional Access is the central building block for implementing the Zero Trust principle. Instead of a single rule for all sign-ins, policies decide depending on the situation: a sign-in from a managed company laptop is treated differently from access from an unknown device abroad. The feature requires a suitable license for Microsoft Entra ID. Without this license, Microsoft's security defaults provide simpler baseline protection.
How does Conditional Access work?
Every policy follows an if-then pattern:
- Who and what: Which users, groups, or roles and which applications the policy applies to. Exclusions can be defined specifically.
- Conditions: For example, location or IP range, device platform, type of application, or, depending on the license, a sign-in risk calculated by Microsoft.
- Access controls: Access is blocked or granted only under conditions, for example with multi-factor authentication or from a device that is considered compliant in Microsoft Intune.
- Session controls: Rules for the ongoing session, for example how often users must sign in again.
Conditional Access takes effect after the first authentication stage: only once the user name and first factor have been verified do the policies decide on further requirements or a block. If several policies apply, all of them must be satisfied. A blocking policy takes precedence. New policies can be tested in report-only mode, which logs the effects without enforcing them.
Typical examples
- Multi-factor authentication for all users and all applications.
- Stricter, phishing-resistant sign-in methods for administrative roles.
- Access to email and files only from managed, compliant devices.
- Blocking legacy authentication methods that do not support multi-factor authentication.
- Blocking sign-ins from countries in which the company does not operate.
What companies should keep in mind
- Provide emergency access: Exclude at least one specially protected emergency account from restrictive policies so that IT does not lock itself out in the event of a misconfiguration.
- Test first, then enforce: Check new policies in report-only mode and evaluate them using the sign-in logs.
- Avoid gaps: Define policies for all applications wherever possible, document exclusions, and review them regularly.
- Do not overrate location: IP addresses and countries are a signal, but on their own they are not reliable protection.
- Monitor continuously: Sign-in logs show which policies apply and where sign-ins fail.