What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A passkey cannot be recovered by the server. If a user loses the only device or synchronized account that holds the private key, the relying party has no way to rebuild it. Your application therefore needs a separate, deliberately designed recovery path: a second registered authenticator, a set of single-use recovery codes, or both. This guide explains how to build those fallbacks in a Node.js service, what the standards require, and where the common mistakes happen.
Why recovery is part of the passkey design
WebAuthn authenticates with a public-key credential. Your server stores the credential ID and the public key, while the private key never leaves the authenticator. That split is what makes passkeys resistant to phishing and credential theft, and it is also why losing the authenticator can lock a user out. The private key cannot be exported from your side or regenerated on it.
The W3C Web Authentication Level 4 Working Draft (dated 2026-09-15, and still subject to change) says that Relying Parties should ensure each user account has additional authenticators registered and/or an account recovery process in place. The specification does not prescribe one recovery ceremony. That leaves the design to you, and the rest of this guide follows from that choice.
Know what synced passkeys do and do not cover
Synced passkeys, held by a platform credential manager, can make the same credential available on several devices. That covers the common case of replacing a phone when the user still has access to the synchronizing account. It does not cover every failure. A user who loses access to that account, or who never enabled synchronization, may have no copy of the credential at all. Build your recovery flow for that case rather than assuming sync will always be present.
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
NIST’s guidance on backup flags is relevant here. Passkey backup eligibility indicates that a credential can be synchronized, and backup state indicates that it has actually been synchronized. These are different signals. NIST cautions against making public-facing acceptance decisions depend on the backup-state flag, so do not use it as a gate for whether a login or recovery is allowed. Store it for information and support analysis.
Registration and authentication lifecycle
The recovery endpoint depends on the state that registration and authentication store, so define that lifecycle first. The examples below use the SimpleWebAuthn server library (documentation for version 14.0.x), but the same responsibilities apply to any WebAuthn server.
Rank #2
- POWERFUL SECURITY KEY: The YubiKey 5C NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5C NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5C NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Registration
- Generate a server challenge for the registration request and keep it server-side, bound to the user and session.
- Set the relying-party ID and expected origin explicitly in configuration rather than deriving them from request headers.
- On response, verify the challenge, origin, and RP ID before trusting the credential.
- Persist the credential ID, public key, signature counter, transports, device type, and backup state when the library returns them.
Authentication
- Create authentication options for the account and store the challenge with a short expiry.
- Verify the assertion against the expected challenge, origin, RP ID, and the stored credential for that user.
- On success, write back the new counter value for that credential.
The counter deserves caution. A counter that fails to increase can indicate a cloned or misbehaving authenticator, but some authenticators legitimately always report zero. Log counter anomalies and review them, but do not treat the counter as a universal clone detector that alone should block a login.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Designing backup codes correctly
Saved recovery codes are a practical fallback for users with no usable authenticator. NIST SP 800-63B, section 4.2.1, sets the baseline. Each code should carry at least 64 bits of randomness. The verifier stores only a hash of each code, the verification attempts are throttled, and each code is invalidated and replaced after use. The user keeps the codes offline and secure. NIST also notes that a saved code may be presented as numeric or printable ASCII for manual entry, or as a machine-readable optical label such as a QR code.
Rank #3
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Generating codes
Use a cryptographically secure random source. The following sketch produces 80 bits of randomness per code, which exceeds the 64-bit floor:
const crypto = require('node:crypto');
function newRecoveryCode() {
// 10 random bytes = 80 bits of entropy
return crypto.randomBytes(10).toString('hex');
}
function hashRecoveryCode(code) {
// Only the hash is stored. Codes are high-entropy, so a fast hash is acceptable here.
return crypto.createHash('sha256').update(code).digest('hex');
}Show the plaintext codes to the user once, at generation time, and never again. Store the hashes with the user ID, a creation timestamp, and a nullable used_at column.
Rank #4
- POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Verifying and consuming a code
Comparison should be constant-time. Compare the hashes with crypto.timingSafeEqual or perform a hashed lookup, then consume the code in a single conditional write so that two concurrent requests cannot both succeed:
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →UPDATE recovery_codes
SET used_at = now()
WHERE user_id = $1
AND code_hash = $2
AND used_at IS NULL;Accept the recovery only if the statement affects exactly one row. If it affects zero rows, treat the attempt as a failure, and count it toward throttling.
Best Value
- Security Key : Protect your online accounts against unauthorized access by using FIDO2 and U2F authentication with T110. It's the world's most protective security key that works with windows, Mac OS, Linux as well as Chrome, Firefox, Edge and many other major browsers.
- Certified with the new FIDO2 standard, T110 provides the benefit of fast login and strong protection against phishing, account takeover as well as many other online attactks.
- Works with : Bank of America, Github, Google, Microsoft, DUO, Twitter, Facebook, Dropbox, Apple, ebay, BINANCE, mor and more.
- Fits USB-A port : Insert the T110 security key into the USB-A port of each service and log in conveniently with one touch
- For the driver download and user guide, please visit TrustKey Solutions Home support page.
Throttling and replacement
- Apply throttling per account and per source, with increasing delays or a temporary lock after repeated failures.
- After a successful use, invalidate that code and, when the user’s remaining set runs low, offer to generate a fresh set. Invalidate the old set when a new one is issued.
- Notify the user by an existing verified channel whenever codes are regenerated.
A recovery flow that does not treat codes as assertions
The most important design rule is that a backup code is not a WebAuthn assertion. Do not feed it into the passkey verification path or mark the session as having completed a passkey login. Recovery is a separate, state-changing process with its own audit trail.
- The user chooses Can’t use my passkey on the sign-in page and enters the account identifier.
- The server checks the throttling state for that account and returns a generic response that does not reveal whether the account exists.
- The user submits a recovery code. The server validates and consumes it as described above.
- On success, the server starts a restricted recovery session that can do only one thing: enroll a new passkey or an additional authenticator.
- The new credential is registered through the same registration checks used at signup.
- The server revokes or flags the lost authenticator according to your risk policy, writes an audit event, and notifies the user.
- The server issues a new recovery code set, because the user has just used one.
Your policy may require more than a code before enrollment, such as a verified email or phone, a waiting period, or a review step for high-risk accounts. NIST’s account recovery guidance recognizes saved codes, issued codes, recovery contacts, and repeated identity proofing as recovery method classes, and says the chosen mix should follow a documented risk analysis.
Comparing recovery options
| Option | What it helps with | Limits and trade-offs |
|---|---|---|
| Synced passkey | Restores the same credential on new devices while the user can access the synchronizing account. | Fails if the user loses access to that account or never enabled sync. The relying party still needs a recovery route. |
| Additional registered authenticator | A second phone, computer, or hardware security key lets the user sign in after losing the first. | Must be registered before the loss. It is redundancy, not a way to recreate the lost private key. |
| Saved recovery code | A fallback when no usable authenticator is available. | Codes are bearer secrets. They need high entropy, hashed storage, throttling, one-time use, and secure offline storage by the user. |
| Issued code or identity recovery | Helps when saved codes and authenticators are all unavailable. | Delivery channels and identity proofing create their own takeover risks, so they should follow a documented risk analysis. |
Compare options on four things: whether the user regains access after device loss, how well the method resists account takeover, how much operational work it adds, and how long recovery takes. No single method is safest in every case. Name the threat model before choosing.
Troubleshooting common failures
- Recovery codes accepted twice: the consume step is not atomic. Use a conditional update and check the affected-row count.
- Passkey login fails after a clone-check alert: the counter returned zero or did not advance on a legitimate authenticator. Review logs rather than blocking on the counter alone.
- Users locked out of passkey sign-in on new devices: the account has only one registered authenticator and no unused recovery code. Prompt users to register a second authenticator at signup and after each successful sign-in.
- Origin or challenge errors on recovery: the recovery flow reuses an expired or session-mismatched challenge. Issue a fresh challenge for each enrollment attempt.
Implementation checklist
- Store credential IDs, public keys, counters, transports, device type, and backup state from registration.
- Verify challenge, origin, and RP ID on every registration and authentication.
- Generate recovery codes with at least 64 bits of randomness and store only hashes.
- Consume codes atomically, throttle attempts, and replace codes after use.
- Keep recovery in its own restricted flow, with audit logging and user notification.
- Encourage users to register a second authenticator before they need it.
Passkey recovery is an account-design problem as much as a cryptography problem. The standards give you the floor. The fallback routes you choose determine whether a user who loses a phone can still get back in safely.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
