Passkeys Are Taking Over in 2026—The Part Nobody Warned You About Is ‘Device Recovery’ (and it’s where accounts go to die)
Passkeys don’t just remove passwords—they move failure into recovery. Lose a device, botch platform recovery, or hit a brittle “can’t sign in” flow and you can be locked out for good.
By TheMurrow Editorial
February 28, 2026
Key Points
- 1Recognize passkeys shift risk from phishing to recovery—lose a device or platform account and your “secure” logins can vanish.
- 2Choose wisely between device-bound and synced passkeys: one resists cloud compromise, the other survives device loss but hinges on account recovery.
- 3Build redundancy across device, vault, and website recovery now—before a new phone, stolen SIM, or locked “can’t sign in” flow strands you.
The great promise of passkeys is simple: you can’t be tricked into typing your login into a fake site if you never type a login at all. The private credential stays on your device; the service keeps only a public key. Phishing—still the workhorse of account takeovers—loses its favorite handle.
The catch is quieter, and more consequential. Passwords fail politely. You forget one, you reset it, you move on. Passkeys fail structurally. If your phone is gone, your laptop is wiped, or your platform account recovery goes sideways, you can be locked out of the very accounts passkeys were supposed to protect.
What’s emerging, as Apple, Google, and Microsoft push passkeys deeper into consumer sign-ins, is a new center of gravity: recovery. Not the cryptography. Not the “passwordless” marketing. Recovery—of devices, of credential managers, of the services you’re trying to reach—is now where both users and attackers will spend their time.
“Passkeys don’t eliminate risk; they relocate it—from typing secrets to recovering access.”
— — TheMurrow Editorial
Passkeys, explained like an adult: the credential you can’t be phished for
A passkey is a login credential built on FIDO/WebAuthn standards. A service stores a public key tied to your account; the matching private key remains on (or protected by) your device or credential manager. When you sign in, your device proves it holds the private key—without revealing it.
Microsoft’s consumer rollout frames the core benefit plainly: because the credential is cryptographically bound to the legitimate site or app, passkeys are phishing-resistant in a way passwords are not. A lookalike login page can’t “capture” what you never submit. (Microsoft Security blog, May 2, 2024)
That design changes the stakes for everyday users. Password systems assume forgetfulness and compensate with reset links. Passkey systems assume stronger proof of possession—and that shifts the failure mode. The FIDO Alliance has been blunt about the tension: if recovery is too strict, people get locked out; if recovery is too lenient, attackers walk through the side door. (FIDO Alliance white paper on high-assurance enterprise FIDO authentication)
Microsoft’s consumer rollout frames the core benefit plainly: because the credential is cryptographically bound to the legitimate site or app, passkeys are phishing-resistant in a way passwords are not. A lookalike login page can’t “capture” what you never submit. (Microsoft Security blog, May 2, 2024)
That design changes the stakes for everyday users. Password systems assume forgetfulness and compensate with reset links. Passkey systems assume stronger proof of possession—and that shifts the failure mode. The FIDO Alliance has been blunt about the tension: if recovery is too strict, people get locked out; if recovery is too lenient, attackers walk through the side door. (FIDO Alliance white paper on high-assurance enterprise FIDO authentication)
The real security story is not sign-in—it’s the “can’t sign in” screen
The login prompt looks elegant: Face ID, fingerprint, a screen lock. The chaos begins when those signals disappear—because the device is lost, the biometric sensor fails, or you’re setting up a new phone on a rushed Monday morning. A passkey is not a password you can remember later. It’s a key that either exists in your trusted environment, or doesn’t.
Practical implication: treat passkeys as a security upgrade plus a recovery planning problem. The cryptography is doing its job. Your preparedness often isn’t.
Practical implication: treat passkeys as a security upgrade plus a recovery planning problem. The cryptography is doing its job. Your preparedness often isn’t.
Key Insight
Passkeys reduce phishing by design—but they also force you to plan for what happens when your device, vault, or platform account isn’t available.
Two kinds of passkeys, two very different failure modes
Passkeys arrive in two broad flavors, and the difference matters most on the worst day: the day you lose the device that “has your login.”
Device-bound passkeys: safer from the cloud, harsher on the user
A device-bound passkey lives only on one device or a hardware security key. There is no cross-device syncing fabric to rescue you if your phone is destroyed or factory-reset.
The benefit is straightforward: fewer dependencies on a platform account. The cost is also straightforward: device loss can become credential loss. If the relying party (the website or app you’re trying to sign into) doesn’t offer a robust recovery method, you can lose access.
Real-world example: a user stores a device-bound passkey on a single phone. The phone is stolen, then wiped. Even if the user knows their email address and old password (if one exists), the service may prioritize the passkey and push the user into a brittle recovery funnel.
The benefit is straightforward: fewer dependencies on a platform account. The cost is also straightforward: device loss can become credential loss. If the relying party (the website or app you’re trying to sign into) doesn’t offer a robust recovery method, you can lose access.
Real-world example: a user stores a device-bound passkey on a single phone. The phone is stolen, then wiped. Even if the user knows their email address and old password (if one exists), the service may prioritize the passkey and push the user into a brittle recovery funnel.
Synced passkeys: easier life, bigger “account recovery” target
A synced passkey lives inside a credential manager that can synchronize across devices—Apple’s iCloud Keychain, Google Password Manager, Microsoft’s password manager in Edge on Windows, and third-party managers.
The upside is what most consumers want: you buy a new phone, sign into your platform account, and your passkeys reappear. The downside is what security engineers worry about: a synced passkey is only as secure as the platform account and its recovery process. (FIDO Alliance)
The upside is what most consumers want: you buy a new phone, sign into your platform account, and your passkeys reappear. The downside is what security engineers worry about: a synced passkey is only as secure as the platform account and its recovery process. (FIDO Alliance)
“Synced passkeys trade one risk—phishing—for another: platform account recovery.”
— — TheMurrow Editorial
For readers, the decision is less ideological than practical. Do you prefer the independence of a local credential that can’t be “cloud recovered,” or the resilience of syncing that can save you after device loss? There is no free lunch—only different bills.
Device-bound vs. synced passkeys (what you’re really choosing)
Before
- Device-bound — fewer cloud dependencies; loss of device can mean loss of credential; recovery depends heavily on the website/app
After
- Synced — easy migration to new devices; security hinges on platform account + its recovery; bigger target for attackers
The three-layer recovery trap: device, vault, and website
When passkeys “fail,” they rarely fail in one place. Most people confront three overlapping recoveries, each with its own rules and single points of failure:
1) Device unlock recovery (PIN/biometric access)
2) Passkey provider recovery (Apple/Google/Microsoft/1Password vault access)
3) Relying party recovery (the website/app’s “can’t sign in” flow)
A new phone scenario illustrates the trap. You’ve replaced your device. You attempt to sign in to a bank or email provider. The service asks for a passkey. Your passkey is synced—great. But to unlock the synced vault, the platform account demands proof you’re you. Now you’re in layer two before layer three even begins.
Failure at any layer can stop the chain. Lose the ability to unlock the phone? You can’t access the passkeys. Lose the platform account? The synced passkeys might as well not exist. Lose the relying party’s recovery channel? You can’t reach the account even if your platform access returns.
1) Device unlock recovery (PIN/biometric access)
2) Passkey provider recovery (Apple/Google/Microsoft/1Password vault access)
3) Relying party recovery (the website/app’s “can’t sign in” flow)
A new phone scenario illustrates the trap. You’ve replaced your device. You attempt to sign in to a bank or email provider. The service asks for a passkey. Your passkey is synced—great. But to unlock the synced vault, the platform account demands proof you’re you. Now you’re in layer two before layer three even begins.
Failure at any layer can stop the chain. Lose the ability to unlock the phone? You can’t access the passkeys. Lose the platform account? The synced passkeys might as well not exist. Lose the relying party’s recovery channel? You can’t reach the account even if your platform access returns.
Why “structural failure” is the new consumer pain point
Passwords are portable and duplicable—dangerously so. Passkeys are intentionally non-portable in the old sense. The portability comes from trusted syncing, not from memorization. That’s a security win, until life happens.
Practical takeaway: When you adopt passkeys, you are also choosing a recovery architecture. Most people don’t realize they’ve made that choice until they’re standing in a checkout line, locked out of the account that holds their boarding pass.
Practical takeaway: When you adopt passkeys, you are also choosing a recovery architecture. Most people don’t realize they’ve made that choice until they’re standing in a checkout line, locked out of the account that holds their boarding pass.
What “recovery” really means with passkeys
Passkey failure is rarely one problem. It’s a chain: (1) unlock the device, (2) unlock the passkey vault/platform account, (3) satisfy the website/app’s recovery rules.
Apple’s recovery bargain: iCloud Keychain can save you—if you prepared
On Apple devices, passkeys typically sync via iCloud Keychain when enabled. For users with multiple Apple devices, the experience can feel seamless: create on iPhone, sign in on Mac, approve with Face ID, done. The recovery story is less visible, and therefore more dangerous.
Apple documents pathways for recovering iCloud Keychain data even if all devices are lost or stolen, but those paths depend on preconditions many people haven’t set up. Apple describes options that can involve a Recovery Contact (if configured ahead of time) and/or iCloud Keychain escrow recovery protected by strict conditions. Apple also says it cannot read the escrowed data; recovery can require SMS to a trusted phone number plus the device passcode. (Apple Support documentation)
Those dependencies matter. A trusted phone number that you can’t access—because you changed carriers, lost the SIM, or the number was ported—becomes a gate. A device passcode you haven’t typed in months becomes a memory test under stress.
Apple documents pathways for recovering iCloud Keychain data even if all devices are lost or stolen, but those paths depend on preconditions many people haven’t set up. Apple describes options that can involve a Recovery Contact (if configured ahead of time) and/or iCloud Keychain escrow recovery protected by strict conditions. Apple also says it cannot read the escrowed data; recovery can require SMS to a trusted phone number plus the device passcode. (Apple Support documentation)
Those dependencies matter. A trusted phone number that you can’t access—because you changed carriers, lost the SIM, or the number was ported—becomes a gate. A device passcode you haven’t typed in months becomes a memory test under stress.
The 10-attempt limit: a small detail with big consequences
Apple notes a 10-attempt limit for authentication attempts during recovery. After too many failures, the record can be locked, and the user may need to contact Apple Support to regain more attempts. (Apple Support)
That number—10—is the kind of statistic people glance past until it’s their tenth try. It also reveals Apple’s posture: recovery is treated as a high-risk moment, so attempts are deliberately limited.
That number—10—is the kind of statistic people glance past until it’s their tenth try. It also reveals Apple’s posture: recovery is treated as a high-risk moment, so attempts are deliberately limited.
10
Apple documents a 10-attempt limit during certain recovery authentication flows—after which you may need Apple Support to regain attempts.
“Recovery is a security event, not a customer-service formality.”
— — TheMurrow Editorial
Practical takeaways for Apple users
- ✓Set up Recovery Contacts before you need them.
- ✓Keep your trusted phone number current and reachable.
- ✓Record and securely store your device passcode somewhere safe (not in your head alone).
Google’s approach: encryption, a PIN, and humans you can call when it all breaks
Google’s passkeys can be saved and synced via Google Password Manager across Android and desktops. The company has been adding explicit controls that acknowledge the obvious: a synced vault is only as safe as the mechanism to unlock it.
In September 2024, Google introduced a Google Password Manager PIN to help protect end-to-end encrypted access to synced passkeys across devices. When setting up on a new device, users need either that Password Manager PIN or the screen lock for an Android device as a recovery factor to access synced passkeys. (Google blog)
Two details are worth sitting with:
- The mechanism is designed for cross-device recovery without simply “emailing you a reset link.”
- The mechanism still creates a critical dependency: lose your PIN and lose your screen lock access, and the vault can become inaccessible.
In September 2024, Google introduced a Google Password Manager PIN to help protect end-to-end encrypted access to synced passkeys across devices. When setting up on a new device, users need either that Password Manager PIN or the screen lock for an Android device as a recovery factor to access synced passkeys. (Google blog)
Two details are worth sitting with:
- The mechanism is designed for cross-device recovery without simply “emailing you a reset link.”
- The mechanism still creates a critical dependency: lose your PIN and lose your screen lock access, and the vault can become inaccessible.
Recovery Contacts: a safety net—and a new social-engineering target
On October 15, 2025, Google announced Recovery Contacts as an account recovery option, explicitly including lockout scenarios like losing the device that holds a passkey. (Google blog)
This is a humane design choice: most people do have someone they trust. It’s also a security compromise. Independent coverage has warned that adding humans to recovery expands exposure to social engineering—attackers manipulating victims into choosing the wrong contact, or manipulating the contact into approving access. (Forbes coverage)
Google is making a bet: that carefully designed human-in-the-loop recovery can reduce lockouts without becoming a standing invitation to scammers. Readers should see that bet clearly. You are not merely selecting a friend; you are designating a potential pathway into your account.
This is a humane design choice: most people do have someone they trust. It’s also a security compromise. Independent coverage has warned that adding humans to recovery expands exposure to social engineering—attackers manipulating victims into choosing the wrong contact, or manipulating the contact into approving access. (Forbes coverage)
Google is making a bet: that carefully designed human-in-the-loop recovery can reduce lockouts without becoming a standing invitation to scammers. Readers should see that bet clearly. You are not merely selecting a friend; you are designating a potential pathway into your account.
The push for phone-based re-entry
Coverage also points to an Android feature described as “Sign in with Mobile Number,” aimed at easing re-entry when switching phones. The rollout has been described as gradual and Android-specific.
Practical takeaways for Google users
- ✓Set a Password Manager PIN you can actually reproduce under stress.
- ✓Choose Recovery Contacts who are skeptical, patient, and hard to pressure.
- ✓Treat any recovery prompt as suspicious until verified out-of-band.
Sep 2024
Google introduced a Password Manager PIN to protect end-to-end encrypted access to synced passkeys across devices.
Oct 15, 2025
Google announced Recovery Contacts as an account recovery option, including lockout scenarios like losing the passkey-holding device.
The new attack surface: “account recovery” becomes the easiest way in
Passkeys blunt classic phishing because there’s no password to steal. Attackers don’t retire; they reroute. The most promising reroute is recovery, because recovery is where systems must make allowances for human messiness.
The FIDO Alliance frames the core dilemma: tighten recovery and you increase lockouts; loosen recovery and you increase compromise. That dilemma isn’t theoretical. It shows up in platform choices:
- Synced passkeys concentrate power in the platform account and its recovery workflow.
- Device-bound passkeys concentrate power in a single device and whatever backup the relying party offers.
- Human-based recovery (Recovery Contacts) concentrates power in relationships—and relationships can be manipulated.
The FIDO Alliance frames the core dilemma: tighten recovery and you increase lockouts; loosen recovery and you increase compromise. That dilemma isn’t theoretical. It shows up in platform choices:
- Synced passkeys concentrate power in the platform account and its recovery workflow.
- Device-bound passkeys concentrate power in a single device and whatever backup the relying party offers.
- Human-based recovery (Recovery Contacts) concentrates power in relationships—and relationships can be manipulated.
Multiple perspectives: usability vs. assurance
Security purists tend to prefer harsh guarantees: if you lose the key, you lose access. Consumer platforms can’t live there. People forget PINs, lose phones, and change numbers. A system that locks out ordinary users is not “secure” in any meaningful societal sense—it just moves harm from fraud to abandonment.
At the same time, consumer-friendly recovery has a cost. Any path that helps a legitimate user back in can, under pressure, help an attacker too. The question is whether platforms can raise the friction for attackers without making recovery unbearable.
Practical implication for readers: your strongest defense is not a clever trick; it’s redundancy. More than one trusted device. More than one recovery method. Less dependence on a single phone number.
At the same time, consumer-friendly recovery has a cost. Any path that helps a legitimate user back in can, under pressure, help an attacker too. The question is whether platforms can raise the friction for attackers without making recovery unbearable.
Practical implication for readers: your strongest defense is not a clever trick; it’s redundancy. More than one trusted device. More than one recovery method. Less dependence on a single phone number.
A recovery-first checklist: how to adopt passkeys without losing your life to them
Most passkey advice focuses on the moment of sign-in. The mature advice starts earlier: before you create passkeys for high-value accounts, make sure you can recover them.
Build redundancy across the three layers
Device layer
- Maintain at least one additional signed-in device where possible (a tablet or laptop).
- Don’t rely solely on biometrics; know your device PIN/passcode.
Passkey provider layer
- For Apple: enable iCloud Keychain deliberately and set up Recovery Contacts.
- For Google: set up a Google Password Manager PIN and ensure your Android screen lock is stable and memorable.
Relying party layer
- Confirm the service still supports a secondary sign-in method (some retain passwords, backup codes, or support-based recovery).
- For critical accounts (email, banking), review the “can’t sign in” flow now—when you’re calm.
- Maintain at least one additional signed-in device where possible (a tablet or laptop).
- Don’t rely solely on biometrics; know your device PIN/passcode.
Passkey provider layer
- For Apple: enable iCloud Keychain deliberately and set up Recovery Contacts.
- For Google: set up a Google Password Manager PIN and ensure your Android screen lock is stable and memorable.
Relying party layer
- Confirm the service still supports a secondary sign-in method (some retain passwords, backup codes, or support-based recovery).
- For critical accounts (email, banking), review the “can’t sign in” flow now—when you’re calm.
Recovery-first actions (quick scan)
- ✓Maintain at least one additional signed-in device.
- ✓Know (and be able to re-enter) your PIN/passcode.
- ✓Enable syncing intentionally (or commit to device-bound + backups).
- ✓Configure platform recovery options (PINs, Recovery Contacts, trusted numbers).
- ✓Verify every critical site’s “can’t sign in” flow before you need it.
Case study: the “new phone” failure cascade
Consider a common scenario: you upgrade your phone, trade the old one in, and discover you can’t log in to your email.
- Device recovery fails if you don’t remember the old passcode needed for restoring encrypted data.
- Passkey provider recovery fails if your trusted phone number is inaccessible or your vault PIN is forgotten.
- Relying party recovery fails if the email account is the recovery for everything else—creating a circular dependency.
The fix is rarely clever. It’s procedural: ensure at least one non-phone pathway exists before you switch phones, and avoid making a single account the key to your entire digital life.
- Device recovery fails if you don’t remember the old passcode needed for restoring encrypted data.
- Passkey provider recovery fails if your trusted phone number is inaccessible or your vault PIN is forgotten.
- Relying party recovery fails if the email account is the recovery for everything else—creating a circular dependency.
The fix is rarely clever. It’s procedural: ensure at least one non-phone pathway exists before you switch phones, and avoid making a single account the key to your entire digital life.
“A passkey is strongest when it has a second place to live—and a second way to come back.”
— — TheMurrow Editorial
Where this is heading: passkeys will be normal, and recovery will be policy
Passkeys are becoming standard across major ecosystems, and the direction of travel is clear: fewer passwords, more device-bound proofs, more reliance on platform identity. Microsoft’s consumer push, Apple’s iCloud Keychain syncing, and Google’s PIN and Recovery Contacts all point in the same direction.
The open question is whether recovery can mature without becoming the next scammer’s favorite script. The early signs are mixed in an instructive way:
- Apple emphasizes strict gating (including a 10-attempt limit) and pre-configured options like Recovery Contacts, implying a preference for controlled recovery over frictionless rescue.
- Google is layering in encryption protection via a Password Manager PIN and adding social recovery via Recovery Contacts, acknowledging both technical and human realities.
Readers don’t need to pick a side in a platform war. The real lesson is broader: authentication has finally become harder to steal—and now it must become harder to lose. The future of “passwordless” won’t be decided by how smooth the Face ID prompt feels. It will be decided by what happens after your phone falls into a lake.
The open question is whether recovery can mature without becoming the next scammer’s favorite script. The early signs are mixed in an instructive way:
- Apple emphasizes strict gating (including a 10-attempt limit) and pre-configured options like Recovery Contacts, implying a preference for controlled recovery over frictionless rescue.
- Google is layering in encryption protection via a Password Manager PIN and adding social recovery via Recovery Contacts, acknowledging both technical and human realities.
Readers don’t need to pick a side in a platform war. The real lesson is broader: authentication has finally become harder to steal—and now it must become harder to lose. The future of “passwordless” won’t be decided by how smooth the Face ID prompt feels. It will be decided by what happens after your phone falls into a lake.
3
Passkey lockouts often require clearing three overlapping recoveries: device unlock, passkey provider vault/platform access, and the website/app’s own recovery flow.
1) What exactly is a passkey, and why is it phishing-resistant?
A passkey is a FIDO/WebAuthn credential. A service stores a public key, while your device or credential manager protects the matching private key. You don’t type a secret into a website, so a fake login page can’t capture it. Microsoft emphasizes that the credential is bound to the legitimate site/app, which blocks classic phishing tricks.
2) If I lose my phone, do I lose my accounts?
It depends on whether your passkeys are device-bound or synced. Device-bound passkeys may be lost with the device unless the service has a separate recovery method. Synced passkeys can reappear on a new device after you recover access to the platform account or credential manager. The risk shifts from “forgot password” to “can you recover your device and vault safely?”
3) What’s the difference between iCloud Keychain passkeys and Google Password Manager passkeys?
Both can sync passkeys across devices, but their recovery mechanics differ. Apple’s iCloud Keychain recovery can rely on factors like a trusted phone number, device passcode, and pre-set Recovery Contacts, and Apple documents a 10-attempt limit during recovery. Google added a Password Manager PIN (September 2024) and later Recovery Contacts (October 15, 2025) as explicit recovery tools.
4) Are Recovery Contacts a good idea or a security risk?
Both. Recovery Contacts can prevent lockouts when a device holding a passkey is lost, which Google explicitly cites as a target scenario. The tradeoff is social-engineering exposure: attackers may manipulate you into choosing the wrong contact or pressure the contact during recovery. Choose contacts who are cautious, hard to rush, and willing to verify requests through a separate channel.
5) What should I do before switching to a new phone?
Treat it like moving house: secure the keys before you pack the boxes. Make sure you can unlock your old device (know the passcode), confirm access to your platform account, and verify that your passkeys are syncing. Review the “can’t sign in” options for critical services ahead of time. Avoid relying on a single phone number or single device as your only recovery path.
6) Why do platforms limit recovery attempts (like Apple’s 10 tries)?
Recovery is a high-risk moment: it’s when attackers try to impersonate you. Apple notes a 10-attempt limit for authentication attempts during certain recovery processes; too many failures can lock the record, requiring Apple Support to regain attempts. Limits like this reduce brute-force guessing and add friction where the stakes are highest.
7) Are passkeys worth it if recovery is so complicated?
Yes—if you plan for recovery. Passkeys reduce exposure to phishing by design, which is a meaningful security improvement. The cost is that you must take recovery seriously: maintain redundancy (more than one device when possible), configure platform recovery options (PINs, Recovery Contacts), and understand relying-party fallback flows. Passkeys improve security most when paired with deliberate recovery hygiene.
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering how-to / guides.
Frequently Asked Questions
What exactly is a passkey, and why is it phishing-resistant?
A passkey is a FIDO/WebAuthn credential. A service stores a public key, while your device or credential manager protects the matching private key. You don’t type a secret into a website, so a fake login page can’t capture it. Microsoft emphasizes that the credential is bound to the legitimate site/app, which blocks classic phishing tricks.
If I lose my phone, do I lose my accounts?
It depends on whether your passkeys are device-bound or synced. Device-bound passkeys may be lost with the device unless the service has a separate recovery method. Synced passkeys can reappear on a new device after you recover access to the platform account or credential manager. The risk shifts from “forgot password” to “can you recover your device and vault safely?”
What’s the difference between iCloud Keychain passkeys and Google Password Manager passkeys?
Both can sync passkeys across devices, but their recovery mechanics differ. Apple’s iCloud Keychain recovery can rely on factors like a trusted phone number, device passcode, and pre-set Recovery Contacts, and Apple documents a 10-attempt limit during recovery. Google added a Password Manager PIN (September 2024) and later Recovery Contacts (October 15, 2025) as explicit recovery tools.
Are Recovery Contacts a good idea or a security risk?
Both. Recovery Contacts can prevent lockouts when a device holding a passkey is lost. The tradeoff is social-engineering exposure: attackers may manipulate you into choosing the wrong contact or pressure the contact during recovery. Choose contacts who are cautious, hard to rush, and willing to verify requests through a separate channel.
What should I do before switching to a new phone?
Make sure you can unlock your old device (know the passcode), confirm access to your platform account, and verify that your passkeys are syncing. Review the “can’t sign in” options for critical services ahead of time. Avoid relying on a single phone number or single device as your only recovery path.
Why do platforms limit recovery attempts (like Apple’s 10 tries)?
Recovery is a high-risk moment where attackers try to impersonate you. Apple notes a 10-attempt limit during certain recovery processes; too many failures can lock the record, requiring Apple Support to regain attempts. Limits reduce brute-force guessing and add friction where the stakes are highest.
