2.2.3. Authentication Context and Protected Actions

💡 First Principle: Not all actions inside one app carry equal risk, and not all admin operations deserve the same bar. Authentication context and protected actions let you attach step-up requirements to moments — a specific SharePoint site, a specific admin operation — rather than to whole applications.

Authentication context is a taggable label (c1–c99, given friendly names like "Highly confidential") that resources raise when something sensitive is touched. You create the context in CA, build a CA policy targeting it (e.g., require phishing-resistant strength + terms of use), then bind it to resources: sensitivity labels applying to SharePoint sites, Defender for Cloud Apps session policies, PIM role activation settings, or your own apps via the acrs claim. The user may already be signed in, but touching the tagged resource triggers re-evaluation against the stricter policy — step-up in place.

Protected actions apply the same idea to directory operations: high-blast-radius permissions (create/modify CA policies themselves, manage cross-tenant access settings, custom rules for network locations) can be bound to an authentication context, so even a legitimately-assigned admin must satisfy the step-up (say, passkey MFA) at the moment of the dangerous action. This closes the "compromised admin session" gap: a stolen session cookie can browse, but performing the protected action demands fresh, strong proof.

The pairing question the exam asks: which is it? Resource-touch step-up (a site, a session, a role activation) = authentication context by itself; specific Entra admin operation step-up = protected actions (which use an authentication context under the hood).

⚠️ Exam Trap: Authentication context does nothing until both halves exist — a CA policy targeting the context and a resource binding that raises it. A context with a policy but no binding (or vice versa) silently enforces nothing.

Reflection Question: Your CA policies are the crown jewels — an attacker who edits them owns the tenant. Design the protected-actions configuration that makes editing them require a passkey, and explain what a cookie-stealing attacker can and cannot do afterward.