This article shows some of the base conditional access policies which can be implemented for all Microsoft Entra ID tenants. Phishing resistant authentication should be required for all administration flows and some other user policies like sign-in risk MFA or terms of conditions. I recommend these base policies when implementing an Microsoft Entra ID tenant using a P2 license.
Disable security defaults
The security defaults are a good basic setup, but when a P2 license is used, conditional access policies can be applied and the tenant can be setup to force things like phishing resistant authentication.
Disable on the tenant in the “your-tenant” | Overview | Properties
All the security defaults are disabled and good conditional access policies are now required.
Activate conditional access policies
There are many conditional access policies. These are applied and different depending on the tenant requirements. The following base policies make sense in all tenants:
- Force MFA conditional access policy (All users)
- Require Terms of Use policy
- Block legacy authentication (All users)
- Enable Sign-in risk policy (All users)
- Require phishing resistant authentication for admins
- Enable User risk policy (All users)
A single break glass account is excluded from these policies and this account should never be used except in an emergency. Alerts are required on this account.
1. Force MFA conditional access policy
Multi-factor authentication can be forced for all users except the break glass account. This uses the “Require authentication strength” policy and the tenant can set the default strength as required.
Add the following policy ( Force MFA All users except break glass account )
2. Require Terms of Use policy
Add a Require Terms of Use for app ( App Require Terms of Use ) policy. You can use Microsoft Entra ID to force the users of the tenant and all the client apps to except the terms of conditions required by the tenant and the hosted applications.
The terms of use needs to be added to the Azure tenant:
https://learn.microsoft.com/en-us/entra/identity/conditional-access/terms-of-use
The policy can be created for the terms of use. See the Microsoft docs for details.
https://learn.microsoft.com/en-us/entra/identity/conditional-access/require-tou
3. Block legacy authentication
Block the legacy authentication in the tenant. The Client apps should select only the Exchange ActiveSync clients and Other clients and the access must be blocked.
4. Enable Sign-in risk policy
You can activate the sign-in risk and choose how strict. If a risky sign-in is detected, the user is required to do a multi-factor authentication. This requires a P2 license for user accounts. See the Microsoft docs for details:
5. Require phishing resistant authentication for admins
Phishing resistant MFA should be applied to app administrator workloads. This can be created from the Azure provided template.
The policy is applied to the Azure roles:
- Global Administrator
- Application Administrator
- Authentication Administrator
- Billing Administrator
- Cloud Application Administrator
- Conditional Access Administrator
- Exchange Administrator
- Helpdesk Administrator
- Password Administrator
- Privileged Authentication Administrator
- Privileged Role Administrator
- Security Administrator
- SharePoint Administrator
- User Administrator
When a user account has one of the Azure admin roles, phishing resistant authentication is required for access to the tenant.
6. Enable User risk policy (All users)
If a user account has a high or medium level possibility that it has been compromised, the user is required to do a multi-factor authentication. Why not Self-service password reset (SSPR)? I don’t really see the point of this if you are using passwordless sign-ins. Without a SSPR for a user with a password, the user-risk is not reset and the user will be forced to MFA again. I am not sure how this policy works with passwordless or phishing resistant authentication flows. This policy only makes sense with the high threat category and the block user. This requires a P2 license for users accounts.
Summary
These are the base policies and further policies can be added depending on the tenant requirements. Some session based controls would normally make sense as well.
Notes
The examples of the continuous access policies are shown and set up using the Azure portal. This would be way better as a terraform script and a fully automated set up using something like Azure DevOps or Github actions.
Links
https://learn.microsoft.com/en-us/entra/identity/conditional-access/require-tou
Software Engineering 
[…] Create conditional access base policies for a Microsoft Entra ID tenant (Damien Bowden) […]
[…] Create conditional access base policies for a Microsoft Entra ID tenant – Damien Bowden […]