Entra ID authentication contexts

Authentication contexts in Microsoft Entra ID let Conditional Access policies trigger action-specific authentication requirements — step-up MFA when the user is about to perform a sensitive action, not just when they sign in to an app. They're how you implement "you can browse SharePoint with regular MFA, but you need passwordless authentication to access this specific sensitive site."

The model

Traditional Conditional Access policies key on app or resource: "to access SharePoint, require MFA." Authentication contexts add a more granular layer: define named contexts (e.g., "High-Risk Access," "Privileged Operation"), apply Conditional Access policies to those contexts, and then tag resources with the contexts.

When a user attempts an action requiring a tagged context, Entra ID checks whether the current session satisfies the context's policy. If not, the user is prompted to step up — MFA, passwordless re-auth, or another stronger factor.

Where contexts apply

Authentication contexts can be referenced by:

• SharePoint sites — require a specific context to access labelled sensitive sites (via sensitivity labels + auth context).
• Microsoft 365 Groups / Teams — sensitivity labels can require an auth context.
• Privileged Identity Management (PIM) activations — require a stronger auth method to activate specific roles.
• Microsoft Graph operations — apps can demand a specific auth context for sensitive APIs.
• Custom applications built with Graph or MSAL can demand contexts for specific operations.

A worked example

A bank wants to allow:

• General SharePoint and Teams use with regular MFA.
• Access to the legal-hold SharePoint site only with a passwordless authentication method.

Steps:

1. Create an authentication context named "Legal Hold Access."
2. Create a Conditional Access policy that, for this context, requires passwordless authentication.
3. Create a sensitivity label "Legal Hold" that requires the context for site access.
4. Apply the label to the relevant SharePoint sites.

The user signs in normally with MFA, can browse around freely. When they click into the legal-hold site, Entra ID prompts: "this site requires additional authentication" — and they re-auth with passwordless. The session is now elevated; they access the site.

Why this matters

Without auth contexts, your only granularity is at the app level: MFA required to enter SharePoint Online (the app), but every site behaves the same. Auth contexts let you say "this specific resource within the app needs more." That granularity matters for:

• Mixed-sensitivity workloads — most content is normal, some is highly sensitive.
• Step-up patterns — start with low friction, escalate only when needed.
• Privileged-access scenarios — require FIDO2 / passwordless for admin-role activation while normal users use Authenticator MFA.
• Compliance frameworks that require stronger auth for specific data classes.

Licensing

Authentication contexts require Microsoft Entra ID P1. Combined with Microsoft Purview sensitivity labels (E3 / E5 territory) for site-level enforcement.

Practical advice

• Start with a small set — two or three contexts (Normal, High-Risk, Privileged) is usually enough.
• Pair with sensitivity labels for consistent governance.
• Document the policy — what each context means, what it requires, when it triggers.
• Test the user experience — step-up prompts mid-session are noticeable; ensure they're not surprising.

For tenants doing serious zero-trust work, authentication contexts are one of the most useful but underused Entra features.