Account recovery guide
Use case
Add context without locking out recovery
Recovery is both high-impact and accessibility-critical. Device observations can support review, but the account must remain recoverable when telemetry is absent or unexpected.
Recovery event flow
Use a short-lived recovery_attempt ID as action_id. Do not expose whether an account exists when creating the attempt.
Mobile collection
const recoveryIntel = new DeviceIntel({
consent: consentFor([
"device_identity",
"application",
"os_integrity",
"device_security_posture",
"network",
"locale",
"runtime",
]),
});
const observations = await recoveryIntel.collect({
sessionId: recoveryAttempt.id,
});
await api.post("/api/v1/device-signal-events", {
action_id: recoveryAttempt.id,
action_type: "recovery_attempt",
sdk_version: SDK_VERSION,
platform: Platform.OS,
observations,
});Do not attach clientId unless the application already has an authenticated account session. The server owns account lookup and challenge verification.
Backend use
Primary evidence
Recovery codes, passkeys, verified channels, support review, and authenticated server history remain primary.
Contextual evidence
App provenance, integrity, device lock capability, network context, and locale can help explain an attempt.
Auditability
Store feature versions and reason codes separately from the immutable raw event so decisions can be reconstructed.
Missing data is expected
Permissions, OS versions, hardware, probe timeouts, privacy choices, and collection failures all affect availability. Preserve omission, skipped, timeout, error, and observed false as distinct states.