Your Conditional Access strategy matters

Identity is the new perimeter — and Conditional Access (CA) is your gatekeeper. When you’re using Microsoft Entra ID to manage access, CA becomes a crucial part of your Zero Trust strategy. But CA isn’t just about turning on MFA or blocking risky logins. It’s about translating your business and security goals into enforceable policies.

In this post, we’ll walk through the core building blocks of access policy enforcement, show how they apply to real-world access scenarios and explore how to align your CA strategy with user personas and business needs.

Conditional Access 101

Conditional Access is a set of rules defined in your Entra ID tenant that governs how users can access your environment. These rules specify that even when users successfully provide their username and password, they may still need to meet additional conditions.

It’s essentially a big ‘if-then’ calculation. For example:
If you come from an unmanaged device with a user that is part of my tenant, then I’m going to require MFA.

However, enforcing MFA alone is no longer sufficient — there are many more scenarios you should be considering. Modern identity and access strategies take additional variables into account to ensure secure access.

‘If’ variables

User types

Within your organization, you’ll have different types of users. Each user type has its own use cases — and as such, requires different policy considerations.

Regular users

These are your standard user accounts, used for day-to-day tasks like browsing, emailing, using Teams, etc.

Guest users

These are accounts from other tenants that have been invited into your own. That means the account is managed externally, and you have no visibility into the source tenant’s security hygiene. The only thing you can control is the MFA registration in your own tenant. Password strength, account security and integrity are all out of your control when it comes to guest users.

Admin accounts

These are accounts used exclusively for administrative actions. They should be heavily protected and subject to strict policies.

User-based service accounts

These are standard user accounts used by applications or scripts to authenticate in the background — often with a saved username and password. This is considered bad practice, as these accounts can’t complete MFA (since there’s no human involved), and they often require exceptions in your CA policies.

Instead, authentication should be moved to service principals.

Service principals

Service principals allow applications and automation tools to authenticate securely against Microsoft services using Entra ID. They enable application identities to access resources via Microsoft’s official APIs, supporting more secure and scoped access through role-based access control (RBAC) and app-specific credentials (like certificates or client secrets).

Protecting service principals via Conditional Access requires a separate license.

Break glass account

This is your emergency account with active global administrator privileges. It should be excluded from all Conditional Access policies.

Device types

Within your tenant, you can distinguish between different device types. One common method is by operating system.

For servers and endpoints: Windows, macOS and Linux

For mobile devices: iOS and Android (Windows Phone is technically still possible to filter on)

As an organization, it’s important to take a clear stance on which operating systems you will allow. This decision is often influenced by the platforms you provide to your end users.

For example, if your company does not provide corporate macOS devices to employees, how much access are you willing to allow from an unmanaged macOS device?

Join types

Conditional Access allows you to filter access based on the device join state. These states help determine how much control you have over the device and what policies it receives. The three most common join types are:

Microsoft Entra ID registered

These are devices registered to Entra ID but not signed in with an organizational account. They’re usually BYOD or personal devices. Since they don’t receive security policies or configurations from your organization, they’re considered untrusted and pose a higher risk.

Hybrid Azure AD joined/Entra ID joined

These are your managed devices. Hybrid means the device is joined to both on-prem Active Directory and Entra ID, while Entra ID joined means it’s cloud only. Both are typically managed through Intune (or Group Policy, in hybrid scenarios), which means you can enforce security baselines and compliance policies on them.

Compliant devices

These are devices that pass your defined Intune compliance policies. For instance, a device lacking antivirus or a required OS version would be marked non-compliant — and can then be blocked or restricted. Compliance status is a key enforcement tool in modern device management.

Browser vs. application access

A critical decision in your policy strategy is how you handle access via browser versus native applications.

Application access

When using native apps (like Outlook or Teams desktop), data is often cached locally on the device. If the device is unmanaged or personal, that data could be exposed to risk. Conditional Access can be used to block or restrict access from apps unless the device is trusted and compliant.

Browser access

Web access can be more tightly controlled, especially when combined with Microsoft Defender for Cloud Apps (MDCA) and Conditional Access App Control. With these tools, you can:

• Block downloads from sensitive apps like SharePoint or OneDrive
• Prevent copy/paste or printing

Browser-based access gives you more flexibility to enable access from untrusted devices without giving up control over the data.

Locations

Conditional Access can also evaluate the location a sign-in is coming from, based on named locations that were defined in Entra ID.

Trusted locations

You can define IP ranges (e.g., corporate offices or VPN ranges) as trusted locations.

Compliant networks

If you’re using Global Secure Access (part of Microsoft’s SSE strategy), a compliant network is one where an agent has been deployed to enforce access policies (for example, to allow access to on-prem file servers).

Important: From a Zero Trust perspective, location ≠ trust.
Granting access based solely on IP address or office location increases your attack surface.

‘Then’: Grant and session controls in Conditional Access

Once your ‘if’ conditions — such as user, device, app, location and risk — are defined, the next step is to configure the ‘then’ actions: the controls that determine whether access is granted, restricted or modified. These controls fall into two main categories: grant controls and session controls.

Grant controls

These determine the prerequisites for access. If conditions are met, access is granted; otherwise, it’s blocked.

From building blocks to real-world scenarios

Conditional Access shines when you combine multiple signals — user context, device trust, app sensitivity, location and authentication strength — to shape smart, adaptive access policies.

Scenario 1: Enforce phishing-resistant access for Azure Portal

• Target users: IT administrators
• Resources: All applications
• Device requirement: Entra ID joined + compliant
• Application: Azure admin portal
• Policy outcome:
  • Require phishing-resistant MFA (e.g., FIDO2)
  • Limit session validity to 8 hours
• Exclusions: External IT consultants

Scenario 2: Restrict access from an unknown BYOD device to Microsoft 365

• Resource: Microsoft 365
• Device state: Entra ID registered (BYOD)
• Application: Web browser
• Location: Unknown or public IP
• Policy outcome:
  • Require MFA
• Enforce read-only session with download restrictions via Defender for Cloud Apps

Persona-based architecture

Persona-based architecture is the natural next step in your access policy roadmap. It allows you to map access scenarios to defined user “personas” within your organization — such as IT admins, frontline workers, developers or third-party consultants.

As your CA policies grow to cover more scenarios, it becomes increasingly difficult to keep track of which policies apply to which user types. This often leads to inconsistent exclusions, overlapping policies and potential coverage gaps.

The most important — and often most challenging — step is to identify and define your core personas. Start simple. Avoid creating too many personas based on minor differences. Focus on the distinct roles and risk profiles that justify differentiated access requirements.

By organizing policies around well-defined personas, you gain:

• Clarity in policy intent
• Consistency in enforcement
• Scalability as your environment evolves

This approach helps ensure your Conditional Access strategy stays targeted, maintainable and aligned with Zero Trust principles.

Example: Persona-based Conditional Access matrix

This table illustrates how different Conditional Access scenarios can be aligned to specific user personas. It provides a clear, scalable way to apply access policies consistently based on role, risk and context.

Conclusion

Persona-based architecture isn’t built in a day. Understanding the capabilities and implications of Conditional Access is essential to designing policies that truly reflect your real-world scenarios. By clearly defining your personas and mapping the right controls to user needs, you lay the foundation for a scalable and maintainable access strategy that grows with your organization.