6.1 Authentication Methods Portfolio

Why authentication methods sit at the center of SC-300

Domain 2 of the Microsoft Identity and Access Administrator Associate exam (SC-300)—Implement authentication and access management—is the heaviest weighted area (about 25–30%). Before you write Conditional Access policies that require multifactor authentication (MFA) or passwordless grants, you must know which methods exist, how strong they are, how users register them, and which admin policy enables them.

Microsoft Entra ID (formerly Azure Active Directory) authenticates people and, with other features, workloads. This section is about human authentication methods: passwords, Microsoft Authenticator, Temporary Access Pass (TAP), certificate-based authentication (CBA), FIDO2 passkeys, software/hardware OATH, SMS/voice where still used, and related planning concepts. Passwordless device credentials such as Windows Hello for Business appear again in section 6.3; here you need them as part of the strength ladder.

/practice/azure-sc-300Practice questions with detailed explanations

Plan authentication for the organization

SC-300 planning questions rarely say “enable every method.” They describe a risk posture and ask for the right method mix.

Zero Trust assumes breach and verifies explicitly. Authentication planning is how you raise the cost of credential theft: stolen passwords alone should not open corporate apps; phishing of SMS codes should not open Tier-0 admin portals.

Recommended enterprise pattern for SC-300 design answers:

1. Disable or tightly limit weak methods (SMS/voice) for admins and sensitive apps when stronger methods are available.
2. Enable Microsoft Authenticator (including passwordless phone sign-in where appropriate) for the broad workforce.
3. Enable FIDO2/passkeys and/or CBA (and Windows Hello for Business on managed Windows) for phishing-resistant coverage.
4. Use TAP for onboarding and recovery so users can register passwordless methods without sharing long-lived passwords.
5. Drive registration with combined registration and registration campaigns before enforcing Conditional Access.

Authentication methods policy (modern control plane)

In the Microsoft Entra admin center, Protection > Authentication methods > Policies (wording may appear as Authentication methods policy) is the modern place to enable methods, set targets (all users or selected groups), and configure method-specific options.

Exam distinction: older per-user MFA and some legacy MFA service settings still appear in documentation and migration stories, but new designs use authentication methods policy + Conditional Access (and Security defaults only as a simple baseline—section 6.2). If a scenario says “enable FIDO2 for the finance group only,” answer with the authentication methods policy targeting that group—not a random Azure RBAC role on a subscription.

Method-specific configuration matters. Examples:

• Authenticator — number matching and additional context reduce MFA fatigue/push-bombing risk.
• FIDO2 — enforce attestation or restrict AAGUIDs when only approved keys are allowed.
• TAP — maximum lifetime, length, and whether one-time use is required.
• CBA — which CAs are trusted, username binding (for example PrincipalName / RFC822), and affinity binding rules.

Certificate-based authentication (CBA)

Certificate-based authentication lets users sign in with an X.509 certificate—commonly on a smart card, PIV/CAC, or provisioned device certificate—instead of (or in addition to) passwords. Microsoft Entra CBA is a cloud authentication path that validates the certificate against configured trusted certificate authorities in Entra.

SC-300 depth:

• CBA is a strong, often phishing-resistant method when certificates are bound to hardware and private keys are non-exportable.
• You upload or configure certificate authorities and define username bindings so the cert maps to the correct Entra user.
• CBA is popular in government, regulated, and smart-card-heavy enterprises; it also appears when organizations move away from AD FS federated cert auth toward cloud authentication.
• CBA is not the same as “upload a client cert to an App Service.” The exam means user sign-in to Entra with CBA policy.

Temporary Access Pass (TAP)

A Temporary Access Pass is a time-limited passcode that an admin (or automated process with rights) issues so a user can sign in and complete authentication method registration, recover access, or bootstrap passwordless without knowing a permanent password.

Classic exam stories:

• Joiner starts Monday, no phone enrolled → issue TAP → user registers Microsoft Authenticator and FIDO2 → TAP expires.
• Lost phone → helpdesk issues TAP after identity proofing → user re-registers methods.
• Passwordless-only workforce → TAP is the bridge because there is no password to reset in the classic sense.

Do not choose TAP as the standing second factor for executives; choose phishing-resistant registered methods.

OAuth 2.0 token awareness (identity admin view)

SC-300 is not a deep OAuth developer exam, but identity admins must understand what gets issued after successful authentication and why revocation (section 6.3) matters.

Primary refresh tokens and session artifacts are why “disable the account” alone is incomplete if a refresh token is still valid for some resources until revocation/CAE evaluates. You will connect this to Revoke sessions and Continuous Access Evaluation in later Conditional Access content; for this section, remember: successful auth produces tokens, and method strength reduces how easily an attacker obtains them.

App registrations and API permissions (Domain 3) consume these tokens; here, focus on user proof-of-possession of a method strong enough for the resource.

Microsoft Authenticator

Microsoft Authenticator is the default modern phone-based method for Microsoft 365 and Entra:

• Notification (push) — approve a sign-in prompt (prefer number matching).
• OATH TOTP codes — six-digit rotating codes if push is unavailable.
• Passwordless phone sign-in — use the phone as a primary credential (device registration + Authenticator), reducing password use.

Admin tasks for SC-300:

• Enable Authenticator in the authentication methods policy.
• Configure passwordless phone sign-in where the organization wants phone-as-credential.
• Understand that Authenticator registration is a prerequisite for many MFA Conditional Access grants.
• Prefer Authenticator over SMS for security and reliability; SMS is SIM-swap and interception prone.

Authenticator is strong MFA, but push MFA can still be phished or push-bombed in weaker configurations. Phishing-resistant methods (FIDO2, CBA, Windows Hello for Business in appropriate modes) sit higher on the strength ladder for privileged access.

Passkeys (FIDO2)

FIDO2 security keys and passkeys provide public-key credentials bound to an authenticator (hardware key, TPM-backed platform authenticator, or synced passkey ecosystems depending on platform support and policy).

Why exams love FIDO2/passkeys:

• Phishing resistant — credentials are origin-bound; fake sites cannot complete the ceremony the same way stolen passwords or OTP codes can.
• Works well for shared workstation constraints when personal phones are banned (hardware keys).
• Complements passwordless strategies with TAP for bootstrap.

Configure via authentication methods policy: enable passkey (FIDO2) authentication, set enforcement options (for example attestation, enforce specific authenticators), and target groups (pilots first, then broad).

Method strength and registration concepts

Method strength (and related Conditional Access grant options such as requiring phishing-resistant MFA or authentication strength policies) lets you express “not just any MFA.” On SC-300, when a stem says regulators require phishing-resistant authentication for admins, do not answer “SMS to Global Administrators.” Answer FIDO2, CBA, or Windows Hello for Business (as appropriate) enforced via Conditional Access authentication strengths / grant controls after methods are enabled and registered.

Registration is the operational bottleneck:

1. Admin enables methods in policy.
2. User (or admin) registers security info—often at https://aka.ms/mysecurityinfo or during combined registration.
3. Conditional Access or Security defaults require the method at sign-in.
4. Without step 2, step 3 locks users out—hence TAP, registration campaigns, and staged enforcement (report-only → pilot groups → all users).

Combined registration experiences let users set SSPR and MFA methods in one flow, reducing helpdesk tickets. MFA registration campaigns (often discussed with Identity Protection) nudge users who have not registered.

Putting the portfolio together

For any SC-300 authentication scenario, walk this path:

1. Identify user population and risk (privileged? external? frontline?).
2. Choose methods that meet strength requirements and device reality.
3. Enable them in the authentication methods policy with correct targeting.
4. Plan TAP and helpdesk identity-proofing for bootstrap/recovery.
5. Drive registration before hard enforcement.
6. Enforce with Conditional Access (prefer over Security defaults for granular modern designs—section 6.2).
7. Remember tokens: strong auth reduces theft; session revocation handles residual sessions (section 6.3).

/study-guides/azure-sc-300Free exam prep with practice questions & AI tutor