How to Configure Microsoft Entra ID Conditional Access Authentication Contexts for Granular App Security

In the traditional Zero Trust model, security is applied at the front door. A user logs into Microsoft 365, Conditional Access evaluates their device compliance and location, challenges them for MFA, and grants them a session token. Once inside the application—for example, SharePoint Online—the user can navigate anywhere based on their standard RBAC permissions.

The problem arises when an application contains data of wildly varying sensitivity. A user might legitimately need to access a standard “Company Picnic” SharePoint site from a personal, unmanaged iPad at a coffee shop. However, that exact same user must never be allowed to access the “Project Apollo Merger” SharePoint site unless they are on a company-issued, fully managed Windows 11 laptop, sitting on the corporate VPN, utilizing a phishing-resistant FIDO2 key.

Applying the strict policy globally blocks the user from the picnic site. Applying the weak policy globally compromises the merger site.

Microsoft solved this architectural conflict with Authentication Contexts. Authentication Contexts allow you to attach a specific Conditional Access policy directly to a granular resource inside the application (like a specific SharePoint site, a specific sensitivity label, or a specific action in a custom line-of-business app). The user is challenged dynamically, mid-session, only when they attempt to cross that micro-boundary.

This guide explains how to configure and deploy Authentication Contexts in Microsoft Entra ID.

Step 1: Defining the Authentication Context

An Authentication Context is essentially a tag that you create in Entra ID. You will later apply this tag to your Conditional Access policy, and then apply the same tag to your sensitive data.

1. Navigate to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Protection > Conditional Access > Authentication context.
3. Click New authentication context.
4. Name: High-Security-Merger-Data
5. Description: Requires Managed Device and FIDO2 MFA.
6. Publish to apps: Ensure this is checked.
7. Click Save.

Step 2: Building the Step-Up Conditional Access Policy

Now, you must define the rigorous security requirements associated with that context tag.

1. Navigate to Protection > Conditional Access > Policies.
2. Create a New policy named Enforce-High-Security-Context.
3. Users: Include All Users.
4. Target resources: This is the critical change. Instead of selecting “Cloud apps” (which targets the entire application front-door), click the dropdown and select Authentication context.
5. Check the box for the High-Security-Merger-Data context you just created.
6. Conditions: Under Filter for devices, configure a rule to exclude unmanaged devices (e.g., device.isCompliant -ne True).
7. Grant: Select Require multifactor authentication (or optimally, Require authentication strength: Phishing-resistant MFA).
8. Enable policy: On.
9. Click Create.

This policy now sits dormant in Entra ID. It only triggers when an application explicitly requests the High-Security-Merger-Data context.

Step 3: Tagging the Resource (SharePoint Example)

The final step is to apply the context tag to the sensitive data. In this example, we will apply it to a specific SharePoint site.

This is configured via the SharePoint Online Management Shell (PowerShell), as the GUI options are often abstracted behind Microsoft Purview sensitivity labels.

First, connect to your SharePoint tenant:

Connect-SPOService -Url https://yourtenant-admin.sharepoint.com

Next, you must retrieve the exact GUID of the Authentication Context you created in Step 1. You can find this in the Entra ID portal, or via the Microsoft Graph API.

Finally, apply the context ID directly to the sensitive site collection:

Set-SPOSite -Identity https://yourtenant.sharepoint.com/sites/ProjectApollo -ConditionalAccessPolicy AuthenticationContext -AuthenticationContextName "c1234567-89ab-cdef-0123-456789abcdef"

(Replace the GUID with your actual Authentication Context ID).

Step 4: The Dynamic User Experience

The Zero Trust micro-perimeter is now active. Here is exactly how it operates in practice:

1. The user authenticates to the Office 365 portal from their personal iPad. Standard Conditional Access allows this.
2. The user opens the standard “Company Picnic” SharePoint site. It loads perfectly.
3. The user clicks a link to the “Project Apollo” SharePoint site.
4. SharePoint recognizes the site is tagged with the High-Security-Merger-Data Authentication Context. It pauses the HTTP request and issues a Claims Challenge back to the user’s browser, redirecting them to Entra ID.
5. Entra ID evaluates the Enforce-High-Security-Context policy. It sees the iPad is not a compliant, managed corporate device.
6. The user is instantly blocked with a message: “You cannot access this resource from an unmanaged device.”

If the user was on a corporate laptop, they would simply be prompted to insert their FIDO2 key for a “step-up” authentication, and then seamlessly granted access.

Conclusion

Global Conditional Access policies force security architects into a miserable compromise between absolute security and user productivity. By deploying Microsoft Entra ID Authentication Contexts, you detach security from the application front door and push it down to the micro-resource level. This allows users to retain frictionless access to low-risk data from any device, while mathematically enforcing draconian Zero Trust constraints the millisecond they attempt to touch highly classified intelligence.