Key things to consider to get most out of Conditional Access Policies
Conditional access policies enables organizations to create access policies to control authentication requirements . But what should you think about when you are planning to take them to action?
Via numerous customer cases I’ve learned a few key do’s and don’ts, and in this blog, we dig into things that are necessary to make your access policies fly: Conditional Access Policy building principles, naming convention and what policies should everyone implement. Additionally, let’s dig into advanced policies.
What is conditional access policies?
Microsoft defines Conditional access policies (CA policies) like this:
“Modern security extends beyond an organization’s network perimeter to include user and device identity. Organizations now use identity-driven signals as part of their access control decisions. Microsoft Entra Conditional Access brings signals together, to make decisions, and enforce organizational policies. Conditional Access is Microsoft’s Zero Trust policy engine taking signals from various sources into account when enforcing policy decisions.
Conditional Access policies at their simplest are if-then statements; if a user wants to access a resource, then they must complete an action. For example: If a user wants to access an application or service like Microsoft 365, then they must perform multifactor authentication to gain access.”
My 6 points on Conditional Access Policy building principles
- Think Conditional Access Policies are like firewall rules. Every sing-in or actions needs to be evaluated by policy. Include everything, exclude as little as possible.
- Break-glass and service accounts: These accounts will be excluded from almost all policies. This exception is often necessary. Accounts have block policies, to block access from untrusted locations.
- Create Entra ID security groups specifically for Conditional Access Policies: Use a prefix like “CA-” that is reserved for Conditional Access Policies.
- Create Entra ID security group to be used as an excluding assignment. Exclude group per Conditional Access Policy for easier management and visibility of exclusions.
- Create Entra ID security groups based on M365 license types: These groups are reserved for advanced Conditional Access policies.
- Avoid using Report-only mode on mobile devices: This mode creates additional popups on Android and iOS devices.
Naming convention
One of the most critical aspects is the naming convention. Properly planning your naming convention before rolling out refreshed policies is essential. Often, old policies are a tangled mess, and a “refresh” is simpler than trying to decipher the existing ones.
Here are some insights and recommendations for refreshing and naming of CA policies:
- Start with a Clean Slate: Old policies, especially those older than five years, can be outdated and may not utilize new features or meet current organizational security needs. Refreshing these policies can bring them up to date with the latest security standards.
- Leverage Zero Trust Principles: Many organizations aim to implement Zero Trust principles. Ensure your refreshed CA policies align with these principles to enhance security.
- Annual Review: It’s crucial to review your CA policies yearly. This helps ensure they remain relevant and effective in addressing evolving security threats and organizational changes.
By following these best practices, you can maintain a robust and up-to-date CA policy framework that supports your organization’s security goals.
There are different ways you can built Conditional Access policies and Microsoft also has recommendations, but these recommendations is often customized for organizations own needs. Contact us and we can advice you what is best for your organization. The main thing is that you have clear view what would be the desired end result.
Conditional access policies do require Entra ID security groups. I recommend to use prefix for all security groups related to Conditional access for easier management and visibility. Common security groups are related to excluding users from policy or really specific policy for group of users.
Policies that everyone needs
- General block policies
General block policies would include blocking of legacy auth, unknown or unsupported platforms, service- and break-glass accounts from untrusted locations and so on. - Admin / Admin portal access policies
For admin access, multi-factor authentication (MFA) is required to use Entra admin roles. For Admin portals like Azure Admin portal, they do not follow Entra admin roles at all and therefore has to be controlled using policy requiring MFA. For added security, some roles or portals can enforce stronger MFA, phishing resistant MFA like Windows Hello, Passkeys or Certificate based authentication. - Break-glass access policies
“Break-glass when facing issues”. Break-glass accounts are used when other admin accounts are not working. Limiting Break-glass access from trusted networks only and requiring MFA is one of the most important policies. - Security info registration access policies
When users start to use MFA, they need to register MFA methods. This policy will limit what device or location is required for end user to register MFA. Most often a trusted network or compliant device is required. - Device registration policies
For registering devices to Entra, in any platform, MFA would be required. - User access policies
These policies define what are the requirements for normal end-users to get access to all cloud resources. Minimum is requiring MFA and can be adjusted to require more on non-compliant devices or selected cloud resources. What is required more, would include stronger MFA or/and Sign-in frequency limits. - External/Guest access policies
For guest accounts, minimum of MFA with sign-in frequency would be required to get access. These policy depends on Entra external identity settings, like trusting MFA or device compliance for other Entra tenants. - Partner access policies
Partner account are normal member accounts on Entra, but are used by partners or other affiliated users. These user have M365 licensed and are using own device or company provided devices. Minimum requirement is MFA with Sing-in frequency.
Advanced policies
Advanced Conditional Access policies are Risk-based, Device-based, app-based and more admin related policies. Advanced policies is all about adding additional layer of security, mostly by using device compliance requirement.
End users need additional licenses for some of these policies, such as Entra ID P2, which is included in M365 E5 or the E5 security add-on. With these, organizations ambition also needs to require compliant devices on all cloud resources as a part of Zero trust journey. There are of course some caveats for device based access.
Risk-based Conditional Access policies
Risk-based policies provide more control, automate risk remediation, and allow you to assign different risk levels to various user groups. Configuring network locations is also crucial, as these locations will impact risk level detection and reduce false positives.
Risk-based Conditional Access policies require additional licenses for end users. An Entra ID P2 license is necessary to utilize the full features of Entra ID Protection and to access more options within Conditional Access policies. The Microsoft Entra Admin Center uses a dedicated Identity Protection policy page for monitoring purposes. It refers to Entra ID Protection policies as ‘User Risk Policy’ and ‘Sign-in Risk Policy’.
For more information about different risks, please visit What are risks in Microsoft Entra ID Protection – Microsoft Entra ID Protection | Microsoft Learn
Device-based conditional access policies
Device-based Conditional Access policies have additional requirements, as device compliance can only be evaluated on managed devices using Intune. Microsoft Intune compliance policies are sets of rules and conditions that you use to evaluate the configuration of your managed devices. These policies can help you secure organizational data and resources from devices that don’t meet those configuration requirements. Managed devices must satisfy the conditions you set in your policies to be considered compliant by Intune.
Intune can also utilize partner connectors to third-party MDM providers, which will have their own compliance policies and are reporting device compliance to Intune and from there to Entra.
Design device compliance policies based on your organizations guidelines. Once these policies are deployed, they will evaluate the configuration of your managed devices. The evaluation results are then sent to Entra for use in Conditional Access.
Device can be either:
- Compliant: Intune has determined that the device meets all compliance policies after evaluation.
- Non-compliant: Intune has identified that this device does not meet the compliance policies.
- Unknown: The device is not managed, so its compliance status cannot be determined and is considered non-compliant.
My recommendations for device-based Conditional Access policies fall into two categories: browser-based access and modern client-based access, with Conditional Access policies tailored to each platform. Requiring device compliance for browser access has additional requirements, and more details to consider.
Device code flow policies
Some devices, like IoT devices requires alternative methods for authentication. Device code flow is an OAuth 2.0 authorization method designed to facilitate secure sign-ins on these devices by leveraging another device, like a smartphone or computer, for the authentication process.
This type of authentication method can have security risks, particularly on unmanaged devices that lack security controls. Device code flow conditional access is a critical security feature that enables organizations to manage and mitigate these risks effectively.
App-based conditional access policies
App-base conditional access depends on Intune MAM capabilities, App configuration policies and App Protection policies. Intune MAM has two different deployment models, MAM and MAM-only.
- Intune MAM is typically used for Intune-managed devices to enhance application-based security and access. These devices can be either personally owned (BYOD) or corporate-owned.
- MAM-only is intended for unmanaged or third-party MDM-managed devices. These devices are not managed by Intune MDM and are also considered for BYOD use cases.
App protection policy supports Android and iOS/iPadOS. Windows is currently supported only on Edge browser. Microsoft has a very good documentation about “Data protection framework using App Protection Policies” that is designed to be a starting point for deploying App protection policies.
App protection enforcement is always implemented through Conditional Access, which necessitates different policies and additional configuration.
Admin access conditional Access policies
Conditional access policies for admins should be in place for every organisation. But to add additional requirements and even more secure admin access, more policies are available.
What suits best for your organization, depends heavily on organizations policy. Exclude or include roles that fit you the best.
Conclusions
As you probably have noticed, what suits for your organization the best varies a lot. Contact us for advice and implementation of policies to secure your environment and your organizational needs!
This blog was originally published at Valtteri’s Wallo Blog as a blog-series, visit the blog here: Wallo Blog – Your Trusted Source for Intune, Windows 365, and AVD Expertise
Need help?
When you want to optimally offer the wide range of IT environment opportunities to your organization’s business and employees in a controlled, secure and cost-effective manner, and develop know-how in your organization, we are your partner.