top of page
Search

Mastering Microsoft Entra Authentication Contexts - Part 3: Advanced Data Protection

  • Writer: Sebastian F. Markdanner
    Sebastian F. Markdanner
  • 2 minutes ago
  • 10 min read

With identities and access strengthened in part 2, it’s time to turn our focus to real-world data protection with Authentication Contexts.

A woman holds a laptop with a shield icon. Large padlock in the background. Text: Safeguarding Information: Microsoft Entra Authentication Contexts (Part 3).

One of the more underused capabilities of Authentication Contexts is their power to secure data across the environment, whether through direct enforcement using Sensitivity Labels or by protecting user sessions via Microsoft Defender for Cloud Apps.


In this post, we’ll explore exactly that: how to secure organizational data using Authentication Contexts to add another layer of protection without adding unnecessary complexity.


Without further ado—let’s dive in.


Table of Contents

  1. Continuation of Authentication Contexts in Everyday Use

  2. Real-World Scenarios for Authentication Contexts

  3. Conclusion

Continuation of Authentication Contexts in Everyday Use

As a reminder from the latest post in the series, Authentication Contexts are available with any SKU that includes Conditional Access - right down to the standalone Entra ID Premium P1.

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

Grant

Persona

Number Range


Global

CA000-CA099


Admin

CA100-CA199

BLOCK POLICIES

Guest

CA200-CA299


Workload & ServiceAccounts

CA300-CA399


Specific Users or Groups

CA400-CA499


Global

CA500-CA599


Admin

CA600-CA699

ALLOW POLICIES

Guest

CA700-CA799


Workload & ServiceAccounts

CA800-CA899


Specific Users or Groups

CA900-CA999


Real-World Scenarios for Microsoft Entra Authentication Contexts

Data security has never been more important. With hybrid work, external collaborators, and contractors becoming the norm, and with AI tools like Microsoft Copilot now accessing the data plane, we need to be more deliberate about when, what, and who gets access to our data.


That’s where Microsoft Entra Authentication Contexts come in. They allow us to enforce stricter, more targeted requirements for sensitive actions and data, ensuring that security adapts to the context instead of relying on broad, one-size-fits-all controls.



Microsoft Defender for Cloud Apps (MDCA)

Requires License: Microsoft Defender for Cloud Apps


Microsoft Defender for Cloud Apps (MDCA) allows us to monitor, control, and protect access to cloud applications across the organization. It provides the flexibility to secure data and sessions without introducing unnecessary friction for users.


Managing how data is handled in SaaS applications, especially on unmanaged devices, remains a major challenge for compliance teams, admins, and leadership alike. Everyone wants strong security, but not at the cost of a massive administrative overhead.


This is where MDCA Session Policies come in.


As mentioned in part one of this series, we can combine Authentication Contexts with MDCA Session Policies to apply adaptive security measures for specific actions. These should be used alongside other Conditional Access and data protection policies for maximum effect.


Let’s go through a few recommended real-world scenarios where using Authentication Contexts with MDCA can add targeted control through step-up authentication:

  • Downloading data on unmanaged devices

  • Downloading data from high sensitive app

  • Uploading data

  • Printing & copying sensitive data



Examples for Microsoft Defender for Cloud Apps


  1. Downloading data on unmanaged devices

    Controlling downloads without fully blocking them provides a strong balance between security and usability - especially for access from unmanaged devices.


    With this configuration, users can still download data (for example, from SharePoint), but they’ll first need to re-authenticate to verify their identity before doing so.

    Edit session policy screen displaying fields for policy name, category, description, and session control. Options include file download control.
    Settings interface showing options for inspection method, actions like audit, block, or authentication. Alerts section with checkboxes and dropdowns.

    Associated Conditional Access Policy

    Name:

    CA600-PROD-AuthStr-DataProtection-Global-AuthContext-Any-Require re-auth for downloading data-v1.0.0


    Policy:

    json

    Diagram of a user flow for data protection policy. Shows user access to high privileged data with passwordless MFA and sign-in frequency.


  1. Downloading data from high sensitive app

    Staying compliant with regulations such as GDPR, the Privacy Act, or industry-specific requirements often means preventing sensitive data from being downloaded without additional verification.


    Reducing insider risk can be difficult, employees acting within their roles may still exfiltrate data, intentionally or not. By requiring step-up authentication before downloading from high-sensitivity systems (like Workday, HR-ON, Oracle, or Dynamics 365), we can make data extraction more difficult while keeping legitimate use smooth.


    Here we'll require strict requirements for downloading data from our HR System CoSHR Staff:

    Session policy setup screen showing options for policy name, severity, category, and control type. Dropdowns and text fields visible.
    Settings interface for security policies showing actions like Audit, Block, Protect. Highlights "Require step-up authentication" with email alerts.

    Associated Conditional Access Policy

    Name:

    CA600-PROD-PRMFA-DataProtection-Global-AuthContext-Any-Require PRMFA for downloading high sensitive data-v1.0.0


    Policy:

    json

    Diagram showing user access flow with multifactor authentication for high-privileged data. Includes grant and session controls.


  1. Uploading data from unmanaged devices / external users

    Working with external consultants and partners often involves two-way data sharing, which introduces additional risks such as supply chain attacks, malware uploads, or XSS injection.


    By using Authentication Contexts, we can require re-authentication and other requirements before uploads to critical areas, especially from unmanaged devices or external users, ensuring that only trusted, verified sessions can contribute data:

    Creating a session policy in a cloud app interface. Options for policy name, severity, and actions like file upload control are shown.
    Settings page for malware detection, showing options for actions like audit and block, with checkboxes, dropdowns, and alert preferences.

    Associated Conditional Access Policy

    Name:

    CA700-PROD-AuthStr-DataProtection-Guest-AuthContext-Any-Require re-authentication for data upload for external users-v1.0.0


    Policy:

    json

    Flowchart detailing Azure user access policy. Shows user inclusion, grant access, authentication context, and session controls.

  1. Printing & copying sensitive data

    Managing uploads and downloads goes a long way, but controlling print and copy actions helps close the loop on potential data leaks.


    Not every organization can block printing entirely (many still rely on physical copies), so consider this configuration carefully and test before wide deployment. Blocking or requiring re-authentication for these actions can significantly reduce data leakage risk while maintaining user productivity.

    Session policy creation screen showing options like policy name, severity, and category. Includes filters for devices and apps, and a warning message.
    Settings interface showing options for content inspection and actions like auditing, blocking, or requiring authentication. Checkbox selections visible.

    Associated Conditional Access Policy:

    Name:

    CA600-PROD-AuthStr-DataProtection-Global-AuthContext-Any-Require re-auth for printing and copying data-v1.0.0


    Policy:

    json

    Flowchart showing user access management, with text "Grant access" and "Authentication context". Includes actions like "Multifactor authentication" and "Sign-in frequency".


  1. Blocking sessions for specific apps prior to step-up authentication on unmanaged devices for HR department

    Unmanaged devices always pose a higher risk, and some applications—especially those handling HR or intellectual property—require stricter protection.


    In these cases, it’s better to block the session entirely until the user completes step-up authentication. This ensures sensitive HR data remains secure until trust is fully established.

    Form to create a session policy with fields for template, name, severity, and control type. Options set for blocking activities.
    Microsoft Entra settings screen with filters for device and app. Dropdown showing selected actions: Send, Print, Paste, Cut/Copy.
    Settings interface for user activity policy with options for audit, block, and step-up authentication. Alerts sent via email for policy events.
    Associated Conditional Access Policy:

    Name:

    CA900-PROD-AuthStr-DataProtection-HR-CoSHR Staff-Any-Require step-up & re-authentication for access to CoSHR Staff data-v1.0.0


    Policy:

    json

    Flowchart of user authentication process using Passwordless MFA for HR data access. Includes session controls, highlighting sign-in frequency.

MDCA Session Policy Step-up Authentication User Experience

Once configured, users will be prompted for the step-up authentication requirements when attempting any of the secured actions.


The exact experience varies slightly depending on the session type, and requirements, but the process is consistent:


  1. The user attempts a protected action (e.g., printing a sensitive document).

    The accompanying Conditional Access policy triggers, prompting for re-authentication.

    Security check pop-up with cloud icon. Text prompts for identity confirmation. Buttons: "OK, Proceed" in blue, "Close" in gray.

  2. The user completes the step-up requirement.

    Security window prompting a PIN for a security key with "Use a different passkey," "Cancel," and "Next" buttons. Microsoft login info.

  3. MDCA confirms successful completion of step-up authentication.

    Security check completed screen with blue cloud icon and check mark. Text invites to continue to Microsoft SharePoint Online.

  4. The user can proceed with the action (e.g., printing the document).

    Print dialog box with "Super Secret: I like apple pie" on a white page. Options include saving as PDF in portrait layout.


Microsoft SharePoint Sites

Requires License: Microsoft SharePoint Advanced Management license or Microsoft 365 CoPilot


Data storage in SharePoint is something nearly every organization in the Microsoft ecosystem relies on. Yet, I often hear the same concern - a lack of granular access controls. Many organizations still depend on broad, site-level permissions while trying to uphold Zero Trust principles.


This is where Sensitivity Labels and Authentication Contexts can make a major difference. By applying them, either directly on a site or through Sensitivity Labels, you gain fine-grained control over SharePoint data using Conditional Access.


Although the focus here is on Sensitivity Labels within SharePoint, the same approach applies across the entire Microsoft 365 estate—anywhere Authentication Contexts are supported, as covered back in Part 01 of this series.


These requirements can apply to both internal and external users, further strengthening your organization’s data protection posture.


Here are the scenarios covered in this segment:

  • Block access to SharePoint site from unmanaged devices

  • Require step-up authentication for access to sensitive site

  • Require TOU for external access to project site

  • Require compliant device, trusted location & re-authentication for confidential site



SharePoint Sites Authentication Context Known Limitations

While Authentication Contexts offer excellent control, there are a few known limitations when applied to SharePoint sites. These are documented on Microsoft Learn, but here’s a summarized list for quick reference:


  • Older version of Office apps

  • SharePoint mobile apps

  • Viva Engage

  • OneNote app can't be added to channel if the associated SharePoint site has an authentication context.

  • Teams channel meeting recording upload fails on sites with an authentication context.

  • SharePoint folder renaming in Teams fails if the site has an authentication context.

  • Teams webinar scheduling fails if OneDrive has an authentication context.

  • The OneDrive sync app won't sync sites with an authentication context.

  • Associating an authentication context to the enterprise application catalog site collection isn't supported.

  • The “Visualize SharePoint List in Power BI” feature doesn't currently support authentication context.

  • Outlook on Windows, Mac, Android, and iOS don't support communication with SharePoint sites protected by an Authentication Context.

  • The multiple-file download feature currently doesn't function when both the authentication context and 'Use Conditional Access App Control' in session control are enabled in the conditional access policy.

  • The file copy and move feature between different regions (cross-geo) currently doesn’t function when an authentication context is applied to the destination site.

  • Exporting to Excel as an Excel Web Query (IQY) doesn't currently support authentication context.



Configuring Authentication Context within Sensitivity Labels

Before we go through the examples, we need to ensure that our Sensitivity Label is configured with an Authentication Context requirement.


I covered this process in Part 01 of the mini-series, but here’s a quick refresher for completeness.


  1. Navigate to the Purview portal, select Solutions → Information Protection → Sensitivity labels.

    Click Create a label.

    Screenshot of Microsoft Purview Sensitivity Labels interface. No labels present. Prompt to create a label. Blue and white layout.

  1. Enter a Name, Display name, and Description → Next.

    Form fields for creating a new sensitivity label in Microsoft Purview. Options include name, display name, priority, descriptions, and label color.

  1. Select the Scope for the label → Next.

    Microsoft Purview interface for defining sensitivity label scope, listing options like files, emails, meetings, and groups, with checkboxes.

  1. Configure any additional protection settings you want applied with the label (or skip if not needed).

    Microsoft Purview screen titled "New sensitivity label." Options to choose protection settings include control access and apply content marking.

  2. On the External sharing and Conditional Access step → Next.

    (Optional) For enhanced security, you can also enable Privacy and external user access options.

    Microsoft Purview screen showing protection settings for groups and sites. Options include privacy, external sharing, and conditional access.

  3. Enable Use Microsoft Entra Conditional Access to protect labeled SharePoint sites.

    Select an existing Authentication Context from the dropdown → Next.

    Microsoft Purview screen showing sensitivity label settings for external sharing and conditional access. Dropdown menu with roles visible.

  1. Complete the wizard, then publish the label in a publish policy so it becomes available to users and admins.

    Microsoft Purview dashboard displaying a message: "Your sensitivity label was created." Includes steps, resources links, and a completion sidebar.


How to directly assign an Authentication Context to a SharePoint Site

As an alternative to using Sensitivity Labels, you can directly assign an Authentication Context to a SharePoint site.


This approach requires at least a SharePoint Advanced Management license and, at the time of writing, can only be done via PowerShell:

# Install SPO Module
Install-Module Microsoft.Online.SharePoint.PowerShell

# Import SPO Module
Import-Module Microsoft.Online.SharePoint.PowerShell

# Connect SPO
Connect-SPOService -Url "https://<org>-admin.sharepoint.com"

# Assign Authentication Context to SharePoint Site
Set-SPOSite -Identity https://<siteurl> `
 -ConditionalAccessPolicy AuthenticationContext `
 -AuthenticationContextName "Name of your authentication context"


Examples for Microsoft SharePoint


  1. Block access to SharePoint site from unmanaged devices

    This configuration reduces the risk of data extraction by enforcing managed-device access only. While this is typically a baseline Conditional Access policy for all SharePoint resources, using Authentication Contexts allows per-site targeting for more precise control.


    This policy is highly specific, so direct assignment is recommended.

    PowerShell commands are displayed in a black terminal. Warnings about unapproved verbs are shown in yellow. A SharePoint URL in green text.

    Associated Conditional Access Policy:

    Name:

    CA000-PROD-Block-DataProtection-Global-AuthContext-Any-Block access to Auth Context Sensitive Data from unmanaged devices-v1.0.0


    Policy:

    json

    Flowchart showing users blocked from accessing authentication context for sensitive data protection, with various access controls listed.

    If a user tries to access the site from an unmanaged or non-compliant device, they’ll be met with the following error message:

    Access denied message from Microsoft with text instructing to sign out or use a different account. Blue and black text on a white background.


  1. Require step-up authentication for access to sensitive site

    Requiring step-up authentication for certain sites adds a powerful layer of control and ensures only verified users can access sensitive data.


    This approach fits well for multiple sites across the environment, making Sensitivity Labels ideal for this deployment.

    Security label creation form for "Step-up Security" with fields for name, priority, user/admin descriptions. Color options displayed below.
    Settings panel for external sharing and conditional access in SharePoint. Options include conditional access and authentication context.

    Associated Conditional Access Policy:

    Name:

    CA600-PROD-AuthStr-DataProtection-Global-AuthContext-Any-Require Step-up authentication for SharePoint Access with Auth Context Step-up Authentication-v1.0.0


    Policy:

    json

    Flowchart of user authentication for SharePoint, displaying grant access with passwordless MFA. Includes session and grant controls.


  1. Require TOU for external access to project site

    Most organizations already require external users to accept Terms of Use (TOU) before accessing data. However, you can use Authentication Contexts to re-enforce or extend those requirements for specific project sites.


    This scenario is broad in nature and also suits Sensitivity Label deployment.

    Microsoft Purview screen showing settings for a new sensitivity label. Options include name, display name, label priority, and descriptions.
    Microsoft Purview screen showing sensitivity label settings. Options for external sharing and conditional access are checked. Blue and white interface.

    Associated Conditional Access Policy:

    Name:

    CA700-PROD-TOU-DataProtection-Guest-AuthContext-Any-Require TOU for guest users for SharePoint access via Auth Context External Data Access-v1.0.0


    Policy:

    json

    Diagram showing user access to SharePoint via Authentication context with grant access controls. Includes Azure AD users. Text: "External users Terms of Use."


  1. Require compliant device, trusted location & re-authentication for confidential site

    Some sites, like those handling corporate restructuring, new IPs, or confidential projects, demand the strictest access conditions.


    This policy enforces multiple layers of protection (PR-MFA, compliant device, and re-authentication) and is best suited for direct assignment due to its specificity.

    If you take away just one example from this post, make it this one!

    PowerShell script displays warnings and commands in a console window. Text includes URLs and settings related to SharePoint configuration.

    Associated Conditional Access Policy:

    Name:

    CA600-PROD-PRMFA+Compliant-DataProtection-Global-AuthContext-Any-Require PR-MFA, Compliant device and re-auth for confidential data access-v1.0.0


    Policy:

    json

    Flowchart showing a policy for granting access to users via compliant devices and MFA. Includes icons, conditions, and session controls.


SharePoint Sites: Sensitivity Labels or Direct Assignment?

While both methods ultimately deliver the same result, there are practical differences that can guide which to use.


  • Sensitivity Labels are ideal for broad, automated enforcement, but sync delays can slow down enforcement.

  • Direct Assignments offer immediate effect and greater flexibility, but require manual scripted deployment.


Here’s a quick comparison:

Aspect

Sensitivity Labels

Direct Assignment

Automation

Automatic via labeling

Manual or scripted

Speed of Enforcement

Slower due to label sync delay

Immediate

Licensing

E5 + Information Protection

E5, SAM or CoPilot for M365

Flexibility

Limited to label design

Fully admin-controlled

Recommended use

Broad enforcement with consistent requirements

Rapid enforcements or edge cases


Conclusion

Today, we explored how Authentication Contexts can be leveraged for advanced data protection, from enforcing session controls in Microsoft Defender for Cloud Apps to applying Sensitivity Labels and even direct assignments on SharePoint sites.


These examples demonstrate that Authentication Contexts aren’t just an access control feature - they’re a key part of a broader data protection strategy. When used together, Conditional Access, MDCA session policies, and SharePoint Authentication Contexts create a layered defense that maintains both security and usability.


Whether you’re controlling downloads on unmanaged devices, requiring re-authentication for sensitive sites, or applying stricter requirements for HR data, the goal remains the same: security where it matters most, flexibility where it’s safe to allow it.


Now the most important and dearly missed part, the bad joke section:


My pants kept falling down, so I made a belt out of Ethernet cables...

It was a waist of bandwidth! 😎


And remember... with great context comes great responsibility.


Now is a good time to start exploring where you can apply these advanced Authentication Contexts in your own environment, and to review existing Conditional Access policies for opportunities to tighten protection without compromising user experience.


Up next

In the final part of this mini-series, I’ll walk through how to track, and report on Authentication Context usage across your environment.


Until then, stay secure, stay curious, and make your contexts count.



🔗 Authentication Context Series Index

Part 3: Advanced Data Security (You're here!)

bottom of page