Phishing-Resistant Login Still Needs a Recovery Plan: The Public-Service Passkey Problem

1. The difficult login is the one after the phone disappears

A resident has successfully signed into a public-service portal with a passkey for months. Then the phone containing the credential is lost. The replacement phone is not yet connected to the same credential manager. The resident's email account wants confirmation from the missing phone. An appointment deadline is approaching, and the portal's friendly instruction is to use the passkey that is no longer available.

This is a fictional situation, not a reported incident at a named agency. It illustrates a problem that a successful normal login cannot answer: what happens when the person is still entitled to use a service but no longer controls the usual way of demonstrating that they belong to the account?

The underlying technology continues to mature. W3C published Web Authentication Level 3 as a Recommendation on August 25, 2026. The specification defines an API for public-key credentials scoped to a relying party, with browsers mediating interactions with authenticators. Its publication is a standards milestone, not evidence that every public-service portal has implemented every capability or solved recovery. W3C, Web Authentication Level 3.

For a public service, the missing-phone case is not an edge condition that can be dismissed because most people sign in successfully. The people who cannot finish may be the ones who need assistance most urgently. That does not justify weakening account protection: giving access to an impostor can expose records or redirect a service. The design problem has two sides that must be addressed together—keeping the wrong person out and giving the right person a workable, appropriately verified route back in.

This article examines that problem through a fictional portal called Harbor Services. It is not a real agency, product, pilot, or deployed system. Its residents, account states, tests, and numerical examples are invented to make the decisions inspectable. Official standards and actual public support pages provide the factual boundaries; the worked scenarios show how those boundaries interact.

The question is not whether passkeys are secretly bad because recovery remains difficult. It is whether a service understands the difference between protecting its normal authentication ceremony and protecting the entire account lifecycle. A strong front door is valuable. It does not describe the rules for replacing a lost key, helping someone operate the door, or deciding which rooms they may enter afterward.

2. Proving identity, authenticating, and granting a service are different decisions

NIST's Digital Identity Guidelines distinguish identity proofing, authentication, and federation, with separate assurance measures for those functions. Identity proofing concerns establishing the relationship between a person and claimed identity evidence; authentication concerns control of authenticators associated with an account. Treating the functions separately prevents a strong login mechanism from being mistaken for proof of every fact about the person using it. NIST SP 800-63-4.

In Harbor Services, imagine that an account is associated with resident Mira after the fictional service completes its required enrollment process. A passkey is then registered to that account. A later successful login helps the service recognize control of that account's authenticator. It does not, by itself, establish that Mira's mailing address is unchanged, that a particular application is complete, or that she qualifies for every service offered through the portal.

Those distinctions become important during recovery. A caller might know the account's email address and a case reference printed on a letter. That information can help locate a record. It does not automatically establish control of the account or satisfy Harbor's recovery requirements. Conversely, a resident can be the correct person yet lack a document or device needed for one particular proofing route. A failed route is not the same proposition as a fraudulent identity claim.

Harbor therefore separates three fictional decisions in its workflow. First, which account is the person trying to reach? Second, has the required evidence for returning control of that account been established? Third, what actions may this authenticated account perform? The distinctions do not dictate a universal technical implementation. They prevent an operator from resolving all three questions by selecting a single “verified” checkbox.

Consider a request to change the bank account associated with a payment. Harbor's hypothetical policy requires stronger confirmation for that action than for reading a public appointment guide. It would be a mistake to make the guide unavailable to everyone who cannot complete the higher-risk transaction. It would also be a mistake to infer that access to the guide authorizes a payment change. The two activities need not share the same access boundary.

This separation makes assistance more practical. A staff member could explain what documents an application requires without viewing the resident's private account. Someone could receive information about an in-person support location without resetting any credential. Useful help does not always require account access, and account access does not eliminate the need to check permissions for a sensitive action.

3. Name the three places involved in a passkey

A passkey experience can involve the service being accessed, a device used to authenticate, and a provider that manages or synchronizes credentials. FIDO's consumer deployment paper distinguishes synced and device-bound passkeys and discusses circumstances in which users can still lose access. Syncing can help credentials survive a device loss; it does not mean that every credential is available on every device or that the provider account can never become inaccessible. FIDO Alliance, Synced Passkey Deployment.

For the fictional Harbor account, give these places plain labels. Harbor is the service. Mira's phone is one device. Cedar Vault is an invented credential provider, not a real company. The names exist only to distinguish responsibilities in the example. Harbor does not become Cedar Vault merely because a credential stored through Cedar Vault can authenticate to Harbor.

Now imagine four different failure descriptions. “My phone broke” identifies a device problem. “I cannot unlock Cedar Vault” identifies a provider-access problem. “Harbor no longer recognizes the credential” identifies a service-side or association problem requiring investigation. “The browser never presents the expected choice” identifies an interaction problem, not necessarily a lost credential. The same complaint—“my passkey does not work”—can refer to any of them.

That distinction changes the appropriate response. If the credential remains usable through another already configured device, the person may not need Harbor to recover the account at all. If no accepted authenticator is available, merely reinstalling a browser might not supply one. If the account association was removed at Harbor, a provider's display of a credential does not guarantee that Harbor will still accept it.

A support form that asks only whether the resident “has a passkey” collapses these states. A better diagnostic description would identify where the resident expects the credential to be available, whether any previously configured method still works, and which stage produced the error. It should not ask the resident to reveal private key material or send a screenshot containing a recovery secret.

There is a similar distinction between unlocking a local authenticator and sending a reusable password to the service. The user may encounter a familiar device interaction, but the service is not simply receiving a copy of that local unlock secret. WebAuthn uses public-key credentials and authentication assertions; understanding that boundary helps prevent misleading claims that a fingerprint or device PIN is the website's new password. W3C's WebAuthn model.

In a correctly implemented WebAuthn ceremony, relying-party scope and origin checks help prevent an unrelated lookalike site from obtaining a usable authentication assertion for the intended service. That protection concerns the authentication ceremony, not every later account operation. WebAuthn security considerations.

For the resident, the interface should make these boundaries understandable without demanding cryptographic expertise. “Use another device that already has your credential” and “recover access to your credential provider” are different instructions. Neither should be presented as a guaranteed solution when the service has not established that the relevant route exists.

4. Count independent routes, not icons on a settings page

FIDO's paper on multiple authenticators explains why registering another authenticator can reduce the need for recovery, while also noting that the primary and backup can become unavailable together. The important property is usable resilience, not a decorative count of registered items. FIDO Alliance, Multiple Authenticators.

Here is Harbor's first fictional dependency map. Mira normally uses a passkey on her phone. She also sees a “backup email” option. The email account, however, needs approval from that phone for a fresh sign-in. A recovery document is stored inside Cedar Vault, whose fresh-device access also depends on the phone in this scenario. These are explicit assumptions for this resident, not statements about the behavior of every email or credential provider.

The first three entries are three menu choices but one shared dependency. Counting them as three independent fallbacks overstates what the resident can do after the phone disappears. The fourth could supply independence, but only under the conditions shown. A key that was never registered, cannot connect to an available device, or is not accepted by the service is not a working route merely because it exists physically.

A minimal logical model makes the failure visible. Let P mean the phone route is available. Let E mean the email route is available. Let V mean the vault document can be retrieved. In the assumed setup, E requires P and V also requires P. If P is false and no additional route exists, listing P or E or V does not make the result true. This is a dependency calculation, not a probability estimate of actual account loss.

Now add K, a separately registered and usable key whose access does not depend on P in this model. The expression P or K can remain true when P is false and K is true. But “independent” is relative to the failure being considered. If the phone and key are carried in the same lost bag, both may become unavailable. If the key is safe at home while the resident is traveling, it may exist but not be reachable in time.

Harbor's design exercise therefore records the failure scenario alongside each route. Device breakage, loss of a bag, loss of access to a provider account, and inability to operate a particular interface are not interchangeable. The useful question is what remains usable after a specified event, not how many recovery symbols appear before anything goes wrong.

This does not imply that every resident should buy several devices or maintain an elaborate security kit. It identifies where the service must decide whether it offers a suitable alternative and how a resident can reach it. Resilience that exists only for people with spare hardware and immediate transport may leave the hardest cases unanswered.

5. A second working authenticator is not the same as recovering an account

NIST's authenticator-management guidance distinguishes account recovery after loss of required authenticators from replacing a credential while sufficient authentication remains available. It recognizes several recovery classes, including recovery codes, recovery contacts, and repeated identity proofing, with requirements depending on the account and assurance context. These are not interchangeable permissions to reset an account on demand. NIST SP 800-63B-4, Authenticator Event Management.

In one Harbor scenario, Mira's phone is lost but her separately configured laptop still authenticates successfully. Under the scenario's policy, she can use the existing accepted route to manage authenticators and establish a replacement. The design question is how Harbor verifies and records that change, not how a support worker can waive the missing phone requirement.

In a second scenario, the laptop is unavailable too, and the provider account cannot be reached. Harbor now needs its defined recovery process. The resident's problem has changed even though the lost phone is still the first fact in the story. A help page that always says “sign in and change your settings” works for the first case and loops uselessly in the second.

FIDO's earlier account-recovery guidance makes a related distinction: reducing recovery needs through multiple authenticators is one strategy; appropriately re-establishing account control when those authenticators are unavailable is another. The document warns that weaker recovery mechanisms can undercut the security of the FIDO implementation. Its historical examples are not a substitute for current service-specific requirements. FIDO Alliance, Recommended Account Recovery Practices.

For Harbor, the immediate design improvement is to stop using one button label for both situations. A person who can still authenticate needs credential-management assistance. A person who cannot authenticate needs a clearly identified recovery route. Someone who only wants public information may need neither. Routing people correctly reduces unnecessary sensitive-data collection as well as frustration.

This distinction also prevents a misleading performance claim. Suppose Harbor reports that ten residents “recovered their accounts,” but nine simply used an existing second authenticator and one completed a formal recovery process. The combined count may be useful as a broad support statistic, but it does not show that the difficult recovery process works well. Its evidence consists of one case, not ten.

The same caution applies to test results. A team that disables the phone but leaves a working laptop session available has tested one failure mode. It has not tested total loss of accepted authenticators. Both tests can be valuable, but they answer different questions and should produce different records.

6. A library computer should not become the resident's new authenticator by accident

Consider another fictional resident, Luis, who has a working phone but uses a shared library computer to complete a long form. His goal is to authenticate to Harbor for that session, not to leave a credential on a machine that other people will use. The design must distinguish signing in through a credential he controls from creating a new credential on the shared endpoint.

FIDO's consumer deployment guidance discusses cross-device authentication and sign-in from devices without a registered passkey. Such support is a capability to evaluate, not a guarantee that every public terminal, browser, device combination, or service configuration permits it. FIDO's consumer deployment guidance.

Harbor's hypothetical flow begins by making the choice clear: use an existing sign-in method, or intentionally add a credential where appropriate. It does not automatically interpret a completed login on the library computer as consent to save a new passkey there. An invitation to create a credential should identify what the user is doing, rather than disguising enrollment as a mandatory next step in finishing the form.

A successful authentication also does not establish that a shared computer is trustworthy. Even if the credential remains on Luis's phone, the resulting browser session can display private information. The service cannot infer from a strong login that the terminal has no malicious software, that nobody is watching, or that downloaded files will disappear afterward. Those are separate endpoint and session risks, not defects that an authentication protocol is designed to erase.

The fictional acceptance test therefore has several observations. Luis must be able to recognize the intended service and the sign-in action. Canceling an unexpected credential-creation prompt must not silently enroll the shared machine. After the task, signing out must end access through that session according to the application's design. Returning to a sensitive page should not reveal account data to the next user. These are expected behaviors for a controlled test environment, not claims that a real library or Harbor deployment was tested.

The test should also distinguish browser history, cached page content, and files explicitly downloaded during the session. Treating all three as “signed out” can conceal what remains on a shared device. Where the terminal's safety cannot be established, the service needs an alternative way to complete the task rather than promising that passkeys make every borrowed computer safe.

For residents, the most helpful message is not a detailed explanation of transport protocols. It is a clear account of whether they are signing in, saving a credential, or leaving information on a shared device—and a way to decline an action that does not fit their situation.

7. “Use your face or fingerprint” is not a complete accessibility strategy

A passkey should not be explained as though every person must use the same biometric gesture. FIDO's accessibility guidance examines different interactions—touching a key, typing, scanning, inserting a device, reading instructions, or completing a timed step—and the different barriers they can create. Its discussion is a planning aid, not a prediction that every person with a particular disability will prefer the same method. FIDO's Passkey Accessibility guidance.

In a third Harbor scenario, resident Elena uses assistive technology and cannot reliably complete the fingerprint interaction on her usual device. The design team has two questions, not one. Does an accepted local verification alternative exist in her actual device and service configuration? If so, can she discover and operate it? A technically available alternative hidden behind an unlabeled control may not be a usable alternative.

For this fictional test, assume the configured device offers an accepted PIN-based route that Elena can operate. The expected outcome is not that Harbor asks for the PIN in an ordinary website form. The expected outcome is that the legitimate device interaction is discoverable, the credential can be used through the supported route, and the service returns to a meaningful state afterward. This is a stated test configuration, not a promise that every device offers the same controls.

Now change the scenario. Elena cannot use that PIN interaction either. The existence of two local gestures has not solved her problem. Harbor must evaluate a different supported route rather than conclude that the resident failed to follow instructions. Repeating the same inaccessible prompt with a larger “Try again” button does not create a new path.

A useful test record describes the interaction and the barrier, not merely the person's diagnosis. “The control cannot be reached using this input method” is more actionable than “the accessibility test failed.” “The status change is not announced after the native prompt closes” points toward a different defect from “the resident cannot physically operate this authenticator.” One is primarily a transition in the service interface; the other may require a different usable authentication option.

The service also should not assume that adding a second person solves the problem. A support worker may help explain navigation, but taking possession of the resident's credentials can blur responsibility and privacy. If a public service supports an authorized representative, that is a separate relationship to design and verify, not a reason to treat credential sharing as an accessibility feature.

The practical goal is a path the resident can use with appropriate assistance and protection, not a claim that one authentication method is universally accessible. The relevant evidence is successful completion of the whole intended task under a clearly described configuration, including recovery when the preferred interaction is unavailable.

8. Recovery screens are part of the accessible journey

W3C's explanation of WCAG 2.2 Success Criterion 3.3.8 addresses cognitive-function tests in authentication. It describes alternatives or assistance mechanisms, with specified exceptions, and explains that all steps in a multistep authentication process must satisfy the criterion. Its discussion explicitly includes authentication used to recover or change account credentials. This is accessibility guidance, not a claim that one particular login design satisfies every applicable legal requirement. W3C, Understanding Accessible Authentication.

Suppose Harbor's normal passkey route is easy for a resident, but its recovery screen requires manually copying a long code between two windows and blocks pasting. The team cannot declare the account journey accessible solely because the normal login avoided memorized passwords. The recovery step introduces a different burden at the moment the resident has already lost the usual route.

In this fictional design review, Harbor permits the supported input assistance appropriate to its chosen recovery mechanism and tests the complete sequence with the relevant assistive technology. That does not mean forwarding secrets to a helper, weakening the verification requirement, or assuming that every cross-device transfer is safe. It means avoiding needless interface barriers around a process whose security requirements still have to be met.

There is another boundary around the operating system's prompt. Harbor may not control every native dialog, but it controls what leads into that dialog and what happens after it closes. FIDO's passkey UX guidelines emphasize clear communication before and after platform interactions, including showing the resulting state and preserving user choice. FIDO Alliance, UX Guidelines for Passkey Creation and Sign-ins.

Imagine that Elena cancels a prompt because she selected the wrong method. The native dialog closes, but keyboard focus lands behind an overlay, and the page silently changes a small icon from blue to red. A sighted mouse user might recover by clicking around. A screen-reader user might receive no meaningful indication of what happened. The authentication technology can function correctly while the surrounding service becomes unusable.

Harbor's proposed test records the focus position, announced message, available alternatives, and whether entered nonsecret context survives the cancellation. Passing this test would mean the resident can understand the state and choose the next permitted action. It would not mean every recovery route has passed, or that the system has received a legal accessibility certification.

This is why a polished screenshot is insufficient evidence. It can show labels and spacing, but not what a screen reader announces, where focus moves, whether a control works without a pointer, or what happens after a native prompt is dismissed. Those observations require interaction testing with the relevant tools and users. The examples here specify tests to perform; they do not claim those tests were performed on a real service.

9. Recovery must establish control before it installs a replacement credential

A recovery process changes who can authenticate to an account. That makes it more than a customer-service convenience. In Harbor's fictional design, the process has distinct states: a request has been opened; the required evidence is being evaluated; the recovery decision has been made; a replacement authenticator has been bound; and the resident has successfully used it. A status of “request received” must not be mistaken for completion of the later states.

NIST's authenticator-management guidance requires recovery notifications and describes requirements for binding new authenticators. Its treatment also makes clear that recovery methods and combinations depend on assurance context. Merely having an email address, a recovery code, or a helpful support agent does not establish that every possible reset flow meets those requirements. NIST on authenticator events and recovery.

For example, if Harbor adds a password-only fallback that immediately grants the same account access, that route does not acquire phishing resistance just because a passkey button appears beside it. The service must assess the fallback on its own properties. Keeping an accessible alternative is important, but calling all alternatives equally protective would conceal the very tradeoff the design needs to examine. FIDO on recovery weaknesses.

Consider a fictional support record with these entries: request opened at 10:00; a resident supplied one requested item at 10:20; automated confirmation sent at 10:21; replacement credential enabled at 10:22. The record does not yet establish that the required recovery decision occurred. Perhaps it did, in another record. Perhaps the workflow omitted it. The appropriate conclusion is that the evidence is incomplete, not that a real fraud occurred or that the supplied item must have been sufficient.

A better record identifies which approved route was used, whether its required checks were completed, the resulting decision, and the credential association changed by that decision. It need not reproduce sensitive identity evidence in a general support log. The point is to make the state transition accountable without turning every troubleshooting record into another repository of personal documents.

After a replacement is bound, the account may also need treatment of older credentials or sessions according to the service's security policy. Deleting something from a device and changing what the service accepts are different actions. Harbor's test plan checks the intended account state explicitly rather than assuming a reassuring message means every old route has disappeared.

The resident should be able to distinguish “your recovery request is pending” from “your new sign-in method is ready.” A new credential that has never successfully authenticated should not be reported as a tested working replacement. Conversely, an unavailable old device should not prevent all progress when the approved recovery route has actually established the required assurance.

These are design principles for the fictional service, not an operational recipe for bypassing a real service's controls. Real recovery must follow the service's official process and applicable requirements. The important public-interest question is whether that process is documented, usable, and correctly implemented—not whether a persistent caller can persuade someone to skip it.

10. Actual public-service support pages show why universal advice fails

Current official support material provides a useful reality check. Login.gov's authentication-methods page encourages people to configure two methods. It warns that losing access to the required methods can leave the account inaccessible and describes deletion and creation of a new account in its lockout guidance. It also lists security keys among its supported authentication methods. That is a description of Login.gov's published guidance, not an instruction to delete an account without first examining the person's situation and official recovery information. Login.gov, Authentication methods.

VA.gov's separate passkey support page describes a different set of service-specific details. As checked on October 29, 2026, it says the direct VA.gov passkey option does not support security keys and directs users experiencing passkey problems toward its listed sign-in partners. It distinguishes credentials saved on another device or provider from credentials removed from the VA.gov profile or credential manager. Those are current statements on that particular support page, not universal properties of passkeys. VA, Support for common passkey issues.

The contrast matters. “Use a backup security key” can be sensible only if the relevant service supports that route and the credential has been properly configured. “Use your identity-provider account instead” requires that the person actually has a usable supported provider account. A general article should not turn either sentence into a guaranteed remedy for every portal.

Nor should a reader assume that two services with government branding have identical recovery policies. The service, credential provider, identity provider, and underlying application can be different actors. A resident may need help identifying which one is rejecting the attempted sign-in before choosing the appropriate official support route.

For Harbor, these examples lead to a specific content requirement: its help material must describe its own supported configurations and explain where a user is being sent. A link labeled “recover your account” should not silently move someone to a provider's generic homepage while implying that Harbor has initiated a verified recovery request.

The fictional design also separates troubleshooting from destructive account actions. Clearing an association, deleting an account, and creating a replacement can have consequences beyond resolving a prompt. The interface must explain the relevant effect and use the service's authorized process, rather than presenting deletion as a universal first troubleshooting step. This article does not perform or recommend such an action for any reader's account.

Published help pages can change as services add capabilities. Their value here is to demonstrate why the exact service and current support route matter. The technical standard does not promise that every relying party has chosen to expose every feature that an authenticator or browser can support.

11. Measure successful access, not just successful enrollment

A passkey rollout can look excellent if its dashboard counts only people who finish enrollment. To examine the missing denominator, consider a fictional Harbor pilot with 200 invited participants. Of those, 160 attempt enrollment and 144 finish. The completion rate among attempters is 90 percent, but completed enrollment represents 72 percent of all invited participants. Neither percentage alone explains why 40 did not attempt or why 16 attempts did not finish.

Now imagine a later, separately defined recovery exercise involving 40 participants who consent to a controlled test. Twenty-four use a previously configured second authenticator, eight complete the designated formal recovery route, and eight do not complete either within the exercise. Thirty-two of 40 regain access under the tested conditions, or 80 percent. That aggregate should not be advertised as an 80 percent success rate for the formal recovery route: only eight completions came through that route, and its relevant denominator must be identified separately.

For this example, assume the 16 participants without a usable second authenticator all enter formal recovery. Eight complete it, so that route's completion rate is 50 percent within the exercise. The second-authenticator group completes at 100 percent, while the combined result is 80 percent. The arithmetic is straightforward, but the interpretation changes sharply when the paths are separated.

These numbers are invented, not research findings or performance targets. They demonstrate why a dashboard needs route-specific denominators. They also do not show whether every unsuccessful participant could eventually complete the process, whether the sample represents all residents, or whether any particular method caused the outcome. Those would require additional observations and an appropriate study design.

FIDO's Passkey Rubric recommends visible alternatives when prompts fail or are canceled and distinguishes ordinary sign-in friction from situations requiring account recovery. It also emphasizes matching recovery to the service's risks rather than treating every fallback as equally protective. FIDO's Passkey Rubric.

Harbor's proposed measurement therefore records the attempted route, the stage reached, the reason for stopping when known, and the time to a usable outcome. It distinguishes a resident choosing to postpone from a technical failure, an inaccessible interaction, an unavailable prerequisite, or a decision that the required evidence was not established. These are categories to investigate, not labels that automatically assign blame.

A second measurement asks whether the service preserved protection. A route that produces faster completion by skipping a required check is not an unqualified improvement. Conversely, a lower completion rate is not proof of better security. A blocked legitimate resident and a blocked impostor are different outcomes. Reporting both access and protection evidence is more informative than choosing whichever single percentage makes the rollout look successful.

12. A five-case acceptance exercise for the whole account journey

The Harbor examples can be converted into a bounded acceptance exercise. The following are proposed tests with expected outcomes, not results from a deployed system. They belong in an authorized test environment using synthetic accounts and nonproduction information. No resident's real credentials need to be collected for the exercise.

First, simulate loss of the phone while a separately configured authenticator remains usable. The expected outcome is successful authentication through the remaining accepted route, followed by the service's authorized credential-management process. The record should call this continuity through an existing authenticator, not proof that full account recovery works.

Second, make all accepted authenticators unavailable under the test assumptions. The expected outcome is entry into the documented recovery process without an endless instruction to sign in first. Passing does not mean granting immediate access. It means the process reaches the correct decision using its required evidence, communicates the status, and does not create a replacement credential before the necessary checks are complete.

Third, use a supported assistive-technology configuration and cancel the native passkey prompt. The expected outcome is a comprehensible return to the service interface with usable focus, an announced result, and available permitted next steps. The test fails if the user becomes trapped behind an overlay or receives no actionable state information, even if the cryptographic operation correctly reports cancellation.

Fourth, sign in on a controlled shared-terminal configuration using a credential that remains under the user's control. The expected outcome is a clear distinction between authentication and enrollment, no unintended creation of a credential on the terminal, and the intended session termination behavior. The exercise must separately examine residual displayed or downloaded information. A pass here does not certify arbitrary public computers as safe.

Fifth, complete the approved replacement process and examine account state. The new authenticator must work in the intended configuration, required notifications must be generated, and the service must treat previous authenticators and sessions according to its stated policy. A green “done” banner without those observations is not enough evidence to mark the exercise successful.

The value of these cases is their specificity. If Harbor passes four and fails one, it should report which case failed rather than average them into a claim that recovery is “80 percent secure.” These tests cover different conditions; they are not interchangeable samples from a single probability distribution. They also leave questions unanswered, including whether other devices, languages, disabilities, service outages, and fraud scenarios are adequately handled.

Passkeys can improve the normal sign-in experience while leaving those questions open. That is not a contradiction. The public-service challenge is to carry the improvement through loss, change, assistance, and return to service without quietly weakening protection or excluding people whose circumstances do not match the easiest demo.

A credible account-access promise is therefore more precise than “you will never need a password again.” It identifies the supported sign-in methods, the dependencies that remain, the approved recovery route, and the evidence that residents can actually use it. The strongest claim is the one whose limits are visible before someone loses their phone—not the one discovered only after every convenient route has disappeared.