Passwords & accounts recovery: two-factor authentication and being locked out of your own machine

The instinct when a password stops working is to reach for the reset link immediately. That order matters less than it looks: a reset is a specific, sometimes irreversible action against a specific credential, and choosing the wrong one can leave you locked out of data rather than just an account. The first job is therefore identification, not action — establishing exactly which credential failed, what it protects, and whether a working copy already exists somewhere you own.

The most common error at this stage is treating all secrets as one thing. An account password, a device PIN, a disk-encryption passphrase and a one-time recovery code are four different objects with four different failure behaviors. A forgotten Windows Hello PIN is not a forgotten Microsoft account password; a lost FileVault recovery key is not a forgotten Mac login password at all. If you reset the wrong one — or assume that resetting one restores the others — you can spend an hour changing a credential while the actual lockout stays exactly where it was.

Check for saved credentials before you ask for a new one

Many sign-in failures are memory failures, not access failures. Before requesting anything, check the three places browsers and operating systems keep working copies: your browser's built-in password manager (usually under Settings → Passwords or a key icon in the address bar), the operating system credential store (Windows Credential Manager on Windows; the login Keychain on macOS), and any third-party password manager you may have used. If a saved entry exists and signs you in, the problem is solved without consuming any recovery option — which matters because some options, like backup codes, are single-use.

Assess what a reset can and cannot recover

The table below is the core of the pre-reset assessment. The column that causes the most damage is the last one: changing an account password does not decrypt anything. If your device or files are protected by encryption, the passphrase or key for that layer is a separate credential with its own recovery path, and no amount of account-side resetting will substitute for it.

The pre-reset sequence

1. Name the exact target: which service or device, and which account identity on it (the full email address or username, not 'my work account').
2. Make one careful sign-in attempt and record the exact response — 'wrong password', 'account locked', 'verify another way' are three different situations with different next steps.
3. Check saved credentials in your browser, OS credential store and any password manager. If one works, stop here.
4. Read the sign-in screen's own recovery options (the official links on that screen) and list which of them you actually satisfy — alternate email, phone, backup codes, trusted device.
5. Ask the data question: is anything behind this credential encrypted or stored in a keychain/vault? If yes, identify that layer's key before choosing a path.
6. Only then start the reset that matches the real target — and do it once, deliberately, rather than several times in a row.

You have done the assessment correctly when you can answer four questions in one sentence each: which credential failed, what it protects, which recovery options you personally satisfy, and whether any encrypted data sits behind it. If any of those answers is 'I don't know', that unknown is your next task — not the reset button.

• Related reading:
• Article 02 — Why a correct password can still fail
• Article 15 — Forgotten local Windows account password
• Article 46 — Password reset succeeds but you still cannot access your data

Being certain of your password and still being rejected is one of the most frustrating states in computing, because it feels like the system is lying. In practice the rejection is almost always truthful — something about how or where the password arrives differs from how it was set. The useful reframe: a sign-in check compares bytes, and between your memory and that comparison sit several layers where bytes can be altered, redirected or checked against the wrong account.

The layers, in order of frequency: input (keyboard layout, modifier keys, input methods), identity (the sign-in screen is asking for a different account than the one you are supplying the password for), state (cached or synced credentials that no longer match the live value), and connectivity (the service cannot reach its identity backend, so certain verification paths are disabled). Each has a cheap test, and running them in this order avoids both random flailing and unnecessary lockout risk.

Test the input layer first — it is the cheapest and most common

1. Type your password into a visible text field (a note app, or the password box with 'show password' enabled where offered) and read what actually appears. This single test exposes layout swaps, sticky keys and input-method interference at once.
2. Check Caps Lock, Num Lock (for passwords containing digits typed on a numpad), and whether Sticky Keys or Filter Keys is active (Windows: Settings → Accessibility → Keyboard; macOS: System Settings → Accessibility → Keyboard).
3. If you use a non-QWERTY physical keyboard or recently changed keyboards, confirm the active layout in the OS language settings — 'z' and 'y' swaps are the classic symptom.
4. If an input method editor (IME) for Japanese, Korean, Chinese or another script is active, switch it to direct/Romaji mode before typing; IMEs can silently transform keystrokes.

Then test the identity layer

Many sign-in screens accept a password for whichever account is currently selected, and devices commonly hold two or more: a personal account and a work or school one, or several accounts with similar names. Confirm that the account shown on the screen — full email address or username — is the one whose password you are typing. On Windows, note whether the prompt expects user@domain, DOMAIN\user or just a local name; supplying the right secret in the wrong identity format reads as a wrong password.

The state layer matters after any password change made elsewhere. Windows, for example, caches Microsoft account credentials so you can sign in offline; if the password changed on another device and the cache has not refreshed, the local check can reject what is now correct online — or accept a stale value that no longer works anywhere else. A network-dependent service may also be unable to verify at all, which some interfaces present as a plain rejection rather than a connectivity error.

If input and identity both check out and the password is genuinely rejected on a networked service, the remaining explanations are a stale live value (changed by you, an admin, or an attacker) or a service-side problem. At that point the correct move is the provider's official recovery path — not more attempts — and if the change was not yours, treat it as a possible compromise and read Article 35 before anything else.

• Related reading:
• Article 01 — What to do before resetting a forgotten password
• Article 43 — Your computer is locked after too many sign-in attempts
• Article 35 — Recovering an account after suspicious sign-in activity

When you request a password reset and nothing arrives, the first assumption — that the email was lost in transit — is often wrong. Reset mail has at least four distinct failure modes: it is delayed but coming; it arrived somewhere you are not looking; it was never sent to the address you are watching because the registered recovery address is different; or the service deliberately did not send anything, either because of throttling after multiple requests or because its anti-enumeration design avoids confirming that an account exists at all. Each mode has a different correct response, so identifying which one applies beats simply re-requesting.

Work through the mailbox side first

1. Check the inbox and the spam/junk/quarantine folder of every mailbox you might have used — including mailboxes you think are dead. On work or school networks, also check any corporate quarantine or hold list if your organization filters external mail.
2. Wait at least 15–30 minutes before concluding delivery failed; some providers batch or delay transactional mail, and upstream delays can stretch longer during incidents.
3. If you are still signed into the mailbox on another device, open its account settings and confirm which address is actually registered as the recovery contact for the locked service. The registered address is frequently an old one that itself needs recovering (see Article 04).
4. Check the provider's public status page or official social channels for a known outage affecting sign-in or email delivery.

Then consider the service side

Two service-side behaviors are deliberate, not bugs. First, rate limiting: several reset requests in a short window can suppress further mail entirely, sometimes for hours — so the second and third impatient re-requests are often what cause the silence to continue. Second, account enumeration protection: many large providers respond identically whether or not an account exists at a given address, which means 'no email' is not evidence that the account is gone. A missing reset email therefore proves only that the delivery chain did not complete; it does not diagnose where.

The safe escalation order: one patient wait with mailbox checks → confirm the registered recovery address from a device where you are still signed in → one further request from a different network if the first came from a filtered or metered connection → official support channels if the provider exposes them for account access. What to avoid is rapid repeated requests and third-party 'email lookup' services, which add nothing and sometimes harvest the very details an attacker would want.

If the registered recovery address turns out to be one you no longer control, the problem has become a nested lockout: the key to your account is stored in another account you cannot open. That changes the plan entirely — read Article 04 for how to approach it without giving up prematurely.

• Related reading:
• Article 04 — Recovering access when you no longer know your recovery email
• Article 31 — Recovering a locked email account
• Article 36 — What to do when an account recovery request is denied

Most recovery flows assume you can still reach at least one verified contact — usually an email address. When that address is itself locked, forgotten or recycled to someone else, the usual path closes and the situation becomes a nested lockout: account A points to account B for its key, and B is also shut. Nested lockouts are where 'just use the recovery option' stops being true advice, because the recovery option has its own front door and no one is home either.

Inventory what the locked service still offers besides that email

Before treating the case as hopeless, list every factor the service has on record for you — not just the recovery email. Common alternates include a different registered email, a phone number (SMS or voice call), one-time backup codes if you ever saved them, a trusted device you still possess, or an administrator route for work and school accounts. Services differ in which of these exist and how much weight each carries; the sign-in screen's own 'can't access this?' links are the authoritative list for that service, and third-party articles describing specific button layouts go stale quickly.

1. Open the official recovery page for the locked service and read every offered verification method before choosing one — do not commit to the first option shown.
2. If an alternate email or phone is listed, use it; each successfully verified factor also strengthens your position if later steps fail.
3. If the only remaining route is identity verification ('prove who you are'), prepare concrete evidence: the full name on the account, old passwords you genuinely remember (never guess lists), billing details tied to the account, and dates of significant activity. Providers ask for what they can verify, and vague answers are declined.
4. If the recovery email belongs to a major provider, run that provider's recovery flow first. Solving the outer lockout frequently reopens the inner one automatically, and it is usually the higher-value account anyway (see Article 31).

When recovery may be impossible — say so to yourself early

Some combinations genuinely do not have a supported path: no alternate factor on record, no backup codes, the recovery contact lost, and identity evidence too thin for the provider's verification. In that case the honest outcome is that the account may be unrecoverable, and the productive next steps shift to containment — securing everything else that trusted that account (linked services, subscriptions, contacts who might be phished in its name) and planning the replacement. No legitimate recovery service can promise to bypass identity verification; offers to do so are how attackers monetize exactly this desperation (Article 52).

The general rule for nested lockouts: always attack the outermost, highest-value account first, verify every factor you can in parallel rather than serially, and keep a written log of what you tried and what each step returned. That log is both your memory aid across multi-day recovery windows and the clearest possible artifact if you later need to explain the situation to support.

• Related reading:
• Article 03 — Password reset emails never arrive
• Article 31 — Recovering a locked email account
• Article 52 — Recognizing fake password recovery services and support scams

A password manager inverts the usual lockout: instead of dozens of forgotten passwords, you have one — but that one gatekeeps all the others, so its failure mode is a cascade. The recovery options available to you depend entirely on the product's design, and those designs differ in ways that matter before you act. Some managers keep an encrypted vault only on your devices; some sync it through their own cloud tied to a normal account; some offer a one-time recovery key generated at setup; some offer 'emergency access' where a trusted contact can request the vault after a waiting period; and some offer none of these. Identifying which combination you have is step zero.

Why the first instinct — uninstalling or resetting the app — is dangerous

If the vault lives locally on your device and you did not generate a recovery key, deleting or reinstalling the application can destroy the only copy of the encrypted vault. The vendor cannot help: the entries are encrypted with material derived from your master password, and no support team holds a back door — that absence is what makes these products safe in normal times, and it is exactly why there is no 'support will reset this for you' path when the key material is gone. Even where cloud sync exists, resetting the app to factory state before checking the account-recovery options can log you out of the sync in a way that is harder to reverse than the original problem.

1. Stop and identify the product's recovery design: open its help documentation (from the official site, typed by hand — not from a link in an email) and find the pages on master-password loss, recovery keys and emergency access.
2. If you generated a recovery key at setup, locate it now. It was usually offered once and suggested for offline storage; check where you would have put it before assuming it is lost.
3. Try the master password deliberately, with visible input (Article 02 applies in full): layout, case, trailing characters. Do not brute-force variations — some managers lock or wipe after repeated failures.
4. If emergency access was configured for a trusted contact, initiate that flow and let its waiting period run; it is designed precisely for this moment.
5. If the vault syncs through an account (the manager's own sign-in), recover that account using its provider's normal recovery routes — the vault then re-downloads once you can sign in with the master password or a stored session.

The realistic worst case deserves to be named: local-only vault, no recovery key, no emergency contact, master password genuinely gone. In that configuration the entries are unrecoverable by design — including by the vendor. The damage is then limited to re-establishing access to each underlying service through its own recovery routes (which is why Article 06's planning matters: a manager should never be the only key to anything critical).

After any successful vault recovery, treat the event as a planning review: generate or re-issue a recovery key if the product offers one, configure emergency access if it lacked it, and confirm the sync account's own recovery factors are current. The goal is that the next master-password failure costs an afternoon, not everything.

• Related reading:
• Article 06 — How to build a safe password recovery plan
• Article 53 — What to do if your backup codes or recovery key were exposed
• Article 56 — Create a secure emergency access kit

Every other tutorial in this library describes reacting to a lockout; this one is about making the reaction cheaper. A working recovery plan has a simple structure: for each account that matters, at least two independent ways back in, at least one of which does not depend on any single device you own, and a record of where every backup artifact lives. 'Independent' is the word that does the work — a backup code stored in a note on the same phone as your authenticator app protects against forgetting, not against losing the phone.

The components, and what each one actually buys you

• A dedicated recovery email address. A mailbox whose only job is receiving recovery mail for your important accounts. It should have its own strong password plus two-factor, and it must not be the same as your daily inbox — when the daily inbox is locked, the recovery inbox is still open.
• Backup codes, per critical service. One-time 2FA bypasses issued by most major providers. They are single-use, so store a fresh set offline and label which service each set belongs to (Article 09 covers storage and verification details).
• Password-manager recovery configured and tested. A generated recovery key plus emergency access for a trusted contact — the manager is your master key, so it needs its own plan (Article 05).
• A named recovery contact. A person who knows the plan exists, can be reached in an emergency, and is authorized by you to act. 'Someone in the family' is not a contact; a specific person with a specific role is.
• Secure storage for the plan itself. An encrypted file or a physical document in a safe place — not a cloud note on your phone, and not a plaintext file on a machine you are trying to recover. The plan's location must survive the loss of every device it describes.

Verification is part of the plan, not an afterthought

Recovery artifacts decay silently: recovery emails get retired, phone numbers get recycled, backup code sets get consumed by one forgotten sign-in and nobody notices. The countermeasure is a periodic verification pass — quarterly is a reasonable cadence — during which you confirm each component without consuming anything irreplaceable: can the recovery inbox still be opened? Is the authenticator app still registered on the critical services? Does the password manager's emergency access still name a reachable person? Test one full recovery path end-to-end per year on a non-critical account so you know what the real thing feels like when it matters.

The finished plan should fit on one page: account, its two independent recovery routes, where each backup artifact is stored, and who the contact is. Anything longer will not be read in an emergency, and a plan that must be decoded under stress has already failed. Build it while you are calm, verify it on a schedule, and update it whenever a phone, email address or relationship changes.

• [ ] Recovery inbox created, secured with its own two-factor, registered on critical accounts
• [ ] Backup codes generated and stored offline for each critical service, labeled by service
• [ ] Password manager: recovery key generated, emergency access configured and named
• [ ] One named recovery contact who has seen the plan and agreed to the role
• [ ] Plan document stored in a location that survives loss of all your devices
• [ ] Quarterly verification scheduled; annual end-to-end test on a non-critical account

• Related reading:
• Article 09 — How to use and store two-factor backup codes
• Article 55 — Build a personal account recovery inventory
• Article 60 — The complete password and account recovery readiness checklist

Losing the phone that holds your authenticator app is the most common two-factor lockout, and it has a counterintuitive core: an authenticator app is not a sync service. TOTP apps generate six-digit codes from a secret key (the seed) that was registered with each service when you scanned its QR code. That seed lives in the app's local data — and, for some apps, in an encrypted cloud backup if you enabled one. Reinstalling the app on a new phone gives you an empty vault: without the seeds, there is nothing to generate codes from, no matter how many times you reinstall.

The recovery routes, in order of speed and reliability

Notice what is absent from that table: 'reinstall the app'. The one exception worth checking early is an authenticator with encrypted cloud backup you actually enabled — if so, signing into the app on the new phone with your platform account may restore the seeds, and every code works again. If you did not enable it (the default on most apps), the seeds are gone with the old device's storage, and the table above is your real menu.

When several services are locked at once — which is the usual state after a phone loss, since the same app served all of them — the order of work matters as much as the method. Work in dependency order: the email hub first (its recovery may key other services), then banking and anything that gates money, then the rest. For each service, use the fastest available route from the table rather than the 'best' one, because a working backup code today is worth more than an elegant re-enrollment next week; you can tidy the factor configuration later, but you cannot un-lose an account whose review window closed while you were optimizing.

1. For each locked service, start at its sign-in screen and read which verification methods it currently offers — the offered list is the truth for that account.
2. Use backup codes first where available; they are instant and do not require any device. Note how many you consume.
3. Where a trusted session exists on another device, act through it: confirm the new phone number or email, add a new factor, and regenerate backup codes before that session expires.
4. For services with no working factor, submit the official recovery flow once, completely, with accurate information — then wait out the stated review period rather than resubmitting.
5. Once access is back, re-enroll the new phone on every critical service and retire the old device's role in your security model (Article 11).

The underlying lesson is structural: an authenticator app concentrates many services' second factor into one physical object. The fix is not a better phone but breadth — at least one critical service should have a second, independent method (a hardware key or a second registered device) so that no single loss takes out the whole column.

• Related reading:
• Article 09 — How to use and store two-factor backup codes
• Article 11 — Moving an authenticator to a new device
• Article 12 — When every two-factor method is unavailable

When the six-digit code on your screen is rejected as invalid, the failure sits in one of three places: the code was generated for a different registration than the service thinks you have, the two clocks involved disagree by more than the allowed window, or the code simply arrived outside its validity period. All three are fixable without touching the account password — but the fixes are different, and guessing between them wastes sign-in attempts that may count against lockout limits.

Understand the mechanism you are debugging

Standard authenticator apps use TOTP (time-based one-time passwords): a shared secret plus the current time, rounded to 30-second steps, produces each code. The service recomputes the same value from its own clock and accepts codes from the current step — usually also the step before (and sometimes after) as grace for drift. That design means two things: codes expire by construction (a code typed slowly is often simply old), and any meaningful clock disagreement between your device and the service's servers invalidates every code, not just some. A smaller family of schemes, HOTP (counter-based), advances a counter instead of using time; those are rarer in consumer apps but appear in some hardware tokens — for HOTP, 'out of sync' means the counter drifted and the service typically accepts a burst of future values to resynchronize.

1. Re-enter the code immediately after it appears, within its 30-second window, watching the on-screen countdown. If a slow entry was the pattern, this alone fixes it.
2. Check your device's clock: enable automatic date/time (network-provided). A manual time setting, or a phone that has been off for days and resynced badly, is the classic cause of total code failure across all services at once.
3. If only one service rejects codes while others work, suspect the registration: you may have added that account to the app more than once (two entries, one stale) or scanned a QR code for a different account than the one you are signing into. Delete the duplicate entry and re-add the account from the service's own 2FA settings page — which requires being signed in, so do this through a trusted session if needed.
4. For counter-based tokens that report 'out of sync', use the resync flow the service offers (usually: submit several consecutive codes until one is accepted).

Verification is simple and should be done deliberately: after fixing the cause, complete one sign-in on a second service that uses the same app. A working code on an independent service confirms the app and clock are healthy; a working code only on the originally failing service suggests its registration specifically needed the re-add.

• Related reading:
• Article 07 — Lost your authenticator phone? Recovery options explained
• Article 35 — Recovering an account after suspicious sign-in activity
• Article 42 — Choosing between passkeys, authenticator apps and security keys

Backup codes are the deliberate escape hatch in two-factor design: a fixed set of single-use strings that each substitute for one second-factor step, issued when you enrolled the factor. Their value is entirely conditional on two things — that they exist for the accounts that matter, and that they survive independently of every device you could lose. A backup code stored in a notes app on the same phone as your authenticator fails at precisely the moment it was created for: the day the phone is gone.

The one-time rule changes how you handle them

Each code works once, then it is spent — most services tell you how many remain after use. That has three practical consequences. First, using codes is not a test you can repeat: every verification consumes real safety margin. Second, if you find yourself reaching for backup codes regularly, the underlying factor setup is broken and should be repaired (Articles 07–08), because the net is shrinking with each use. Third, after any use — or any suspicion that codes were seen by someone else — regenerate a fresh set from the service's 2FA settings while you are still signed in, and store the new set properly before discarding the old.

Storage that actually works

• Offline and separate. A printed sheet in a secure location, or an encrypted file on a drive you keep away from daily devices. The storage location must not be the phone, the primary laptop, or any cloud note synced to them.
• Labeled per service. 'Backup codes — bank account (issued March)'. In an emergency you will not remember which set belongs to which service, and mixing them up wastes single-use items.
• Dated. If a service lets you regenerate sets, old sets are usually invalidated when new ones issue. The date tells you whether the sheet in your hand is still live.

How do you verify the net works without consuming all of it? You usually cannot test a backup code end-to-end on a critical account — using one is itself an event. Instead, verify the perimeter: confirm the service's settings page still lists 'backup codes available' with a remaining count, confirm your stored set matches what was issued (compare the first few characters), and run a real end-to-end test on a low-stakes account where burning one code costs nothing. That combination tells you the mechanism is intact without spending the margin that matters.

• Related reading:
• Article 07 — Lost your authenticator phone? Recovery options explained
• Article 53 — What to do if your backup codes or recovery key were exposed
• Article 56 — Create a secure emergency access kit

Changing phone numbers seems like a routine life event until you discover how much of your digital identity was routed through the old one. The severity depends on which type of two-factor used that number, because the types behave very differently when the number stops being yours. An SMS-based factor sends a code to the number itself: if you ported the number to a new SIM, most services keep working with zero changes; if the number was cancelled and later recycled to someone else, that person now holds your second factor — a genuine security incident, not just an inconvenience. An app-based (TOTP) factor is attached to the account registration, not the number: changing phones does not break it at all, which is one reason app-based factors are recommended over SMS in the first place.

Sort the accounts by exposure before doing anything

1. List the services where the old number was registered as a sign-in factor or recovery contact — banking and email first, since they gate everything else.
2. For each, determine the factor type: SMS codes to that number, or app-based codes plus the number only as a backup contact. The service's 2FA settings page (reachable while you can still sign in) is authoritative.
3. While access still works, update the registered number and recovery contact on every reachable account, and regenerate any SMS-dependent backup options where the service offers app-based alternatives.
4. For accounts you can no longer reach: use their official recovery flows. Most major providers let you verify through other factors (email, app codes, trusted devices) and then replace the dead number — the dead number is a recoverable state if another factor survives.

The carrier dimension deserves its own paragraph because it creates risk even when nothing has gone wrong yet. Numbers are recycled: carriers reassign cancelled numbers, sometimes within weeks. If your old number was your only recovery contact for an account you rarely use, the window between 'I stopped using this number' and 'someone else can answer codes for my account' is open today. The mitigation is not vigilance over carrier policy — it is simply not leaving a single dead-number dependency on any critical account, which is what the update sweep above accomplishes.

Where no other factor survives and the number is gone, the remaining route is provider identity verification — proving who you are through registration history, billing records and other evidence (Article 04's framework applies). Outcomes vary by provider and by how complete your evidence is; some accounts in this state are genuinely unrecoverable, which is the strongest available argument for app-based factors plus a second, number-independent recovery contact on every account that matters.

• Related reading:
• Article 07 — Lost your authenticator phone? Recovery options explained
• Article 54 — Preventing account takeover through recovery channels
• Article 34 — Work or school account recovery

Moving an authenticator app to a new phone is where 'it should just sync' meets reality: most authenticator apps do not move automatically, because the seeds they protect are exactly as sensitive as the passwords themselves. The migration therefore has two possible shapes — a supported transfer or backup that carries the seeds across in one step, or a per-service re-enrollment where each account is registered on the new device again. Which shape you get depends on the app and whether you enabled its backup feature before the move, which makes pre-move preparation the real subject of this tutorial.

The supported-transfer path

Some apps offer encrypted backup tied to your platform account (sign in with the same account on the new device and the entries restore), or a direct device-to-device transfer using a code shown on each screen. Where you have this: enable or confirm the backup before losing or replacing the old phone, sign into the app on the new device with the correct platform account, verify that a known entry generates a working code (test it on one low-stakes service), and only then decommission the old device. The verification step matters because a 'restored' list can be incomplete — a partial restore discovered at migration time costs minutes; discovered during an emergency costs access.

The re-enrollment path, done without a gap

1. Order your work by criticality: banking and email first, then anything that gates them. You want the highest-stakes services migrated while you still have every factor available.
2. For each service: open its two-factor settings while signed in on a trusted session, choose to add or switch the authenticator, scan the new QR code with the new device's app, and confirm the first generated code is accepted by completing one sign-in.
3. Handle the QR codes themselves carefully: they are single-use registration credentials. Do not photograph them into shared photo rolls or chat apps; if a screenshot is unavoidable for later use, it belongs in encrypted storage and should be deleted after enrollment.
4. Replace backup codes where the service issues new ones on re-enrollment, storing the fresh sets per Article 09.
5. Keep the old device's app running until every critical service confirms the new registration works — then remove the old entries from the services' settings (so two devices are not both 'valid' and confusing future troubleshooting) and wipe or securely erase the old phone before it leaves your control.

One distinction keeps migrations clean: adding a second authenticator registration is reversible and gap-free — both devices work until you remove the first. Replacing (removing the old registration before the new one is proven) is not. Every step above follows that order deliberately, because the failure mode of getting it backwards is discovering, mid-emergency, that the 'migrated' account only ever registered the old phone.

• Related reading:
• Article 07 — Lost your authenticator phone? Recovery options explained
• Article 39 — Passkeys do not appear on your new device
• Article 57 — Prepare a computer before traveling or replacing a phone

This is the case every other tutorial in this category prepares you to avoid: the phone is gone, the backup codes were never saved or are spent, the old phone number was recycled, and the hardware key is lost. Nothing on your side of the relationship works anymore. What remains is narrower than it looks — a sequence of official provider processes, each with its own evidence requirements, timelines and realistic success rates — plus the containment work you can do independently while those processes run.

The decision process

1. Inventory honestly, per service: every factor the service lists, and for each one, why it is unavailable. Write it down. This inventory is both your recovery input and the document that tells you which accounts are actually in this category — often fewer than felt.
2. Check for any surviving trusted session (another device still signed in). Even a few hours of trusted-session time lets you add a new factor and regenerate codes, converting an unrecoverable case into a routine one. Act on it first, before it expires.
3. For work or school accounts, route to the organization's IT/admin channel immediately — managed identities have administrator resets that personal recovery flows do not (Article 34). This is usually the fastest path available.
4. For personal accounts, submit each provider's official account-recovery flow once, completely and accurately: identity evidence, device history, anything asked. Then stop resubmitting — review queues process in order, and duplicate submissions do not accelerate them.
5. While reviews run (days to weeks is normal), contain the blast radius: change passwords on every service that trusted the compromised account's email, warn contacts who might be phished from it, and pause subscriptions or standing orders that route through it where possible.

The honest part of this tutorial is about limits. Providers cannot verify you beyond their evidence requirements, and when those are not met — no alternate factor, thin registration history, recycled contact details — the supported outcome for some accounts is permanent loss. That is a design choice in favor of security: the same wall that stops an attacker with stolen credentials also stops the legitimate owner who cannot produce evidence. No legitimate service will promise to clear that wall on request; vendors and individuals offering 'guaranteed recovery' for exactly this situation are operating as attackers do (Article 52).

After the dust settles — whichever way each case resolved — the structural fix is the same as for every other lockout class: no single device, number or key should be the only path into any critical account. One hardware key plus one app factor plus stored backup codes means this article's worst case requires three simultaneous losses instead of one. And because the review windows and identity-verification timelines in steps 2–4 are measured in days, the calm version of this preparation is simply doing it now: confirming, for your top ten accounts, which alternate factors exist and where their backup material lives, while no lockout is making the work urgent.

• Related reading:
• Article 07 — Lost your authenticator phone? Recovery options explained
• Article 34 — Work or school account recovery
• Article 52 — Recognizing fake password recovery services and support scams

The first thing to establish is what a Windows Hello PIN actually is, because the common assumption — that it is 'the password' — points at the wrong recovery path. A PIN is a device-local credential: a short numeric code that Windows verifies against data protected by the device's TPM chip (where available), optionally tied to your Microsoft account for backup and reset purposes. It is not the Microsoft account password, it does not work on any other machine, and forgetting it does not lock you out of your online account — only of this device's fast sign-in.

The supported reset paths

On the Windows 11 sign-in screen, choosing PIN as the sign-in method and then selecting 'I forgot my PIN' starts the supported flow. Which branch you get depends on how the PIN was created: for a PIN tied to a Microsoft account, Windows asks you to verify your identity online — typically by signing into that account with its password (or another accepted verification) — and then lets you set a new PIN. For a local-account PIN, the available options depend on what recovery was configured when the PIN was enrolled; where nothing was configured, the fallback is the account's own password (which leads to Article 15 if that is also unknown).

This is where the connectivity question lives. The Microsoft-account-linked path verifies against online identity services, so a working internet connection is required for that branch — on a device with no network, the option may be absent or fail. That does not mean the device is unrecoverable offline: it means the online verification branch is unavailable, and the remaining options are the locally configured ones (another Windows Hello method such as fingerprint or face if still enrolled, the account password, or administrator assistance on the machine).

1. At the sign-in screen, select your account and the PIN option, then choose 'I forgot my PIN'.
2. If asked to verify online: connect to the internet, sign in with the Microsoft account password, and set the new PIN when offered.
3. If no network is available or the online branch fails: try another enrolled Windows Hello method (fingerprint/face) or the account password where one exists.
4. If neither works and the account is local: use the local-account routes in Article 15 — including a previously created password reset USB, or another administrator account on the machine.

Verification after resetting: sign in with the new PIN, confirm the account's files and settings loaded normally (not a temporary profile — Article 17 covers that failure), and check Settings → Accounts → Sign-in options to see exactly which methods are currently enrolled. Knowing your enrolled set is what makes the next lockout a ten-minute event instead of an investigation.

• Related reading:
• Article 14 — Forgotten Microsoft account password on a Windows PC
• Article 15 — Forgotten local Windows account password
• The Windows troubleshooting library — sign-in failures, BitLocker prompts and recovery tools

A Microsoft account is an online identity: one email address, one password, and a set of registered recovery options that live with the provider, not on your PC. Forgetting its password therefore has exactly one legitimate recovery venue — the provider's official account recovery flow — regardless of which device you are standing in front of. The Windows sign-in screen is where you notice the lockout (especially if the PC signed you in with that account), but it is not where the reset happens, and no local tool on the machine can perform it.

The official recovery flow

1. From any device with a browser — including the locked PC if it has network access — go to the provider's sign-in page for Microsoft accounts and choose the 'can't access your account' / forgotten-password path. Type the address yourself; do not use recovery links from email.
2. You will be asked how you want to verify: options typically include a code sent to an alternate email, a code by SMS or voice call to a registered phone, or (where enrolled) approval on a trusted device. Choose one you actually still control — each successful verification also confirms the factor is current.
3. Set the new password when verification succeeds. Use a password you have not used before on this account, and store it in your password manager immediately.
4. Back on the Windows PC, sign in with the new password. The device's cached credential refreshes from then on; if the PC previously signed in with the old cached value, entering the new password once online completes the sync.

Two distinctions prevent most confusion at this stage. First, cloud account versus local account: a PC can hold both — a Microsoft-account sign-in and one or more local accounts. Resetting the Microsoft password changes only the cloud identity; any local account on that machine is untouched, with its own (unknown or known) password and its own routes (Article 15). Second, the Windows Hello PIN survives: changing the account password does not invalidate an already-enrolled PIN on a device — the PIN remains a working local sign-in method there, which is often how you get back into the machine while the online reset completes.

If verification itself is blocked — no reachable alternate email, recycled phone number, no trusted device — you are in the nested-lockout situation described in Article 04, and the remaining route is the provider's identity-verification review with evidence. If instead the password was changed without your knowledge, skip recovery entirely and move to Article 35: a changed password plus unexpected sign-ins is a compromise pattern, and 'recovering' it as if you had forgotten it would hand the account back to whoever changed it.

• Related reading:
• Article 13 — Forgotten Windows 11 PIN: supported recovery methods
• Article 04 — Recovering access when you no longer know your recovery email
• Article 35 — Recovering an account after suspicious sign-in activity

A local Windows account stores its password hash on the machine itself, with no online identity behind it — which means there is no provider to ask for a reset, and the supported options are exactly those built into the OS: previously configured reset media, or action by another administrator account on the same machine. That list is shorter than people expect, and the honest framing of this tutorial is describing what exists, what it requires, and where the limits are — rather than promising that every locked local account can be opened with its data intact.

The supported options, in order of preference

1. Check for a password reset disk: if one was created for this account (a USB drive written with the account's key material — an option Windows offered when the password was set or changed), inserting it at the sign-in screen after a failed attempt enables a guided reset. Most accounts never had one created, so this usually fails fast — but check before moving on.
2. Sign in with another administrator account on the machine (a second local admin, or a Microsoft-account admin if one is configured), then change the locked account's password from Settings → Accounts → Other users, or via the local users and groups tool on Pro/Enterprise editions. This is the standard supported route where a second admin exists.
3. If no other admin account exists and no reset disk was made, there is no supported self-service path that preserves everything: the realistic options are creating a new administrator account through Windows recovery environments (which restores machine access but not necessarily the locked user's protected data) or professional recovery. Treat any tool that promises otherwise with the skepticism reserved for anything touching authentication.

The data question is where local accounts bite hardest, and it comes down to EFS (Encrypting File System). Files a user encrypted with EFS are protected by keys tied to that user's certificate. If the user backed up their EFS certificate (or the organization does), those files open again after any password reset — the data was never at risk. Without such a backup, resetting or bypassing the account password can leave EFS-encrypted files permanently unreadable even though the rest of the profile is fully accessible. Before choosing any route that changes or replaces the account, find out whether EFS is in use: right-click files → Properties → Advanced → 'Encrypt contents to secure data', or search the profile for .evt-style encrypted stores; a professional can audit this quickly from an admin session.

Prevention is cheap and specific: keep one known-good administrator account on every personal PC (a local admin with a strong, managed password), and if you use EFS at all, back up the certificate to a USB drive and store it with your recovery kit (Article 56). Those two facts convert this article's worst case — no admin, no reset disk, EFS in play — from a probable data loss into a checked box.

• Related reading:
• Article 13 — Forgotten Windows 11 PIN: supported recovery methods
• Article 46 — Password reset succeeds but you still cannot access your data
• The Windows troubleshooting library — BitLocker prompts and recovery-drive tools

'Account locked' is one message with at least four different causes, and the correct response differs for each: a short automatic delay after too many failed attempts, an organizational lockout policy that only an administrator can clear, a security block placed because sign-in activity looked suspicious, or a manual disable by the person who manages the account. The diagnosis starts by reading what the screen actually says — the wording is more informative than it looks — and by establishing which kind of account you are trying to open.

Distinguishing the four kinds

The temporary kind is the only one where 'wait' is the complete answer — and it is worth waiting properly. The delay exists because rapid failed attempts are indistinguishable at the gate from an attack, so adding more attempts during the wait does not shorten it; on some services it extends it. Note the stated duration, stop attempting, and use the time to verify you have the right account identity and the right password (Article 02) so that the first attempt after the delay is a good one.

The suspicious-activity kind deserves care in both directions. It is frequently protective — the system noticed something odd (a sign-in from a new country, a burst of failures, a changed device identifier) and paused rather than guessed. Completing its verification from the provider's official account-security page (reached by typing the address, not from any email) usually clears it, and the security review it offers is worth finishing even when the block lifts quickly. But if the 'suspicious activity' includes things you did not do — sign-ins you don't recognize, a changed password or recovery contact — then the lock is the system catching an active takeover, and the correct next step is Article 35's containment sequence, not simply waiting for the block to expire.

Verification that the lock is truly gone: after the delay or verification completes, sign in once deliberately on the original device, then check the account's sign-in activity page (where the provider offers one) to confirm the session you just created is the only recent one. A clean single entry means the episode closed; additional entries mean it did not.

• Related reading:
• Article 43 — Your computer is locked after too many sign-in attempts
• Article 35 — Recovering an account after suspicious sign-in activity
• Article 34 — Work or school account recovery

This failure is easy to misread because the part that usually fails — authentication — is working. You type the right password, Windows accepts it, and then the desktop you get is wrong: a blank 'temporary profile' with none of your files, settings or installed shortcuts, sometimes announced with a message that your profile was signed in temporarily. That means the lockout has moved one layer up: the question is no longer who are you but why will the system not load your stored user profile — and the answer sits in profile integrity, the services that build a desktop session, or the storage underneath.

Separating the four causes

• Damaged profile data. The registry hive or profile folder for your account is corrupted (a classic cause after an interrupted update or bad shutdown). Windows falls back to a temporary profile so you can still use the machine. Telltale: the message naming a temporary profile, and your real files absent from the desktop.
• Failed user session services. Components that construct a desktop (user profile service, shell components) fail to start — often after an update. Telltale: sign-in completes but the session stalls, loops back to sign-in, or shows a minimal desktop without your folders.
• Storage problems. Filesystem errors, failing disk, or permission damage on the profile path. Telltale: slow or hung sign-in, Event Viewer disk errors, SMART warnings — and possibly other users' profiles affected too.
• Profile path / permission corruption. The profile's security descriptor no longer grants your account access to its own folder. Telltale: 'access denied' when opening your Documents or desktop contents from another admin session.

The order of operations matters more than the diagnosis here, because several repairs are destructive to exactly what you are trying to save. Preserve data first. From a working session — the temporary profile itself, or a second administrator account — copy your real profile's user folders (Documents, Desktop, Pictures, and anything else of value) from C:\Users\<yourname> to an external drive. This copy takes minutes and converts every later repair decision from 'risk the data' to 'restore the data'. If even that path is unreadable, stop and treat it as a storage problem needing professional attention (Article 48) rather than running repairs over a failing disk.

1. Copy your profile's user folders to external storage (see above). Do this before any repair, reset or re-registration.
2. Check Event Viewer → Windows Logs → System for disk and volume errors around the failure time; note any filesystem or SMART-related entries.
3. If the disk is healthy: try signing in as a different account to confirm the machine itself is stable, then return. A second consecutive temporary-profile sign-in after a clean reboot sometimes resolves transient service failures on its own.
4. For confirmed profile corruption with safe storage: the supported repair is creating a new profile (new local user or re-registering the Microsoft account), migrating your copied files into it, and only then deleting the damaged profile — deletion is the last step, never the first.
5. For storage faults: image or clone the disk before further work, and involve professional recovery if SMART data shows failure progression (Article 48).

Verification after repair: sign in to the working profile and confirm your files, desktop layout and at least your most-used applications behave as before; check that no temporary-profile remnants remain (Settings → Accounts → Other users should list only real accounts); and if a storage fault was involved, verify disk health again a week later rather than assuming one clean day means health.

• Related reading:
• Article 15 — Forgotten local Windows account password
• Article 48 — When to stop troubleshooting and seek professional recovery
• Startup, boot & recovery options — the OS-side recovery environments

Network outages turn ordinary lockouts into harder ones, because part of the usual recovery menu goes dark. The useful mental model is that Windows keeps two kinds of sign-in material on the device: local credentials (local-account password hashes, PIN data bound to the TPM) that verify entirely offline, and cached online credentials (a protected copy of your Microsoft account's sign-in state) that let a cloud account work without a connection — but only for verification, not for anything the provider must perform. Which routes survive an outage depends on which kind you need.

What works offline

• Local accounts: fully offline by design. Password, PIN and biometrics all verify against data on the machine; no connectivity is ever involved.
• Microsoft accounts with cached sign-in: after a successful online sign-in at some point, Windows caches enough to let you sign in again offline — password or PIN. This is why a plane-mode laptop still opens for its owner. The cache refreshes whenever an online sign-in succeeds; a device that has never signed in online cannot use this path.
• Windows Hello biometrics and TPM-backed PINs: verification is local hardware work; the network is irrelevant to the check itself.

What does not work offline

• Resetting a Microsoft account password — the reset happens at the provider, which requires reaching the provider. Offline, you can only use what is cached or local.
• The online-verification branch of 'I forgot my PIN' for Microsoft-linked PINs (Article 13) — same reason.
• Recovery options that phone home: some sign-in screens offer 'verify with email/phone' as a fallback when the cached path fails; those need connectivity to issue and check the code.

So the offline decision tree is short: local account → use its local routes (Article 15) regardless of network. Microsoft account with working cache → sign in normally with the cached password or PIN; the outage changes nothing. Microsoft account whose cache fails (wrong password because it changed elsewhere, or a device that never signed in online) → you are genuinely blocked until connectivity returns, and the correct action is to wait for network rather than force local workarounds that create new admin accounts over a still-valid cloud identity. One nuance: BitLocker behavior during outages is about TPM and boot state, not internet — an offline machine with a healthy TPM boots straight past encryption; a changed boot state prompts for the recovery key whether or not you have Wi-Fi (Article 44).

Preparation that makes this article moot: confirm your critical PC has at least one local administrator account with a known strong password (independent of any cloud outage), keep BitLocker recovery keys stored per Article 56, and do one deliberate offline sign-in test after major changes — airplane mode, reboot, sign in. Thirty seconds of testing tells you exactly which branch of the tree above your machine actually lives on.

• Related reading:
• Article 13 — Forgotten Windows 11 PIN: supported recovery methods
• Article 44 — Login fails after a BIOS, firmware or hardware change
• The Windows troubleshooting library — BitLocker and recovery tools in depth

A forgotten Mac login password has more supported escape routes than most people realize, but those routes are gated by how the account was originally configured — whether it is tied to an Apple ID, whether FileVault is on, and which macOS version you are running. The first step is therefore reading the login screen itself: after a failed attempt, macOS shows the options it actually has for this account (reset with your Apple ID, reset with the FileVault recovery key, or a hint prompt). What the screen offers is the truth; what forums assume is not.

The supported paths

1. Reset with your Apple ID (where the login screen offers it): enter the Apple Account password and complete any verification, then set a new Mac login password. This is the fastest path and exists when the account was linked to an Apple ID at setup.
2. Recovery Mode: restart into recovery — on Intel Macs hold Cmd+R at the chime; on Apple Silicon Macs hold the power button until 'Loading startup options' appears, then choose Options. From there, the password-reset utility (or Terminal's resetpassword tool) can set a new login password for a local account. Note that Recovery Mode itself may ask for the FileVault recovery key if the disk is encrypted — encryption gates recovery before recovery can help.
3. The FileVault recovery key: where the above are unavailable and you have the 48-character key (stored with your Apple ID for some accounts, or in a document you saved at enablement), entering it unlocks the volume and allows password reset. Article 21 covers what that key is and where it lives.

Now the distinction this whole category depends on: resetting the login password gets you into the account; it does not automatically decrypt everything the old password protected. The login Keychain — saved Wi-Fi passwords, website credentials, app logins — is encrypted with material derived from your login password. After a reset via Apple ID or Recovery Mode, macOS will offer to update the keychain's password when you first unlock it; accept that prompt and the keychain follows you across the change. If you decline it, or if the reset path did not allow keychain migration (some recovery-key-based resets do not), the keychain stays locked to the old password — its contents remain unreadable even though you can sign in, browse and use the machine normally. That is a partial recovery, and it is worth knowing which one you got.

Verification after any reset: sign in with the new password; when prompted to update the login keychain, do so and then confirm by opening a known saved credential (a Wi-Fi network you joined before, or a site login in Safari); check that your files, desktop and applications are present and open normally. If the keychain prompt never appeared, test one saved credential deliberately — that single check tells you whether your recovery was total or partial.

• Related reading:
• Article 20 — Mac password reset options are missing
• Article 21 — Understanding FileVault recovery keys
• The macOS library — when to use Safe Mode, Recovery or ordinary troubleshooting

The worst moment in a Mac lockout is the login screen that offers no way forward: no 'reset with Apple ID' link, no recovery key prompt, just a password field and a hint. The options are not missing because of a bug — they are absent because each reset path has preconditions, and this account fails at least one of them. Diagnosing which precondition failed is possible from the outside, using only observable facts: what the login screen shows, whether the machine boots to Recovery Mode at all, what that mode asks for, and what you know about how the account was created.

The four preconditions, and how to test each

One more reason the options vary, and it is worth naming because it explains why two identical-looking Macs behave differently: the reset surface you see is the intersection of four independent states — the macOS build's UI, the account type at creation time, the disk's encryption configuration, and any management enrollment. Each can differ between machines bought in different years or set up by different people, which is why 'my friend's Mac had a reset button' is not evidence that yours will. The four preconditions above are the complete list of what can remove an option; if you can state each one for your machine, you know exactly which paths exist and which do not, before you need them.

The decision tree from observable conditions

1. After a failed attempt, photograph the login screen's offered options. Their absence pattern is your first diagnostic input.
2. Boot into Recovery Mode (Intel: Cmd+R; Apple Silicon: hold power → Options). Observe what it asks for first: a FileVault key request means the disk is encrypted and that key is now the critical object (Article 21); a straight path to the password-reset utility means you can proceed locally.
3. If Recovery Mode's reset utility lists your account and lets you set a new password: do it, then verify keychain behavior per Article 19.
4. If the machine is organization-managed at any point in that sequence: stop self-service and route to IT (Article 34) — managed Macs deliberately remove user reset paths, and working around MDM is a policy violation, not a troubleshooting step.
5. If neither Apple ID linkage nor a FileVault key exists for a personal machine: the supported options are exhausted. The remaining honest choices are professional data recovery on the encrypted volume (success depends on what 'encrypted' means in practice — see Article 21) or reinstallation with data loss. Do not let either feel like a judgment on you; it is the consequence of the security configuration, and it is preventable next time (Article 56).

The through-line: every 'missing option' is a precondition you can name, and naming it converts an emotional dead end into a checklist. Apple ID linkage — yes or no? FileVault key — held or not? Managed machine — yes or no? Those three answers, which take minutes to establish, determine the entire remaining decision space.

• Related reading:
• Article 19 — Forgotten your Mac login password
• Article 21 — Understanding FileVault recovery keys
• Article 34 — Work or school account recovery

FileVault is macOS's full-disk encryption: the entire startup volume is encrypted, and the volume stays sealed until something proves it may open — your login password (which derives the unlock), an authorized Apple ID verification, or the recovery key. The recovery key is a 48-character string generated when FileVault was enabled. It is not a password you choose and it cannot be reset, regenerated or 'recovered' by Apple support in the ordinary sense: it is the master credential for the volume, and its security properties are exactly what make FileVault trustworthy — and exactly what make losing it serious.

Personal versus institutional arrangements

Where people go wrong is assuming a default. For many personal Macs there is no Apple-side copy of the key at all — the enablement screen showed it once, offered to save or print it, and moved on. If you clicked through without saving, the key exists only as entropy on your disk and in your memory of having seen it. The practical consequence table is short: key found → every recovery path opens; key not found but Apple ID verification available → that route still works where configured; neither available → the volume cannot be unlocked by any supported means.

This is also why the key's storage deserves the same care as any master credential: offline or in an encrypted password manager with its own solid recovery plan (Article 05), labeled with the machine it belongs to, and — for personal Macs — verified to still be readable at least once a year. A recovery key you cannot locate when needed is functionally identical to one that was never generated, and the difference between those two states is only whether you would have caught it in a calm moment.

Verification of a stored key is possible without using it: the key's format is checkable at a glance (48 characters in groups), and on a Mac where you can still sign in, FileVault status in System Settings → Privacy & Security confirms encryption is active and which recovery arrangement applies. Knowing your own arrangement — personal key, Apple ID linkage, or MDM — before a lockout is the single highest-value fact in this category.

• Related reading:
• Article 19 — Forgotten your Mac login password
• Article 24 — What to do before erasing or reinstalling a locked Mac
• Article 56 — Create a secure emergency access kit

Type the right password, watch the spinner, and never reach a desktop — or reach one that is not yours. This failure pattern is diagnostically valuable precisely because it clears the most common suspect: your credentials are accepted, so the lockout is not an authentication problem at all. The fault sits somewhere in what happens after verification — the startup sequence completing, the user session building, the profile loading, or the storage underneath any of it. Each has a different signature and a different first test.

Separating the post-authentication stages

• Startup does not complete. The Mac hangs at or after the login screen, restarts in a loop, or drops to a recovery prompt. Signatures: a stuck Apple logo with progress bar, repeated reboots, or the 'no volume' state. First test: boot into Recovery Mode and check the disk's health and the startup disk selection.
• The session builds but fails. You pass authentication, see a brief desktop or a spinner, then are returned to login — sometimes with a message about an incomplete sign-in. Signatures: loop back to the password screen, partial desktop that collapses. First test: Safe Mode (hold Shift at startup on Intel; the power-button 'Safe Mode' option on Apple Silicon), which disables non-essential components and often lets a faulty extension or login item reveal itself.
• The profile will not load. A generic or empty desktop appears where your files should be — macOS's fallback when your user profile fails to open. Signatures: missing home folder contents, 'default' appearance. First test: check whether your home directory is intact from another account or via Recovery Mode Terminal — the data is usually still on disk even when the session cannot open it.
• Storage is failing. Any of the above, plus slowness, repeated filesystem messages, or disk errors in Console logs. Signatures: I/O error mentions, SMART warnings, behavior that worsens over hours. First test: disk health reporting from Recovery Mode — and if it shows failure, stop writing to the disk and go to Article 48.

The data-preservation rule is identical in spirit to the Windows equivalent (Article 17) but has a Mac-specific convenience: because authentication already works, you can often reach your files through a second account, guest session where available, or Recovery Mode's disk utilities while the primary profile is broken. Copy what matters — Documents, Desktop, and any app data folders you know hold value — to an external drive before running repairs, reinstalling user components, or creating a new user. Repairs that rebuild a profile are safe for data only when that copy exists.

1. Record the exact sequence: what appears after the password is accepted, how long each stage lasts, and whether it loops or hangs — the stage boundary is your diagnosis.
2. Copy your user folders to external storage via any working access path (second account, guest, or Recovery Mode). If no path exists, that itself is a diagnostic result pointing at storage.
3. Boot Safe Mode once and observe: if the desktop reaches you there, the fault is in an extension, login item or non-essential component — remove them one at a time back in normal mode.
4. If Recovery Mode reports disk errors or SMART warnings: image the disk before further work and involve professional recovery (Article 48). Do not run repair utilities repeatedly on a failing drive.
5. For confirmed profile failure with safe storage: create a new user, verify the machine is stable in it, migrate your copied files, and only then retire the broken profile.

Verification after repair: a clean sign-in to your real profile with files present; one full day of normal use without recurrence; and, if storage was implicated, a follow-up health check a week later. A post-authentication fault that returns within days was usually a symptom, not the disease — treat recurrence as the same case reopened, not a new one. Keep the pre-repair copy of your user folders until that week has passed; it is cheap to hold and expensive to have needed.

• Related reading:
• Article 19 — Forgotten your Mac login password
• Article 48 — When to stop troubleshooting and seek professional recovery
• The macOS library — Safe Mode behavior and log-based diagnosis

Changing your Apple Account password is one of those routine actions that can quietly produce a lockout, because the Apple Account and the Mac's login account are related but distinct objects. The Apple Account is your online identity — iCloud, the App Store, Find My, and (where linked) the recovery path for your Mac login password. The Mac login password is the local credential that unlocks this specific machine's user session. They can share the same string by habit, but changing one does not automatically change the other — and the interactions between them are where the post-change surprises live.

The three things that can go wrong after the change

• The keychain prompt. If your Mac login password was the same as the old Apple Account password and you changed only the Apple side, nothing breaks immediately — until some feature needs to reconcile the two. More commonly, after any login-password change on a Mac that is linked to an Apple ID, macOS asks at next unlock whether to update the login keychain's password. Declining (or missing) that prompt leaves saved Wi-Fi passwords and website credentials locked to the old value: sign-in works, but the keychain does not follow.
• Trusted-device verification loops. The Apple Account uses your devices as verification factors. After a password change, other services may ask for approval on a trusted device — and if the Mac you are trying to use was itself signed out or is the device needing re-verification, you can be asked to prove yourself with the very thing you are locked out of. The break is usually made by completing verification from a different already-trusted device (another iPhone, iPad or Mac).
• iCloud sign-in on the Mac. The Mac's iCloud settings may still hold the old Apple Account session and prompt for the new password at various moments — or, if you changed the password elsewhere and forgot the new one promptly, the Mac becomes one more locked-out client of the same account.

The reason these three failures cluster around one routine action is that the link between the two objects is maintained by cached state, not by a live connection: the Mac stores an iCloud session token, a keychain encryption derived from the local password, and (where configured) an Apple ID recovery association. A password change invalidates the online half of each cache immediately but can leave the local half valid for hours or days — so the machine appears fine until the first operation that forces reconciliation, which is why post-change lockouts tend to arrive a day later rather than at the moment of the change. Knowing that, the diagnosis after any surprise is simply: which cache just got reconciled, and what did it find?

1. If the Mac login itself still works: sign in normally, answer the keychain update prompt when it appears (choose to update), then open System Settings → Apple Account and confirm iCloud is signed in with the current password. Test one saved credential (a known Wi-Fi network) to prove the keychain followed.
2. If the Mac login password is now unknown because you changed the Apple side (they were the same, and the change propagated or confused you): use the standard reset paths in Article 19 — with the extra fact that your Apple ID verification should now succeed with the new password, which often makes the Apple ID reset branch available.
3. If you are locked out of the Apple Account itself after the change: go to the provider's official account-recovery page from any browser and complete verification via a trusted device or alternate factor. Do not attempt to 'reset' the Apple Account through the Mac's local settings — the local machine cannot perform an online identity reset.
4. Once back in: check the Apple Account's security section for recent sign-in activity, confirm two-factor is still enrolled on devices you control, and re-sync any Mac that shows stale iCloud sessions by signing out and back in where prompted.

Verification for this specific scenario has two parts: the machine-level check (sign in, keychain updated, one saved credential works) and the account-level check (Apple Account security page shows only your devices and recent sign-ins you recognize). Both clean means the change is fully absorbed; either dirty means one object is still out of sync, and the fix is a deliberate re-verification of that object, not more waiting.

• Related reading:
• Article 19 — Forgotten your Mac login password
• Article 35 — Recovering an account after suspicious sign-in activity
• The macOS library — permissions and account behavior on the Mac

The point at which a locked Mac's owner decides to 'just erase it and start over' is the moment most recovery value is destroyed — because erasure is irreversible for exactly the data that made the machine worth saving, and because several things about the machine change permanently with an erase. None of this argues against erasing when it is the right call; it argues for making that call with four facts in hand rather than from frustration: backup status, encryption state, recovery-key availability, and what Activation Lock will do afterward.

The four facts, checked in order

1. Backup status. Is there a Time Machine volume (or other backup) that is current enough to live with? Check from another Mac if needed: does the latest backup predate the lockout by minutes, days or months? 'A backup exists' and 'a backup I can afford to restore from' are different answers, and only the second one makes erasure safe.
2. Encryption state. Is FileVault on? If yes, an erase-and-reinstall does not give you the old data — it gives you a clean machine, and the old volume's contents are gone with the encryption. If you hoped reinstallation would 'unlock' anything, stop: reinstalling macOS over an encrypted volume requires unlocking or wiping it first; there is no path where the install recovers sealed data.
3. Recovery keys. If FileVault is on and a recovery key exists (Article 21), one last attempt at the supported reset paths — Apple ID verification, then the key — should happen before erasure, because it is the only route that preserves anything. If no key and no Apple ID route exist, say so out loud: the data is already lost in any practical sense, and the erase decision is now purely about the machine.
4. Activation Lock. Erasing a Mac does not remove Activation Lock — the device remains tied to the Apple Account that was signed in. After a wipe, setup requires that account's credentials (or its recovery process). If you are erasing because you cannot reach that account, the post-erase machine is still gated by it; if the Mac is being sold or transferred, the lock must be satisfied from the account side first, or the next owner inherits a brick. This is protection working as designed, and it makes 'erase my way out' a two-account problem, not one.

A practical note on the first fact, because 'current enough' needs an operational definition: from any other Mac, open the Time Machine volume in Finder and look at the timestamp of its newest snapshot — that is your worst-case data age if you erase today. Then answer honestly what you would lose between that timestamp and now: for a machine whose work lives in synced services (iCloud Drive, mail, cloud documents), days may be acceptable; for one holding local-only files — photo libraries never uploaded, project folders, unreleased work — the gap is exactly what erasure will cost you. If the answer to 'what do I lose?' is anything you cannot rebuild, the erase is not yet a rational choice, and the remaining move is to spend the time on the reset paths (Article 19) or a professional assessment before touching the volume.

The decision, stated plainly: with a good backup and no reachable reset route, erasing is a rational choice — the machine's value outranks its contents, and Activation Lock can be resolved through the account's own recovery process once you are ready. Without a good backup, the erase converts 'locked but intact' into 'gone', which no later step undoes; in that state, the remaining options are professional assessment of the encrypted volume (Article 21's honest limits apply) or accepting the loss deliberately, with eyes open. Either way, write down what you decided and why — it is the difference between a decision and a surrender made at 2 a.m.

• Related reading:
• Article 21 — Understanding FileVault recovery keys
• Article 19 — Forgotten your Mac login password
• Article 48 — When to stop troubleshooting and seek professional recovery

On a typical Ubuntu desktop or server, your user password is stored locally in the system's shadow password file — there is no vendor to call for a reset. The supported recovery route for a forgotten password on a non-encrypted system therefore runs through the bootloader: boot into a maintenance context where you can change the account directly. This procedure requires physical access to the machine (or console access in virtualized/cloud environments), assumes standard GRUB with no additional bootloader password, and is described here for Ubuntu 18.04 and later on UEFI systems — older BIOS/legacy-GRUB layouts differ in menu details but not in principle.

The route, and what each step does

1. At the GRUB menu (hold Shift during boot on BIOS systems; on UEFI systems the menu may need to be enabled or appears briefly — interrupt with the appropriate key for your firmware), select 'Advanced options for Ubuntu' and choose a kernel entry ending in (recovery mode), or edit a normal entry.
2. If editing a normal entry: press e, find the line beginning with linux, replace ro with rw init=/bin/bash, and boot with F10. This starts the system with root access to a writable filesystem and no services running — a controlled maintenance state, not normal operation.
3. Identify your username (the home directories under /home), then run the password change for that account. The command below is the actual account change; everything before it was only getting to a place where it may be run.
4. Finish cleanly: run exec /sbin/init (or, more safely on newer systems, sync, then reboot with echo b > /proc/sysrq-trigger or a hardware reboot after syncing). A clean transition matters because the filesystem was mounted writable outside the normal startup sequence.

passwd yourusername

What LUKS changes about all of this

If the system uses full-disk encryption (LUKS — common on Ubuntu Server and offered at desktop install), the bootloader route above is gated: GRUB will prompt for the LUKS passphrase before any kernel starts, and without it no maintenance shell exists to change anything. That passphrase is a disk-encryption credential, not a user password, and it has its own recovery story (Article 28). A forgotten user password on an LUKS system where you know the passphrase is still solvable with the same steps once the volume unlocks; a forgotten passphrase is a different and much harder problem — no account-level procedure substitutes for it.

Precautions before running it: note the exact kernel line you edited (so you can revert), avoid making other changes while in the maintenance shell — one variable per session — and after a successful password change, boot normally and verify both that the new password works at the login screen and that your files, cron jobs and services behave as before. If the system now boots to a different failure than before, you have changed two things at once; revert the edit and re-approach with one variable.

• Related reading:
• Article 28 — Understanding LUKS disk encryption recovery
• Article 30 — Linux account locked by authentication policies
• Article 58 — Recovering access to a shared or family computer

On Linux, 'your password' is checked by different code paths depending on where you type it, and those paths can disagree. The graphical login screen (GDM, LightDM or SDDM), a terminal su/sudo prompt, an SSH connection and a remote directory service each run their own authentication stack — usually built from PAM modules, but configured per context. When the same string is accepted in one place and rejected in another, the fault is almost never 'the password changed'; it is a difference between contexts: layout, policy, configuration or identity source.

The contexts, and what each one adds on top of the password check

Diagnosing in the right order

1. Establish the layout question first, per context: at a TTY or graphical prompt, type your password into a visible field and compare. Keyboard layouts differ between virtual consoles and graphical sessions on some setups, and numpad/IME states carry over differently.
2. Test the same account in two contexts you can reach (e.g., local terminal su - versus SSH from another machine). One working and one failing localizes the fault to the failing context's configuration rather than to the credential itself.
3. For SSH failures specifically: read the server's SSH configuration for password authentication state (/etc/ssh/sshd_config, effective values via sshd -T where you have access) and check the auth log (/var/log/auth.log on Debian/Ubuntu, /var/log/secure on RHEL-family) for the exact rejection reason — 'invalid user', 'authentication failure' and 'refused connect' are three different problems.
4. For directory-backed accounts: ask (or check) whether the identity source has its own lockout counter, and when the last successful authentication was recorded there. A directory lockout behaves exactly like a wrong password from the client's seat.

One subtlety worth naming: PAM is a stack, not a single check. Modules run in order — account validity, password verification, session setup — and any module can deny. That is why 'the password works at the TTY but not in the GUI' can be an account policy (expiration, required 2FA module present only in one stack) rather than a password problem at all. The auth log entries name the denying module; reading them is the difference between guessing and knowing. On a system where you cannot read those logs, the two-context test from step 2 is your substitute — it localizes the fault even when it cannot name it, and that is enough to stop the wrong repairs.

Verification: after fixing the identified context difference, complete sign-in in every context you rely on (graphical, terminal, SSH), because a fix that only repairs one path leaves the next failure waiting in another. A short written note of which contexts were tested and when is the cheapest insurance against this exact diagnosis being needed again.

• Related reading:
• Article 29 — SSH access fails after a password or key change
• Article 30 — Linux account locked by authentication policies
• Article 25 — Forgotten an Ubuntu user password

A Linux machine that never reaches its login prompt has failed somewhere between power-on and a usable session, and the four usual suspects — a crashed display manager, a damaged or checking filesystem, a half-finished update, and an authentication loop — produce overlapping symptoms: a blank screen, a text console with no prompt, or repeated reboots. The diagnostic discipline is the same as for every other lockout class in this library: read the evidence before changing anything, prefer read-only access while diagnosing, and treat user data as the asset under protection from the first minute.

Reading the evidence at each stage

• What appears at all. A graphical splash that dies mid-sequence points at the display stack; a text console with kernel messages scrolling then silence points earlier; a 'filesystem check' progress report that loops or fails names the disk layer directly; an immediate reboot loop often indicates a failing boot component rather than any login issue.
• Recent changes. A failed apt/dnf/pacman update is the single most common cause of 'worked yesterday' display failures — interrupted package states leave half-configured services. If an update was in progress at last power-off, that is your prime suspect and changes the correct first step (repairing package state rather than touching display configuration).
• The logs, if reachable from anywhere. A previous session's journal (/var/log/journal), /var/log/syslog or messages, and the kernel ring buffer all record the failure — readable from a live-USB session mounted read-only, which is the key trick of this entire article.

The read-only diagnostic pass

1. Boot from a live USB of the same distribution family. This gives you working tools without touching the installed system's state at all.
2. Identify the root partition (by size, mount hints in /etc/fstab on other partitions, or LUKS headers) and mount it read-only: the point is to read evidence without writing a single block to a system whose fault you have not yet named.
3. Read the failure: journal files for the last boot, package manager state (interrupted transactions are visible in their status databases), and filesystem check logs. Note disk health indicators — I/O errors in the kernel log on a live session are a hardware signal that changes everything (Article 48).
4. Only after the fault is named, mount read-write for the specific repair: complete or roll back the interrupted update, fix the display manager's configuration, or run the filesystem check the system itself requested. One repair per mount, then re-test from normal boot.

User data protection runs in parallel with all of this: the home directories on the installed system are readable from the live session even when the system itself cannot boot, so copying what matters to external storage early is both a safety measure and a diagnostic aid — if reading the homes fails with I/O errors while other paths read fine, you have localized a disk problem with your data in the blast radius. That information is worth more than any fix applied before it. And because the live session sees the disk exactly as a repair would, anything readable there now will be readable after the repair — which lets you verify data integrity from the safe side before the system is trusted again.

Verification after repair: normal boot to the login screen; sign-in with the known password (if that also fails, you now have Article 25/30 layered on top — handle them in order); a day of normal operation; and for update-caused failures, confirming the package state is fully consistent so the next update does not inherit the old breakage.

• Related reading:
• Article 25 — Forgotten an Ubuntu user password
• Article 48 — When to stop troubleshooting and seek professional recovery
• Startup, boot & recovery options — the cross-platform view of pre-OS failures

LUKS (Linux Unified Key Setup) is the standard full-disk encryption layer on most Linux distributions, and its recovery model is worth understanding precisely because it removes an option people assume exists: there is no 'reset' for a LUKS passphrase. The volume is encrypted with a key stored in the LUKS header; your passphrase (or a keyfile) is one of possibly several ways to unlock that header's key material — and if none of the available ways work, the data is sealed by design. Every other recovery procedure in this library operates on credentials that can be re-issued; the LUKS passphrase is not re-issuable, because re-issuing it would mean re-encrypting the disk with new key material, which requires being able to read the disk first.

The objects involved

• The passphrase: what you type at the pre-boot prompt. It is checked against key material in the LUKS header; it does not itself decrypt data directly, and changing it later does not change the underlying volume key.
• Key slots: the LUKS header holds multiple independent unlock slots (typically eight). A passphrase occupies one slot; a keyfile can occupy another. This is the structural source of LUKS's 'recovery arrangements': you are not limited to one way in if you set up more than one.
• The header itself: contains the key slots and metadata, but not the encrypted data. A header backup is a copy of exactly this structure — small (a few MiB) and worth keeping, because it lets you restore unlock capability if the on-disk header is damaged, while the data partitions remain intact.
• Keyfiles: files whose contents serve as an unlock credential in their own slot. Common on servers (unattended boot) and a good second factor for desktops — stored offline, they survive passphrase amnesia that would otherwise be total.

What exists as recovery, by failure mode

sudo cryptsetup luksHeaderBackup /dev/sdX
  --header-backup-file ~/luks-header-backup.img

One practical detail about keyfiles, since they are the recovery arrangement most people never set up: at boot, the bootloader can be configured to read a keyfile from a fixed location (commonly an unencrypted small partition) instead of asking for a passphrase — which is how servers unlock themselves unattended. The security trade is explicit and should be understood before adopting it: the keyfile's storage location becomes as sensitive as the passphrase itself, so it lives on hardware that must never leave your control, and its loss or theft is equivalent to handing over the disk. For a desktop, the simpler arrangement is usually better — keep the keyfile offline (encrypted external drive), use it deliberately when you need a second unlock path, and let the passphrase remain the daily credential.

The planning consequence is specific and cheap: at least two unlock slots in use (passphrase plus keyfile, or two passphrases known to different authorized people), a header backup stored separately from the disk, and both facts recorded in your recovery kit (Article 56). With that configuration, 'forgotten passphrase' becomes an administrative task; without it, the same amnesia is permanent — and no procedure written anywhere changes which of those two states you are in when it happens.

• Related reading:
• Article 25 — Forgotten an Ubuntu user password
• Article 46 — Password reset succeeds but you still cannot access your data
• Article 56 — Create a secure emergency access kit

Changing an SSH credential is supposed to be a quiet operation — swap the key, update the password, move on. When access fails immediately afterward, the failure is almost always in the plumbing between your new credential and the server's authentication policy: the key was not installed correctly, permissions are wrong (SSH is famously strict about them), the server's configuration no longer accepts the method you are trying, or an account policy intervened. Each has a distinct signature in the server's auth log, and all four are fixable by an authorized administrator with another access path — which is why the first practical question is always 'how do I get to this machine at all right now?'

The four failure classes

• Key not effectively installed. The new public key was added to authorized_keys with a typo, truncated paste, wrong line structure, or into the wrong user's file. Signature: password auth still works but key auth is rejected; the log shows the offered key not matching.
• Permissions too loose. SSH refuses keys when ~/.ssh is group- or world-writable, authorized_keys permissions are open, or the home directory allows group writes. Signature: identical behavior before/after a change that touched nothing but file modes — often after a copy operation that reset permissions.
• Server policy changed. PasswordAuthentication no (keys-only), AllowUsers/DenyUsers lists, or a configuration reload that activated a pending change. Signature: one method stopped working sitewide while the other still works — the policy, not your credential, moved.
• Account-level intervention. Lockout counters (Article 30), account expiry, or directory-side policy for managed servers. Signature: the rejection names the account rather than the method; other users on the same server are unaffected.

Diagnosing and restoring, in order

1. Secure an alternate access path first — this is what makes everything below safe: physical/console access, a cloud provider's serial console or metadata service, a management network, or another account that still works. Without one, you are troubleshooting blind on a machine you cannot reach.
2. Read the auth log for the failed attempts (/var/log/auth.log or /var/log/secure): the exact rejection reason distinguishes all four classes above in one pass.
3. Check key-file hygiene where the log points there: the permissions below are the canonical safe state, and comparing against them is a read-only test that often finds the fault immediately.
4. Verify effective SSH policy (sshd -T prints the running configuration's effective values) before editing anything — the running config, not the file on disk, is what rejected you.
5. Apply one fix, reload the SSH service, and test from a new client session. Keep your alternate access path open until the new session works — closing it first is how a fixed server becomes an unreachable one.

ls -ld ~/.ssh ~/.ssh/authorized_keys
ls -ld ~

Step 1 deserves its own expansion, because 'an alternate access path' means different concrete things in different environments, and knowing yours in advance is what separates a thirty-minute fix from an escalation. On a physical machine: the console port or a directly attached monitor and keyboard. On a cloud instance: the provider's serial/console session (available from the management interface without any network route to the box) — this is usually the fastest path of all. On managed hardware: the out-of-band management controller (iDRAC, iLO, IPMI) gives console access independently of the operating system and its network stack. If none of these existed before the failure, that absence is itself a finding worth recording: single-path access to any server you depend on is a standing risk, and the fix — a second path, however modest — costs an afternoon, not a lockout.

Verification for this scenario is deliberately two-part: the new credential works from a fresh client session on a different network path if possible, and the auth log shows the success entry naming your key or account cleanly. Then update your notes on how this server is reached — the 'only way in' knowledge that lived in one head (or one laptop) is exactly what made this failure expensive.

• Related reading:
• Article 30 — Linux account locked by authentication policies
• Article 26 — Linux accepts your password in one place but rejects it elsewhere
• Article 58 — Recovering access to a shared or family computer

Linux distributions protect accounts from guessing attacks with failed-login accounting: after N consecutive failures, the account refuses further attempts for a delay period or until an administrator clears it. The mechanism is real protection — it is also the reason a user who mistyped their password five times at a TTY can find themselves locked out of every context on the machine, including ones that previously worked fine. Distinguishing 'policy lockout' from 'wrong password' matters because the fix for one (wait, or admin reset) does nothing for the other, and repeated attempts during a policy lockout usually make it longer.

The controls differ by distribution — name yours first

The table encodes the category's core warning: there is no single 'unlock' command that is safe to quote for every Linux system. The correct first step on any of them is reading what the PAM stack actually contains (/etc/pam.d/common-auth on Debian-family, /etc/pam.d/system-auth or password-auth on RHEL-family) — which module enforces the lock, with what deny threshold and unlock delay. That reading also answers the question 'will this clear itself?' because time-based unlocks do, while indefinite denies need an administrator.

The administrator recovery, done deliberately

1. Confirm the lock is policy-based: the auth log shows denied attempts with the faillock/lockout module named, and the account works from a context that bypasses PAM accounting where one exists. If the log instead shows plain authentication failures with no lockout module, the password itself is the problem (Article 25), not a counter.
2. Inspect the counter: on faillock-based systems, faillock --user NAME (run as root or the affected user) shows failure count and last-failure time — evidence you can quote in any support conversation.
3. Clear it deliberately: sudo faillock --reset --user NAME. This is an administrative action that removes the lockout record; on shared or organizational systems it should be logged and, where policy requires, approved — clearing another person's lockout silently is how 'help' becomes a cover for something else.
4. Verify with one clean sign-in in each affected context (TTY, graphical, SSH), then check the account's recent activity log for anything the failed attempts were actually responding to — a lockout pattern sometimes means someone else was typing wrong passwords before you arrived at the keyboard.

faillock --user yourusername
sudo faillock --reset --user yourusername

Prevention that fits this failure mode: where the distribution allows it, configure time-based unlocking (the lock clears itself after a delay) instead of indefinite denies for personal systems, so amnesia costs minutes rather than administrator involvement; and keep one known-good administrative path per machine — the person who can clear locks should not be locked out of the clearing tool. On a fleet, that means the unlock procedure itself belongs in your recovery inventory (Article 55): which module enforces, what the reset command is on this distribution, and who holds the credentials to run it.

• Related reading:
• Article 25 — Forgotten an Ubuntu user password
• Article 26 — Linux accepts your password in one place but rejects it elsewhere
• Article 43 — Your computer is locked after too many sign-in attempts

An email account deserves a different urgency than any other lockout in this library, for a structural reason: it is the hub. Password resets for banking, cloud storage, social platforms and work tools all route through it; two-factor codes often land there; and when a provider asks 'verify with your recovery email', the answer is frequently the very account you are trying to recover. Losing the hub does not just lock one door — it removes the key ring for most of the others, which is why this tutorial treats an email lockout as the first priority in any multi-account incident.

The official recovery path, and what providers can actually verify

1. Go to the provider's sign-in page by typing its address — never via a link in an email or search ad — and choose the account-recovery / 'can't access your account' flow. This is the only path whose outcome you can trust, because it is the one that updates the real account state.
2. Work through the verification methods the flow offers, in order of strength: a code to another registered email you control, approval on a trusted device you still possess, a phone code where registered, and finally the evidence-based review (old passwords, registration details, activity history). Each method you pass also confirms that factor is current.
3. If the flow stalls at a method you cannot use, check whether the account's recovery contacts are themselves locked (the nested-lockout problem, Article 04) — and if so, recover the outer account first where possible before returning here.
4. Once back in: run the provider's security review (recent sign-ins, connected apps, active sessions), change the password, re-verify two-factor, and revoke sessions you do not recognize. An email recovery that skips containment is half a job — see Article 49 for the full sequence.

The evidence-based review is where expectations need calibrating. Providers ask for what their systems can check: registration details, old passwords you genuinely remember, approximate activity history. They do not accept character references, and no support conversation — human or automated — can override a failed verification by promise. Some accounts in weak-evidence states are permanently unrecoverable; that is the cost of the same verification wall that stops attackers, and it is stated here plainly rather than papered over with 'support will sort it out'.

Verification that the recovery held: sign in on two devices; confirm the security page shows only your sessions and devices; send a test message to an account you control from outside the provider's ecosystem; and check that password-reset links for at least one other major service still arrive in this inbox. The last test is the one that proves the hub function — not just the mailbox — is restored.

• Related reading:
• Article 04 — Recovering access when you no longer know your recovery email
• Article 35 — Recovering an account after suspicious sign-in activity
• Article 49 — What to do immediately after recovering a compromised account

A locked cloud storage account looks like an ordinary online lockout, but it has one property that changes the correct behavior: the data may exist in two places at once. Files synced to a laptop or desktop are local copies with their own lifecycle — deletions and changes on either side propagate depending on the client's state. That symmetry is usually a feature; during a lockout it is a hazard, because the most common self-inflicted damage in this scenario is cleaning up 'duplicates' on the local machine while the cloud originals are still inaccessible and unsynchronized.

The recovery sequence, with the data trap handled first

1. Before touching anything: identify where synced copies live locally (the sync client's folder — check its status indicator for last-sync time) and stop the cleanup instinct. Do not delete, move or reorganize local synced files while the cloud account is locked. Local copies are currently your only guaranteed access to at least part of the data, and they may be the only version of recently changed files.
2. Run the provider's official recovery flow (typed address, never a link): identity verification via alternate email, phone, trusted device or evidence review, as available. The process is structurally the same as Article 31; what differs is what you do with the account once it opens.
3. On first successful access, check the sync state before acting: compare the cloud folder's recent-change history against your local copy's. If both sides changed during the lockout window (possible if a second device was still signed in), resolve conflicts deliberately rather than letting the client auto-resolve them.
4. Review retention and sharing settings while you are in: files shared with others may outlive your access assumptions, and some plans have retention or versioning windows that affect what 'the data' means. Note anything surprising before closing the session.

Shared-account situations add a second axis of risk worth naming explicitly. Where a storage account is shared — family photo libraries, small-team drives, legacy business accounts — the lockout may belong to one person's credentials while the data belongs to several, and the recovery path depends on who owns the account itself (the billing/primary identity), not who is locked out. In those cases the correct first call is to the account owner or the organization's IT function (Article 34 for managed contexts), because a non-owner 'recovering' a shared account can reset credentials that other legitimate users depend on, converting one lockout into several.

Verification after recovery goes beyond 'I can see my files': confirm a deliberate round-trip (upload a test file, see it appear locally; modify locally, see it appear in the cloud), check that sharing links still behave as expected, and confirm the account's recovery contacts are current — a storage account whose only recovery route is the same inbox that just locked you out has not finished its recovery, only paused it.

• Related reading:
• Article 31 — Recovering a locked email account
• Article 34 — Work or school account recovery
• Article 55 — Build a personal account recovery inventory

'I can't get into my social account' covers two situations with opposite correct responses, and the first job is telling them apart. A lock — forgotten password, expired session, a protective suspension after unusual activity — is a recovery problem: the account is intact, waiting for you to prove yourself. A taking — someone else changed the password and contacts and is using the account — is a security incident: the same 'recovery' flows exist, but they are now contested, because the other party can see your attempts and may act to block them. The symptoms that lean toward takeover: the account posting or messaging things you did not do, friends reporting odd behavior, recovery contacts changed without your action, or a sign-in history showing devices and locations you do not recognize.

The official paths, used correctly

1. Reach the platform's account-recovery page by typing the platform's address directly. Social platforms maintain dedicated 'compromised account' or 'hacked account' flows that are separate from ordinary password recovery — where you have takeover symptoms, use that flow; it is designed to weigh evidence differently than the routine one.
2. Complete identity verification as offered: registered email/phone codes where still reachable, photo ID matching the profile where the platform supports document verification, and device-history questions. Provide only what is asked, through the official page — platforms do not verify accounts over third-party 'recovery services', DMs or phone numbers found in search results (Article 52 exists because this exact desperation is monetized).
3. While the review runs, contain the social blast radius: warn close contacts that messages from the account may be phishing (a short note through channels you control), and if the account manages money, subscriptions or business relationships, flag those specifically — takeover abuse concentrates there.
4. On recovery: change the password to something new, review and clean the sign-in history and connected apps, re-enroll two-factor on a factor the attacker did not have (a newly generated authenticator entry or hardware key, not a phone number that may be compromised), and read through recent activity for what was done while you were out.

One expectation to set honestly: outcome timing and success vary by platform and by evidence strength, and no external party — including anyone who finds your situation online and offers to 'fix it fast' — has more authority than the platform's own process. Identity-verification-based recovery can take days; accounts with thin identity history (new profiles, few connections, no document verification on file) may not be restorable even when the owner is legitimate. That asymmetry — strong for attackers who act fast, weak for owners who arrive later — is why the containment steps above run in parallel with the review rather than after it.

Verification after recovery has two layers: the technical one (only your sessions remain, two-factor is on a fresh factor, connected apps are cleaned) and the social one (contacts confirm normal behavior resumed). The second layer matters because takeover damage often continues through people who were phished during the window — a brief follow-up to close contacts is what ends the incident rather than merely the lockout.

• Related reading:
• Article 35 — Recovering an account after suspicious sign-in activity
• Article 49 — What to do immediately after recovering a compromised account
• Security: suspicious behaviour, phishing & social engineering basics

The single most important fact about work and school accounts is that you are not their sole principal. A managed identity — whether it lives in your organization's directory service or in a cloud identity provider such as Microsoft Entra ID, Google Workspace or Okta — is administered by an organization with its own policies, and the recovery routes available to you are exactly those the organization has published. The personal-account procedures elsewhere in this library (self-service evidence reviews, waiting out provider timelines) do not apply, because the 'provider' in this case is your employer or school, and its support channel is internal IT rather than a web form.

What typically gates a managed account, and who can clear each gate

The compliance row in that table is worth unpacking, because it is the one cause where the lockout message names its own cure and people still get stuck. Modern managed sign-in is frequently conditional: the identity provider checks not just who you are but what state your device is in — operating system version within policy, disk encryption on, screen lock enabled, management agent enrolled and reporting. A 'compliance failure' block therefore usually means one specific, checkable condition on your machine has drifted out of policy (an update was skipped, a drive was re-partitioned without re-encryption), and the fix is to satisfy that named condition, after which sign-in typically clears without any human intervention at all. Reading the compliance message as a to-do list rather than a wall is the difference between a ten-minute fix and an IT ticket.

1. Check the organization's published self-service first: most organizations run a password-reset or account-unlock portal for exactly the common cases. The intranet, IT service desk page or the sign-in screen's own links name it where it exists.
2. If self-service is unavailable or the message names a policy hold, open a ticket with IT that states: your identity as the organization knows it (employee/student ID where applicable), the exact error text, when it started, and what changed just before (new device, travel, password attempt). Precise input shortens verification back-and-forth.
3. Expect identity verification through organizational channels — manager confirmation, HR records, badge systems. This is slower than consumer flows by design, and the slowness is the control: it is what prevents a stolen laptop from being used to reset its owner's work identity remotely.
4. While waiting, do not attempt workarounds that touch organizational controls: no third-party 'unlock' tools against the directory, no creating personal accounts to route around compliance checks. Those actions are policy violations with their own consequences, independent of whether they would have worked.

Verification after recovery is organizational in flavor too: confirm sign-in works from your registered device, that MFA prompts appear and approve normally, that compliant-device status is green in whatever portal shows it, and — where the lockout was security-related — ask IT what the hold was based on. Knowing which pattern triggered a security suspension tells you what not to do next time (a travel pattern, a device change, an attempt burst), which is information no consumer support flow would ever give you.

• Related reading:
• Article 12 — When every two-factor method is unavailable
• Article 16 — Windows says your account is locked
• Article 58 — Recovering access to a shared or family computer

When an account locks itself after unusual sign-in attempts, the first interpretive error to avoid is reading it as a boring forgotten-password problem. A protective lock means the provider's risk system observed something inconsistent with your normal pattern — a new device in a new location, a burst of failures, a credential used from an unfamiliar network — and chose to pause rather than guess. The lock is the system doing its job on your behalf, and the correct response is to complete its verification through trusted channels and then review what it saw. The alternative reading — that the 'suspicious activity' was an actual intrusion in progress — requires a different, faster sequence, and the two readings are separated by one concrete question: do you recognize everything the account's activity log shows?

Trusted recovery channels only

This is where compromised-account situations are won or lost procedurally. The only safe entry points to your account's recovery are: the provider's official website, reached by typing its address into a browser you control; the official mobile app already installed on your device; and support channels published from those same surfaces. Everything else — links inside 'security alert' emails (which attackers send precisely when they have triggered a lock), phone numbers found in search results, DMs from 'support agents' on other platforms — is an untrusted channel that may be the attacker's own infrastructure. The test is simple and worth applying reflexively: could this channel exist if the account were already compromised? If yes, it is not a trusted channel, whatever it claims.

1. Reach the official sign-in page by typing the address. Complete the verification the protective lock requires — this usually succeeds quickly for legitimate owners, because your remaining factors (alternate email, authenticator app, trusted device) are exactly what the system wants to confirm.
2. Run the full security review immediately after re-entry: recent sign-ins (devices, locations, times), active sessions, connected/third-party apps with access, and the state of two-factor and recovery contacts. Read all of it, not just the first page.
3. If everything is recognizable: the lock was protective and the episode closes with a password change to a fresh value and confirmation that no stale sessions remain (sign out everywhere where offered).
4. If anything is unrecognizable — unknown devices, changed contacts, apps you did not add, messages sent — switch to containment mode (Article 49): revoke those sessions and connections, replace two-factor with factors the intruder did not hold, change the password, and review linked accounts that trusted this one.
5. Document what you found: a short written record of the unrecognized activity, timestamps, and what you changed. It is the input for any provider dispute later, and the clearest possible statement of where the incident ended.

Verification that the state is clean: a second look at the activity log after your changes shows only your remediation entries; sign-in from two of your own devices works with the new credentials and fresh two-factor; and the provider's security status for the account (where shown) reads normal. If a subsequent lock arrives within days, treat it as the same incident reopening — the first pass missed something — rather than as bad luck.

• Related reading:
• Article 49 — What to do immediately after recovering a compromised account
• Article 16 — Windows says your account is locked
• Security: suspicious behaviour, malware basics & safer everyday computing

A denied recovery request is the moment where most people either give up too early or start doing things that make the situation permanently worse. The useful reframe: a denial is usually not a verdict on your ownership — it is a statement that this submission did not meet the verification bar. Those are different objects. The first is appealable with better evidence; the second is often final, and the difference between them is determined by what the denial actually said, which is worth reading carefully rather than pasting into an anger-driven resubmission.

The three denial shapes, and what each one allows

• 'We couldn't verify your identity' (evidence shortfall). The submission lacked something checkable: details that did not match records, old passwords that were guesses, activity history too vague to validate. This shape is the most recoverable — a second, better-documented request has a genuine chance, because the bar was evidence quality, not ownership itself.
• 'This account does not meet recovery criteria' (policy limit). Some accounts — thin identity history, no document verification on file, long dormancy — fall outside what the provider's process can restore even for legitimate owners. This shape is where honest expectations matter most: the supported path may simply end here, and the productive work shifts to containment and replacement (securing linked services, warning contacts, rebuilding elsewhere) rather than an infinite appeal loop.
• 'Under review' that resolves to denial (timing). Multi-stage reviews take days to weeks; an interim 'not yet' is not a final no. The error to avoid here is resubmitting during the window — duplicate requests do not accelerate queues and can reset them.

Why evidence quality is the lever you actually control deserves a sentence of mechanism. Providers verify submissions against records they hold — registration data, payment history, activity patterns — and what they can check is consistency and specificity: does what you submit match what their systems show, and does it read as remembered rather than constructed? That is why the second request should be narrower and more precise than the first, not longer: three concrete, mutually consistent facts that match records beat twenty vague ones, and a submission that contradicts your earlier one (different 'old password' characteristics, different registration details) actively damages the case it was meant to repair. Before resubmitting, re-read everything you sent before and make the new submission consistent with it — including the parts you are not repeating.

Preparing the subsequent request, correctly

1. Read the denial for its specific reason where one is given; if none is given, assume evidence shortfall and prepare accordingly. Note the reference/case number for any follow-up.
2. Gather verifiable specifics, not volume: exact registration details as they were set (name variants you actually used, the original password's characteristics — you do not need to submit a guess list, but consistent remembered details strengthen the case), billing or payment history tied to the account, and dated activity you genuinely recall. Consistency across your submissions matters more than any single item.
3. Submit once, completely, through the official channel named in the denial (the appeal/review link on that page, not a fresh first-time request). A second submission should read as 'here is the evidence the first one lacked', not as a repeat of it.
4. Respect the stated review window. If the provider gives a timeframe, wait it out fully; if it gives none, a single polite status inquiry after a reasonable interval is appropriate — daily check-ins are not.

When the supported path genuinely ends — a policy-limit denial upheld on review — the remaining work is the same containment sequence this library uses for every unrecoverable case: secure everything that trusted the lost account, warn the people an attacker could phish through it, document the outcome (dates, case numbers, what was tried), and close the loop on subscriptions and services that routed through it. A denied recovery handled this way costs an account; handled any other way — endless resubmissions, fabricated evidence, third-party 'recovery' services with fees attached (Article 52) — it can cost more than the account was worth.

• Related reading:
• Article 04 — Recovering access when you no longer know your recovery email
• Article 12 — When every two-factor method is unavailable
• Article 52 — Recognizing fake password recovery services and support scams

The first question after losing a passkey is not 'how do I get it back' but where was it — because a passkey is not one object, it is a credential that lives in one of two places with very different loss semantics. A device-bound (local) passkey exists only in the secure element or keychain of the specific device where it was created: lose that device and the credential is gone with it, full stop. A synced passkey is copied through your platform account — a Microsoft account for Windows Hello passkeys, iCloud Keychain on Apple devices, Google's password manager on Android/Chrome — so the same passkey can exist on every signed-in device of that ecosystem, and losing one phone does not lose the credential itself.

The sync differences, stated without overclaiming

It is worth being precise here, because 'passkeys sync' is too vague to plan with. Syncing is a property of the platform account and ecosystem, not of passkeys as a technology: a passkey created while signed into your Microsoft account on Windows can appear on your other Windows devices signed into the same account; one created in iCloud Keychain follows your Apple ID across your Apple devices; one created with Google sync follows that account. A passkey created without sync enabled — or on a platform whose sync you did not sign into — stays local. And cross-ecosystem syncing does not exist: an Apple-ecosystem passkey is not available to your Windows machine, whatever the marketing shorthand suggests. Which of these states applies to a given passkey is usually visible in the device's password/passkey settings where the platform shows sync status.

What the relying party can do when a credential is lost

1. Establish which passkeys exist for the account, from any device you still control: most platforms list registered passkeys in their password manager, and many services show their own list of sign-in methods in their security settings. The question to answer: did I lose one credential among several, or the last one?
2. If other credentials remain (another synced passkey on another device, a hardware key, an authenticator app, a backup code): sign in with one of those, then manage the lost passkey from inside — remove the dead registration so it stops cluttering the list, and confirm the surviving set is what you want.
3. If the lost passkey was the only registered method: use the service's fallback factors where it has them (email/phone verification, backup codes), or its account-recovery flow (Article 12's decision process applies — passkeys do not create a new recovery category, they change which factors exist).
4. Once access is restored, re-establish breadth: at least one synced passkey per ecosystem you actually use, plus one factor that does not depend on any single device (a hardware key or stored backup codes), so the next single-device loss is not also a total loss.

The structural lesson mirrors Article 07 exactly: passkeys reduce password fatigue and phishing surface, but they do not remove the concentration problem — they relocate it. A user whose entire sign-in world is one synced ecosystem plus one phone has traded 'forgot my passwords' for 'lost my phone', which is a better trade in most threat models but still a single point of failure. The fix is the same breadth principle: multiple credentials, at least one outside the sync ecosystem, and backup codes stored offline for the accounts that matter.

Verification after recovery: sign in with each surviving method deliberately (not just the one you need today), confirm the platform's passkey list matches reality — no orphaned entries for dead devices, all intended ecosystems present — and note in your recovery inventory (Article 55) exactly which device/credential combination gates each critical account. That note is what converts the next loss from an investigation into a lookup.

• Related reading:
• Article 39 — Passkeys do not appear on your new device
• Article 07 — Lost your authenticator phone? Recovery options explained
• Article 42 — Choosing between passkeys, authenticator apps and security keys

A lost hardware security key is the cleanest version of 'something you hold' going wrong: no software to reinstall, no cloud copy to restore, no seed to recover — the credential physically left your possession. The recovery question therefore has two halves that are often handled in the wrong order. Half one is getting back into your accounts (the familiar factor-management work). Half two is making sure the lost key stops working for everyone else — including, potentially, the person who finds it — and half two is the one that gets skipped because it feels like bad news about your own security setup.

Getting back in: the standard factor inventory

For each affected service, the available routes are the same ones this library has covered for any lost second factor: other registered methods (a passkey on a device you still hold, an authenticator app, SMS where the service still offers it and you accept its weakness), backup codes if stored, trusted sessions that have not expired, or the provider's account-recovery flow where nothing else works. What is specific to hardware keys is how often they were the only registered method — chosen precisely because they are phishing-resistant and durable — so the 'other methods' column is frequently empty and the recovery flows carry the load. That is the single-key risk made concrete, and it is the planning lesson this article ends on.

Getting the lost key out of circulation

1. Recover access to each affected service through its remaining methods (inventory first, per Article 12's process).
2. From inside each recovered account, open the security/sign-in methods list and remove the lost key's registration. This revocation is what makes the physical object inert: an unregistered key can no longer authenticate to that service, whoever holds it.
3. Where a service offers it, check the device/key history for any use of the lost key after you realized it was missing — a use event means the finder (or someone) has already tried it, and the account deserves the full containment sequence (Article 49), not just the revocation.
4. Register your replacement key on the critical services now that access is restored — with the ordering discipline of Article 41: add first, verify, then remove old registrations only after the new one is proven.

A word on protocol scope, because it affects what 'the same key' means across your services: modern FIDO2 keys register per-service credentials (each service holds its own registration for that key), while the older U2F model registered a single credential usable anywhere. In practice this means revocation is per-service in both cases — there is no central 'deactivate this key everywhere' switch — and it also means a key's compatibility is a per-service question: some services support FIDO2, some only U2F, and a given physical key may implement one or both. Check the service's supported methods before buying a replacement rather than assuming the lost key's successor will be interchangeable.

The planning fix is structural and cheap: no critical account should have exactly one hardware key as its only second factor. The minimum sensible set is two keys (one daily, one stored separately — a desk key and a home-safe key cover the common loss modes), plus backup codes offline for the accounts where the service offers them. With that configuration, losing any single key is an inconvenience with a known procedure; with one key, it is this article in full.

• Related reading:
• Article 41 — Replacing an old security key without losing access
• Article 12 — When every two-factor method is unavailable
• Article 42 — Choosing between passkeys, authenticator apps and security keys

Set up passkeys on your old phone, buy a new one, and the sign-in sheet that should list them arrives empty. The failure has a short list of causes, all of them about where the credential is allowed to live rather than anything broken: the new device is not signed into the platform account that syncs the passkey; the passkey was created without sync in the first place; the platform's passkey/credential-provider settings on the new device are disabled or misconfigured; or the device itself does not meet the eligibility requirements for that platform's passkey storage. Each cause has a specific check, and the checks are cheap — which is why this is a configuration article, not a recovery one.

The four causes, in check order

1. Same platform account? Synced passkeys follow the platform account (Microsoft account, Apple ID, Google account — per ecosystem). Confirm the new device is signed into that exact account in the relevant place: Windows Hello settings on Windows, iCloud/Keychain on Apple devices, the Google password manager on Android. A device signed into a different account of yours sees none of the first account's passkeys.
2. Was sync actually on when the passkey was created? Check the old device (if still available) or the platform's passkey list from any synced device: if the credential appears there, it is synced and should propagate; if it exists only on the old device, it was local, and the fix is re-creating it on the new device rather than waiting for a sync that will not happen.
3. Credential-provider settings on the new device. Platforms gate passkey storage behind settings — keychain access, password-manager sync toggles, enterprise policy on managed devices. A managed work device may have passkey storage disabled by policy; in that case the 'fix' is an IT conversation (Article 34), not a setting you can flip.
4. Device eligibility. Passkey storage needs the platform's secure hardware path (secure element/TPM integration) and a current-enough OS version. Older devices or heavily customized setups may simply not offer passkey creation; the platform's settings page shows whether the feature is available at all on that device.

The distinction this article keeps returning to — missing credential versus failed sign-in — matters because their fixes are opposites. A missing credential (the passkey genuinely does not exist on this device) is fixed by creating or syncing it: a configuration problem with a positive solution. A failed sign-in (the passkey exists, the device prompts for biometrics, and the service still rejects) points at the relying party's registration state — a stale entry, a revoked credential, or a service-side issue — and is fixed in the service's security settings, not the device's. The observation that separates them: does the platform's sign-in sheet offer the passkey at all? Offered-but-rejected is one problem; absent-from-the-list is the other.

Verification is a two-device check: the passkey appears in the new device's sign-in sheet, and completing one real sign-in with it succeeds end-to-end (prompt → biometric → accepted). Then confirm the old device's role: if it is being retired, remove its registrations per Article 11's discipline; if it stays, both devices' lists should show the same current set — agreement between them is the definition of a healthy sync state.

• Related reading:
• Article 37 — Lost a passkey: what happens next?
• Article 11 — Moving an authenticator to a new device
• Article 40 — Understanding biometric sign-in failure

The mental model that makes biometric failures tractable: a fingerprint or face is not a credential, it is an unlock mechanism for one. When you enroll Windows Hello or Face ID, the system stores a mathematical representation of your biometric and binds it to your device's underlying credential — the PIN (on Windows) or the passkey/device key (on Apple platforms). Scanning successfully means 'this authorized body may use that credential right now'. Which is why a biometric failure never means 'the account rejected me' — it means one link in a local chain stopped working, and the rest of the chain (the PIN, the password) is still intact behind it.

Why the scan stops working — and what each cause implies

• Sensor or surface issues. Dirty, wet or injured fingers; a smudged camera; facial changes (illness, new glasses, significant styling) that fall outside the enrolled template's tolerance. Signature: intermittent failure, works sometimes, fails in conditions. Fix is environmental — clean the sensor, re-enroll if the template is stale.
• The biometric enrollment itself degraded. Templates age; some platforms prompt for re-enrollment after updates or a period of failures. Signature: progressive worsening rather than sudden total failure. Fix: re-enroll through the platform's settings while you can still sign in by other means.
• Policy restrictions. Managed devices (work/school) can disable biometric sign-in entirely or restrict it to specific conditions — some organizations require PIN fallback after a set interval, others disable biometrics on shared or kiosk-style machines. Signature: the option is greyed out or absent in settings, or works only sometimes by design. Fix: an IT conversation (Article 34), not a troubleshooting session.
• The underlying credential changed. A PIN reset or password change can invalidate biometric bindings on some configurations until re-verification. Signature: biometrics stopped working immediately after a credential change you made. Fix: complete the re-verification prompt the platform offers, or re-enroll.

1. Use the fallback deliberately: sign in with the PIN or password — this both restores access and confirms the underlying chain is healthy, which is the diagnostic that matters most.
2. If the fallback works: the failure is confined to the biometric link. Clean/retry once for surface issues; re-enroll the biometric from settings if failures persist; check settings for policy indicators (greyed-out options) that point at managed-device rules.
3. If the fallback also fails: you no longer have a biometric problem — you have a credential problem (Articles 13–15 depending on platform), and the biometric symptom was just the first door you tried.
4. On managed devices, check with IT before assuming a fault: a 'broken' biometric that is actually policy behaves identically to a broken one from the user's seat, and only the administrator can tell which it is.

What a biometric failure does not indicate is worth stating as clearly as what it does: nothing about your account's security state. A scanner that rejects you today is not evidence of compromise, lockout or suspicious activity — it is local hardware-and-software behavior with the four causes above. The error to make is reading it through the anxiety lens of this whole library and starting containment procedures (Article 49) for a smudged fingerprint reader. Conversely, the one biometric-related observation that does warrant security attention is not a failure but an anomaly: signs that biometrics enrolled or used on a device you do not recognize — that is activity-log material, not sensor material.

Verification: after re-enrollment or the fix, use the biometric for several sign-ins across a day — including the conditions where it previously failed (different lighting, the wet-finger morning) — and confirm the settings page shows the enrollment as current. A biometric that works in your test but not in life is a template problem wearing a fixed costume; a full day of uneventful scans is the actual verification.

• Related reading:
• Article 13 — Forgotten Windows 11 PIN: supported recovery methods
• Article 39 — Passkeys do not appear on your new device
• Article 34 — Work or school account recovery

Security keys fail slowly rather than dramatically: a battery that will not hold, a connector that works in some ports and not others, a key that simply ages out of your pocket rotation. The replacement is routine — until it is done in the wrong order, because the entire risk profile of key replacement comes from one sequence error: removing or retiring the old key before the new one has proven itself on the accounts that matter. Every safe procedure in this article is a variation on avoiding that single mistake.

The safe replacement sequence

1. Register the replacement first, on the critical services. While the old key still works, add the new key as an additional sign-in method on your most important accounts — banking and email first, then everything else in order of consequence. Each service's security settings page has an 'add security key' flow; plug in the new key and complete it. At this point both keys are valid registrations: redundancy is at its maximum, which is exactly where you want to be mid-migration.
2. Verify the new key with real sign-ins. For each critical service, sign out (or use a private/incognito session) and sign back in using the new key specifically — not the old one, not a backup code. A registration that was added but never exercised is an untested assumption; the exercise is what converts it into a fact.
3. Keep the backup factor alive throughout. If your services offer backup codes or another method, confirm they are current before starting (regenerate if stale). The backup factor is your escape hatch if step 2 reveals that a 'verified' registration actually was not — and you want that hatch confirmed before you need it.
4. Remove the old key only after validation. With every critical service signed in successfully via the new key, remove the old key's registrations from each service's settings. This is also the moment to note the old key's retirement in your recovery inventory (Article 55) so a future 'which keys exist' question has a written answer.

Why the ordering matters, stated as the failure it prevents: remove-first means there is a window — however short — in which the old key is gone and the new one is unproven. If the new registration had a silent defect (a paste error in the flow, a service that registered it under a different account state, a key whose firmware the service quietly rejected), that window is a total lockout on exactly the accounts where you cannot afford one. Add-first makes the same defect discoverable while redundancy still exists: the verification sign-in fails, you fix or re-register, and nothing was ever at risk. The ten minutes of temporary redundancy are the cheapest insurance in this library.

Verification of the completed migration: one fresh sign-in per critical service using only the new key; a settings-page check showing the old registration removed and the new one listed; and your recovery inventory updated with the new key's location alongside its backup (remember Article 38's two-keys principle — if this replacement leaves you with a single key again, that is the follow-up task to schedule now, not after the next loss).

• Related reading:
• Article 38 — Recovering access when a hardware security key is lost
• Article 42 — Choosing between passkeys, authenticator apps and security keys
• Article 55 — Build a personal account recovery inventory

The three mainstream second-factor options are usually presented as a ladder — SMS at the bottom, apps in the middle, keys and passkeys at the top — but 'better' depends on which axis you weight, and the axes pull in different directions. A hardware key is the hardest to phish and the easiest to lose; a synced passkey is the most convenient and the most device-ecosystem-dependent; an authenticator app is the most portable across service types and the most vulnerable to a single lost phone. The honest comparison is axis by axis, because the right answer is a configuration — a mix with defined roles — not a winner.

Read the table as a set of trade-offs and a pattern emerges: phishing resistance rises as recoverability falls. The options that an attacker cannot socially engineer into surrendering a code are the same options whose loss has no software-level undo. That is not a flaw in any one option — it is the security property doing its job — but it means the deployment question is really a recovery-architecture question: whatever primary factor you choose, what is the independent backup that survives its specific failure mode? A key's failure mode (physical loss) is covered by a second key plus offline codes; an app's failure mode (lost phone) is covered by cloud backup, a second device or a hardware key; a passkey ecosystem's failure mode (ecosystem lockout) is covered by a factor outside the ecosystem entirely.

A defensible default configuration for individuals

• Primary: a synced passkey per ecosystem you actually use (it will be your daily path — lowest friction, strong phishing resistance), or a hardware key where the services you care about support it and you prefer the physical model.
• Independent backup: one factor that does not share the primary's failure mode — if the primary is ecosystem-synced, a hardware key stored separately; if the primary is a key, an authenticator app with cloud backup on a second device. Plus offline backup codes for the top five or ten accounts where the service offers them.
• Retired: SMS as a first choice — keep it only where a service offers nothing better and the account's stakes are low, understanding that a recycled number is an active exposure (Article 10).

For organizations the same table gains a deployment row in practice: passkeys and keys both require device-management attention (policy gating, eligibility, MDM interaction per Article 34), while apps require the least infrastructure — which is why app-based factors dominate current enterprise rollouts even where keys are technically superior. The choice at organizational scale is between migration cost and long-term phishing exposure, and it should be made with the recovery policy written first: an organization that deploys single-factor-of-one-type sign-in without a defined backup-factor policy is manufacturing Article 12's worst case for every employee who loses a phone.

• Related reading:
• Article 37 — Lost a passkey: what happens next?
• Article 08 — Authenticator codes are incorrect or out of sync
• Article 12 — When every two-factor method is unavailable

'Too many attempts' is the lockout message people least understand, because it sounds like a suggestion to try again later when it is actually a statement about which system is now in charge of your access. Three different layers can impose this state — the local operating system's own accounting, the online identity provider's risk controls, and an organization's directory policy — and they differ in who releases them, how long they last, and what doing more attempts does. The diagnostic work is identifying the layer from the evidence you already have: the exact wording of the message, which account type was involved, and whether other devices are affected.

Identifying the layer from its signature

The cross-device test is the single cheapest discriminator: try the same sign-in on a second device (or have someone you trust observe what their device shows for the same account). A block that follows the account everywhere is provider-side; a block confined to one machine is local. That one observation collapses three possible procedures into one, which is why it comes before any waiting or escalation.

1. Stop attempting immediately — this applies to all three layers, because every layer's counter treats your careful retries identically to an attack's rapid fire, and on at least two of the three more attempts extend or deepen the lock.
2. Record the exact message text and note which account type it concerns (local, personal online, work/school). The wording is diagnostic input for the table above, not just an inconvenience.
3. Run the cross-device test to localize the layer.
4. Local layer: wait out the stated delay with a verified-correct credential ready (Article 02's checks first), or use that machine's administrative routes. Online layer: complete the provider's verification from its official page when the window allows. Organizational layer: open the IT ticket now — the queue time starts at submission, not at your frustration point.
5. After release, sign in once deliberately and check the account's activity log (where offered) to confirm what the attempt burst actually was — usually your own failures, occasionally something worth containing (Article 35).

Prevention specific to this failure mode: know your lockout thresholds in advance where they are visible (provider security pages show some; organizations publish policy), and structure your sign-in habits so bursts are impossible — verify the password visibly before submitting on locked or unfamiliar machines (Article 02), because a single mistyped attempt on a strict system is the seed of this entire article. And where you manage several devices, keep a note of which of them run strict local lockout policies — that list tells you in advance which machines demand the visible-verification habit and which will forgive a slip.

• Related reading:
• Article 16 — Windows says your account is locked
• Article 30 — Linux account locked by authentication policies
• Article 02 — Why a correct password can still fail

A machine that signed in yesterday and refuses today after a firmware update, a new drive, a RAM swap or a motherboard replacement is not misbehaving randomly — it has changed which stage of the boot chain gets to say no. The chain runs: firmware power-on self-test → boot device selection → (for encrypted disks) the pre-boot unlock prompt → OS loader → OS sign-in. Each stage has its own notion of 'trusted', and hardware changes invalidate those notions independently: a new TPM changes what the OS considers its trusted platform, a changed boot order changes which disk firmware loads, a firmware update can change how Secure Boot validates the loader, and an encrypted disk asks for its key before any sign-in screen exists at all. The first diagnostic move is therefore locating the stage: where exactly does the machine stop?

Pre-boot prompt versus sign-in failure — the fork that decides everything

The firmware-update row deserves its mechanism explained, because it is the most common 'I did nothing wrong' variant. Encrypted volumes with hardware backing (BitLocker on a TPM, LUKS with measured boot) record a set of integrity measurements — PCR values in TPM terms — at startup, and they will unlock automatically only when those measurements match what was recorded when encryption was enabled. A firmware update changes the code that gets measured, so the measurements no longer match, and the volume falls back to asking for its key: not because anything is wrong with your password or your disk, but because the platform's self-description changed. The same logic covers boot-order and Secure Boot mode changes: each one alters what the pre-boot stage can verify, and the encryption layer's response is the same conservative question — 'prove you have the key'. Understanding that the prompt is a measurement mismatch, not an accusation, keeps the response calm: locate the key, boot, then let the system re-establish its trusted baseline.

1. Establish the stop point precisely: does the machine reach the OS sign-in screen at all? A photo of exactly where it stops is the entire first diagnostic.
2. If pre-boot encryption prompt: locate the recovery key for that volume (Article 18 for Windows BitLocker storage locations, Article 21 for FileVault, Article 28 for LUKS). Enter it to boot; afterward, check why the trusted state changed — a firmware update can be re-validated so the prompt does not recur at every boot.
3. If OS sign-in failure after TPM-related change: use the non-biometric credential path (account password) where available, then re-enroll Windows Hello/TPM-bound methods once the platform state is stable. Do not attempt repeated PIN entries — they count against lockout while the underlying binding is simply invalid.
4. If boot-configuration failure: enter firmware setup and restore the intended boot order and mode before touching anything OS-side. A machine that cannot find its disk has no sign-in problem to solve yet.
5. After the machine boots normally: complete one online sign-in per critical service to refresh device trust, and note the change in your records so the next firmware update is not a mystery (Article 57's pre-change checklist exists exactly for this).

Verification has two layers for this failure class: the machine boots to a working sign-in without new prompts (the trusted state is restored, not merely bypassed), and online services accept the device again without repeated re-verification. If the encryption prompt returns at the next boot, the underlying state change was only papered over — return to step 2's 'check why' rather than carrying the key to every startup, which is a daily reminder that the fix is incomplete.

• Related reading:
• Article 18 — Recovering access to a Windows PC without internet
• Article 28 — Understanding LUKS disk encryption recovery
• Motherboard & BIOS/UEFI: POST codes, settings and updates

Every recovery procedure in this library assumes the recovery tooling works — and in a real lockout, that assumption is exactly what can fail. The Windows Recovery Environment won't mount, the recovery USB shows an error, the macOS Recovery download stalls, the Linux live USB refuses to boot. At that point the problem has split into two: the original lockout, and a new one — the inability to reach any repair surface. This article is about the second problem, because solving it correctly determines whether the first problem remains solvable at all. The diagnostic discipline is unchanged from everywhere else in this library: identify which component of the recovery chain failed before replacing or rebuilding anything.

The four failure classes of recovery tooling

• The recovery environment does not exist on the machine. Recovery partitions get deleted by disk utilities, shrink operations and some third-party partition tools; machines that were factory-reset without vendor imaging lose them too. Signature: the recovery key combination produces a normal boot instead of a recovery environment, or firmware's boot menu shows no recovery entry. The fix is external media — an official recovery image for that OS version — not more key combinations.
• The recovery media is bad. Corrupted downloads, failed USB writes (the classic 'copied 4 GB, verified nothing'), and drives that are themselves failing all produce media that looks present but cannot boot. Signature: the media boots partway then errors, or firmware sees it as a device the OS never loads from. The fix is redoing the media properly — re-downloading from the official source, verifying the download's published hash where one is provided, and writing with a dedicated imaging tool rather than a file copy.
• Network dependency. Some recovery paths are inherently online: macOS Internet Recovery downloads its environment from the vendor's servers (a stalled download can be your machine's fault or theirs), Windows activation-linked repairs phone home, and cloud-based account recovery obviously needs connectivity. Signature: progress stops at a network operation, and other networked devices on the same connection behave differently. The fix is establishing which side of the connection is broken before blaming the tool.
• Version mismatch. Recovery media for a different OS generation than the installed one (Windows 10 media against an 11 install, an old live-USB against a newer kernel with encryption it cannot read) fails in confusing mid-boot ways. Signature: the media works on other machines or other disks but not this configuration. The fix is matching media version to installed version — check what the machine actually runs before assuming what it should run.

The version-mismatch class raises a practical sub-problem: how do you know what the machine actually runs when it will not boot far enough to tell you? Several answers work without any OS session. The firmware/UEFI interface often labels its recovery entries with the installed environment's name; the first screen of any partial boot usually carries an OS version string; and for a Linux system, a live USB can read the mounted root's /etc/os-release file directly — the exact distribution and release, from the safe side. Purchase records, original install notes or the recovery kit's own documentation (Article 56) are legitimate sources too. The point is that 'matching media to installed version' is an investigable question with concrete answers, not a guess — and guessing wrong here is what turns a ten-minute media rebuild into a day of mid-boot failures.

1. Name the failure class using the signatures above — one deliberate observation pass, not a rebuild spree. Rebuilding good media five times does not fix a missing recovery partition; each class has exactly one correct fix.
2. For bad media: re-download from the official source only (typed address), verify the published checksum/hash where provided, write with an imaging tool, and test the result on a non-critical machine or virtual machine first where feasible. A media-testing step costs minutes and saves hours of 'why does it fail on the important machine'.
3. For network-dependent stalls: confirm general connectivity from another device, try a different network path (wired instead of Wi-Fi, mobile hotspot), and check the vendor's status information for known recovery-service incidents. Only after those checks is 'the tool is broken' a supported conclusion.
4. Once a working recovery surface exists, return to the original lockout with its proper procedure — and note what broke the tooling, because a machine whose recovery environment is missing or unreliable has a latent second incident that should be closed (rebuild the recovery partition or keep verified media in the recovery kit, Article 56).

Verification that the tooling problem is actually solved: the recovery environment boots cleanly to its full interface (not partway), its basic functions respond (disk utilities open, network connects where expected), and — the real test — it reaches the specific function the original lockout needs. A recovery environment that boots but cannot see the encrypted volume has not finished its own recovery; treat tooling verification as complete only when the original procedure can actually start from it.

• Related reading:
• Article 18 — Recovering access to a Windows PC without internet
• Article 27 — Recovering a Linux system that cannot reach the login screen
• Startup, boot & recovery options — the cross-platform recovery environments

The most disorienting outcome in this entire library: the reset worked, the sign-in succeeds, the desktop loads — and the files that mattered will not open. Nothing has gone wrong with the procedure; it did exactly what it was for. The disorientation comes from conflating two operations that only share a vocabulary: account access (proving who you are to a system) and data decryption (unlocking specific protected content). A password reset re-establishes the first; it does not, and in several cases structurally cannot, perform the second. This article is the map of those data layers — what protects them, what unlocks them, and which of them a reset was never going to touch.

The layers that survive a reset, and their actual unlock conditions

The practical method after a 'successful' reset that leaves data locked is an inventory against that table, layer by layer: which of your important content sits in which layer, and does the unlock condition for that layer still hold? For each 'no', the answer is specific — locate the EFS certificate backup, find the archive password in your password manager or recovery kit (Article 56), complete the keychain update prompt, or accept that one container's password was never written down anywhere. The inventory converts a vague 'my data is gone' into a short list of named objects with named solutions — and it usually finds that most content was never in a protected layer at all, which is the reassuring majority case.

1. From the working sign-in, open each category of important content deliberately: documents, photos, encrypted folders, zipped archives, keychain/credential-store contents, and applications with separate logins. Note exactly which items refuse to open and how (error text matters — 'wrong password' versus 'no key available' are different layers).
2. Map each refusal to a layer in the table above using the error behavior.
3. For each mapped layer, execute its actual unlock condition: locate stored keys/backups, accept pending update prompts, or recover the specific credential through its own service.
4. Where a layer's unlock condition is genuinely lost (no certificate backup, no written archive password), record it as a confirmed loss for that item and move on — further attempts at that layer are not troubleshooting, they are repetition. Professional assessment applies only where the stakes justify it (Article 48).

Verification of the completed picture: every important content category opens, or is formally recorded as lost with the reason; the keychain/credential store shows current contents (test one saved item); and your recovery kit now records where each layer's unlock material lives — because this article's failure mode has a prevention that is pure documentation: the next reset should be able to consult a map instead of discovering layers by surprise.

• Related reading:
• Article 01 — What to do before resetting a forgotten password
• Article 28 — Understanding LUKS disk encryption recovery
• Article 56 — Create a secure emergency access kit

Services build a layer of convenience on top of authentication: devices that have signed in successfully before get reduced friction — fewer prompts, faster verification, the ability to approve other sign-ins. That trust is a state with a lifecycle, and like all state it expires or invalidates when the conditions that created it change. When a familiar machine suddenly behaves like a stranger — full verification demanded, approval requests rejected, sessions dropped — the question is not 'is the service broken' but 'which condition of trust changed?' The four usual answers are device-identifier drift, session/token cleanup, deliberate revocation (by you, the provider, or an attacker), and security-policy changes on the service side. Each has a different correct response, and one of them — attacker revocation — requires containment rather than re-verification.

The four causes, and their signatures

One clarification on 'device identifier', because it explains why cause one is so common and so benign. Services do not recognize your machine through any single hardware serial; they build a fingerprint from whatever the client can report — browser profile and its stored state, operating-system installation identity, screen and language settings, sometimes hardware characteristics. Any operation that rewrites part of that fingerprint (a browser reinstall with a fresh profile, an OS reinstall, a motherboard swap on some systems) changes the fingerprint even though 'the same computer' is sitting in front of you. That is why identifier drift produces the distinctive signature in the table — one service surprised, its neighbors unbothered — and why the correct response is always the cheap one: re-verify once, note what changed, move on. The expensive error would be treating routine fingerprint churn as an attack signal and escalating a benign event into a multi-hour security review.

1. Check the account's activity/security page first — before re-verifying anything. The revocation and sign-in history tells you whether this is entropy (cause 1–2), protection (cause 3, provider side) or attack (cause 3, attacker side). Five minutes of log-reading prevents the single worst mistake in this scenario: re-establishing trust from a compromised device.
2. If the logs are clean and the cause is identifier drift or aging: complete the service's official re-verification once, deliberately, noting what it asked (a code, a biometric, an approval) so the next occurrence is recognizable rather than alarming.
3. If the logs show protective revocation: finish the provider's security review, then re-verify from your cleanest available device — and confirm the trusted-device list afterward shows only devices you name.
4. If the logs show attacker activity: switch to containment (Article 49) before any re-verification anywhere; the trusted-device system is part of the incident surface until the intruder is out.

Verification that trust is healthy again — not just restored: the device completes sign-ins without repeated re-verification over the following days; the trusted-device list matches your actual devices exactly (no orphans to remove, no strangers present); and where the cause was identifier drift, you have noted what caused it so a future reinstall is a recognized event rather than a fresh scare. Trust systems are only as calm as their owners' understanding of them — this article's value is making the next occurrence boring.

• Related reading:
• Article 35 — Recovering an account after suspicious sign-in activity
• Article 49 — What to do immediately after recovering a compromised account
• Article 34 — Work or school account recovery

Every other article in this library assumes you are inside the zone where careful self-help can succeed. This one is about recognizing the edge of that zone — because the most expensive errors in recovery are not wrong commands, they are continued self-help past the point where each additional attempt has more downside than upside. A failing disk that gets written to during a 'one more repair pass' loses sectors that a professional's read-only tools would have captured. An encrypted volume with no key that gets paid for in increasingly desperate attempts converts a closed cryptographic fact into an open financial drain. The skill this article teaches is the stop decision, and the routing decision that follows it.

The warning signs, by what they indicate

The stop-and-route decision, as a procedure

1. Name the warning sign you are actually seeing — from the table, not from general unease. 'It feels wrong' is not a stop condition; SMART critical attributes, a sealed encrypted volume with no key, or attacker artifacts are. If you cannot name one, you are probably still inside the self-help zone and should continue the relevant article's procedure.
2. Freeze the state: power off (for storage-failure signs — do not 'finish what you were doing'), preserve logs and screenshots of the evidence, and stop all writes to the affected medium. Everything that follows is cheaper with a frozen scene.
3. Choose the professional by the sign's row in the table — this matters more than choosing any individual: a data-recovery firm cannot open missing encryption keys, and an account-support channel cannot image a failing drive. Mismatched routing is how people pay twice.
4. Prepare the context package that makes any professional engagement efficient: the exact sequence of events, what was tried (with outcomes), the evidence you preserved, and — for encrypted systems — a frank statement of key availability. Professionals price and plan from this information; withholding it (or exaggerating it) distorts both.
5. Set the decision boundary before paying: what outcome would make this engagement worth its cost, and what is the plan if the answer is 'no'? For data recovery that means knowing which files are actually worth the money — a full-disk rescue for a machine whose important data was backed up last month is a different purchase than the same service for a disk that holds irreplaceable archives.

The first conversation with a professional is itself a diagnostic, and it takes five minutes. Ask what they will do first (the correct answer for storage failure is a read-only image; hesitation on that answer is informative), how they price (assessment-then-quote versus fixed upfront fees — both exist, but you should know which before committing), what happens to the original medium afterward, and whether their quote changes if the outcome is 'no data recoverable' (a firm confident in its assessment answers calmly). The red flags are specific: guarantees of 100% recovery before any examination, pressure to pay in full before diagnostics, refusal to say what the first step is, or claims that they can open an encrypted volume whose key you do not have — which no honest firm will claim. A professional who tells you the engagement is not worth its cost is doing the same stop-decision this article describes, on your behalf, and that answer is worth paying for.

The post-engagement verification differs by route: data recovery ends with a verified image or restored set that you check item-by-item against your inventory before accepting the work (and before the original medium is released or destroyed — ask what happens to it); security engagements end with a clean-state attestation and a written account of what was found; and honest 'no' outcomes — sealed volumes, unrecoverable media — end with documentation you can act on and close. In every case, the engagement's value includes what it tells you about prevention: the backup that was missing, the key that was never stored, the monitoring that would have caught the compromise early. Write those down while they are fresh; Article 56 is where they go.

• Related reading:
• Article 28 — Understanding LUKS disk encryption recovery
• Article 36 — What to do when an account recovery request is denied
• Article 51 — Securing a computer after unauthorized access

The moment an account you believe was compromised comes back under your control, the temptation is to stop — the lockout is over, the day can resume. But a recovered account in which an intruder operated is like a house after a break-in: the door is locked again, but you do not yet know what was taken, whether keys were copied, or whether the alarm was disabled. The containment sequence below closes those questions, and it has an order for a reason: each step either depends on the previous one or is undermined if done before it.

The sequence, and why in this order

1. Revoke everything that is currently signed in ('sign out everywhere' / 'other active sessions', where the provider offers it). This comes first because every other step you perform next — password change included — could be mirrored or intercepted by a live intruder session. Kill the audience before changing the locks.
2. Change the password to a value that has never been used on this account — not a variation of the old one, not a value reused from another service (that is how compromises spread between accounts). Store it in your password manager immediately; a strong unique password you cannot remember is still a password you will 'forget', and the recovery routes must be healthy by then.
3. Audit and restore the recovery contacts. This is the step that gets skipped and the one an attacker prioritizes: check the registered recovery email and phone, and if either was changed without your action, restore it to a contact you control — verifying that the replacement contact itself is secure (a recycled or shared inbox as a recovery contact re-opens the door). Article 50 is the detailed version of this step.
4. Reconfigure two-factor onto factors the intruder did not hold. If SMS was the factor and the phone number is suspect, move to an authenticator app or hardware key (Article 42 for choosing). Regenerate backup codes fresh and store them per Article 09. The point: the second factor must be something the previous occupant of your account did not have access to.
5. Run the full activity review: recent sign-ins (devices, locations), connected/third-party apps with granted access, sent messages or posts in the compromise window, and any API tokens or app passwords issued. Remove what you do not recognize; read what you do — the review is how you learn the scope of what the intruder could see.
6. Secure the linked accounts that trusted this one. Services that used this account for recovery (especially email, per Article 31), single sign-on relationships, and any service where this account was an administrator. A compromised hub re-compromises everything it keys — the list is your account inventory (Article 55) applied in reverse.

Two calibrations keep this sequence proportionate rather than panic-driven. First: 'compromised' should mean you have evidence of unauthorized access or a strong indication of it (unrecognized activity, changed contacts, a protective lock with an explanation that fits intrusion) — not merely anxiety about a lockout that turned out to be a mistyped password. Running this sequence after a false alarm is harmless and occasionally useful as practice; skipping the evidence check after a real one is how intruders get a second week. Second: the sequence is complete when its outputs exist — sessions revoked (verifiable in the activity log), new password set and stored, contacts audited with their state noted, two-factor on fresh factors, review done with findings written down. A containment you cannot describe afterwards was not performed; it was merely felt.

Verification that containment held: after 24–48 hours, re-check the activity log for new unrecognized entries (an intruder who was logged out may try back in with what they still have), confirm sign-ins work from your devices without repeated re-verification prompts, and note any service that still shows the old session state. The two-day re-check is not paranoia — it is the difference between 'I changed the password' and 'the account is demonstrably mine again'.

• Related reading:
• Article 35 — Recovering an account after suspicious sign-in activity
• Article 50 — How to check whether a recovery email or phone number was changed
• Article 51 — Securing a computer after unauthorized access

Recovery contacts — the registered email and phone behind your two-factor and reset flows — are the highest-value targets in an account takeover, because changing them is how an attacker makes the lockout permanent and themselves the owner. The check for tampering is therefore not optional hygiene after a scare; it is a core diagnostic that applies to any account where you have had a lockout, a protective block, or simply a long period without reviewing settings. The good news: most major providers expose enough security history to answer the question directly. The bad news: what they show varies by provider, and 'no record' is not always the same as 'no change'.

Where the information lives, by provider type

The method works the same regardless of how much history a provider keeps: compare current state against known truth, then read the history for the delta. Step one is the current values — open each important account's security settings and note the registered recovery email and phone exactly as shown. Do you recognize both, precisely (including which of your numbers it is)? A value you 'sort of' recognize is a finding, not a pass: attackers change numbers to lookalikes and emails to accounts they control that resemble yours. Step two is the history where available — sign-in events and account-change events in the compromise window, with attention to events from devices or locations you do not recognize. Step three, where the provider alerts on contact changes: check your own mail/SMS for those alert messages during the window — an alert you received but do not remember triggering is direct evidence of a change event, whether or not the current value looks right (the attacker may have changed it twice).

1. For each critical account: record the currently registered recovery email and phone from the official settings page.
2. Compare each against your known-good values. Any mismatch — including 'I think I would have set the other one' — is treated as a finding until explained by something you can point to (a change you made, with a date).
3. Read the security history for the window of concern: sign-in events and account-change events; note devices, locations and times you do not recognize.
4. Check your own channels (the inboxes/numbers that would have received change alerts) for alert messages from that window.
5. If any finding is unexplained by your own actions: restore the correct contact values immediately (you are signed in — do it now), then run the full containment sequence (Article 49) because a changed recovery contact is, by definition, an attacker's priority action and rarely their only one.

Making this check routine rather than reactive: fold it into the quarterly verification pass of your recovery plan (Article 06) — five minutes per critical account, current values against known truth, history skimmed for the quarter. Accounts where you can verify in one glance are the ones that will not surprise you at 2 a.m.; accounts whose security settings you have never opened are the ones an attacker chooses, precisely because no one is comparing their state against anything.

• Related reading:
• Article 49 — What to do immediately after recovering a compromised account
• Article 54 — Preventing account takeover through recovery channels
• Article 35 — Recovering an account after suspicious sign-in activity

When an account is compromised, the first assumption to test is that the compromise lived only in the account. Sometimes it did — a phished password, a leaked credential from elsewhere, a session hijack on another device. But sometimes the account was the exit, not the entry: malware on your machine captured the credentials, keylogged the recovery codes, or exfiltrated the vault, and in that case every password you change from this computer can be watched while you type it. The distinction — account incident versus machine compromise — determines where the security work happens, and the test for it is behavioral: what does this computer do that you did not ask it to do?

The evidence check before any cleanup decision

• Unexpected software or processes: programs you do not recognize installed, background processes with unfamiliar names or network connections, browser extensions that appeared. Check the OS's program list and a process view against what you expect to be there.
• Behavioral anomalies: searches or page visits you did not make appearing in history, messages sent from your accounts (check outbox/sent folders), new scheduled tasks or startup entries, security software disabled with no memory of disabling it.
• Credential-capture indicators: the compromise timing matching periods when the machine was doing something odd; multiple accounts compromised around the same time from the same machine (one phished password explains one account; three simultaneous captures explain a keylogger).
• System integrity: security updates current or not; antivirus/defender in a healthy state with no suppressed detections; no signs of tampered system components.

1. Run the evidence check above and write down what you find — this record decides the branch, and it should exist before cleanup changes anything.
2. Branch A — account incident only (no machine indicators): complete containment from this machine (Article 49), ensure security updates are current and the security suite is healthy and up to date, and verify your backups are intact and recent (an attacker with account access sometimes targets backup accounts too). The machine stays in service.
3. Branch B — machine compromise indicators present: stop using the machine for anything sensitive. Isolate it from the network if practical; run a full scan with current definitions and read what it finds (suppressed or previously-quiet detections are especially telling); and assess whether the affected software is load-bearing. For personal machines with high-value accounts, the honest default when indicators are clear is a clean reinstall from official media with data restored from a backup verified to predate the compromise window — cleanup of an actively compromised system is possible but its completeness can never be proven the way a clean build's can.
4. Escalate where the machine is organizational: company or school devices with compromise indicators go to IT security, not to self-cleanup — the organization needs the evidence, the device may hold other people's data, and self-imaging an MDM-enrolled machine without IT can violate policy while failing to fix the actual problem (Article 34).
5. Verify backups before trusting them: in both branches, confirm your backup set is complete, restorable (test-restore one or two items), and — critically for Branch B — dated before the compromise window. A backup taken while malware was resident may carry the problem forward on restore; knowing the dates is what tells you which side of the line your backup sits on.

One structural recommendation follows directly from this failure mode: account separation. The machine that does your risky browsing, trial software and file opening should not be the same identity surface that holds your banking session and recovery codes. Where a second device or at least a strict separation of browser profiles exists, credential-capture malware on the casual side has a much shorter list of things it can read — which is exactly why attackers who do get in tend to take everything: most personal machines offer them one undivided kitchen sink.

Verification of a secured machine differs by branch: Branch A ends with updates current, security suite healthy with a clean full-scan result, containment complete on all affected accounts, and two weeks of uneventful behavior. Branch B ends with the clean build verified against your pre-compromise backup inventory (files present, applications working, no carried-over surprises), fresh credentials established everywhere, and the evidence log closed out. In both cases, the final check is the same as every other article's: a written record of what was found, what was done, and what state things were left in — because the next person to ask 'is this machine safe?' should be able to answer from a document rather than a feeling.

• Related reading:
• Article 49 — What to do immediately after recovering a compromised account
• Article 48 — When to stop troubleshooting and seek professional recovery
• Security: suspicious behaviour, malware basics & safer everyday computing

There is a business built on exactly the state this entire library describes: a person who cannot get into their own accounts, searching frantically at an hour when judgment is thin. The scams in this article are not random malware — they are responses to that search, engineered so that the desperate person finds them first and pays for a 'recovery' that either does nothing, steals the account permanently, or installs remote access that harvests everything else. Understanding the threat model makes each variant recognizable: the scammer needs three things from you — payment, credentials, or machine access — and every variant is just a different delivery mechanism for one of those three.

The variants, and the specific tell in each

• The search-result impersonator. A 'recovery service' ranking high for queries like '[provider] account recovery help', styled to look official, offering guaranteed restoration. The tells: it is not the provider's own domain (check the address bar — real providers do not outsource account recovery to third-party sites); it asks for your credentials or a 'verification fee' up front; its guarantees are absolute ('100% recovery in 24 hours'), which no legitimate service can offer because recovery depends on evidence you control (Article 36's honest limits exist for a reason).
• The remote-access support call. Outbound calls or chat 'support agents' who diagnose your problem impressively, then request remote access via a named tool (AnyDesk, TeamViewer and similar are legitimate software being used illegitimately here) to 'fix the registry / clear the cache / recover the account'. The tell is structural: no legitimate vendor support flow requires handing over control of your machine to recover an online account. Account recovery happens on the provider's website with your credentials and verification factors — full stop. Remote access plus a recovery request is the single highest-value scam pattern in this category, because it converts one lost account into every account on the machine.
• The phishing 'recovery link'. An email or message — sometimes appearing to come from the provider, sometimes from a 'security team' — with a link to 'complete your recovery verification'. The tells: urgency and threat ('your account will be deleted'), a link rather than an instruction to type the address yourself, and a lookalike domain on close inspection. Real providers do not send links that replace their own sign-in page; they send links to their own pages, and even then the safe habit is to type the address independently.
• The payment-demand variant. Any recovery process that asks for money — gift cards (the universal tell: no legitimate service accepts gift cards), wire transfers, cryptocurrency, or 'processing fees' by card to a non-provider merchant. Legitimate account recovery is free; you pay providers for accounts, not for getting them back.
• The fake support number. Phone numbers found in search results, 'helpful' forum comments, or on stickers applied to devices that are not the vendor's official line. The safe pattern: obtain the contact channel from inside the official surface — the provider's own website (typed address), the official app, or the number printed in official documentation — and treat every other source as untrusted by default.

A structural note on why these scams sit exactly where you look: search engines rank by relevance and payment, and 'account recovery' queries are worth money to scammers in a way that is rare for other topics — the searcher has already declared both the problem and the willingness to pay. That is why the top results for desperate queries routinely include impersonation sites with professional design, fake phone numbers and 'official-looking' branding: they are advertisements, not directories. The practical consequence is that finding a support channel through search is itself an untrusted operation. The only reliable verification loop runs in the other direction — from a surface you reached independently (typed domain, installed app) outward to the contact details it publishes. If a number or site you found by searching does not match what the official surface says, the official surface wins, every time, without exception.

1. Apply the three-needs test to any 'recovery' offer: what does it actually require from you — payment, credentials, or machine access? If the answer is any of those three in a context where official recovery would not ask for it, the offer is the scam regardless of how professional it looks.
2. Verify domains character by character. Lookalikes differ by one character, a prefix or a suffix (providername-recovery.com, provider-name-support.net). The address bar is the only authority; the page's appearance is decoration.
3. Reach official support only through surfaces you reached independently: type the provider's main domain, use the installed official app, or use contact channels published from those places. If a 'support agent' contacted you first — by call, DM or email — they are not support; real support does not cold-call about account recovery.
4. If you have already given something: credentials go to an immediate password change and containment (Article 49) from a clean device; payment goes to your card issuer's fraud process (recoverability varies, act fast); remote access goes to ending the session immediately, disconnecting the machine from the network, and treating it as compromised (Article 51) — the remote session may have left persistence behind.
5. Report it: providers have phishing/scam reporting channels (usually in their support or security sections), and reporting a working scam page takes it down for the next victim. The report costs minutes; the scam's lifetime is measured in victims, and each report shortens it.

Verification that you are clean after a scare: no unknown payment authorizations on your cards, no remote-access sessions or new user accounts on your machine, security settings for your accounts unchanged from what you confirmed (Article 50's check), and your browser history for the incident window showing only the official domains you actually visited. A short written note of what was offered, what you refused and what you reported closes the loop — and is exactly the record a card issuer or provider wants if any of the scam's touches turned out to be real.

• Related reading:
• Article 36 — What to do when an account recovery request is denied
• Article 51 — Securing a computer after unauthorized access
• Security: suspicious behaviour, phishing & social engineering basics

Backup codes and recovery keys are designed for one holder: you, in an emergency. That design makes their exposure qualitatively different from a password leak. A leaked password can be changed; the old value stops working the moment it does. An exposed backup code set or recovery key cannot be 'changed' in place while it remains valid — each code is a live entry until consumed or the set is regenerated, and a recovery key grants full access to whatever it keys (a password manager's entire vault, per Article 05) for as long as it exists. The correct response therefore has two parts with a strict order: invalidate what was exposed, then determine what the exposure window allowed.

The order of operations

1. Invalidate first, investigate second. For an exposed backup-code set: regenerate a fresh set from the service's two-factor settings while you are signed in — on most services, issuing new codes invalidates the old set immediately. For an exposed password-manager recovery key: use or replace it per the product's design (Article 05) and treat the vault as exposed — which means the master password changes and every credential inside gets re-issued at least for the critical accounts. Speed matters here because the exposed material works until it does not.
2. Revoke credentials that shared the exposure surface. If the codes were exposed in a note on a phone, a cloud document, or a chat — ask what else lived in that same place. A recovery sheet stored alongside other account details exposes more than the sheet; each co-exposed credential gets its own reset, not just the one you know about.
3. Read the access history for the exposure window. For every affected service: recent sign-ins, active sessions, and (where shown) backup-code usage events. The questions are specific — did any code from the exposed set get consumed? Did any sign-in occur from a device or location you do not recognize during the window the material was exposed? A clean history is a genuine finding; it means the exposure was real but unused.
4. Assess the protected data, layer by layer. Apply Article 46's map: what sits behind each exposed credential (vault contents, encrypted files, keychain items, linked accounts)? For each layer, does the intruder-hypothetical now hold its unlock material? A vault recovery key exposure means every password in that vault must be assumed known — which is why step 1's 're-issue at least the critical ones' matters: you cannot know which of your passwords an attacker would try first, so the assumption has to be all of them, with practical effort spent on the accounts that gate everything else (email, banking, the manager itself).
5. Close the storage gap that allowed the exposure. The exposure is a design failure in how the material was stored, not just a bad event: move the replacement sets to the offline/encrypted storage described in Article 09 and Article 56, and note the new locations in your recovery inventory (Article 55) so the next person — including future you — knows where the current material lives without having to find it by searching.

The assessment in step 4 deserves its logic stated plainly, because it is where proportionality gets lost. The assumption 'everything exposed is now known' overstates for single-account backup codes (an attacker with one service's codes needs that service's password too — the codes replace the second factor, not the first) and understates for vault recovery keys (which unlock a store of passwords by design). The working rule: treat as compromised exactly what the exposed material can unlock combined with whatever else was exposed alongside it, and verify with the access history rather than guessing. Where the history shows actual use of the exposed material, the case is no longer hypothetical — it is an active compromise with a timeline, and the full containment sequence (Article 49) applies to every account touched.

Verification of the closed loop: fresh code sets stored in their new locations with the old storage location cleared (a leftover copy of the exposed set is an open exposure by definition — delete it deliberately); access histories clean or fully explained for the window; critical-account passwords re-issued where vault material was exposed; and your recovery inventory updated so the current state of every recovery artifact is documented. The incident is closed when no copy of the exposed material exists anywhere you do not control — including the trash, the old note app, and the screenshot roll.

• Related reading:
• Article 09 — How to use and store two-factor backup codes
• Article 05 — Password manager recovery and vault access
• Article 49 — What to do immediately after recovering a compromised account

Attackers who want an account durably — not just for one session — do not start at the password. They start at the recovery channel, because whoever controls the recovery path controls every future lockout: change the recovery email, and the next forgotten password is your permanent loss; capture the phone number, and SMS factors and reset codes route to you-who-is-them. This article's threat model is therefore inverted from the usual 'protect the login' framing: the login can be re-issued, but the recovery path is the standing authority over the account's entire future. The controls below each address a specific edge of that model, and their common thread is that the recovery path must survive the loss or compromise of every single device, number and inbox it references.

The edges of the model, and the control for each

• Edge: the recovery email is itself a normal account with its own weaknesses. If your daily inbox is your recovery contact, then any compromise of that inbox — phished password, leaked credential, its own lockout — cascades into every account it keys. The control: a dedicated recovery mailbox (Article 06) with its own strong unique password and two-factor, registered as the recovery contact for critical accounts, whose entire job is to stay open. It is cheap to create and it removes the single most common cascade in this threat model.
• Edge: phone numbers are rented, not owned. Carriers cancel and recycle numbers; a lapsed plan can hand your number — and with it your SMS factors and reset-code channel — to a stranger within weeks. The control: no critical account relies on SMS as its only second factor or its only recovery contact (Articles 07, 10); app-based or key-based factors do not route through the carrier at all.
• Edge: single-device concentration of recovery material. Backup codes in a note on the phone, authenticator seeds only on the phone, passkeys synced to one ecosystem — one lost device takes the login and the recovery path simultaneously. The control: independence by construction (Article 06's 'independent' test) — at least one recovery artifact per critical account that does not live on any single device, plus a second factor outside the primary ecosystem (Article 42's configuration).
• Edge: the recovery process itself is social-engineered. Support impersonation, fake 'recovery verification' links, remote-access requests — the Article 52 variants all attack the moment you are executing recovery, when you are most willing to hand over exactly what the process asks for. The control: procedural rigidity — official surfaces reached by typed address only, no payment/remote-access/credential-entry outside the provider's own page, and the one-session rule (no recovery action in the same session as discovering the lockout).
• Edge: trusted devices as standing privileges. A trusted device list that is never reviewed accumulates orphans — old laptops, replaced phones still 'recognized' — each a potential shortcut for anyone who later obtains that hardware. The control: periodic review of trusted-device lists on critical accounts (fold into the quarterly pass), removing anything you do not currently possess.

What unifies these controls is a property worth naming: the recovery path should be harder to compromise than the account it protects. Most personal setups get this backwards — the login gets two factors, a password manager and vigilance, while the recovery inbox runs on an old reused password with no second factor of its own. An attacker comparing the two picks the softer side every time, which is why 'I secured my accounts' and 'I secured my account and the path that unlocks them when I forget it' are different claims, and only the second one survives contact with this threat model. The quarterly verification pass (Article 06) exists to keep the claim true: each quarter, confirm the recovery inbox opens, the backup codes are current and stored independently, the trusted-device lists match reality, and no critical account's entire recovery path runs through one object you could lose in a day.

Verification of a hardened recovery posture is the quarterly pass itself, with written outputs: each critical account's recovery routes listed and current; independence confirmed for at least one route per account; trusted-device lists reviewed against actual possession; the dedicated recovery inbox tested open with its own factors working; and any gap found closed in the same session it was found. The document produced is your defense-in-depth map — and when an incident eventually comes (they do, for everyone, eventually), it is also the fastest possible route back: not a scramble to remember how you secured things, but a checklist of what you already know works.

• Related reading:
• Article 06 — How to build a safe password recovery plan
• Article 50 — How to check whether a recovery email or phone number was changed
• Article 52 — Recognizing fake password recovery services and support scams

Every recovery failure in this library has a common underlying pattern: at the moment of crisis, the owner could not answer basic questions about their own digital life — which account is the hub, where are the backup codes, which device holds the authenticator, who else can help. An account recovery inventory exists to make those answers written down before the stress that makes them unavailable. It is a document with a specific scope: it records the structure of your recovery — what protects what, where each piece lives, who holds which role — and it deliberately excludes the secrets themselves, for reasons this article closes with.

What belongs in the inventory, per account

The scope exclusion is as important as the fields: the inventory does not contain passwords, PINs, recovery key values, or backup codes themselves. It contains locations and types. This is not a modesty constraint — it is the document's security design. An inventory that lists 'backup codes for bank: in home safe' is useful to you and harmless to anyone else; an inventory that also lists the codes is a complete key to your banking, stored in exactly the kind of consolidated document that becomes a target. The same logic applies to storing the inventory itself: it belongs in encrypted storage or a physical location with access control (Article 56), not in a cloud note synced to the phone that is most likely to be lost at the moment the inventory would be needed.

1. Start with the top ten accounts by consequence — the email hub, banking, the password manager, work identity, cloud storage — rather than trying to capture everything in one session. Depth on the critical few beats coverage of the long tail; the rest can be added over time.
2. For each, fill the six fields from the table by checking the actual service settings (the registered factors are listed there) rather than from memory — this first pass is simultaneously an audit, and it will find gaps (missing backup codes, SMS-only factors, unknown recovery contacts) that are exactly what the inventory exists to surface.
3. Record device dependencies in a second pass: one physical list of your devices, each with the factors it holds. Cross-reference against the per-account rows — any account whose every factor lives on one device is a concentration finding (Article 54's model).
4. Name the responsible contacts and confirm the role with them: not 'the family will handle it' but a specific person, told what they may do, reachable by a path that does not run through your accounts.
5. Set the verification cadence (quarterly skim of dates; annual full check per Article 06) and store the finished document where Article 56 says recovery material belongs. The inventory is now a maintained asset, not a one-time project — its value is proportional to how current it stays.

The test of a finished inventory is a thought experiment you can run in five minutes: pick your most critical account and ask, out loud, 'if I lost my phone tomorrow, what exactly do I do?' If the answer comes from the document — named factors, located codes, a reachable contact, a clear first step — the inventory is working. If the answer starts with 'I would have to figure it out', the document has a gap, and you are in the rare position of being able to fix it while everything still works.

• Related reading:
• Article 06 — How to build a safe password recovery plan
• Article 56 — Create a secure emergency access kit
• Article 60 — The complete password and account recovery readiness checklist

An emergency access kit is the physical/secure-world counterpart of everything in this library: the collection of recovery artifacts, arranged so that a person under stress — you at 2 a.m., or your designated contact on your behalf — can find and use each piece without detective work. The design constraint that shapes everything else: the kit must survive the exact loss scenarios it exists for. A kit stored in cloud notes on your phone fails the day the phone is lost; a kit in a safe whose combination only you know fails the day you are hospitalized and your contact needs it. Every placement decision below is an answer to one question: which disaster does this location survive, and which does it not?

What goes in the kit — and the standard each item meets

• Recovery key references. For each encrypted system (disk encryption keys per Article 21/28, password-manager recovery key per Article 05): the key itself or its exact location, labeled with the machine/account it belongs to and a date. Standard: usable by someone who has never seen it before, without guessing which key is which.
• Backup code sets for critical services. The current sets (regenerated per Article 09's discipline), one clearly labeled envelope/file per service, with the issue date and a 'remaining count' note where known. Standard: independent of every device — paper in a safe or an encrypted file on offline media.
• The account recovery inventory (Article 55) — structure, locations, contacts; no live secrets.
• Contact and authorization sheet. Who the responsible contacts are, what each is authorized to do, how to reach them by a path that does not run through your accounts, and — where relevant — the documents that prove their authority (for the inheritance case, Article 59).
• Official channel references. The typed addresses of your critical providers' official sign-in/recovery pages, and any account IDs or reference numbers that speed up support interactions. Standard: enough to reach official help without searching under stress — which is also a direct countermeasure to the Article 52 scam surface, since lookalike domains are exactly what search-under-panic finds.

Storage follows a two-location principle, because single locations have single failure modes. Location one survives device loss and theft: the home safe, a fire-safe drawer, or equivalent — holding the paper/physical items (backup code sheets, key references, contact sheet). Location two survives the home itself (fire, flood, long absence): an encrypted file on offline media kept elsewhere (a trusted contact's possession, a bank deposit box where practical), containing the same information in digital form. The two locations should not share a failure mode, and neither should be reachable from a device you carry — that is the whole point of the exercise. Where encryption is used for the digital copy, the encryption password is itself a kit item: it goes with the physical location (not in the file's metadata, not in a note attached to the file), because an encrypted file whose key travels with it is a locked box with the key taped to the lid.

1. Assemble the items from the list above for your top ten accounts — reusing the inventory you built in Article 55 rather than starting over.
2. Label everything for a stressed reader: service names, machine names, dates, and one-line usage notes ('enter this at the pre-boot prompt', 'use only if all other factors fail'). A kit item that needs interpretation is a kit item that will be misused in the moment it matters.
3. Place copies in the two locations per the principle above, and write down where each location is — including for the contact who would use it (a contact told 'it's at home' but not told which drawer has not been given a kit, only a riddle).
4. Set up access control deliberately: who can open the safe / read the encrypted file, and on what authority. For personal kits this is usually you plus one named contact; the authorization sheet (above) states the terms so the arrangement does not depend on memory or goodwill in a crisis.
5. Schedule maintenance with the quarterly pass (Article 06): verify each item against reality (code sets still current? key references still matching the machines they name?), replace what has decayed, and update dates. The kit's failure mode is silent staleness — a backup code set consumed by one forgotten sign-in, a key reference for a machine you replaced — and only a dated check catches it.

Verification that the kit works is a drill, run once a year and worth more than any amount of assembly: pick one scenario from this library (phone lost — Article 07; disk-encrypted machine locked — Article 28) and walk it end-to-end using only the kit, timing yourself and noting every point where you had to guess. Every guess is a labeling or placement defect with a five-minute fix, made while everything still works. A kit that has survived one honest drill is not just organized — it is proven, which is the only adjective that matters at 2 a.m.

• Related reading:
• Article 55 — Build a personal account recovery inventory
• Article 09 — How to use and store two-factor backup codes
• Article 60 — The complete password and account recovery readiness checklist

Travel and device replacement are the two moments when lockouts most often happen to ordinary people — not because anything is wrong, but because both change the conditions that your daily sign-ins depend on: a different network, a different keyboard, a phone that will be lost for a week or replaced entirely. The preparation pass below exists to make those changes known before they are experienced: each check answers a question you would otherwise be asking at an airport gate or in the middle of a two-week trip, when the cost of a wrong answer is measured in missed flights and unrecoverable days rather than minutes.

The verification pass, by what it protects against

1. Recovery routes reachable from the road. For your top accounts: confirm a recovery method that does not depend on the device you are about to travel with or replace — backup codes stored offline and packed, an alternate email reachable, a hardware key in your possession. The test: if this phone were stolen tomorrow, which of my critical accounts could I still reach, and through what? (This is Article 07's question, answered deliberately instead of by surprise.)
2. Sync state current before the change. Cloud sync for files, notes, passwords and the authenticator app (where it has encrypted backup — Article 11) completed and confirmed before the trip or the phone swap. A device replacement with un-synced local data is a data-loss event wearing a routine costume; the sync check is what takes the costume off.
3. Offline behavior known for your primary machine. If the machine signs in with a cloud account: has it signed in online recently enough that cached credentials work (Article 18)? A deliberate offline test — airplane mode, reboot, sign in — takes thirty seconds and tells you whether 'no internet at my destination' is a non-event or a lockout.
4. Device access secured for the travel window. Strong device lock (PIN/biometric with a real fallback), full-disk encryption active and its recovery key located (not remembered — located, per Article 56), remote-wipe capability confirmed working where the platform offers it (the 'find my device' service, tested once so you know the account it lives in). Travel is when devices are lost; these three items are the difference between a lost device and a compromised one.
5. For a phone replacement specifically: the migration order from Article 11. New phone set up, authenticator/passkeys transferred or re-enrolled on critical services while the old phone still works, backup codes regenerated where re-enrollment issued new ones, and only then the old device wiped. The gap-free ordering matters most when the old phone is being sold or recycled rather than kept — a retired phone with live authenticator seeds is a complete key to your accounts in someone else's hands.

One item deserves emphasis because it is skipped most: the offline test. Most personal machines assume connectivity in ways their owners never check — cloud-account sign-in with stale cache, two-factor that requires a network to issue codes, recovery options that phone home. None of these fail at home on your known network; all of them fail abroad, on a plane, or in a hotel where the Wi-Fi is metered and the 'verify with email' option quietly does not exist. Thirty seconds of airplane-mode testing converts an unknown into a fact before the trip, which is the entire economic argument for the pass: the checks cost minutes now because they are un-stressed; the same discoveries made under stress cost the trip.

Verification of the completed pass is deliberately concrete: one offline sign-in succeeded on the primary machine; the sync indicators show current state for files and credentials; remote-wipe test completed from another device (then released); backup codes physically present in your travel kit or confirmed accessible to your contact; and the phone-replacement migration, where applicable, complete with the old device wiped. Write the results down — a note dated 'pre-trip checks passed, except: …' is both the trip's insurance policy and the input for next time's pass, because preparation is a habit with a record, not an event.

• Related reading:
• Article 11 — Moving an authenticator to a new device
• Article 07 — Lost your authenticator phone? Recovery options explained
• Article 56 — Create a secure emergency access kit

A shared machine — a family PC, a home office box used by several people, a kiosk-style device — inverts the assumption every other article in this library makes: that the person at the keyboard is the account's owner. On a shared system there are multiple owners with multiple credentials, and 'recovering access' can mean three very different acts: restoring your own account on a machine you share (routine), recovering a machine where no one currently has working administrator access (a genuine recovery problem with real procedures), or changing another person's credentials to get at their data (an act whose correct name is not recovery). The distinction is not semantic — it is the line between troubleshooting and unauthorized access, and this article draws it explicitly because shared machines are where ordinary families cross it without meaning to.

The three situations, and what each one permits

The structural fix for most shared-machine pain is the one that prevents the third row from ever becoming necessary: separate user accounts with clear permission boundaries. Each person gets their own account (and on Windows/macOS, their own profile encryption where available), with administrator rights granted deliberately — usually to one or two named household administrators, not to everyone by default. Parental controls then operate as a designed boundary: children's accounts with managed sign-in and content limits, rather than a shared adult account that 'everyone uses' (which is how a family PC ends up with one unknown password gating everything). Where the machine predates that structure, migrating to separate accounts is a project worth doing while access still works — it converts future lockouts from household negotiations into individual procedures.

1. Establish the ownership map first: who has an account on this machine, which are administrator accounts, and who currently holds working credentials for each. Write it down — on a genuinely shared machine this map is usually in no one's head completely.
2. For your own locked account: use your account's supported reset routes, performed with the consent of the household's administrators (on a family machine, that is a conversation, not a formality). The technical procedures are the platform ones from Articles 13–15; what differs here is the authorization step that comes before them.
3. For a machine with no working admin: agree as a household on who will act and what the goal is (restore administration, preserve everyone's data), then follow the supported routes for the platform — reset media first where it exists (Article 15), recovery environment second. Preserve all user profiles throughout; the goal is administration restored, not anyone's data touched.
4. Set the boundaries while you have access: separate accounts per person, named administrators, parental controls configured as policy rather than improvisation, and a household note (in the recovery kit, Article 56) recording who administers the machine and how — so the next lockout does not start from zero knowledge again.
5. Where another person's data is involved at any point — even 'just checking' their files to find a shared document — use their account with their knowledge, or ask them to share the file. The habit of routing through consent is what keeps a family machine out of the third row of the table above, and it costs nothing in the moments it matters least and everything in the moments it matters most.

Verification for a shared machine has two layers: the technical one — each person can sign in to their own account, administrators can administer, parental controls behave as configured — and the social one, which is easy to skip and is actually the load-bearing part: every person who uses the machine knows their own credentials (not 'the family password'), knows who the administrators are, and has agreed that access to another's account goes through that person. A shared machine whose members can all state those three facts has solved most of this article permanently; one where the knowledge lives in a single head has simply scheduled its next lockout.

• Related reading:
• Article 15 — Forgotten local Windows account password
• Article 34 — Work or school account recovery
• Article 59 — Recovering access to an inherited or deceased person's device

This is the article in the library where the first question is not technical at all. When a device or account belongs to someone who has died, the act of opening it carries legal and privacy weight that no other lockout scenario has: the data is protected not only by cryptography but by the deceased person's privacy interests, which survive them in most jurisdictions, and by the expectations of the people around them. The correct sequence therefore starts with authority — establishing who you are in relation to this estate and what that role permits — before any technical step is taken, because several of the technical paths that would be routine for your own device (reset procedures, recovery-environment access) become legally questionable when applied to another person's property without the role that legitimizes them.

The order: authority, then process, then technology

1. Establish your legal position. Are you the executor of the estate, a next of kin with documented standing, or an administrator appointed by the court? The answers differ by jurisdiction and by estate size, and they determine which doors open: executors and court-appointed administrators can generally act on the estate's digital property; other relatives often cannot, however close the relationship. Where the position is unclear, a solicitor/lawyer specializing in estates — not a tech support line — is the correct first call. This step costs days; skipping it costs potentially much more, because actions taken without authority can be challenged afterward.
2. Inventory what is actually being sought. The practical goal is usually narrower than 'access to everything': specific documents, photos, financial information, or closure of accounts and subscriptions. Naming the goal early focuses every subsequent step — some goals (closing a subscription) need no device access at all, just the provider and proof of authority; others (reading photos on an encrypted phone) run into the hard limits below.
3. Use the providers' bereavement processes where they exist. Major platforms and financial institutions have procedures for deceased users: typically requiring a death certificate, proof of your authority (letters of executorship or equivalent), and sometimes the account's identifying details. These processes are slower than any technical procedure in this library — weeks is normal — and they are the only route that produces legitimate access to cloud accounts (email, social, banking). Start them early; their timelines dominate everything else.
4. Assess the device itself with its encryption state named honestly. If the inherited device is encrypted (FileVault on a Mac, BitLocker on Windows, default encryption on modern phones) and no recovery key exists in the estate's papers, the device's contents are sealed by the same cryptography described in Articles 21 and 28 — and for an inheritance, there is no 'try the family's passwords' equivalent that is both likely to work and appropriate to attempt repeatedly. The honest statement: without a stored key or passphrase known to the estate, an encrypted device's contents may be permanently inaccessible, and that outcome belongs in the estate's records as a fact, not a failure of effort.
5. Route physical access through the estate process. Where the device is part of the estate, its handling (who holds it, who examines it, what is extracted) should be documented as part of the estate administration — the same care applied to any other asset. This protects everyone: the executor from later challenge, the family from disputes over what was opened and when, and the record of the deceased's affairs from being assembled by whoever reached the device first.

Two boundaries deserve explicit statement because desperation and grief both push against them. First: do not bypass the device's protections — no brute-force attempts, no 'recovery tools' marketed to open locked phones, no circumvention of encryption or activation locks. Beyond the legal question (which varies by jurisdiction but is real), the practical outcome is usually nothing: modern encryption does not yield to external tooling, and the money spent on attempts at what cryptography has already decided is money the estate does not need to lose. Second: do not treat the device as a free search — its contents include the private affairs of other people (partners, friends, colleagues) whose privacy interests are not extinguished by the owner's death. The estate's legitimate interest is in the deceased's own affairs; a disciplined extraction aimed at the named goals (step 2) respects that boundary and also produces a cleaner record than an undirected read-through.

The prevention angle closes the circle: this article describes what happens when no one planned for death — and planning is exactly what Articles 55 and 56 exist for. A recovery kit that names who may act, where the encryption keys are stored, and which accounts matter converts an inheritance's digital side from a months-long legal-technical struggle into a documented handover: the executor follows the kit, the keys are found, the bereavement processes start with the right information on day one. The deceased cannot benefit from the plan directly; the people left holding the devices do, and that is who the plan is for.

• Related reading:
• Article 56 — Create a secure emergency access kit
• Article 21 — Understanding FileVault recovery keys
• Article 58 — Recovering access to a shared or family computer

Every other article in this library answers a question that arises when something has gone wrong. This one is the instrument for the opposite state: nothing has gone wrong yet, and you want to know — with evidence rather than confidence — whether your setup would survive it. The assessment below is deliberately standalone: it does not re-derive the reasoning of the fifty-nine articles before it (each check links to the article that explains its why), it simply walks the surfaces a real lockout touches, in the order a crisis would touch them, and records what holds and what does not. Run it once to get your baseline; run it quarterly to keep the baseline honest.

How to use the assessment

Work through the tickable checklist in the Readiness Checklist section below, one group at a time. Each group covers one surface of your recovery posture — the password manager, the second factors, the recovery contacts, the encryption keys, the device access, and the procedures you have actually tested. A tick means the item is true right now and verifiable: not 'I think my backup codes are somewhere' but 'set of ten for the bank, in the home safe, issued this spring, count checked last quarter'. Where an item fails, the linked article is the fix — and the fix should be completed before moving on, because a failed early item often explains a failed later one (a password manager you cannot open makes every item behind it unassessable).

Scoring is intentionally blunt: the assessment produces three states, not a percentage. Ready — every group complete, with at least one full recovery procedure tested end-to-end in the past year; a lockout on any critical account would cost hours, not days. Partially ready — most groups complete but with named gaps (usually backup codes that have never been verified, or an encryption key whose location nobody can state); a lockout is survivable but will be slower and more stressful than it needs to be, and the gaps are known and fixable this quarter. Not ready — any group in which the critical items fail: single-factor everything, no reachable recovery contact, encryption keys nowhere stored, no tested procedure. In that state the honest description is that your current setup treats every future lockout as an experiment, and the purpose of this assessment is to end the experimenting while the cost of doing so is still only an afternoon.

The cadence matters as much as the instrument: recovery posture decays silently — phone numbers recycle, code sets get consumed, contacts move house, devices get replaced — so a one-time perfect score is a snapshot, not a state. The quarterly pass (Article 06's discipline) re-checks the dates and the locations; the annual pass adds the end-to-end test on a non-critical account, which is the only check that proves the procedure works rather than merely existing. Ticks are saved in this browser only; nothing about your accounts is sent anywhere — and the checklist's copy function produces a plain-text version you can file with your recovery kit (Article 56) as the dated record of when each surface was last verified.

• Related reading:
• Article 06 — How to build a safe password recovery plan
• Article 55 — Build a personal account recovery inventory
• The Readiness Checklist — the tickable assessment itself