Conditional Access Essentials: Authentication contexts + Secure PIM & Resource Access
- welka2111
- 1 day ago
- 8 min read
Updated: 12 minutes ago
Introduction
This article is part of my Conditional Access Essentials series, where we take a closer look at advanced security controls in Microsoft Entra. Today’s focus is on three important capabilities: authentication contexts, Privileged Identity Management (PIM), and sensitive resource protection. Together, they let you go beyond broad rules and enforce security where it matters most: on elevated permissions and high-value assets.
Along the way, I’ll share practical examples, common pitfalls, and lessons learned from real-world implementations so you can deploy these features with confidence.
Table of contents
Conditional Access Essentials
Here we’ll explore how authentication contexts integrate with Privileged Identity Management (PIM) and sensitive resource assignments. By linking Conditional Access policies directly to elevated roles and specific assets, you can enforce just-in-time controls, add mandatory checks, and reduce unnecessary exposure. This isn’t about blanket restrictions, it’s about precision security, tailored to the way people actually use your environment.
Authentication contexts
What are authentication contexts?
Authentication contexts are a way to enforce extra security checks when users access certain resources or perform sensitive actions. Think of them as step-up authentication: your app may allow general access under normal Conditional Access policies, but sensitive areas (like a confidential SharePoint site) can require stricter checks.
Each context is defined by an ID, name, and description. Administrators assign them to supported apps. Conditional Access policies then define what authentication controls (e.g., MFA type, device compliance) must be satisfied when accessing resources protected by that context.
For example, a SharePoint site with an authentication context called “FIDO2” can require users to authenticate using FIDO2 key before they get access to SharePoint files.
Authentication contexts don’t define requirements themselves, they connect Conditional Access policies to specific resources.
Why this matters for Conditional access?
Authentication contexts let you enforce granular, scenario-specific policies. You can:
Protect particularly sensitive SharePoint sites
Require step-up authentication for critical actions in apps like Defender for Cloud Apps
Control access to Privileged Identity Management (PIM) activation for privileged roles
Apply additional policies for third-party apps that support claims challenges
In short, they allow you to adapt access controls depending on the sensitivity of the resource without affecting general access to the app.
Real-life authentication contexts examples
SharePoint site with sensitive documents: require guests to agree to terms of use before accessing the site.
SharePoint site that only the HR team can access from a compliant device.
PIM activation: enforce reauthentication with FIDO2 every time an admin elevates their privileges.
Defender for Cloud Apps: require step-up MFA for risky actions such as file downloads.
Gotchas and limitations of authentication contexts
Not all apps support authentication contexts. Known limitations include:
Older Office apps, SharePoint mobile apps, Viva Engage
Teams channel uploads and private site provisioning issues
OneDrive sync, Power Automate/Power Apps workflows, and cross-geo file moves
Certain Excel Web Queries, Power BI visualisations, and root SharePoint sites
Always test authentication contexts in a lab environment before wide deployment. Ensure your users and apps are compatible, and document any exceptions.
Note: Shoutout to Erica Zelic on X (@IAMERICAbooted) for pointing out that "if you are federated, authentication contexts will depend on the primary IdP (Identity Provider) and to enforce FIDO2 and WHfB (Windows Hello for Business) with authentication contexts requires a native authentication in Entra. Your primary IdP does support authentication contexts but only if device assurance telemetry is setup."
Thanks for the insights Erica! And if you're not already following her, go do it - she's amazing!, please go and follow her as she is amazing!
***
Conditional access + authentication contexts + PIM
What is Privileged Identity Management?
Privileged accounts have broad access to critical resources, making them high-value targets for attackers. Entra ID Privileged Identity Management (PIM) helps manage these accounts safely, reducing the risk of misuse or unauthorized access.
PIM achieves this by providing just-in-time access and access reviews for privileged roles. This means administrators can control who gets access, for how long, and under what conditions. You can use PIM to manage Entra ID roles, Azure resource roles, or privileged groups, depending on your organisational needs. A Microsoft Entra ID Premium P2 licence is required to use PIM.
PIM primarily protects roles. If you need task-level protection, you can combine PIM with Privileged Access Management in Microsoft 365 to safeguard your most critical resources.
Combining conditional access authentication context with PIM
With the integration options between PIM and authentication context, organisations can now create a robust security framework for privileged roles:
When a user requests access to a privileged role, the assigned authentication context ensures they meet all required security conditions.
This allows organisations to monitor and audit role activations, providing insights into potential risks and compliance issues.
Important: You need Global Administrator permissions and an Entra ID Premium P2 licence to configure authentication contexts in PIM.
Important note about PIM MFA authentication requirement
By default, PIM uses the out-of-the-box Azure MFA activation requirement.
This means that if a user, Adele, signs into the Entra portal and is prompted for MFA (for example, through a push notification via the Microsoft Authenticator app), and then goes to activate a Global Admin role she is eligible for via Privileged Identity Management (PIM), the system will treat her initial authentication as having already satisfied the MFA requirement. As a result, she will not be asked to complete MFA again and will become a Global Admin without an additional authentication step.
The implication is that if Adele is very unlucky and an attacker manages to steal her token after it has already satisfied MFA, they could activate a role without being prompted again. This would compromise her account, and since they could easily activate Global Admin permissions, you can imagine the potential damage to the entire environment.
To defend against this:
Use an authentication context requiring reauthentication for PIM activation
Apply a Conditional Access policy with “every time” sign-in frequency
Include strong MFA and device compliance, ideally phishing-resistant methods
This ensures that even previously satisfied MFA claims cannot bypass your security controls.
Setting up conditional access authentication context for PIM
Continuing with the example of my user Adele, I now want to ensure that anyone activating the Global Admin role is always prompted to authenticate with a FIDO2 key.
Let's go through the process:
Create an authentication context in Entra ID:
Go to Entra ID > Conditional Access > Authentication Context
Click + New Authentication Context
Enter a name, description, and check Publish to apps
Click Save I'm calling mine "PIM activation - FIDO2"
Create a conditional access policy for that context:
Go to Entra ID > Security > Conditional Access > New Policy
Name the policy and scope it to eligible users for the role In my example, I’m naming the policy: 100-Admins-AuthContext-FIDO2-SIFEveryTime-PIM_Activation
Here’s the breakdown of the naming convention:
100 - reference number
Admins - the persona
AuthContext - indicates this policy uses an authentication context
FIDO2-SIFEveryTime - specifies the authentication method (FIDO2) and that Sign-in Frequency is set to “Every Time”
PIM_Activation - clarifies that this policy applies specifically to PIM role activation
This way, I can immediately see what the policy applies to and what it does.
Under Target resources, select Authentication Context and choose the context created earlier
Under Grant, select Require authentication strength > Phishing-resistant MFA, or in my case I have a custom authentication strength called "FIDO2 (Yubikey)" (you'll know from my previous post how to set up authentication strengths https://www.welkasworld.com/post/conditional-access-essentials-rmaus-named-locations-authentication-strengths-service-principals#viewer-zolgq4440)
Enable Session > Sign-in frequency > Every time for elevated roles
Set the policy status to On and click Create
Note: Do not scope a policy to both authentication context and a directory role during activation, as the user does not yet hold the role.
Tagging authentication context in PIM role settings
You can now require an authentication context when activating a role in Entra PIM:
Sign into Entra ID > PIM > Microsoft Entra Roles > Roles
Select the role to configure (e.g., Global Admin) and click Edit Role Settings
Under Activation, instead of having the "Azure MFA" option selected, choose Microsoft Entra Conditional Access authentication context option instead
Choose the relevant authentication context from the dropdown, in my case it is the "PIM activation - FIDO2" one.
(Optionally) modify approvers/ assignment/ notification options if needed.
Click Update
Real-time PIM reauthentication testing
To test the configuration:
Go to Entra ID > PIM > My Roles
Select a role and click Activate
You will see a prompt:
“A conditional access policy is enabled and may require additional verification. Click to continue.”
At this stage you will be asked to authenticate using the MFA method specified in your conditional access policy.
If a user does not already have a FIDO2 key registered to their admin account, they will not be able to sign in. Make sure the user is capable of using the MFA method you specify within your Conditional Access policy. This setup ensures every privileged elevation is validated and complies with your organisation’s security policies.
***
Conditional access + authentication contexts + sensitive resources
Assigning an authentication context to a SharePoint site
Let’s say I have a very sensitive SharePoint site and want to apply specific access requirements to it. The most common ones I’ve come across or implemented for various customers include:
Only allowing specific people to access the site (site permissions can handle this, but for a defense-in-depth approach you may want an additional security layer).
Sign-in every time.
Require a compliant device.
Require acceptance of Terms of Use.
Require phishing-resistant MFA.
You can enforce Conditional Access policies either via sensitivity labels or by directly applying an authentication context to a site. In this post, I’ll show you the latter. License Requirements
Microsoft 365 E5/A5/G5, or
SharePoint Advanced Management licenses
Steps:
For demonstration purposes, I’ll show you how to require both phishing-resistant authentication and a compliant device to access a specific SharePoint site. If you’d like me to cover other scenarios for applying authentication contexts, drop me a comment or DM - I’d be happy to blog about them if there’s interest.
Add an Authentication Context in Microsoft Entra ID
Go to Entra ID > Conditional Access > Authentication Context > New authentication context
Add a name, description, check Publish to apps, then Save.
This process is the same as in the earlier scenario.
For this example, I already have an authentication context named “Sensitive SharePoint location”.
Create a Conditional Access policy targeting that context
Include users/groups, target authentication context, define controls (e.g., compliant device + phish-resistant MFA) In my case, here's the set up - Name: 020-Global-AuthContext-SensitiveSPOsite-CompliantDevice+PhishResistantMFA - Users: All users included, Emergency Access persona excluded - Target resources: Authentication context - Sensitive SharePoint location
- Grant controls: Grant access:
Require authentication strength: 'Phishing-resistant MFA'
Require device to be marked as compliant
For multiple controls: Require all the selected controls (this is key so both are enforced)
Apply the context to sites:
You can apply the context either:
Via a sensitivity label (I’ll cover this in a future post), or
Directly with PowerShell
First, connect to the SharePoint Online PowerShell module and replace the url parameter with the URL for your tenant:
Then apply the authentication context to a specific SharePoint site:
In my case, I wanted to apply the 'Sensitive SharePoint location' authentication context to a SharePoint site called 'HR', here's how I did it via PowerShell:
Optional: you can additionally block background apps accessing that site
Third-party apps may require claims challenge handling. Always test app compatibility before deployment.
Now, when I try to access my HR site, I must log in from a compliant device and use phishing-resistant MFA. If I fail to meet either requirement, access will be denied, and I’ll receive the standard Conditional Access authorisation failure notification, as shown in the example below:
Conclusion
Authentication contexts let you add fine-grained control over sensitive resources and admin operations. Combined with Conditional Access and PIM, you can:
Protect privileged accounts with enforced reauthentication
Require step-up MFA for sensitive SharePoint sites
Tailor security policies to resource sensitivity and user persona
If you’d like me to cover authentication contexts with sensitivity labels or other Conditional Access essentials, let me know in the comments.
Stay tuned for more content!