What are Conditional Access Policies?
Conditional Access Policies (CAPs) are identity-driven policies that govern user access to resources based on certain conditions. We can summarize them as if statements that govern what will be requested, enforced or blocked. As identity has become a key focus for security efforts, it’s essential to manage it in the best way possible.
All policies “think” at the user level and are enforced after a user has completed the first form of authentication, such as entering their username and password. As such, an attacker could understand if the credentials are correct even if there are blocks dictated by CAPs that might block access based on various signals.
Conditional access policies are implemented using Azure Active Directory, which is the cloud-based identity and access management service that is part of Microsoft 365. As of right now, Azure Active Directory (or Azure AD for short) is being integrated into the newly created Entra product family.
It’s important to note that Conditional Access Policies will manage not only native Microsoft apps such as SharePoint, Teams, the Azure Portal, etc. but also all SaaS applications connected to Azure AD and all on-premises applications managed through Azure AD Application Proxy.
This can simplify the management of identities, as, for example, the user will have their MFA methods set in Azure AD, and they’ll be requested on all connected apps in Azure AD for which you have set Azure AD as the identity provider.
In most organizations, the CAPs enforce requirements such as the enforcement of MFA, the block of logins using legacy protocols and requiring a compliant device to access company resources.
It is advisable to create or make changes to CAPs only if you have a basic understatement of the service and always operate with caution since you could risk blocking access to the tenant for all users.
Please consider implementing an emergency administrator before starting with Conditional Access, and exclude it from all the policies. Read more regarding this here:
Manage emergency access accounts in Azure AD
All Conditional Access policies must grant a user access before they can access a cloud app. If one of the CAP blocks the sign-in, the request will be denied. Note that if in the same policy you both include and exclude a user, the user will be excluded.
I wrote a post on how to check which policy is blocking a user sign-in. If you are curious, you can check it out here:
If you are creating a new policy, it can be set to “Report-only” mode first. This will allow you to use insights and reporting workbooks to evaluate the impact of the policy before you go on to apply it to everyone in the organization by turning it “On”. Alternatively, you can keep the policy inactive by setting it to “Off”. Please note that a certificate request might pop up on Macs or mobile devices if you require a check for Intune compliance in the policy, even if it’s in report mode.
Licenses and Security Defaults
As Conditional Access Policies require Azure Active Directory Premium P1, only some organizations are going to be able to use them. If you are not licensed for it, you use Security Defaults to establish a basic security baseline for your tenant. Security Defaults are now activated by default in all the newly created tenants. What Security Defaults will do is:
- Requiring every user to register for MFA. Once enabled, users will have 14 days to register before being required to do so.
- Requesting MFA for both standard users and administrators, especially when a user accesses privileged portals.
- Block legacy authentication protocols which can’t support MFA.
Templates and JSON
There is currently a set of recommended policies that you can deploy right away by clicking on “New policy from template” at the following link:
Conditional Access Policies | Azure AD
The templates are categorized in:
- Secure foundation
- Zero Trust
- Remote work
- Protect administrator
- Emerging threats
While the templates are a very quick and easy way to start with CAPs, please exercise extreme caution. Even though they are created in report-only, they will not, for example, create a break glass admin and exclude it by default. If you mess up, you might end up locked out. Also note that it’s best to exclude users from CAPs using groups so that you don’t have to modify the policies constantly, which might end up in errors.
A cool new feature is the ability to implement CAPs using JSON templates. You’ll be able to export the policies you have created and be able to import them back in case anything happens.
To learn more, refer to the following documentation:
Azure AD Conditional Access documentation – Microsoft Entra | Microsoft Learn
Azvise 
One thought on “What are Conditional Access Policies in Azure AD”