← SC-300: identity, access, and operations
09 / 11 · 40 MIN

Authentication, actions, and traffic

Distinguish methods, privileged-action requirements, and traffic acquisition.

Method, protocol, and recovery

OATH and OAuth are not interchangeable names. OATH tokens generate authentication codes; OAuth 2.0 concerns authorization using resource tokens. During planning, use the official methods matrix to distinguish sign-in, MFA, and SSPR. In a fictional case, a team equips operators with passkeys and assumes password recovery is also solved. Separately check permitted and registered SSPR methods. A suitable sign-in credential may not support that flow. Acceptance planning should include device loss and recovery using test identities, with evidence for each path.

Certificates and authentication strength

Microsoft Entra CBA can authenticate directly with X.509 certificates without retaining AD FS solely for that mechanism. However, single-factor or MFA classification depends on authentication binding policies, including issuer or policy OID. In a fictional pilot, a certificate allows sign-in but an application requires phishing-resistant MFA strength. Inspect the policy, presented certificate, and effective requirements. Do not conclude every certificate meets the same strength. The organization must still operate its PKI, issuance, renewal, and revocation processes and include them in support handover.

Protect an administrative operation

Protected actions associate supported permissions with an authentication context used by Conditional Access. Configure the context and applicable policy in On state first; then associate the action. Report-only is not the required enforcement configuration and can produce repeated requests. In a fictional exercise, protect a selected administrative operation and test with an included user. A missing new prompt can mean the session already satisfies requirements. Inspect events and policy evaluation before declaring failure, retaining an operational recovery path throughout the change.

Microsoft traffic profile and bypass

Global Secure Access separates Microsoft, Internet, and private-resource traffic profiles. For traffic eligible for the Microsoft traffic profile, a Bypass rule does not automatically send the flow through Internet Access: the client uses its normal network path. In a fictional remote-support pilot, Exchange matches a Bypass rule although Internet Access is enabled. Check rules and observed routing before promising inspection. Define pilot users, expected impact, diagnostics, and rollback. An enabled profile does not establish acquisition of every device flow.

IN PRACTICE

An administrative change repeats authentication requests; its context points to a Report-only policy. Validate configuration order in a pilot.

Common pitfalls

OAuth as OATH; every certificate as MFA; prompts as the only evidence; Internet Access as a universal fallback.

Related topics: Tenant, scope, and objects · Hybrid identity and partners · Methods and emergency access

Take this idea with you

Confirm the method, effective policy, and observed path.

Create account

Reference: Configure protected actions · SC-300 objectives effective 2026-04-27; product documentation reviewed 2026-10-01; 2026-10-28 English update compared separately