IDENTITY SECURITY · LAB
Close the weaker fallback with authentication policy
Find the least evidence that reaches Ava's account, then make the passkey replace her password through policy and confirm the sign-in page no longer accepts the weaker path.
Partly readyUses your lab tenant
The lesson
Builds on: Phishing and relayed sign-ins.
New to the labs? Start with the lab toolkit and the shared cast and names every lab uses.
Partly ready. Most of this lab runs today. Steps that wait on platform features are marked, and Missing infrastructure says what they need.
- G20 `acr` / `acr_values` and acr-driven step-up
- G38 Method-aware step-up: require a phishing-resistant method for sensitive actions, not just a recent sign-in
- G43 Push approvals with number matching
Your progress
Press Start before you begin. Only events your tenant records after that count, in the order below. Checking reads your tenant's Audit, so you need Audit read access in it.
Sign in to start this lab and check your progress. Log in or create an account.
Ava signs in with password and code although she has a passkey
Recorded as
account.second_stepsucceeded (second_step_completed) about[email protected].Require the passkey and let it replace passwords
Recorded as
tenant.authentication.updatesucceeded.Ava's password is removed by the migration
Recorded as
account.enrollsucceeded (method_removed) about[email protected].Ava's old password no longer signs her in
Recorded as
account.sign_inrejected (invalid_credentials).The validator refuses a policy that leaves no way in
Recorded as
tenant.authentication.updaterejected.
Setup
Press Start on this page.
Confirm the track baseline in Authentication: Password Required, Authenticator app Optional, Passkey or security key Optional with Passwordless on, Second step
enrolled.Confirm Ava has a password, an authenticator app and a passkey.
Walkthrough
At
$ISSUER/login, sign in as Ava with her password, not her passkey. When asked for a second step, choose the authenticator app and type the code.
Why it matters: the lesson's "choosing the weakest method on offer." Ava owns a passkey, but the sign-in completed without it. A relay that cannot use the passkey would steer her to exactly this path.
Write the list the lesson asks for: every path into Ava's account and what each one requires. Include the password with an authenticator code, the passkey, a recovery code as a second step, a trusted browser if one is remembered, an administrator reset, and sessions and tokens that already exist.
Why it matters: the useful question is "what is the least evidence that gets someone in?", not "is MFA enabled?" Right now the answer is a password and a code, both of which a person types and a relay can forward.
In Authentication, set Passkey or security key to Required with Replaces password on, set Password to Optional, and save. Read the message if the form refuses an order of changes; the validator explains which setting must change first.
Why it matters: the policy, not the sign-in page, decides which methods count. Required starts a forced migration, so users without a passkey enroll one at their next sign-in.
Sign in as Ava with her passkey. Open
$ISSUER/account/securityand regenerate her recovery codes. Read the page again: her password is gone, and the method-changed notice is sent.
Why it matters: once a user holds the required method, the tenant removes the password it replaces at their next change of sign-in methods. It also ends her other browsers and OAuth grants, because those were issued while the weaker path existed.
Sign out and try Ava's old password at
$ISSUER/login. It is refused with the same "The email or password is incorrect" message as any wrong password.
Why it matters: this confirms the setting changed real runtime behavior for Ava. The password path does not just look hidden; the account no longer has a password to check.
In Audit, source User directory, open the
tenant.authentication.updateevent and read which policy sections changed. In Audit, source Protocol activity, find theaccount.enrollevent with reasonmethod_removedfor Ava.
Why it matters: a change to authentication policy alters every account's weakest path at once, so it is a security event in its own right and must be recorded with who made it.
Break it
In Authentication, try to save a policy that sets Password to Off and Passkey or security key back to Optional, so no sign-in method is Required. The tenant refuses it: turning passwords off needs another sign-in method set to Required, so every user has a way to sign in. Nothing was saved, so there is nothing to restore.
Check your work
Check my progress confirms the downgraded sign-in, the policy change, the password removal, the refused old password and the refused invalid policy, in that order.
The refused policy appears in Audit, source User directory, as
tenant.authentication.updaterejectedwith reasonpassword_off_without_migration.
Cleanup
Return the policy to the track baseline so later labs can use passwords: Passkey or security key Optional with Replaces password off, Password Required. The Layered defenses lab asks you to apply the passkey-required policy again.
In Users, set a new administrator password for Ava and store it with
read -rs AVA_PASSWORD.
Missing infrastructure
G20: relying parties cannot ask for an assurance level with
acr_values, so an application cannot demand a phishing-resistant sign-in for itself. Once it exists, the lab will requestacr_valuesfromlab-collageand see a password sign-in refused for that client only.G38: methods are tenant-wide, so "passkey required for finance staff only" cannot be expressed, and sensitive actions cannot require a phishing-resistant method. Once it exists, the lab will require a passkey for role holders and confirm Ben is asked for it while Cora is not.
G43: the tenant has no push approvals, so approval fatigue and number matching are context only. Text-message codes and SIM swaps are context only too, because the tenant sends no text messages.