Don't Guess Wrong: Apple, Google, and the Memory Science Behind Account Lockouts

The password you entered is wrong. Stop. Breathe. Think. And you won't get locked out.

TL;DR

When you sit down to type a password, you either know it or you don't. If you're consulting a piece of paper, you don't know it — you're transcribing. If it's not in a password manager that copy-pastes a known-good string, you don't have a verified credential. The two ecosystems then diverge sharply: Apple locks accounts after repeated wrong guesses and pushes you into a recovery flow whose worst-case wait time is "several days or longer." Google escalates sign-in friction (CAPTCHA, 2FA, recovery prompts) but explicitly states there is no limit on attempts inside the recovery process itself. The same operating rule covers both: stop after the second wrong attempt, every time, and start the recovery flow on purpose instead of stumbling into it — for Apple to avoid the lockout, for Google to avoid burning attempts on guesses when you should be assembling your recovery information.

The Moment I Catch in Almost Every Session

I am sitting next to a client. We open a browser. They type their Gmail address, hit Tab, and fire off a password. Wrong. Without pausing — without even letting their hands settle — they type the same thing again. Wrong. They go for a third. That is the moment I put a hand up and say stop.

What I am stopping is not a typo. Typos resolve themselves on the second attempt. What I am stopping is a behavioral loop: the brain is generating a feeling of near-recognition (it's right there, I almost have it), the body is converting that feeling into action, and three rapid identical guesses are about to escalate the system against the user — and on Apple, commit them to a multi-day recovery process they did not consent to.

The moral is simple, and it is the entire point of this note: don't guess wrong. You either know the password — in the bet-your-day-on-it sense — or you don't. There is no middle state worth typing.

Why "I Almost Know It" Is a Lie Your Brain Tells You

Decades of cognitive-psychology research describe exactly the trap that snaps shut on the third guess.

Tip-of-the-tongue states feel like retrieval but aren't. Brown and McNeill's classic 1966 study established that the subjective sense of being "on the verge" of recalling something is a metacognitive signal — accompanied by partial information, similar-sounding intrusions, and strong feelings of imminence — rather than evidence that the target itself is available. Subsequent work has confirmed that the signal is informative on average but not reliable at the level of any single attempt ¹².

Your sense of knowing is calibrated by partial information, not by the actual presence of the answer. Koriat's accessibility model of feeling-of-knowing shows that subjective confidence is driven by how much related material your brain can dredge up — letter counts, syllable shapes, the year you set the password, the laptop you set it on. None of that material is the password. You can have a strong feeling of knowing and an empty hand at the same time ³.

Source-monitoring errors do the rest. When you have set fifty passwords across thirty services across ten years, your brain stores the fragments without high-fidelity tags about which fragment came from which account. I think I changed this one to the dog's name plus the year — was that this account, or the one before it, or the one you set up for your spouse? Source-monitoring failures are the rule, not the exception ⁴.

Old passwords actively interfere with new ones. Proactive interference — the principle that prior learning blocks the recall of subsequent learning — is one of the oldest, best-replicated findings in memory research ⁵. The application to passwords here is interpretive, not directly tested in the original studies, but it is a clean fit: every previous password for the same account is a competitor at retrieval, which is also why the long-deprecated practice of forced periodic password rotation was so destructive — it manufactured proactive interference on a schedule.

And the reason you keep guessing is not really about the password. Sunk-cost reasoning is well documented across decision making: the more effort you have already invested in a course of action, the harder it is to abandon it ⁶. Three failed attempts make the fourth feel justified. The fourth makes the fifth feel inevitable. By then you are not solving the problem; you are paying for the previous failures with new ones.

The Paper Test

Here is a rule I give every client, and I have yet to see it fail:

If you are reading the password from a piece of paper, you do not know it. You are transcribing.

Transcription is not retrieval. It is a separate cognitive task with its own error rate, and the error rate is not zero — anyone who has copied a long alphanumeric string from a sticky note knows this. Worse, paper goes stale. The site forced a change six months ago. You wrote down a variant. The handwriting is ambiguous between l and 1, between O and 0. The piece of paper is evidence of what you set the password to, at some point, on some site, possibly. It is not a working credential.

A password manager is different in one specific way that matters here: when it autofills, it sends the exact string the manager has on file. The only thing being tested is whether that string is current. If it is wrong, you learn that one fact cleanly, and you go to recovery — you don't burn three more guesses re-typing your best memory of what the manager already remembered for you.

This is the only kind of "guess" that isn't really a guess. Everything else is.

What Apple Actually Does When You Guess Wrong

Apple does not publish an exact threshold for Apple Account sign-in failures. The current support page (HT204106, rewritten on December 5, 2025) says only that an account locks "if you or someone else might have entered your password or other account information incorrectly too many times" ⁷. (An earlier version of this article cited a "six consecutive failures" threshold for accounts with hardware security keys; that figure is not in the current Apple Support documentation, and I cannot reproduce it from any current Apple primary source. The corrected guidance: assume Apple does not publish a number.)

You will see one of these alerts:

• This Apple Account has been disabled for security reasons.
• You can't sign in because your account was disabled for security reasons.
• This Apple Account has been locked for security reasons.

That is iJail. Apple's current support article (rewritten December 5, 2025) documents that some of these alerts now include a Request Access button you can tap directly from the lock alert; that route and iforgot.apple.com/unlock lead to the same recovery flow ⁷.

How long the recovery actually takes depends on what you have left to prove identity with:

• Trusted device already signed in (iPhone, iPad, or Mac): minutes to about an hour. You can reset the password directly from Settings → [Your Name] → Sign-In & Security → Change Password, and Apple's own password-reset page treats this as the fast path. With Stolen Device Protection on, Apple may impose a one-hour security delay on a password change even from a trusted device ⁸.
• Web reset without a trusted device: Apple's documented language is that the reset "might take a little longer" ⁸.
• Account Recovery (locked account, no trusted device, failed verification): Apple's documented worst case is that "it might take several days or longer before you can use your account again," and Apple states that contacting Apple Support cannot shorten this time ⁹. A paired hardware security key can unlock a frozen account on-device once you regain access — but keys are most useful for preventing lockouts, not recovering from them after the fact.

The iPhone device passcode is a separate system with a published escalation worth memorizing because it can erase your phone. The current escalation, from the Apple Platform Security Guide entry on passcodes and passwords ¹⁰, is:

• 4 wrong → 1-minute lockout
• 5 wrong → 5-minute lockout
• 6 wrong → 15-minute lockout
• 7 wrong → 1-hour lockout
• 8 wrong → 3-hour lockout
• 9 wrong → 8-hour lockout
• 10 or more wrong → device locked; must connect to a Mac or PC to restore

If Erase Data is enabled (Settings → [Face ID / Touch ID] & Passcode → Erase Data), all content and settings are removed after 10 consecutive incorrect passcode entries ¹⁰. (An earlier version of this article reported the escalation as starting at 6 attempts and topping out at "60 minutes" before disable — that table reflected a much older iOS version. The figures above are the ones Apple currently publishes; treat the published table as the source of truth and ignore older copies.)

What Google Actually Does When You Guess Wrong

Google's behavior splits cleanly into two phases — sign-in challenges, and account recovery — and they have very different attempt-cost rules.

The sign-in path is risk-based. Rather than counting attempts to a fixed number, Google's authentication system evaluates each sign-in against a model of expected behavior — same device? same network? same time of day? known location? — and escalates challenges proportionally ¹¹.

In practice, that means:

1. Wrong guesses on a known device typically prompt re-entry, then a CAPTCHA, then a secondary factor (device prompt, security key, recovery phone, recovery email). The exact sequence is not published.
2. Wrong guesses on an unknown device or network escalate faster. Google does not publish a fixed attempt count; in practice I see accounts hit a "couldn't verify it's you" dead-end in under five attempts.
3. Persistent failures push you into Account Recovery at g.co/recover.

The recovery path is where Google differs sharply from Apple. Google's own recovery page states, verbatim: "Wrong guesses won't kick you out of the account recovery process. There's no limit to the number of times you can attempt to recover your account" ¹². The recovery questionnaire collects identity signals — previous passwords, account creation date, recovery email — and Google explicitly wants your best-known information, not best-current-guess. Unlike Apple, you will not be locked out of recovery itself for trying. The friction lives in the sign-in challenges, not in the recovery flow. (An earlier version of this article said "persistent failures push you into Account Recovery, which … can take time," implying the recovery flow itself enforces wait penalties. That conflated Apple's behavior with Google's. The correction: only the sign-in side has escalating friction; the recovery side is unlimited-attempt.)

So why does the "stop after two attempts" rule still apply to Google? Because the sign-in challenges escalate based on risk, and each failed attempt makes you look more like an attacker. By the time you arrive at recovery, you want your recovery information already in hand — not after burning five attempts and triggering maximum friction.

Google Workspace accounts (the managed kind a business or school issues) inherit lockout policies from the workspace administrator and may behave differently from consumer Gmail accounts. Workspace administrators can set lockout thresholds, require specific 2FA methods, and even disable account recovery options. If you are not sure which kind you have, ask whoever set the account up before you start guessing.

The Cost Asymmetry No One Likes to Discuss

Both companies' lockout systems are designed against attackers and paid for by users. An attacker who hits a wall moves on to the next account in their list at zero personal cost. A locked-out user spends days proving their identity to a system with no human in the loop. The asymmetry is structural and probably unavoidable given the threat surface, but it is the reason a single avoidable guess can cost you a working week.

That cost is the entire reason for the protocol below.

The Don't-Guess-Wrong Protocol

When you sit down to enter a password — your own, or one you are helping a client enter — run this checklist before your fingers move:

1. Is the credential in a password manager? If yes, autofill or copy-paste. Do not retype from memory. The manager's copy is the source of truth.
2. If not, do you know it — in the bet-your-day-on-it sense? Not "I think so." Not "I almost have it." Not "let me try the usual one." If the answer is anything short of certain, treat the next step as a one-shot.
3. Type once, deliberately. Caps Lock off, correct keyboard layout, correct account selected in the email field. If it works, you're done.
4. If it fails once: pause. Confirm the email/username is right and the field has not autofilled the wrong account. Confirm the keyboard. Then allow yourself one more attempt — only if step 2 was a clear yes.
5. If it fails twice: stop. Do not type a third. For an Apple Account, tap Request Access in the lock alert (where Apple now shows it) or open iforgot.apple.com/unlock. For a Google account, open g.co/recover — there is no attempt limit inside the recovery flow, but if you are still guessing you are not helping yourself. Either way, gather your recovery information first (previous passwords, account-creation date, recovery email and phone), then start the questionnaire on purpose.

That is the whole thing. Two attempts maximum, and only the second if you genuinely passed the bet-your-day test on the first. Anything beyond that is sunk-cost reasoning paying for a feeling-of-knowing that was never going to deliver.

The clients I see get locked out are not the ones who forgot their password. They are the ones who treated the password field as a guessing game and lost.

Prevention: What to Set Up Before You Need It

The original tips below are unchanged in substance — they are the operational floor for both ecosystems. (On a Mac, look for Password & Security where iOS shows Sign-In & Security.)

For Apple

1. Use a strong, unique password — generated by a password manager, not invented at the keyboard.
2. Two-Factor Authentication — Settings → Your Name → Sign-In & Security → Two-Factor Authentication.
3. Passkeys wherever supported, plus a hardware security key (e.g., YubiKey). A paired key can unlock a frozen account once you have access.
4. Recovery Key — Settings → Your Name → Sign-In & Security → Account Recovery → Recovery Key. Print it. Store it physically. Never in Notes.
5. Recovery Contacts — Settings → Your Name → Sign-In & Security → Account Recovery → Add Recovery Contact.
6. Trusted phone number — on a Mac: System Settings → Your Name → Password & Security → Trusted Phone Numbers.
7. Watch for phishing. No legitimate Apple flow asks you to "verify" by clicking a link in an unsolicited email or handing over a verification code by phone.

For Google

1. Use a strong, unique password generated by a password manager.
2. Two-Step Verification — myaccount.google.com → Security → 2-Step Verification. Prefer device prompts or a security key over SMS.
3. Passkeys — Google has rolled them out across consumer and Workspace accounts. Set them up at myaccount.google.com/security.
4. Recovery phone and recovery email — keep both current. These are what Google leans on when the risk model challenges you.
5. Backup codes — generate them, print them, store them physically. They are your offline last resort.
6. Hardware security key for high-value accounts (the Advanced Protection Program is available to anyone, not only journalists and activists).
7. Watch for phishing. Google will never ask for a verification code by phone. The number-matching device prompt cannot be relayed; it is designed to defeat real-time phishing.

In digital security, an ounce of prevention is worth a pound of cure. With these in place, the worst-case scenario shrinks from "lose access for a week" to "stop, recover in five minutes, move on."

References

A BibTeX file for these references is available at /field-notes/apple-sends-you-to-ijail.bib for one-click import into Zotero or any reference manager.

For a second set of eyes on a stuck Apple or Google account before you start guessing, call 619-853-5008.

Last updated April 25, 2026, after a second independent re-verification pass against the absolute-latest live primary sources: Apple Support support.apple.com/en-us/102640 ("If your Apple Account is locked, not active, or disabled," published date 12/05/2025, formerly HT204106); Apple Support support.apple.com/en-us/118574 ("How to use account recovery when you can't reset your Apple Account password," published date 12/05/2025 — the source of the verbatim "it might take several days or longer" quote, which an earlier draft of this article had mis-cited to 102640); Apple Support support.apple.com/en-us/119586 (formerly HT204060, published date 01/14/2026) and the Apple Platform Security Guide entry "Passcodes and passwords" (the canonical primary source for the iPhone passcode-escalation table — verified character-for-character against the live guide); Apple Support support.apple.com/en-us/102656 ("If you forgot your Apple Account password," published date 04/21/2026 — re-confirmed the "might take a little longer" web-reset language and added the documented one-hour Stolen Device Protection security delay); Google safety.google/intl/en_us/safety/authentication/; Google Account Help support.google.com/accounts/answer/7682439 (verbatim: "Wrong guesses won't kick you out of the account recovery process. There's no limit to the number of times you can attempt to recover your account."); and the six cognitive-psychology DOIs 10.1016/S0022-5371(66)80040-3, 10.3758/s13421-010-0066-8, 10.1037/0033-295X.100.4.609, 10.1037/0033-2909.114.1.3, 10.1037/h0044616, 10.1016/0749-5978(85)90049-4. The second pass: (a) re-pointed the "several days or longer" citation from HT102640 to its actual home at HT118574; (b) removed the "iOS 26" version attribution for the Request Access button (Apple documents the button on the rewritten Dec 5, 2025 support page but does not attribute it to a specific iOS version, so the version claim was unsourceable); (c) added the documented Stolen Device Protection one-hour password-change security delay; (d) added the published-date stamp (04/21/2026) for HT102656 and (01/14/2026) for HT119586; (e) renumbered footnotes to insert HT118574 in primary-citation order. Earlier first-pass corrections retained: iPhone passcode-escalation table (was off by 2 attempts and missing the 3-hour and 8-hour stages), removal of an unsourceable "six consecutive failures" account-lockout threshold, separation of Google's sign-in challenges from its unlimited-attempt recovery flow, tiered Apple recovery wait-time language, and qualification of the "under five attempts" Google challenge-escalation observation as field experience rather than published Google policy.