Almost every environment I review has a few SharePoint sites holding particularly sensitive information, such as executive documents, confidential projects or HR files. Standard Conditional Access policies don't help much with these, because they target broad apps like "Office 365" or "SharePoint Online" rather than specific content. Try to require phishing-resistant MFA or a compliant device for only a handful of strategic sites and you'll soon run into that limitation. This is the gap authentication context fills. It gives you far more granular Conditional Access for SharePoint, Teams and other resources.

Authentication context ties Conditional Access to resources instead of apps

In Entra ID, authentication context lets you define your own context values (for example "c1" or "c2") and use them as triggers for Conditional Access. A policy then targets a context instead of an app, and that context is linked to a resource. Usually that's a sensitive SharePoint site, a Teams team or an M365 group. You can also require authentication context for PIM role activation, or use it for session controls in Defender for Cloud Apps.

I'm still surprised how many tenants don't use authentication context at all. Most of the time the admins simply don't know how flexible it is. The licensing is straightforward. Authentication context needs Entra ID P1, and container sensitivity labels need an additional Purview license (details here). If you have both, you can map a label directly to an authentication context and get very targeted protection.

A context value becomes useful once a Conditional Access policy targets it

You start in the Entra portal. Under "Conditional Access > Authentication context" you create a new context, for instance "c1 – High risk access". Then you build a Conditional Access policy that targets this context and sets requirements such as:

  • Require phishing-resistant MFA (FIDO2 or CBA)
  • Or require a compliant, managed device

For any new policy triggered by a context, I start in report-only mode. Microsoft's docs cover the basics well, but targeting by context gives you controls that app-based rules can't provide.

Practical tip: Always test with dedicated test accounts and report-only mode before enforcing authentication context on production sites.

You assign the context to a SharePoint site with a label or PowerShell

Things get interesting once you assign an authentication context to a specific SharePoint site. You have two main options. One is a sensitivity label with container settings, where the context is set as a protection setting. The other is to set it directly with PowerShell:

Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/SecretProject" -ConditionalAccessPolicy AuthenticationContext

Once assigned, the context only takes effect if the right licenses are in place, and only on modern SharePoint sites. The mapping can be completed in the SharePoint admin portal or with PowerShell.

Access to a protected site usually follows this flow:

flowchart TD
  User["User access"] --> SharePoint["SharePoint site"]
  SharePoint --> Context["Authentication context triggered"]
  Context --> CA["Conditional Access policy"]
  CA --> MFA["Phishing-resistant MFA / device"]
  MFA --> Access["Access granted"]

Figure: A user opens a protected SharePoint site, and the authentication context triggers Conditional Access enforcement before access is granted.

Sensitivity labels, Defender and PIM extend the context beyond SharePoint

I like authentication context mainly because it works in so many places. With sensitivity labels (see Microsoft Purview docs) you can link Teams, groups and SharePoint sites to the same context value. That helps a lot in environments with complex data governance or heavy external collaboration. In Defender for Cloud Apps, the context lets you apply session controls to risky actions or block downloads based on real-time risk. In PIM, you can require authentication context before critical roles are activated, which fits nicely with just-in-time privilege elevation.

For more depth, have a look at /blog/conditional-access-entra-id-getting-started, where I cover practical Conditional Access best practices in Entra ID.

Users notice the extra prompt and you should prepare them for it

Most of the time, end users won't notice authentication context at all. That changes on their first visit to a protected site or labeled resource, when they get the extra authentication step. Session controls can reduce repeated prompts, but depending on the browser and sign-in method, users may still see several MFA prompts. Tell people in advance. If you switch on authentication context without warning, users get caught off guard and your helpdesk gets the tickets.

In my projects we normally test label and context assignments thoroughly before they go to production. Report-only mode combined with a staged rollout keeps disruption to a minimum. And keep in mind that classic app-based Conditional Access on its own can't give you this kind of site-specific control.

Authentication context gives you granular security when you roll it out carefully

Authentication context won't solve every problem, but it's one of the most useful tools I know for protecting the most sensitive Microsoft 365 resources. Once the model clicks, you can apply Conditional Access far more precisely than before. Just keep the licensing and technical limitations in mind. Rolled out properly, it delivers precise, risk-based access control, and I expect it to become even more important from here on.