Mastering Microsoft Entra Authentication Contexts – Part 2: Real-World Access & Action Controls
- Sebastian F. Markdanner
- Sep 29
- 8 min read
Updated: Nov 3
In Part 1 of this mini-series, we explored the what, why, and how of Microsoft Entra Authentication Contexts, laying the foundation for what they are and how they work.
In this second part, we’ll build on that foundation with real-world examples of how Authentication Contexts can secure user access and critical actions. Along the way, we’ll walk through configurations, share recommendations, and look at the Conditional Access policies that tie it all together.
So, let’s dive straight in and see Authentication Contexts in action.
Table of Contents
Authentication Contexts in Everyday Access
As we covered in Part 1, Authentication Contexts are available with any SKU that includes Conditional Access - right down to the standalone Entra ID Premium P1.
That said, while contexts themselves are widely available, the features you apply them to may require higher licensing tiers. To keep things clear, I’ll note the minimum required license whenever we hit a scenario that goes beyond P1.
Conditional Access Repository
I’ve created a GitHub repository for Conditional Access, where I share JSON exports of policies. It’s a growing library of practical examples you can adapt to your own environment, providing a single source for policies.
Conditional Access Naming Convention
Throughout the post I'll be providing Conditional Access policy examples, which follow the naming convention that I shared throughout my Conditional Access Series.
For reference, here’s the format I’ll be using
Note: serialization here doesn’t account for other policies you may already have in place
<CANumber>-<GrantControl>-<PolicyType>-<Persona>-<App>-<Platform>-<OptionalDescription>
Number Scheme Across Personas
Microsoft Entra Authentication Context Best Practices
Before diving into scenarios and use cases, let’s cover a few best practices that will help you get the most out of Authentication Contexts. These recommendations are focused on contexts, but they apply just as well to any Conditional Access deployment!
Naming & Descriptions
Establish a consistent naming convention with clear, concise descriptions for each context and its associated policy. This makes the policy’s purpose obvious to both current and future admins, and it reduces confusion when changes inevitably come down the road.
Document Context Assignments
It’s equally important to document where contexts are used. Since there’s no built-in way to list all resources, actions, or settings tied to a given Authentication Context, documentation prevents gaps and guesswork.
In Part 4 of this series, I’ll cover how you can monitor most of these assignments with PowerShell.
Identifying Requirement Groups
Often, different contexts end up sharing the same requirements. To keep things efficient, group contexts with similar requirements together, using persona-like groupings. This helps shrink your overall Conditional Access footprint, reduces overlap, and leaves fewer places for gaps to sneak in.
Don't Over-Engineer Policies
Keep each policy focused and simple.
A policy should have a single clear goal and not try to cover every scenario at once. Overly complex policies increase troubleshooting time and can cause alignment issues across the environment (or worse, just directly fail to work).
Remember: Conditional Access policies are evaluated simultaneously, and all conditions are treated as AND statements.
Real-World Scenarios for Authentication Contexts
Authentication Contexts give us the tools to enforce granular, scenario-based requirements across the cloud. Below are several real-world examples I recommend considering, no matter your organization’s size or industry.
Privileged Identity Management (PIM)
Requires License: Microsoft Entra Premium P2
PIM provides just-in-time, time- & approval-based access to privileged roles and groups, along with options for step-up authentication, approval flows, and ticketing. By layering in Authentication Contexts, we can tighten security around role activations, ensuring the right checks are in place before elevated permissions are granted.
For more information on the feature, take a look at this blog post.
These are a few real-world examples:
Step-up Authentication for privileged roles
High-privilege roles, like Global Administrator, Privileged Role Administrator, and Privileged Authentication Administrator, should always be set as eligible. However, the default PIM configuration only requires a valid MFA token at activation, regardless of type. That’s not enough.
Using Authentication Contexts, we can enforce strict requirements including phishing-resistant MFA, device compliance, or re-authentication when these roles are activated.
Tier 0 Example: Global Administrator
Recommendations for high privileged (T0) roles like the Global Administrator role:
Associated Conditional Access Policy
Name: CA600-PROD-AuthStr&Compliant-IdentityProtection-Admin-PIM T0-Any-Require Phishing-Resistant MFA and compliant device for PIM T0-v1.0.0
Policy:
Tier 1 Example: Global Reader
Recommendations for privileged (T1) roles such as the Global Reader role:
Associated Conditional Access Policy
Name:
CA600-PROD-AuthStr-IdentityProtection-Admin-PIM T1-Any-Require passwordless OR Phishing-Resistant MFA for PIM T1-v1.0.0
Policy:
Azure Resource T0 Example: Owner
Azure RBAC roles follow the same logic as Entra roles.
For a high-privilege role like Owner (T0), the same controls applied to Global Administrator should also be applied here - which can easily be enforced by utilizing the same context.
Note: PIM Policies for Azure resources are applied across scopes and cannot be configured to have different requirements pr. scope with the built-in roles.
Associated Conditional Access Policy
Name: CA600-PROD-AuthStr&Compliant-IdentityProtection-Admin-PIM T0-Any-Require Phishing-Resistant MFA and compliant device for PIM T0-v1.0.0
Policy:
Strict requirements for RMAU Administration
Restricted Management Administrative Units (RMAUs) are ideal for limiting who can manage sensitive users, groups, and devices. Pairing RMAUs with PIM and Authentication Contexts enforces step-up authentication for these highly sensitive operations.
For more information on the feature, take a look at this blog post.
Since PIM role settings apply tenant-wide, this can be implemented with a custom role or PIM for Groups.
Breakglass management
Breakglass accounts (emergency Global Admins excluded from controls) need extra safeguards. By restricting who can manage them with an RMAU and enforcing strong requirements via Authentication Contexts, you can ensure these accounts are both available in a crisis, tightly controlled while reducing risks of accidental or malicious actions on them.
This typically requires two Conditional Access policies Recommendations for the custom RMAU role:
Associated Conditional Access Policies
1. Require phishing-resistant MFA & compliant device
Name:
CA600-PROD-AuthStr&Compliant-IdentityProtection-Admin-PIM BG RMAU-Any-Require Phishing-Resistant MFA & Compliant device for BG RMAU scoped role-v1.0.0
Policy:
2. Block access from untrusted locations
Name:
CA100-PROD-Location-IdentityProtection-Admin-PIM BG RMAU-Any-Block access from untrusted locations for BG scoped role-v1.0.0
Policy:
Board Members
Board-level user accounts often contain access to highly sensitive information but doesn't necessarily require the same level of controls as managing breakglass accounts. For these, a re-authentication requirement when elevating to an RMAU-scoped role is a strong safeguard, ensuring users are who they say they are.
Recommendations:
Associated Conditional Access Policy
Name:
CA600-PROD-AuthStr-IdentityProtection-Admin-PIM RMAU-Any-Require Re-authentication for elevating to RMAU scoped role-v1.0.0
Policy:
Sensitive Local Resource Access with Global Secure Access (PIM for Groups)
Requires License: Microsoft Entra Private Access
Global Secure Access (Microsoft’s ZTNA solution) can secure local resources like servers or legacy apps. Combining PIM for Groups with Authentication Context ensures just-in-time access to these sensitive systems, with strict conditions such as device compliance or phishing-resistant MFA.
To modify PIM for groups policy settings we need to navigate to Privileged Identity Management -> Groups -> Discover groups -> choose wanted group -> Settings
Then choose the role we want to modify - typically the Member role:
Sensitive Server Access
For critical servers (Domain Controllers, PKI, Entra Connect, SCCM, etc.), access should be locked down as tightly as possible.
Associated Conditional Access Policy
Name:
CA600-PROD-AuthStr&Compliant-AttackSurfaceReduction-Admin-PIM GSA-Any-Require Phishing-Resistant MFA & compliant device for Sensitive Server access-v1.0.0
Policy:
Local HR Application
For legacy, self-hosted applications, such as this examples HR app, employees can elevate into a PIM-managed group that requires a compliant device. This reduces risk while keeping access practical.
Associated Conditional Access Policy
Name: CA700-PROD-Compliant-AppProtection-HR-HR Staff App-Any-Require compliant device for access to local HR system-v1.0.0
Policy:
Protected Actions
Requires License: Microsoft Entra Premium P1
In Microsoft Entra, some administrative actions are simply too sensitive to leave unguarded — even if the person has the right permissions. Protected Actions let us secure these operations with stricter requirements, using Authentication Contexts to make sure they can’t be misused accidentally or maliciously.
For a deeper look at Protected Actions take a look at my blog post on the feature here.
Configuring Protected Actions
Navigate to Microsoft Entra Portal → Identity → Roles & Admins Click Show more if you don’t see “Protected Actions” right away Select Protected Actions and click Add Protected Actions
Choose the wanted Authentication Context and click on Select Permissions
In the fly-out, choose the actions you want to protect (e.g., Conditional Access policy modifications).
Once you’ve created the Protected Actions, you can review them in the Protected Actions overview. Here, you’ll see a list of all the actions you’ve secured, along with the Authentication Contexts assigned to them.
Once configured, users attempting to take one of the actions will be required to fulfill the step-up authentication
Protected Actions Conditional Access Policy
For Protected Actions, I recommend requiring phishing-resistant MFA and re-authentication on every use. This provides strong protection and ensures only verified, trusted sessions can carry out these operations.
In practice, this works well, though admins who frequently work with multiple Conditional Access policies may find the constant prompts a bit much. If that becomes an issue, setting the sign-in frequency to 1 hour is a good balance between usability and security.
Note: As soon as you configure Protected Actions, you’ll see additional prompts, even if you haven’t yet enforced requirements through Conditional Access. In that case, you’ll only need to refresh the page, with no extra requirements applied.
Name:
CA600-PROD-AuthStr-AttackSurfaceReduction-Admin-ProtectedActions-Any-Require Phishing-Resistant MFA for Protected Actions-v1.0.0
Policy:
Grouped Conditional Access Policies Approach
Another strategy for enforcing Conditional Access policies for Authentication Contexts is to group contexts with similar requirements. Instead of creating many individual policies, you can reduce complexity by applying fewer, broader policies that cover multiple Authentication Contexts at once.
This approach works well when requirements overlap—for example, roles or resources that all need phishing-resistant MFA. Some contexts, like the HR app in our earlier example, won’t fit neatly into a group and will still require their own dedicated policy, either due to scope or requirements.
Here are two examples of grouped policies, extendable depending on your authentication contexts.
Group: T0 Contexts
This group includes the highest-sensitivity contexts - think T0 roles, Protected Actions, and T0 servers.
Name:
CA600-PROD-AuthStr+Compliance-AttackSurfaceReduction-Admin-T0AuthContext-Any-Require Phishing-Resistant MFA & Compliant device for T0 Contexts-v1.0.0
Policy:
Group: T1 Contexts
This group covers sensitive but slightly lower-tier contexts, such as T1 roles and RMAUs for board members.
Name:
CA600-PROD-AuthStr-AttackSurfaceReduction-Admin-T1Contexts-Any-Require Phishing-Resistant MFA for T1 Contexts-v1.0.0
Policy:
When to Choose Grouped vs. Granular
Go grouped if you want fewer policies, easier management, and reduced sprawl. Great for organizations that value simplicity and broad coverage.
Stay granular if you need maximum clarity, tighter control, or if different personas/contexts really do require distinct requirements. Perfect when troubleshooting or auditing is a priority.
In practice, most organizations benefit from a hybrid approach. Using grouped policies where requirements overlap, while keeping granular policies for high-sensitivity or unique scenarios. It’s not an either/or choice; it’s about applying the right strategy to the right situation.
Key Takeaways & What’s Next
Microsoft Entra Authentication Contexts give us the flexibility to go beyond “one-size-fits-all” access rules and instead apply the right requirements in the right places.
Whether it’s enforcing phishing-resistant MFA for Global Admins, protecting sensitive servers, securing breakglass accounts, or locking down Protected Actions, contexts let us tailor security without adding unnecessary friction everywhere else.
The examples in this post show that there’s no single “correct” approach. Some scenarios call for granular, dedicated policies that make intent crystal clear, while others benefit from grouped policies that reduce complexity and keep your Conditional Access stack manageable. Most organizations will land somewhere in between, using a hybrid approach to balance simplicity with precision.
With user access and actions now covered, the next part of this series will turn to data protection showing how Authentication Contexts can help safeguard sensitive information within our environment, including real-world examples of usage within Sensitivity Labels & Microsoft Defender for Cloud Apps Sessions policies.
After that, we’ll wrap things up in Part 4 by exploring monitoring and reporting, so you can keep your Authentication Context strategy effective over time.
Stay tuned—this journey is only halfway done!
🔗 Authentication Context Series Index
Part 2: Real-World Access & Action Controls (You're here!)
Part 3: Advanced Data Security