Domain 2 of 4 · Chapter 1 of 4

Authentication Methods

The strength ladder and the policy that governs it

Picture two users signing in: one taps a hardware security key, the other types a code texted to their phone. Both completed multifactor authentication, but only the first survives a remote phishing attack, and that single distinction is the spine of this whole topic. Microsoft ranks every credential by phishing resistance, and the exam keeps asking you to pick from the top of that ranking.

A method is phishing-resistant when the credential is cryptographically bound to the user's device and cannot be replayed by an attacker who tricked the user out of a password or one-time code. Microsoft Entra ID's phishing-resistant tier is a fixed list: Windows Hello for Business, passkeys (FIDO2 security keys and synced passkeys), passkeys in Microsoft Authenticator, Platform Credential for macOS, and certificate-based authentication (CBA)[1]. Below them sit the strong-but-phishable methods (Microsoft Authenticator push and passwordless phone sign-in), and at the bottom the weakest accepted factors (SMS, voice call, and OATH one-time codes). A password alone is not a second factor at all.

One policy decides who registers what

Every method above is enabled, disabled, and scoped in one place: the Authentication methods policy in Microsoft Entra ID. For each method you toggle it on and target specific users or groups, so you can let your administrators register passkeys while the wider population still onboards with the Authenticator app. This policy is the modern successor to two older controls you should recognize and plan to retire:

  • Legacy per-user MFA (the old per-account Enabled / Enforced / Disabled state) predates Conditional Access and should not be how you require MFA today.
  • Security Defaults is a free, tenant-wide on/off baseline that forces all users to register and use MFA. It is all-or-nothing: no per-group scoping, no per-app conditions. The moment you need that granularity you turn Security Defaults off and use the Authentication methods policy together with Conditional Access.

The planning order follows from this. Decide which strong methods each population registers in the Authentication methods policy first; then write Conditional Access to require MFA, or specifically require phishing-resistant strength, at the sign-ins that matter. The policy provisions the credentials; Conditional Access enforces when they must be used. Keeping those two jobs separate is what lets you, for example, allow Authenticator everywhere but demand a FIDO2 key only for admin actions.

Authentication method strength (most secure on top) Phishing-resistant Windows Hello for Business, passkey (FIDO2), Platform Credential (macOS), certificate-based auth Strong but phishable Microsoft Authenticator push / passwordless sign-in Weakest accepted factors SMS, voice call, OATH one-time codes Temporary Access Pass bootstraps the top tier; it is time-limited, not a permanent credential
Entra ranks methods by phishing resistance; choose from the top tier when a scenario asks for the most secure sign-in.

Bootstrapping passwordless: TAP, passkeys, CBA, WHfB

The hardest part of going passwordless is the chicken-and-egg problem: a new user needs a strong credential, but registering one normally requires already signing in. The Temporary Access Pass (TAP) solves it in three moves: an admin issues a TAP, the user signs in once with no password, and from that session they register a passkey or Windows Hello for Business. A TAP is simply a time-limited passcode that makes that first passwordless sign-in possible.

Temporary Access Pass settings that get tested

TAP is enabled in the Authentication methods policy by an Authentication Policy Administrator, and individual passes are created by an Authentication Administrator or Privileged Authentication Administrator. The policy defaults and ranges are exam favorites:

Setting Default Allowed range
Minimum lifetime 1 hour 10 min - 30 days (43,200 min)
Maximum lifetime 8 hours 10 min - 30 days
Default lifetime 1 hour 10 min - 30 days
One-time use False (reusable) True / False
Length 8 characters 8 - 48 characters

Two behaviors matter. First, when a one-time TAP is used to register a passwordless method, the user must finish that registration within 10 minutes of sign-in; a reusable (multi-use) TAP has no such window. Second, a TAP can be added to an internal guest but not to an external guest account[2], which instead signs in with its home-tenant credentials under cross-tenant access settings. For federated domains, a TAP is preferred over federation, so the user completes authentication in Entra ID rather than being redirected to the on-premises identity provider.

What the user ends up registering

  • Passkey (FIDO2) is the flagship phishing-resistant method. It can be a hardware security key, a synced passkey, or a passkey stored in Microsoft Authenticator[3]; all are first-factor capable and phishing-resistant.
  • Certificate-based authentication (CBA) lets users present an existing X.509 smart card or certificate directly to Microsoft Entra ID as a phishing-resistant first factor, without AD FS. It suits organizations that already run a PKI.
  • Microsoft Authenticator offers MFA push approvals and passwordless phone sign-in; it is strong but, unlike passkeys, still phishable, so it sits one tier below.
  • Windows Hello for Business binds an asymmetric key pair, preferably in the device TPM, unlocked by a PIN or biometric gesture that never leaves the device. The gesture and PIN are local; the password is not used, which is what makes it phishing-resistant. A user with a registered passkey can even use Windows Hello for Business as a step-up MFA credential[1].

OATH tokens (hardware or software TOTP generators) round out the menu for environments that restrict phones, but they are second-factor only and not phishing-resistant.

Temporary Access Pass breaks the passwordless chicken-and-egg Admin issues a TAP time-limited passcode, no password handed out User signs in once with the TAP, no password used Registers a strong method passkey (FIDO2) or Windows Hello for Business A one-time TAP must finish that registration within 10 minutes of sign-in; a reusable TAP has no window
The TAP bootstrap: issue, sign in once without a password, then register a phishing-resistant credential.

Passwords and hybrid: SSPR, Password Protection, Entra Kerberos

Three controls in this subtopic are about the password itself rather than a second factor, and the exam rewards keeping them straight. SSPR resets a forgotten password, Password Protection blocks weak ones, and MFA adds a factor. They are independent.

Self-service password reset (SSPR)

Self-service password reset lets a user reset their own password after registering authentication methods, cutting helpdesk tickets. The registration bar and the reset bar differ: each user must register at least one method, and the admin policy then requires one or two registered methods to actually reset. Accounts holding an Azure administrator role are forced onto a stronger two-method policy. The base feature is available on Microsoft Entra ID Free[4], but password writeback, which carries a cloud reset back to on-premises AD for federated, pass-through-authentication, or password-hash-synced users, requires Microsoft Entra ID P1. SSPR is recovery; it never satisfies a Conditional Access MFA requirement.

Microsoft Entra Password Protection

Password Protection stops weak passwords at the point of change or reset. The global banned password list is built from Microsoft's own attack telemetry, is applied to every tenant automatically, and cannot be disabled or viewed[5]. On top of it you can add a custom banned password list of up to 1,000 organization-specific base terms (brand, product, location names). The validation algorithm is the testable part, and it runs in three ordered steps:

  1. Normalize the new password (lower-case it, then undo common substitutions like 0 to o, 1 to l, $ to s, @ to a).
  2. Fuzzy-match against the banned lists at an edit distance of 1, and substring-match the user's name and tenant name (terms at least four characters).
  3. Score it: each banned term found counts one point, each leftover character counts one point, and the password must total at least five points to be accepted.

Extend the same enforcement to on-premises AD DS by installing the DC agent on domain controllers plus the proxy service; that on-premises deployment, like the custom list, requires Microsoft Entra ID P1. You can run it in Audit mode to log what would be blocked before flipping to Enforced.

Microsoft Entra Kerberos for hybrid passwordless

Passwordless users still need single sign-on to on-premises Active Directory resources, and Microsoft Entra Kerberos provides it. Enabling it creates an AzureADKerberos computer object in the domain that appears as a read-only domain controller (RODC)[6] but maps to no physical server; Microsoft Entra ID uses it to issue a partial Kerberos ticket-granting ticket (TGT) during sign-in, which the on-premises AD completes for resource access. This is the engine behind the cloud Kerberos trust model of Windows Hello for Business, which Microsoft recommends for hybrid because it skips the certificate plumbing that key trust and certificate trust require. One gotcha: if the Use certificate for on-premises authentication policy is enabled, certificate trust takes precedence over cloud Kerberos trust, and there is no direct migration path from certificate trust without first deleting the Windows Hello container.

Containment: disable accounts and revoke sessions

When an account is compromised, the immediate move is not to rotate methods. Disable the account to block new sign-ins, then revoke its refresh tokens and sessions (for example Revoke-MgUserSignInSession) so existing tokens stop working as they expire and the user is forced to reauthenticate. Disable and revoke are the containment actions; resetting the password or re-registering methods comes afterward.

Password Protection scores a new password in three steps 1. Normalize lower-case, undo 0-to-o, 1-to-l, $-to-s 2. Match banned lists fuzzy at edit distance 1, substring name + tenant 3. Score 1 point per banned term, 1 per leftover character Accepted only at five points or more; the global banned list always applies, a custom list adds your terms
Microsoft Entra Password Protection normalizes, matches the banned lists, then scores; a password needs at least five points to pass.

Exam-pattern recognition

SC-300 items in this area reward matching the scenario keyword to the one correct method, and recognizing the controls that look interchangeable but are not.

Stems and the answer they point to

  • "Most secure / phishing-resistant sign-in" points to a passkey (FIDO2), Windows Hello for Business, or certificate-based authentication, never SMS, voice, or even Authenticator push. If the stem says register a strong method for a brand-new user, the enabling answer is a Temporary Access Pass.
  • "New employee with no credentials must set up passwordless" or "user lost their security key and must re-register" both point to TAP. Watch for the external guest twist: a TAP cannot be issued to an external guest.
  • "Reset their own password" / "reduce helpdesk password calls" points to SSPR; if the users are synced from on-premises AD, the extra requirement is password writeback (Entra ID P1).
  • "Block the company name / weak passwords, including on-premises" points to Microsoft Entra Password Protection with a custom banned list and the DC agent on domain controllers (P1).
  • "Passwordless users need SSO to on-premises file shares" or "deploy Windows Hello for Business in hybrid with the least infrastructure" points to Microsoft Entra Kerberos / cloud Kerberos trust.
  • "Account is compromised, stop access now" points to disable the account and revoke its sessions/refresh tokens, not password reset alone.

Distractors and why they are wrong

  • Security Defaults is offered when the scenario actually needs per-group or per-condition control. Security Defaults is all-or-nothing, so the right answer is the Authentication methods policy plus Conditional Access.
  • SSPR is dangled as a way to satisfy MFA. It cannot: SSPR is recovery, not a sign-in second factor.
  • Per-user MFA is offered as the way to require MFA. It is the legacy control; modern enforcement is Conditional Access.
  • Resetting the password is offered as the first compromise response. Resetting a password does not invalidate existing refresh tokens, so without revoking sessions the attacker keeps access until tokens expire.
  • Certificate trust is offered for a greenfield hybrid Windows Hello for Business rollout. It needs PKI, and remember it also overrides cloud Kerberos trust if its policy is left enabled; the recommended low-overhead model is cloud Kerberos trust.
  • A one-time TAP is offered without noting the 10-minute registration window, which is the detail a well-written item hinges on.

Authentication methods by strength and role

MethodPhishing-resistant?Primary factor?Typical role
Passkey (FIDO2) / security keyYesYesStrongest everyday sign-in; hardware or synced passkey
Windows Hello for BusinessYesYesPhishing-resistant Windows sign-in; TPM-bound PIN/biometric
Certificate-based authentication (CBA)YesYesSmart-card / PKI sign-in directly to Entra ID
Microsoft Authenticator (push / passwordless)NoPasswordless: YesStrong but phishable; passwordless phone sign-in or MFA approval
Temporary Access Pass (TAP)NoYes (time-limited)Bootstrap/recovery to register a strong method
OATH tokens (hardware / software)NoNoOffline TOTP second factor where phones are restricted
SMS / voice callNoSMS: YesWeakest accepted factor; fallback only

Decision tree

New or recovering user with no strong method? Yes Issue a Temporary Access Pass sign in once, then register below No Existing PKI / smart cards? X.509 certificates already issued Yes Certificate-based authentication phishing-resistant, direct to Entra ID No Need phishing-resistant? most secure sign-in required Yes Passkey (FIDO2) or Windows Hello for Business on a Windows device No Microsoft Authenticator passwordless sign-in or push; strong but still phishable Last resort: SMS / voice / OATH weakest accepted factors phones restricted Always: enforce the chosen strength at sign-in with Conditional Access
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Enable and scope every method in the Authentication methods policy

The Authentication methods policy in Microsoft Entra ID is the single tenant-wide place to turn each method on or off and target it to specific users and groups, covering passkey (FIDO2), Microsoft Authenticator, certificate-based authentication, Temporary Access Pass, SMS, voice, OATH tokens, and email OTP. It is the modern replacement for legacy per-user MFA and Security Defaults, with a migration toggle to move off them. Plan from this policy first to decide who registers which strong method, then enforce when MFA is required separately in Conditional Access.

Trap Using legacy per-user MFA's Enabled/Enforced state to require MFA today; that control predates Conditional Access and is being retired in favor of the Authentication methods policy plus Conditional Access.

1 question tests this
Choose a phishing-resistant method when the scenario demands the most secure sign-in

Microsoft's phishing-resistant tier is a fixed list: Windows Hello for Business, passkeys (FIDO2 security keys and synced passkeys), passkeys in Microsoft Authenticator, Platform Credential for macOS, and certificate-based authentication. They resist remote phishing because the credential is cryptographically bound to the device and cannot be replayed from a stolen password or code. Authenticator push and passwordless phone sign-in are strong but still phishable, so they sit one tier below.

Trap Treating Microsoft Authenticator push approval as phishing-resistant; it is strong MFA but a real-time phishing or MFA-fatigue attack can still defeat it, so it is not in the phishing-resistant tier.

2 questions test this
SMS, voice, and OATH codes are the weakest accepted factors

SMS, voice call, and OATH one-time codes are the lowest tier Entra accepts and should be a fallback only, used when phones are restricted or stronger methods are unavailable. They are vulnerable to SIM-swap, interception, and phishing because the secret travels to the user and can be relayed. OATH tokens (hardware or software TOTP generators) are second-factor only and never serve as a primary credential.

A Temporary Access Pass bootstraps passwordless without a password

A Temporary Access Pass (TAP) is a time-limited passcode an admin issues so a new or locked-out user signs in once and registers a strong method such as a passkey or Windows Hello for Business, never using a password. It is the canonical onboarding and recovery path because it lets you stand up phishing-resistant credentials before the user has any. For federated domains a TAP is preferred over federation, so the user authenticates in Entra ID rather than being redirected to the on-premises identity provider.

4 questions test this
Know the TAP policy defaults: 1h/8h/1h lifetime, 8 characters, reusable

The TAP policy ships with a minimum lifetime of 1 hour, a maximum of 8 hours, a default of 1 hour, and a default length of 8 characters; all lifetimes can be configured from 10 minutes up to 30 days (43,200 minutes) and length from 8 to 48 characters. One-time use defaults to False, meaning a TAP is reusable within its validity unless you enforce one-time use tenant-wide. An Authentication Policy Administrator manages the policy, while an Authentication Administrator or Privileged Authentication Administrator creates individual passes.

A one-time TAP must finish passwordless registration within 10 minutes

When a user signs in with a one-time (single-use) TAP to register a passwordless method like a FIDO2 key or phone sign-in, the registration must complete within 10 minutes of sign-in. A reusable multi-use TAP has no such window and can be entered again during its validity, which is why long device-enrollment flows often use either two single-use passes or one multiuse pass. This 10-minute limit reflects MFA enforcement during credential registration, not the TAP lifetime itself.

Trap Assuming a one-time TAP stays usable for its full lifetime to register a passkey; passwordless registration with a single-use TAP must finish within 10 minutes of sign-in or it fails.

A TAP can be issued to internal guests but not external guests

You can add a Temporary Access Pass to an internal guest (a user object whose UserType is Guest but who has methods registered in your tenant), but adding one to an external guest account returns an error. An external guest instead signs in to the resource tenant with a TAP issued by its home tenant, and only if cross-tenant access settings are configured to trust MFA from that home tenant. So a TAP is a same-tenant onboarding tool, not a way to bootstrap an external partner.

Trap Issuing a TAP to an external guest to onboard a partner; external guest accounts are rejected, and their MFA must come from their home tenant under cross-tenant access trust.

A passkey (FIDO2) is the flagship phishing-resistant first factor

A passkey based on FIDO2 can be a hardware security key, a synced passkey, or a passkey stored in Microsoft Authenticator, and all forms are phishing-resistant and capable of primary (first-factor) authentication. The credential is a device-bound key pair verified cryptographically, so there is no shared secret an attacker can phish. Enable it in the Authentication methods policy and target the populations that need the strongest sign-in.

Certificate-based authentication presents a smart card directly to Entra ID

Certificate-based authentication (CBA) lets users authenticate with an X.509 certificate or smart card directly against Microsoft Entra ID, with no AD FS in the path, as a phishing-resistant first factor. It is the natural choice when an organization already operates a PKI and wants to reuse those certificates. CBA is configured in the Authentication methods policy along with certificate-authority and username-binding settings.

Trap Assuming certificate-based authentication still requires AD FS; modern Entra CBA validates the certificate directly in the cloud without a federation server.

Windows Hello for Business binds a TPM key unlocked by a PIN or biometric

Windows Hello for Business provisions an asymmetric key pair, preferably protected by the device TPM, that is unlocked by a local PIN or biometric gesture which never leaves the device. Because the password is not used in the sign-in, it is phishing-resistant; the PIN is device-local, not a network secret. A user with a registered passkey can even use Windows Hello for Business as a step-up MFA credential.

Trap Thinking the Windows Hello PIN is a weaker password sent to Entra ID; the PIN only unlocks a local TPM-bound key and is never transmitted, which is why Hello is phishing-resistant.

SSPR registers at least one method but admins are forced to two

Self-service password reset (SSPR) requires each user to register at least one authentication method, and the admin policy then requires one or two registered methods to perform a reset. Accounts holding an Azure administrator role are automatically forced onto a stronger two-method reset policy regardless of the tenant setting. SSPR cuts helpdesk password tickets by letting users reset their own password after verifying with their registered methods.

1 question tests this
SSPR is free, but password writeback for synced users needs Entra ID P1

The SSPR feature itself is available on Microsoft Entra ID Free, but password writeback, which carries a cloud password reset back to on-premises Active Directory for federated, pass-through-authentication, or password-hash-synced users, requires Microsoft Entra ID P1. Without writeback a hybrid user's reset would not reach their on-premises account. So a scenario that resets passwords for synced users implies the P1 writeback requirement.

Trap Picking SSPR alone for synced on-premises users without enabling password writeback; the cloud reset would not flow back to their AD account, and writeback requires Entra ID P1.

1 question tests this
SSPR is password recovery, not a Conditional Access MFA factor

SSPR exists to let a user reset a forgotten password, which is recovery, and it never satisfies a Conditional Access requirement for multifactor authentication at sign-in. MFA, SSPR, and Password Protection are three separate controls: MFA adds a factor, SSPR restores access, and Password Protection enforces password quality. Keep them distinct when a question offers SSPR as a way to meet an MFA requirement.

Trap Selecting SSPR to satisfy a Conditional Access MFA grant; SSPR is recovery, so it cannot count as the second factor a sign-in policy demands.

The global banned password list is automatic and cannot be disabled

Microsoft Entra Password Protection applies a global banned password list, built from Microsoft's own attack telemetry, to every tenant automatically with nothing to enable, and it cannot be turned off or viewed. It blocks known weak base terms and their variants at password change or reset. For cloud-only users the global list is covered by Microsoft Entra ID Free.

3 questions test this
A custom banned password list holds up to 1,000 base terms and needs P1

On top of the global list you can add a custom banned password list of up to 1,000 organization-specific base terms such as brand, product, and location names, which are combined with the global list at validation. Add only key base terms, not every variant, because the algorithm expands them automatically. The custom list requires Microsoft Entra ID P1 or P2.

Trap Adding every weak variant like Contoso!1 and Contoso@London to the custom list; you list only the base term Contoso, and normalization plus fuzzy matching block the variants, within a 1,000-term cap.

1 question tests this
Password Protection scores a password and needs at least 5 points to pass

Password Protection normalizes a new password (lower-cases it and undoes substitutions like 0 to o, 1 to l, $ to s, @ to a), fuzzy-matches it against the banned lists at an edit distance of 1, substring-matches the user and tenant name for terms at least four characters, then scores it: each banned term found is one point and each leftover character is one point. The password is accepted only if it totals at least 5 points. So a password packed with banned terms and few extra characters is rejected even if it is long.

2 questions test this
Extend Password Protection to AD DS with the DC agent and proxy (P1)

To enforce the same banned-password rules on on-premises password changes, install the Microsoft Entra Password Protection DC agent on domain controllers plus the proxy service that relays policy from Entra ID. This on-premises deployment requires Microsoft Entra ID P1, and you can run it in Audit mode to log what would be blocked before switching to Enforced mode. Tenant-name substring matching is skipped when validating on a domain controller.

Trap Expecting cloud Password Protection to cover on-premises AD password changes automatically; you must deploy the DC agent and proxy on-premises (Entra ID P1) for domain password changes to obey the rules.

Audit mode logs banned passwords before Enforced mode blocks them

On-premises Microsoft Entra Password Protection supports an Audit mode that evaluates and logs which password changes would be rejected without actually blocking them, and an Enforced mode that blocks them. Run Audit first to gauge user impact, then move to Enforced once you understand the blast radius. The mode is a setting pushed from Entra ID through the proxy to the DC agents.

Microsoft Entra Kerberos issues a partial TGT for hybrid passwordless SSO

Microsoft Entra Kerberos gives passwordless users (FIDO2 or Windows Hello for Business) single sign-on to on-premises Active Directory resources by creating an AzureADKerberos computer object that appears as a read-only domain controller but maps to no physical server. Microsoft Entra ID uses it to issue a partial Kerberos ticket-granting ticket (TGT) at sign-in, which the on-premises AD completes for resource access. Without it, a Microsoft Entra joined user can sign in but loses SSO to AD-secured resources like file shares.

2 questions test this

Cloud Kerberos trust, powered by Microsoft Entra Kerberos, is Microsoft's recommended deployment model for hybrid Windows Hello for Business because it skips the certificate infrastructure that key trust and certificate trust require. You enable Microsoft Entra Kerberos, then set the Use Windows Hello for Business and Use cloud trust for on-premises authentication policies. It is the lowest-overhead path to phishing-resistant Windows sign-in with on-premises SSO.

Trap Choosing certificate trust for a new hybrid Windows Hello rollout to get on-premises SSO; it needs PKI, whereas cloud Kerberos trust delivers the same SSO without certificate plumbing and is the recommended model.

Certificate trust overrides cloud Kerberos trust if its policy is enabled

If the Use certificate for on-premises authentication policy is enabled on a device, certificate trust takes precedence over cloud Kerberos trust, so cloud Kerberos trust silently will not apply. There is also no direct migration path from certificate trust to cloud Kerberos trust; you must delete the Windows Hello container (certutil -deletehellocontainer) and re-provision. Leave the certificate policy Not configured on machines you want on cloud Kerberos trust.

Trap Enabling cloud Kerberos trust while the certificate-for-on-premises-auth policy is still on; certificate trust wins, so cloud Kerberos trust never takes effect on that device.

Disable the account and revoke sessions to contain a compromise

When an account is compromised, the immediate containment action is to disable the account to block new sign-ins and revoke its refresh tokens and sessions (for example Revoke-MgUserSignInSession) so issued tokens stop working and the user must reauthenticate. Resetting the password alone does not invalidate existing refresh tokens, so the attacker keeps access until those tokens expire. Method rotation and investigation come after containment, not before.

Trap Resetting the compromised user's password as the first and only response; a password reset does not revoke existing refresh tokens, so you must also revoke sessions to cut the attacker's live access.

3 questions test this
Security Defaults is all-or-nothing; granular control needs Conditional Access

Security Defaults is a free, tenant-wide on/off baseline that forces all users to register and use MFA, with no per-group scoping and no per-app conditions. The moment you need to require MFA for some users, apps, or risk conditions but not others, you turn Security Defaults off and use the Authentication methods policy with Conditional Access. The two cannot run together with Conditional Access policies enabled.

Trap Keeping Security Defaults to apply MFA only to admins or only to risky sign-ins; Security Defaults has no scoping, so granular requirements need Conditional Access instead.

2 questions test this
Limit which FIDO2 key models register with key restrictions and AAGUIDs

In a Passkey (FIDO2) passkey profile, set Enforce key restrictions to Yes and add the approved models' Authenticator Attestation GUIDs (AAGUIDs) to an allow or block list. Key restrictions set the usability of specific models or providers for both registration and authentication, so if you remove an AAGUID you previously allowed, users who already registered that method can no longer use it for sign-in. Attestation enforcement is different: it is checked only at registration, so users who registered a passkey without attestation aren't blocked from sign-in if you set Enforce attestation to Yes later.

Trap Enforce attestation (verifies the vendor at registration) is a separate control from key restrictions (the AAGUID allow/block list). Tightening attestation later does not block already-registered keys, but tightening key restrictions does — removing an allowed AAGUID stops previously registered keys of that model from signing in.

4 questions test this
Restrict one app to a single FIDO2 vendor with a custom authentication strength

A custom authentication strength (Authentication methods > Authentication strengths) lets you pick an exact method combination and, in the Passkeys (FIDO2) advanced options, allow only specific AAGUIDs. Require it in a Conditional Access policy targeting one app so only the approved key model satisfies that app, while the built-in Phishing-resistant MFA strength (which also accepts Windows Hello for Business and Microsoft Entra certificate-based authentication) still applies elsewhere.

Trap The built-in Phishing-resistant MFA strength is predefined and can't be modified or narrowed to one vendor or one method; when the scenario says only a specific FIDO2 model is allowed, you need a custom strength with the AAGUID, not the built-in tier.

4 questions test this

Also tested in

References

  1. Authentication methods and features in Microsoft Entra ID
  2. Configure a Temporary Access Pass to register passwordless methods
  3. Support for passkeys (FIDO2) in Microsoft Entra ID
  4. How self-service password reset works in Microsoft Entra ID
  5. Eliminate bad passwords using Microsoft Entra Password Protection
  6. Windows Hello for Business cloud Kerberos trust deployment