This blog is about recommended Conditional Access Policies and how to build them. First 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.
- 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 of exclusions.
- Create Entra ID security groups based on M365 license types: These groups are reserved for advanced Conditional Access policies. Building these advanced policies will be covered in part 3.
- Avoid using Report-only mode on mobile devices: This mode creates additional popups on Android and iOS devices.
Blog series overview
How about them Conditional Access Policies! Part 1 – Naming convention – Wallo Blog
How about them Conditional Access Policies! Part 2 – Policies that everyone needs – Wallo Blog
How about them Conditional Access Policies! Part 3 – Advanced policies – Wallo Blog
List of Conditional Access Policies that everyone needs:
- General block policies
- Admin / Admin portal access policies
- Break-glass access policies
- Security info registration access policies
- Device registration policies
- User access policies
- External/Guest access policies
- Partner access policies
Let’s break down policies to groups:
- CAB001-CAB100: General block policies
- CAG001-CAG010: Admin, Admin portal, Break-glass account policies
- CAG011-CAG020: General access policies
- CAG021-CAG030: User access policies
- CAG031-CAG040: External/Guest access policies
- CAG041-CAG050: Partner access policies
I like to give a lot of room for additional Conditional access policies, as most often a separate policies are needed for special purpose access.
Next up, Conditional Access policies that everyone needs
1. Block access policies – CAB001-CAB100
CAB001 All block legacy authentication for All Users v1.0
Microsoft already blocks most Legacy Authentication methods, with one exception: Authenticated SMTP on Exchange Online. I recommend creating this policy to block legacy authentication protocols, sometimes excluding specific locations.
CAB002 All block unknown platforms for All Users v1.0
This is a simple and effective policy to block platforms not recognized as supported. Be aware of potential drawbacks, such as developers or services using unrecognized platforms. Plan accordingly and exclude only the platforms you support. If there are no sign-ins from macOS devices, do not exclude them.
CAB003 All block networks other than selected for Break-glass accounts v1.0
“Break-glass when nothing else works”. Secure break-glass accounts, which have Global Admin roles, with a location-based block policy. This policy blocks all locations except selected ones. You can achieve this by excluding trusted locations or creating specific locations for break-glass accounts. Break-glass accounts will also be included in Admin roles assigned Conditional Access policies.
CAB004 All block networks other than selected for service accounts v1.0
For traditional service accounts, a block policy will block all other networks than selected. This adds additional layer of security, allowing only defined locations for sign-in actions. Plan locations really carefully. Consider moving to service principals, as traditional service accounts need to be excluded from all policies requiring MFA.
NOTE! Remember to exclude traditional service account from ALL other conditional Access policy that requires MFA!
2. Admin access policies – CAG001-CAG010
CAG001 All require Phishing-resistant MFA for All Admin roles v1.0
Protect every admin role specified in Entra ID with a Conditional Access Policy that includes phishing-resistant MFA.. This policy involves more than just creation; it requires ensuring that every administrator has registered a phishing-resistant authentication method. Enable Temporary Access Pass (TAP) for all admins as a backup solution. Also note that Admin roles are not specified to a users normal user account, but read-only Admin roles might be!
CAG002 Admin Portals require Phishing-resistant MFA for All Users v1.0
Different admin portals in Azure or M365 must have a policy requiring MFA. For example, a normal user account can access the Azure Portal and maybe even access Azure subscriptions. An admin can assign Azure RBAC roles to normal user accounts, which are outside the scope of Entra admin roles in Conditional Access. Requiring MFA for accessing admin portals is essential! This policy targets resources such as the Windows Azure Service Management API and Microsoft Admin Portals. Those target resources includes several different administrative portals:
Azure Resource Manager
Azure portal, which also covers the Microsoft Entra admin center
Azure Data Lake
Application Insights API
Log Analytics API
Azure CLI
Azure Data Factory portal
Azure DevOps
Azure Event Hubs
Azure PowerShell
Azure Service Bus
Azure SQL Database
Azure Synapse
Classic deployment model APIs
Microsoft IoT Central
SQL Managed Instance
Visual Studio subscriptions administrator portal
Exchange admin center
Microsoft 365 admin center
Microsoft 365 Defender portal
Microsoft Entra admin center
Microsoft Intune admin center
Microsoft Purview compliance portal
Microsoft Teams admin center
NOTE! If you are using traditional service accounts for API calls from Powershell connecting to Azure management API, those would be required for MFA! Microsoft Graph PowerShell that calls Microsoft Graph API is NOT part of this policy.
3. General access policies – CAG011-CAG020
CAG011 Security info registration require TAP or compliant device for All Internal Users v1.0
Internal users should be able to register security information like MFA, performing SSPR or enabling passwordless login. There’s different options how to do this. It’s quite common that you have two access requirements for security info registration and network exclusion also. Note that Externals and Guests are out of scope.
- Use either compliant device OR require TAP. To require TAP, an additional custom Authentication Strength is to be build. I do recommend to set BOTH and require one of the selected controls.
- Second is to exclude trusted locations. Trusted locations needs to be carefully planned.
End result is on trusted locations users can register security information without any requirements. In untrusted locations, users must use a Temporary Access Pass (TAP) or a compliant device.
CAG012 Device registration require MFA for All Users v1.0
This policy does just what it says, requires MFA for Entra device registration or join actions. This policy is designed to replace the Entra tenant-wide policy for better control. Just remember to turn off Entra tenant-wide setting.
4. User access policies – CAG021-CAG030
CAG021 All require MFA for All Users v1.0
Requiring MFA for all users is straightforward yet essential. How often do users perform MFA and what authentication methods are available are settings specified in Entra ID. By default, multifactor authentication requires users to reauthenticate every 90 days. Microsoft recommendation is to use Conditional Access Sign-in frequency, but that does not enforce just MFA, it requires user to sign-in AND perform MFA. This policy enforces MFA for all user types, even traditional service accounts and break-glass accounts.
NOTE! Make sure to exclude service accounts from this policy by using Exclude group!
5. External/Guest access policies – CAG031-CAG040
CAG031 All require MFA for Guest accounts with SIF 14 days v1.0
Guest accounts are B2B collaboration guest users or Local guest users. This policy adds additional control, session control in form of Sign-in frequency (SIF) of 14 days on top of regular MFA requirement. SIF can be anything you require, but this is a good startup point.
CAG032 All require MFA for External accounts with SIF 14 days v1.0
External accounts are B2B Collaboration Member users, B2B Direct connect users, Service Provider users and Other External users. These users require additional configuration in Entra ID but must still be protected with Conditional Access Policies. This policy adds additional control, session control in form of Sign-in frequency (SIF) of 14 days on top of regular MFA requirement. SIF can be anything you require, but this is a good startup point.
6. Partner access policies – CAG041-CAG050
CAG041 All require MFA for Partner accounts with SIF 14 days v1.0
Partner accounts are normal Entra member accounts, for example consultants, contractors and similar roles. The recommended approach would be to use B2B features in Entra ID, but some partner organizations might not use Entra ID at all. This policy adds additional control, session control in form of Sign-in frequency (SIF) of 14 days on top of regular MFA requirement. SIF can be anything your needs, but this is a good startup point. This policy is assigned to a security group specifically created to include all Partner accounts.
Conclusion
These are the minimum Conditional Access policies every organization should implement, with slight adjustments based on your specific needs. In my next post, I’ll focus on additional policies, such as Device Compliance based Conditional Access Policies for browsers and modern clients, as well as other advanced policies that require some forward planning. Stay tuned!