Account recovery

Valid saved code

1. Verify. The lost key is already invalidated. Chronos Hub verifies the password and saved recovery code for FL-17. Only accepted recovery evidence can authorize binding a replacement. K1 is unusable before this example starts; the verified loss report and prompt invalidation are not delayed until a replacement is ready. For this fictional account with two-factor sign-in (AAL2), recovery requires both a valid password bound to FL-17 and a saved recovery code issued earlier. Chronos Hub checks the code against its protected reference, including expiry, prior use, and rate limits. The accepted case assumes the password matches and the unused code is valid. Acceptance consumes the code for this limited recovery transaction; another attempt cannot reuse it. The code’s secret is never displayed. An urgent story, a copied badge photo, or an address supplied by the caller is not this recovery evidence.
2. Bind. Chronos Hub binds replacement passkey K2 to FL-17 through the protected recovery process. The accepted recovery code has already been consumed. Chronos Hub sends notice to contact addresses already on the account. No normal application session is created. The limited recovery transaction authorizes adding this authenticator only. Enrollment verifies possession of the new passkey before its public credential is associated with FL-17; the private key stays with its authenticator. The saved code was invalidated after use in the evidence stage, and a new saved recovery code is issued for the subscriber to store securely. Required recovery and binding notifications go to stored account contacts, with a way to report an unauthorized change. This is not a detailed passkey-enrollment exchange. This example also assumes any pre-existing Chronos Hub sessions were separately terminated during incident handling; invalidating K1 alone would not guarantee that. Trailer permissions stay unchanged.
3. Sign in. The requester now uses K2 for an ordinary fresh sign-in. Chronos Hub verifies the new passkey response before creating an authenticated FL-17 session. Recovery itself did not create that session. This fictional multi-factor passkey uses local user verification plus possession of its private key. Chronos Hub verifies a fresh challenge response against K2’s bound public credential and the required origin, challenge, and user-verification conditions. Only after successful authentication does it establish an ordinary authenticated session. Those protocol messages are outside this workflow picture. A valid response proves control under the account’s authentication policy; it does not independently establish who is at the device or validate the earlier recovery process. No trailer record has been requested yet.
4. Task. The authenticated FL-17 session requests trailer 17. Chronos Hub checks the existing trailer-17 permission and permits that request. Recovery has not granted access to trailer 99 or added an administrator role. Chronos Hub checks this request’s action, resource, and current permission. The example assumes FL-17 has an existing permission to read trailer 17 and no permission to read trailer 99. The displayed successful task is the trailer-17 request only. Binding K2 and authenticating with it do not change that permission. An authenticated request for trailer 99 would still be refused. The pause before the result is an illustrative decision stage, not measured service latency.

Expired saved code

1. Verify. The password matches, but the saved recovery code has expired. Chronos Hub refuses this recovery attempt. K1 stays invalidated, and K2 is not bound to FL-17. The account and password are the same as in the accepted case. The different fact is the code’s expiry, so the required recovery evidence is incomplete. Knowing the password alone cannot complete this account’s recovery method. Chronos Hub does not weaken the method because the request is urgent. A supported alternative would need its own documented checks; none is attempted here.
2. Stop. The refused recovery attempt stops here. There is no replacement binding, fresh sign-in, or trailer request. The old key remains invalidated; an expired code does not restore it. No successful binding or completed-recovery notification is claimed on this path. The rejected attempt can be recorded and handled under the service’s monitoring and recovery policy. FL-17’s existing permissions are unchanged, but no normal application session has been established by this example. Selecting the valid-code comparison restarts the displayed recovery evidence; it does not make an expired code acceptable.

Recovery requirements depend on the account’s assurance and prior enrollment. A recovery code is not a universal MFA substitute. Binding K2 neither creates a normal application session nor expands FL-17’s permissions.

Flow references: NIST SP 800-63B-4 - Account Recovery · NIST SP 800-63B-4 - Invalidation · OWASP - Authorization