10 Conditional Access Policies Every Azure Admin Needs

When it comes to MFA policies for conditional access, you should apply these policies: 

• Set up MFA for all Admin Accounts: All sensitive admin accounts should have MFA enforced (Global admins, Exchange admins, SharePoint admins, etc.). 
• Set up MFA for all Users: Require MFA for all standard user accounts to protect against compromised credentials. 
• Require MFA for all guests: Although not always applied in every organisation, it’s essential to apply MFA to all external identities and guest accounts accessing your tenant to prevent unauthorised access. 

Ultimately, MFA is essential - not optional.

Any account lacking MFA presents a security risk and could be exploited as an entry point in a cyberattack.

2. Block Legacy Authentication

The second policy is to block legacy authentication flows such as POP, IMAP, SMTP kind of protocols which we don't want to be open within our tenant. These legacy protocols don’t support MFA and are vulnerable to attacks like password spraying and credential stuffing.

Blocking these outdated protocols ensures that only modern, secure authentication methods are used, removing weak points that attackers often exploit.

It’s worth noting that Microsoft now disables legacy authentication by default for new tenants through Security Defaults, further strengthening baseline security. 

3. Sign-in risk policy

The sign-in risk policy monitors each login for suspicious activity. If it detects unusual behaviour (e.g. a risky IP address or abnormal device state), it can require the user to change their password. You can configure different risk levels, like low, medium, or high and apply controls like MFA depending on the severity. This ensures that accounts showing potential compromise are secured before granting full access.

4. User-risk policy

The user-risk policy is without doubt one of the policies we believe every Azure admin should have. A user-risk policy monitors sign-in activity, including IP addresses, device state, and unusual behaviour. When risk levels hit medium or high, depending on how you set it up in your environment, you can trigger actions like requiring MFA, forcing a password reset, or restricting access. 

Best Practices: 

• Start in Report-only mode: Evaluate the impact of your policy before enforcing changes. 
• Keep policies focused: Avoid overly complex or broad policies; manage each scenario separately. 
• Separate internal staff and contractors: Contractors often require stricter controls, as HR or third parties may not always notify IT when someone leaves. 
• Avoid combining multiple scenarios: This keeps policies clear and easier to manage.

5. Block device code flow 

Device code flow authentication allows users to authenticate by entering a code from a terminal prompt into a browser, often used with tools like: 

Connect-MgGraph -DeviceCode. 

While this method can be convenient, it poses a security risk because it may bypass some of the controls enforced on managed devices. 

Blocking device code flow helps prevent unauthorised access, especially in environments where strict authentication controls are required.

This policy is rarely implemented - even in large organisations - despite the risk it presents. For most organisations, it’s best practice to block device code flow entirely, or only allow it for specific users who have a legitimate need for this type of access. 

6. Block access from outside approved locations 

Another important conditional access policy is to block access to the tenant from locations we don’t trust or approve. You can, for example, try to block access from all locations where your organisation isn’t operating.  

• Example 1: Let’s say you are a small business based in the UK. All your users are within the UK, and you don’t want access from any locations outside that country, then you can use this policy. 
• Example 2: Imagine an SMB with a few satellite offices around Europe. You could choose the countries where you have a presence and only allow connections from those locations. You can always trust the office locations that you have around the world; in that case, the list of public IP addresses for those locations would be considered trusted. 

7. Block access based on device type 

The next policy is all about blocking access based on the device type. Here you must define you don’t want connections coming in from certain device types to your tenant.  

For example: You might prefer to restrict connections from unused devices such as Mac machines or perhaps from a Windows phones, if not commonly used within your user base. 

8. Disable persistent browser sessions 

Disabling persistent browser sessions ensures that users cannot remain signed in after closing and reopening their browser. With this policy in place, every session is terminated when the browser is closed, requiring users to reauthenticate each time they access the platform.  

This approach helps prevent unauthorised access - especially from unmonitored or compromised machines - by ensuring that authentication cannot be bypassed simply by reopening a browser window.

9. Leverage the session control policy 

The next and very helpful policy is called session control. This policy allows you to have put a time interval of how long somebody can sign in to the environment before they must re-authenticate.  

A common recommendation is 8 hours, aligning with a standard workday, but you can adjust it to any threshold that fits your environment.  

10. Require Hybrid Entra ID Joined Device 

This policy is especially important for organisations operating in a hybrid cloud environment. By requiring devices to be Hybrid Entra ID joined, you ensure that only corporate-managed devices—meeting your organisation’s security standards—can access sensitive resources. 

Enforcing this policy prevents unmanaged or personal devices from connecting, significantly reducing the risk of data leaks or unauthorised access. It also strengthens your device-based conditional access controls by allowing you to specify exactly which endpoints are permitted. 

Additionally, this approach works hand-in-hand with Intune policies, ensuring that all devices comply with required security configurations before they are granted access to secure services. 

Closing thoughts 

By now, you know conditional access is the backbone of a secure Azure environment, giving you control over who can access what, from where, and on which devices. Implementing these conditional access policies will reduce the attack surface and strengthen your security posture in Microsoft Azure.  

Regularly reviewing this helps you see best practices, new features, and steps to strengthen your hybrid cloud identity security.