Authentication Context and Protected Actions

Authentication Context and Protected Actions in Microsoft Entra ID

Understanding Authentication Context and Protected Actions

Authentication Context and Protected Actions are advanced features in Microsoft Entra ID (formerly Azure AD) that allow organizations to enforce granular Conditional Access policies on specific resources, actions, and scenarios beyond the traditional application-level enforcement. These features are critical topics for the SC-300 (Microsoft Identity and Access Administrator) exam.

Why Are Authentication Context and Protected Actions Important?

In modern identity and access management, simply requiring multi-factor authentication (MFA) at sign-in is often not sufficient. Organizations need the ability to:

- Enforce step-up authentication when users attempt to access highly sensitive data or perform critical administrative actions
- Apply different levels of security based on the sensitivity of specific resources within the same application
- Protect privileged administrative operations (such as modifying Conditional Access policies) with additional authentication requirements
- Meet regulatory and compliance requirements that demand stronger authentication for certain types of data or actions
- Implement a Zero Trust security model with fine-grained access controls

Without these features, organizations are limited to applying Conditional Access policies at the application level, which does not account for varying sensitivity levels within a single application.

What Is Authentication Context?

Authentication Context is a feature that allows you to create custom classification tags (up to 25) that can be assigned to resources and then targeted by Conditional Access policies. These tags act as a bridge between your resources and your Conditional Access policies, enabling fine-grained, resource-level conditional access enforcement.

Authentication Contexts are identified by values labeled C1 through C25 in Microsoft Entra ID. You can define custom names and descriptions for each, such as:

- C1: "Sensitive Data Access"
- C2: "Highly Privileged Actions"
- C3: "Compliance-Critical Resources"

Authentication Context can be used with:

- Microsoft Information Protection sensitivity labels – Protect classified documents in SharePoint Online by requiring step-up authentication when accessing files labeled as "Highly Confidential"
- Custom applications – Developers can integrate authentication context into their applications using the Microsoft Authentication Library (MSAL) and the claims challenge capability
- Conditional Access policies – Targeted as an assignment condition under Cloud apps or actions > Authentication context

How Authentication Context Works

1. Define Authentication Contexts: An administrator creates authentication context definitions in Microsoft Entra ID > Protection > Conditional Access > Authentication context. Each context is given a meaningful name and description and is published for use.

2. Create Conditional Access Policies: The administrator creates Conditional Access policies that target specific authentication contexts. For example, a policy might require MFA, a compliant device, and a specific named location when Authentication Context C1 ("Sensitive Data Access") is triggered.

3. Assign Authentication Context to Resources: The authentication context is then associated with specific resources. For example:
- A SharePoint Online site is configured to require Authentication Context C1
- A sensitivity label in Microsoft Purview Information Protection is linked to Authentication Context C1
- A custom application issues a claims challenge requesting Authentication Context C1 for specific operations

4. User Accesses the Resource: When a user attempts to access a resource that is tagged with an authentication context, the application signals Microsoft Entra ID that the specific authentication context is required.

5. Conditional Access Evaluation: Microsoft Entra ID evaluates the Conditional Access policies associated with that authentication context. If the user's current session does not meet the policy requirements, they are prompted to satisfy the additional conditions (e.g., perform step-up MFA, switch to a compliant device).

6. Access Granted or Denied: If the user meets the requirements, access is granted. If not, access is denied.

What Are Protected Actions?

Protected Actions is a feature that allows organizations to apply Conditional Access policies to specific high-privilege administrative operations within Microsoft Entra ID itself. Rather than protecting external resources, Protected Actions protects built-in administrative actions such as:

- Modifying Conditional Access policies (creating, updating, deleting)
- Modifying cross-tenant access settings
- Modifying tenant-wide security settings
- Deleting a tenant
- Updating authentication methods policies

Protected Actions uses authentication context as the underlying mechanism. You map specific Microsoft Entra permissions (defined by their action strings, such as microsoft.directory/conditionalAccessPolicies/delete) to an authentication context, and then a Conditional Access policy targeting that authentication context enforces additional requirements.

How Protected Actions Works

1. Define an Authentication Context: Create an authentication context (e.g., C2: "Protected Admin Actions") in the Conditional Access settings.

2. Create a Conditional Access Policy: Create a policy targeting Authentication Context C2 that requires, for example, phishing-resistant MFA and a compliant device from a trusted location.

3. Map Permissions to Authentication Context: Navigate to Microsoft Entra ID > Roles and administrators > Protected actions. Here, you map specific permissions (e.g., microsoft.directory/conditionalAccessPolicies/delete) to the authentication context C2.

4. Admin Attempts a Protected Action: When a Global Administrator or Conditional Access Administrator attempts to delete a Conditional Access policy, Microsoft Entra ID detects that this permission is mapped to a protected action.

5. Step-Up Authentication: The administrator is prompted to satisfy the Conditional Access policy associated with the authentication context (e.g., perform phishing-resistant MFA).

6. Action Allowed or Blocked: If the administrator satisfies the requirements, the action proceeds. Otherwise, it is blocked.

Key Differences Between Authentication Context and Protected Actions

- Authentication Context is the foundational mechanism — it is a classification tag that can be targeted by Conditional Access policies
- Protected Actions is a specific use case of authentication context applied to Microsoft Entra built-in administrative permissions
- Authentication Context can be used with SharePoint sites, sensitivity labels, custom applications, and Protected Actions
- Protected Actions specifically targets role-based permissions within Microsoft Entra ID

Prerequisites and Requirements

- Licensing: Microsoft Entra ID P1 is required for Conditional Access. Some features like authentication context with sensitivity labels may require Microsoft Entra ID P2 or Microsoft 365 E5.
- Roles: Conditional Access Administrator or Security Administrator role is needed to manage authentication contexts and Conditional Access policies. Global Administrator or Privileged Role Administrator is needed to configure Protected Actions.
- Supported Resources: Authentication context is supported with SharePoint Online, Microsoft Defender for Cloud Apps, custom applications using MSAL, and Protected Actions. Not all services support authentication context natively.
- Application Support: Custom applications must implement the claims challenge pattern to support authentication context.

Configuration Steps Summary

For Authentication Context with SharePoint:
1. Create authentication context in Entra ID
2. Create a Conditional Access policy targeting the authentication context
3. In SharePoint admin center, assign the authentication context to a specific site
4. Users accessing the site will be subject to the Conditional Access policy

For Protected Actions:
1. Create authentication context in Entra ID
2. Create a Conditional Access policy targeting the authentication context
3. Navigate to Protected actions and map specific permissions to the authentication context
4. Administrators performing those actions will be subject to the policy

Common Scenarios for Exam Questions

- Requiring step-up MFA when accessing a SharePoint site containing highly confidential documents
- Requiring phishing-resistant authentication before an admin can modify Conditional Access policies
- Using authentication context with Microsoft Purview sensitivity labels to enforce access controls on classified documents
- Protecting tenant deletion with additional authentication requirements
- Integrating authentication context in custom line-of-business applications

---

Exam Tips: Answering Questions on Authentication Context and Protected Actions

1. Know the relationship: Protected Actions is built ON TOP of Authentication Context. Questions may try to confuse you — remember that you always need an authentication context AND a Conditional Access policy before you can configure Protected Actions.

2. Understand the configuration order: The correct order is always: (1) Create authentication context → (2) Create Conditional Access policy targeting the context → (3) Assign the context to resources or map it to protected actions. If a question presents these steps out of order, identify the correct sequence.

3. Remember C1-C25: Authentication contexts are identified as C1 through C25. You can create a maximum of 25 authentication contexts.

4. Protected Actions protects Entra ID admin operations, not applications: If a question asks about protecting access to a SharePoint site, the answer involves authentication context assigned to the site. If it asks about protecting the act of deleting a Conditional Access policy, the answer involves Protected Actions.

5. Licensing matters: Authentication Context and Conditional Access require at least Microsoft Entra ID P1. Be wary of answer choices that suggest these features work with free-tier Entra ID.

6. Claims challenge for custom apps: If a question mentions a custom application needing to enforce authentication context, the answer likely involves implementing a claims challenge using MSAL. The application must be able to handle the claims challenge response from Microsoft Entra ID.

7. SharePoint is a key integration point: SharePoint Online is one of the most commonly tested integrations for authentication context. Remember that you assign authentication context at the site level in SharePoint, not at the document or library level (sensitivity labels handle document-level protection).

8. Differentiate from session controls: Authentication context is NOT the same as Conditional Access session controls (like app-enforced restrictions or MCAS integration). Questions may present both as options — authentication context enforces step-up authentication requirements, while session controls limit what users can do within a session.

9. Watch for "least privilege" scenarios: If asked who can configure Protected Actions, remember that this requires elevated privileges (Global Administrator or Privileged Role Administrator). Conditional Access Administrators can manage authentication contexts and CA policies but may not have permission to map permissions to Protected Actions without additional roles.

10. Phishing-resistant MFA: Protected Actions scenarios in exam questions often pair with phishing-resistant MFA methods (FIDO2 security keys, Windows Hello for Business, certificate-based authentication). If a question describes protecting critical admin actions, look for answer choices that include phishing-resistant authentication strength.

11. Know what cannot be protected: Not all administrative actions can be mapped to Protected Actions. The feature covers specific, supported permission strings. If a question asks about protecting an action that is not within the supported set, that may be a distractor.

12. Read carefully for "existing session" scenarios: Authentication context enables step-up authentication even when a user already has an active session. This is a key differentiator — the user might have already signed in with MFA, but accessing a resource with a higher authentication context requirement can trigger additional authentication prompts.