Conditional Access: The Key to a Secure Microsoft 365 Environment
What is Conditional Access?
Conditional Access, or "conditional access control," is THE central security feature of Microsoft 365 and the most effective way to secure access to your corporate resources.
Here is the official Microsoft link to the topic: https://learn.microsoft.com/de-de/entra/identity/conditional-access/overview
Conditional Access serves as the central access control mechanism for your Microsoft 365 environment. Imagine Conditional Access as an intelligent access system: a user is only allowed to access a resource if predefined conditions are met. These conditions can be based on signals containing information such as user location, device status, or risk assessments of the user or the device attempting to sign in. This enables granular control over access, tailored precisely to your organization's needs.
These signals include:
Identities
Applications
Devices
Locations
Risk assessments
In the end, Conditional Access has a straightforward task: allow or block access based on defined prerequisites. The goal is to protect all identities with Conditional Access.
Why is Conditional Access so important?
Depending on your licensing, there are two basic ways to protect your identities when using Microsoft 365.
Security Defaults
This feature activates basic security functions for the entire tenant. It’s particularly useful if your organization does not meet the licensing requirements for Conditional Access (at least Entra ID Premium P1). However, the downside is that Multi-Factor Authentication (MFA) can only be enabled or disabled for all accounts. For service accounts, for example, this is not always feasible. This creates a trade-off: less flexibility and security in exchange for slightly lower licensing costs—yet at the expense of higher business risk due to the increased likelihood of a cyberattack and less flexibility or convenience.Conditional Access
In comparison to Security Defaults, Conditional Access offers extensive capabilities to control access to your Microsoft 365 tenant. This allows identities and resources to be effectively protected. As mentioned earlier, access is either granted or denied based on specific conditions. This feature enables maximum flexibility and security at manageable licensing costs, as it is already included in packages like Business Premium.
Conditional Access: A Powerful Tool, Often Misused
From my years of experience implementing Conditional Access (CA) projects, I know this: Conditional Access simply determines whether access is granted or denied—while adhering to defined security guidelines.
The motto is: "Easy to learn, hard to master."
A well-implemented Conditional Access framework protects all identities and significantly reduces the attack surface. However, I frequently encounter companies that mistakenly believe they already have a solid Conditional Access policy in place—when this is often not the case.
A Typical Example
One common issue with Conditional Access is the incomplete configuration of security policies. Many organizations use a single policy requiring all users to use MFA, such as through the Microsoft Authenticator. Often, the organization’s public IP addresses are excluded from this rule because they are considered trusted.
This means:
Employees working exclusively in the office are never prompted to set up or use MFA.
Attackers who obtain login credentials can register the second factor without being noticed.
Attackers infiltrating the network locally can easily compromise identities, as only a username and password are required.
The Result: It creates a large attack surface. Attackers who manage to infiltrate the corporate network can easily compromise identities, as only a username and password are required for login. Moreover, employees who eventually work remotely often need IT support to set up their second factor.
The Problem
Such Conditional Access implementations result in only a small portion of access requests being protected by Conditional Access—leaving the majority vulnerable.
My Recommendation
In cloud environments, identity is the most important perimeter. Every IT administrator or IT security professional should regularly review their Conditional Access framework. This is the only way to ensure that:
100% of sign-ins are protected by Conditional Access—no logins bypass it.
Misconfigurations are identified and resolved promptly.
The framework is continuously improved and adapted.
A regular, professional review minimizes risks and maximizes security—sustainably.
Which Licenses Are Required for Conditional Access?
To use Conditional Access, you need at least the following licenses:
Microsoft Entra ID P1
Enables the use of basic Conditional Access policies.
Already included in Microsoft 365 Business Premium (as well as Microsoft 365 E3, Microsoft 365 E5, and others), making it a cost-effective solution for small and medium-sized businesses.
Microsoft Entra ID P2 (optional)
Ideal for companies looking to implement risk-based policies (“Risk-based Conditional Access”).
These advanced policies allow for dynamic and flexible access protection based on the individual risk status of a user and their sign-in behavior.
What Happens Without Entra ID P1/P2 Licenses?
Without these licenses, you’re left with only Security Defaults, which provide static, basic protection. However, for many businesses, these are insufficient:
Limitation: Individual accounts cannot be excluded from security policies, nor can relaxed policies be applied to specific accounts. Security Defaults can only be turned on or off.
Risk: Additional attack surfaces remain, such as the inability to include devices in the sign-in process, preventing the enforcement of access only from corporate devices.
Recommendation
We recommend using Microsoft Entra ID P2 to achieve the highest security standard. At a minimum, Microsoft 365 Business Premium should be utilized, as it includes Entra ID P1 and Microsoft Intune P1, providing a strong foundation for a robust Conditional Access framework.
Implementing Conditional Access
Step 1: Analysis – Understand the Company’s Workflow
Before implementing Conditional Access, it is crucial to understand how the company operates. The following questions should be addressed:
Are only corporate devices being used?
The use of personal devices requires different policies compared to corporate-only environments.Are files frequently shared with external partners?
Frequent collaboration with external parties demands specific security and access measures.Are there external employees or administrators in the tenant?
External users and admins require tailored policies to minimize risks while ensuring smooth collaboration.From which locations do employees work?
Considering locations (e.g., office, home office, abroad) is essential for appropriate access policies.Which systems are particularly sensitive?
The type and sensitivity of data determine the required level of access security.
Important Note
A successful Conditional Access framework must ensure productivity without hindering day-to-day operations. Striking the right balance between security and user-friendliness/productivity is key.
Step 2: Licensing – Selecting the Right Licenses
Choosing the right licenses is a critical part of implementing a robust Conditional Access framework. Consider the following points:
Microsoft Entra ID P1 or Business Premium
Necessary for all users, including service accounts (except for shared mailboxes).
Provides the foundation for using Conditional Access.
Microsoft Entra ID P2
Recommended if risk-based policies are to be implemented.
Enables dynamic security measures based on user and sign-in risk.
Tip:
Compare the pros and cons of Entra ID Security Defaults, P1, and P2. Ultimately, the organization must decide what level of risk is acceptable.
Step 3: Securing Emergency Access
Emergency Access Accounts are essential to maintain access to your Microsoft 365 tenant in critical situations. These accounts are exempt from all “standard” Conditional Access policies but must follow their own policy requiring phishing-resistant MFA (e.g., FIDO2 key).
Why are these accounts so important?
Without them, you could lose access to your tenant in the event of a misconfiguration or security incident.
For more details and a comprehensive guide, read the blog post on Emergency Access Accounts: Microsoft 365 Emergency Access
Step 4: Hybrid Environments – Cleanly Separate Cloud and On-Premises
In hybrid environments, it’s crucial to properly configure synchronization between on-premises Active Directory and Entra ID to minimize security risks.
Recommendations:
Synchronize only standard users and service accounts required in both environments.
Strictly separate admin accounts and other privileged identities between on-premises and cloud environments. This reduces the risk of lateral movement, where an attacker compromises Entra ID if Active Directory is already breached—or vice versa.
Why is this important?
For example: If attackers gain access to a synchronized account with domain admin rights in Active Directory that also holds global admin rights in Entra ID, both environments (on-premises and Microsoft Cloud) are compromised simultaneously—a worst-case scenario. Such poorly considered synchronizations create massive attack surfaces and significantly increase the risk of major incidents.
Tip:
Configure Entra ID Connect to synchronize only selected organizational units (OUs) from Active Directory. This requires a well-organized AD and OU structure. Clear separation and precise control of synchronization protect both your local and cloud infrastructure.
Step 5: Leverage as Many Signals as Possible
Incorporating multiple signals into your security strategy makes it more effective. Conditional Access can dynamically respond to suspicious sign-in attempts or non-compliant devices, providing more data to inform automated or manual actions.
Examples of Signal Integration:
Microsoft Intune Compliance Policies and Microsoft Defender for Endpoint
Define compliance policies in Intune to determine whether a corporate device is deemed "secure."
A key parameter is the device’s risk level, assessed by Defender for Endpoint.
Defender XDR and Entra Identity Protection
These services provide risk signals to Conditional Access.
For example, if a user is involved in a security incident, their risk score increases. Based on this, high-risk users can either be blocked or allowed under stricter conditions.
Tip:
The more features you actively use, the more signals you can incorporate. Especially through Microsoft Intune and Defender for Endpoint, Conditional Access policies can be enriched with valuable signals, resulting in safer access decisions.
Step 6: Authentication Methods – Security in Transition
The requirements for secure authentication methods have drastically evolved over the years. While strong passwords were once sufficient, they are no longer adequate today.
From Strong Passwords to Multi-Factor Authentication (MFA):
Passwords alone no longer provide sufficient protection as they can be easily stolen or guessed.
MFA was a significant step forward, requiring a second factor like an SMS code or Authenticator app for added security.
New Threats: Token Theft
Even MFA is not infallible. Attackers now use techniques like token phishing with realistic-looking phishing websites to trick users and steal tokens. These tokens, created after a successful login, grant attackers access to systems without needing the password or second factor again.
The Solution: Phishing-Resistant Authentication Methods
Modern authentication methods like FIDO2 keys or biometric logins are the gold standard. They not only offer the highest security but also simplify the login process for users with intuitive and user-friendly methods.
Recommendations:
Use FIDO2 keys or Passkeys on Android and iOS for maximum security.
If Conditional Access requires sign-in from a corporate device (compliant or hybrid-joined), this login is also considered phishing-resistant.
If this is not possible, at least use Microsoft Authenticator with passwordless login enabled.
Step 7: Are Locations Truly Trustworthy?
A common Conditional Access scenario is to require MFA only outside of defined “trusted” locations, such as corporate offices. While this may seem convenient, it carries significant risks:
Risks of Trusted Locations
No second factor for local users: Employees working exclusively at these locations are not required to set up a second factor.
On-site attackers: If attackers have already compromised devices on-site, they can use these to log in, bypassing the second-factor requirement.
Challenges for mobile users: Employees working outside the office may need IT support to set up MFA.
Recommendation
For internal users and administrators:
Enforce MFA at all times, regardless of location.
Combine this with the use of compliant devices to achieve a higher security level.
For guests and external users:
Use phishing-resistant MFA methods, even if these users do not have compliant devices.
Step 8: Personas
An effective Conditional Access framework relies on categorizing all users into persona groups. These are groups of users with similar access needs, Microsoft 365 usage patterns, and requirements. Each group receives tailored security policies to ensure both protection and productivity.
Examples of Persona Groups and Security Requirements
Administrators:
Access only with FIDO2 keys and compliant devices.
Strict security policies due to their high-value target status.
Guests:
Often lack corporate devices or FIDO keys.
Secured through alternative measures like phishing-resistant MFA.
Key Principle
All identities must belong to a persona group.
Users without a group assignment are blocked until an administrator assigns them appropriately.
This ensures clear and secure access management to Microsoft 365.
What Personas Exist?
The following structure, developed for enterprise environments, covers all common identities:
Global Protection: CA001–CA099
Admins Protection: CA100–CA199
Internals User Protection: CA200–CA299
Externals User Protection: CA300–CA399
Guests User Protection: CA400–CA499
Guest Admins Protection: CA500–CA599
Microsoft 365 Service Accounts: CA600–CA699
Azure Service Accounts: CA700–CA799
Corporate Service Accounts: CA800–CA899
Workload Identities: CA900–CA999
Conclusion
Categorizing all users into persona groups creates structure and enhances security. Tailored policies ensure that all identities are protected while maintaining productivity. Such a framework also improves policy readability and simplifies troubleshooting.
Step 9: Introducing Conditional Access Seamlessly
The goal of implementing a Conditional Access framework is a smooth rollout. Users should experience minimal disruption while all identities and access points are secured in the background.
How to Ensure a Smooth Rollout?
To address all potential impacts, policies should be tested in Report-Only mode. Regular evaluations help understand their effects and make adjustments early.
Simulation: Analyze the impact of policies over 2–4 weeks.
Optimization: Gradually adjust policies to align with company workflows without disrupting daily operations.
How Are Policies Evaluated?
A Log Analytics Workspace in a dedicated Azure subscription is essential for data collection and evaluation. This workspace stores and analyzes Sign-In Logs.
Data Source: Sign-In Logs record how and when users authenticate.
Evaluation: Detailed analysis using KQL queries (Kusto Query Language).
Visualization: A custom workbook provides clear graphical representations of Report-Only policies' impact.
Interactive vs. Non-Interactive Sign-Ins
Interactive Sign-Ins: User actively logs in, such as to a portal or service.
Non-Interactive Sign-Ins: Automated background authentications, such as token renewals for apps.
The default Log Analytics workbook only displays Interactive Sign-Ins, missing critical Non-Interactive Sign-Ins, which are often used by service accounts or automated processes. This oversight can lead to issues during Conditional Access implementation.
Acknowledgment to Christopher Brumm
Special thanks to Christopher Brumm, who published a workbook that includes both Interactive and Non-Interactive Sign-Ins. This tool significantly simplifies Conditional Access implementation by enabling comprehensive analysis of Report-Only policies.
Link: crmhh/CAWorkbooks
Step 10: The Conditional Access Rule Set
Below is an example of a Conditional Access framework tailored to a fictitious customer’s workflow, licensing, and Microsoft Cloud capabilities. Each persona group is assigned specific security policies that balance protection and productivity.
Global Policies
These policies protect all personas and define fundamental security standards.
CA001-Global-BaseProtection-AllApps-AnyPlatform-BlockNonPersonas
Function: Blocks all users not assigned to a persona group to prevent unauthorized access.
Example: A newly created user without a persona group assignment is blocked by default until an administrator assigns them to a group.
CA002-Global-BaseProtection-AllApps-AnyPlatform-ProtectedAction-CA-PWlessMFA
Function: Allows changes to the Conditional Access framework only if the administrator authenticates using a phishing-resistant MFA method (e.g., FIDO2).
Example: Changes to CA policies can only be made by an administrator adhering to the highest security standards.
CA010-EmergencyAccounts-IdentityProtection-AllApps-AnyPlatform-PhishingResistentMFA
Function: Ensures that Emergency Access Accounts are secured exclusively with phishing-resistant MFA methods.
Example: Protects emergency accounts from phishing attacks targeting MFA vulnerabilities.
Admin Policies
Administrators require the highest security standards due to their access to critical systems and data.
CA100-Admins-BaseProtection-AllApps-AnyPlatform-CompliantandMFA
Function: Grants administrators access only with compliant devices and completed MFA.
Example: An admin can only log in if the device meets compliance policies and MFA is successful.
CA101-Admins-BaseProtection-AllApps-AnyPlatform-PhishingResistentMFA
Function: Mandates the use of phishing-resistant MFA methods like FIDO2.
Example: An admin can log in only if a FIDO2 key is used for authentication.
CA102-Admins-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration
Function: Defines security requirements for making changes to security methods.
Example: A new admin requires a compliant device and MFA (or a Temporary Access Pass) to register their passkey.
CA103-Admins-IdentityProtection-AllApps-AnyPlatform-MFAforMediumRiskUser
Function: Requires MFA for users with medium or higher risk based on Identity Protection signals.
Example: An admin flagged as high risk due to involvement in incidents must complete MFA again.
CA104-Admins-IdentityProtection-AllApps-AnyPlatform-MFAforMediumRiskySignIns
Function: MFA is required for sign-ins with medium or higher sign-in risks.
Example: An admin logging in from a new IP address is prompted for MFA.
CA105-Admins-IdentityProtection-AllApps-AnyPlatform-BlockLegacyAuth
Function: Blocks insecure authentication methods like Basic Authentication.
Example: An admin is prevented from using legacy methods like SMTP or POP3.
CA106-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-NoPersBrowserSession-ExcCompl
Function: Prevents persistent browser sessions to minimize stolen session token risks.
Example: Admins must reauthenticate after each session.
CA107-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUnknownPlatforms
Function: Blocks access from unknown or unsupported platforms.
Example: An admin cannot log in from a device with an unsupported operating system.
CA108-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-DenyDeviceCodeFlow
Function: Blocks logins via insecure device code flows.
Example: An admin cannot authenticate using device code flows like IoT logins.
Internal Employee Policies
Security policies for internal employees combine MFA and compliance requirements for desktop and mobile devices.
CA200-Internals-BaseProtection-AllApps-DesktopOS-CompliantandMFA
Function: Allows desktop access only with compliant devices and MFA enabled.
Example: Employees can access their laptops only if the device is compliant and MFA is completed.
CA201-Internals-BaseProtection-AllApps-SmartphoneOS-MFA
Function: Activates MFA for smartphone access.
Example: Employees logging in from their smartphones must use MFA.
Note
Additional policies are not detailed here but adhere to the same principles: providing specific protection for various access types and scenarios.
Step 11: Low-Hanging Fruits
For a quick start and immediate security improvement, implement the following measures:
Enforce MFA for all users: Protect all accounts with a second factor.
Restrict service account usage: Use Conditional Access to limit service accounts, e.g., restrict login to specific IPs.
Block legacy protocols: Disable insecure protocols like SMTP-Auth, often exploited by attackers. Check attack attempts in the Entra ID portal.
Limit token lifetime: Reduce token validity so users must reauthenticate periodically.
Risk-based policies: Respond dynamically to security threats, such as suspicious location changes.
Restrict OneDrive and SharePoint access: Set clear rules for non-compliant devices, such as preventing downloads or copying.
These actions provide a solid foundation to quickly enhance security with Conditional Access and close common attack vectors.
Conclusion: Conditional Access – Powerful, But Only Effective with a Clear Plan
Conditional Access is a highly powerful tool to protect organizations from modern threats. However, in practice, incomplete rule sets are often found. Security teams must understand that an effective Conditional Access framework requires careful planning, implementation, and regular review to ensure maximum security.
As outlined, Conditional Access can be introduced with minimal user disruption—provided it is done with thorough planning and the right methods.
