ADR 0032 — Customer account recovery: A+B only (multi-passkey + backup codes; no email recovery; no agent re-enrollment)

Status: Accepted Date: 2026-04-30 UTC Deciders: Kristerpher (product owner) Refs: epic #651, sub-card #670, docs/security/auth-posture.md §11

Context

Raxx customer accounts authenticate exclusively with WebAuthn passkeys (ADR-0001). There is no password. There is no SMS OTP. There is no email login factor.

This creates a real failure mode: a customer who loses all enrolled devices has no credential to present to the application. The question is what — if anything — the platform does in response.

The industry default for fintech and consumer auth products is to add a secondary recovery surface:

• Email magic-link: send a time-limited link to the account email address. Customer clicks it, gets in, re-enrolls a passkey.
• Agent-mediated re-enrollment: support agent verifies identity (DOB, payment card, account history, etc.), then manually triggers a passkey re-enrollment for the customer.
• SMS / OTP: send a code to a verified phone number on file.

Raxx explicitly rejects all three. This ADR records that decision, why it was made, and what it requires from the rest of the system.

Decision

A+B only — no other recovery surface exists.

A. Multi-passkey enrollment at signup (required, non-skippable)

Customers must enroll at least two passkeys before their account is activated. Signup cannot complete with a single passkey. If only one device is available at signup time, the customer can pause and resume — but the account does not go live until a second passkey is enrolled.

This is not a recommendation. It is a hard gate enforced at the API layer.

B. Backup codes (required save, 30-second display gate)

Ten single-use backup codes are generated at signup. The signup flow blocks until the customer has:

1. Seen the codes displayed for at least 30 seconds, and
2. Explicitly affirmed "I have saved my backup codes."

Using a backup code does not restore normal access — it opens a forced passkey re-enrollment flow that must complete before the session can do anything else. Each code is single-use and its consumption is audit-logged. Customers can regenerate backup codes from the dashboard at any time; regeneration invalidates the entire previous batch.

What happens if a customer loses both devices and backup codes

The account is permanently inaccessible. Raxx cannot help. This is stated in plain language at signup. It is a deliberate posture choice.

Consequences

For the platform

• Signup has two non-skippable steps that require physical presence of multiple devices (or a deliberate write-down). This is a real onboarding cost. It is the right cost to pay: the cost of redundancy at signup is always lower than the cost of an account-takeover event or a social-engineering incident.
• Support agents have no re-enrollment procedure and no tooling. The runbook entry is: "We cannot recover this account. We are sorry." (See the support-agent response template in the runbook — TODO: land in docs/ops/runbooks/support/ when the support epic work begins. No runbook directory exists yet; this ADR points to where it should go.)
• Customer-facing copy at signup must state clearly that losing both enrolled devices and backup codes means permanent lockout, with no exceptions. Suggested copy: "Account recovery is not possible without your enrolled devices or backup codes — please save both before completing signup."
• The customer.passkey.added, customer.passkey.revoked, customer.backup_code.used, and customer.backup_codes.regenerated events must all be written to the audit log. These are the only signals Raxx has of a customer's recovery state.

For customers

• Customers who enroll two passkeys and save their backup codes have a solid path back in. The failure mode is real but avoidable with the prescribed setup.
• Customers who skip the redundancy steps — meaning they somehow bypass the hard gate, which is a bug — have no recovery path. The gate exists precisely to prevent this outcome.
• Customers who lose access permanently cannot be helped by support. This is a hard outcome, and the signup copy must not soften it to the point of dishonesty.

For the support team

• Support agents must not promise recovery to customers who have lost both factors. Doing so opens a social-engineering vector: an attacker who knows a customer's email can claim device loss, apply pressure, and get re-enrolled into an account they do not own.
• The answer is: "We are sorry — account recovery is not possible without your enrolled devices or backup codes. This is a security decision that protects you from account takeover."

Alternatives considered

Email magic-link recovery

The most common industry recovery path. A time-limited link is sent to the verified email address; clicking it grants access and triggers passkey re-enrollment.

Rejected. Email is the single largest account-takeover surface for fintech accounts. An attacker who compromises a customer's email inbox — through phishing, credential stuffing against the email provider, or session hijacking — gets full access to the Raxx account as a consequence. Email access tokens are phishable; passkeys are origin-scoped and not. Adding email as a fallback to a passkey-only auth system reintroduces the entire phishable-credential threat model via the recovery path.

The risk is asymmetric. The number of customers who will lose all devices and backup codes is small. The number of customers whose email accounts will be compromised over the account lifetime of the platform is not small. We do not make the majority vulnerable to protect the minority.

There is an additional GDPR angle: the email magic-link recovery flow must store a recovery token against the user record. Tokens can be compromised in transit, in storage, or through log exposure. This creates a credential-replay surface that ADR-0002 (no stored credentials) is specifically designed to eliminate.

Agent-mediated re-enrollment

A support agent collects identity-verification signals (date of birth, last four of payment card, account history, recent activity details) and, after a threshold of confidence, manually triggers a passkey re-enrollment link or session.

Rejected. Social engineering is a known attack against fintech support workflows. A sufficiently motivated attacker can acquire personal details (DOB, last four digits of a public card, account history gleaned from breached datasets) and use them to convince an agent that they are the legitimate account holder. At Raxx's current scale, there is no dedicated, trained trust-and-safety team capable of running this verification safely. Building the procedure before the team exists is building the vulnerability before the defense.

More concretely: the support team is the weakest link in any agent-mediated flow. Adding a procedure that requires agents to make high-stakes identity judgments under time pressure (frustrated customers, social pressure) is a procedure that will eventually be abused. We are too small to staff this safely.

SMS / OTP fallback

A code sent to a verified phone number on file.

Rejected on three independent grounds:

1. SIM-swap risk. SIM-swapping attacks are documented and repeatable. An attacker who successfully ports a customer's phone number receives the OTP. For a financial-services platform, this is a known and unacceptable vector.
2. Provider deliverability. SMS delivery is not guaranteed. Deliverability degrades internationally, at peak load, and due to carrier filtering. A recovery path that fails silently or inconsistently is worse than no recovery path, because it creates a false expectation.
3. Customer fatigue and desensitization. A customer who regularly receives recovery SMS codes as part of account flow will be less vigilant when a code arrives unexpectedly — which is precisely when an attacker would send one.

Identity-verification re-enrollment (DOB + payment method + manager approval)

A more rigorous version of agent-mediated re-enrollment, requiring more signals and a second-operator approval gate.

Not built for the same reasons as agent-mediated re-enrollment, compounded. More rigorous verification procedures create more friction in the legitimate case and do not eliminate the social-engineering risk in the attack case — they raise the bar, but a sufficiently determined attacker clears a higher bar if the reward is high enough. Financial accounts are high-reward targets. We decline to build a verification procedure that creates a documented attack recipe.

References

• ADR-0001 — WebAuthn / passkeys only
• ADR-0002 — No stored credentials
• ADR-0003 — GDPR by default
• ADR-0031 — Platform auth posture
• docs/security/auth-posture.md §11 — Customer account recovery policy
• Issue #651 — Customer support epic (parent)
• Issue #670 — Implementation card (multi-passkey enrollment + backup codes)
• Issue #672 — This doc's companion card (auth posture update + ADR)