The instructions were right. For last year's screen
I was adding a hardware security key to an account. I have done this before. I knew the steps. I typed them from memory, confidently, and locked myself out of the account for the rest of the evening.
The steps were not wrong. They were right, for the interface that existed the last time I did it. Somewhere between then and now the provider had moved a toggle, renamed a section, and changed what happened when you enabled the new method: instead of adding a second factor alongside the old one, it replaced it. The screen said so. I did not read the screen, because I already knew what it said.
Recovery took four steps, two devices and a phone call. All of it avoidable.
Driving to a friend's house from memory works until the council makes your usual turn one way. You do not notice the new sign, because you are not reading signs. You are reciting a route.
Here is what makes credential screens different from every other interface, and why the normal human habit of pattern matching is actively dangerous on them. Most software punishes a mistake with an error message. You read it, you undo it, you move on. Authentication punishes a mistake by removing your ability to come back and fix it. The failure is not a wrong result. The failure is losing the door.
So the rule I now follow without exception: for anything touching passwords, two factor methods, recovery codes or account ownership, I read the current screens out loud and I do not act on a remembered sequence. It feels slow and slightly insulting, like following assembly instructions for a chair you have built twice. Build the chair wrong and you have a wobbly chair. Do this wrong and you are on a support queue proving you are yourself.
The second thing I changed matters more than the reading. I now set up the way back in before I turn the lock. That ordering is the whole lesson, and it is the part everybody gets backwards, including me.
A safe order of operations for changing two factor settings or adding a hardware key, written so that every step leaves you able to get back in. This is about protecting your own accounts. Nothing here depends on a particular provider, because the whole point is that you read theirs rather than trusting mine.
1. Before touching anything, write down how you would get back in today
Not how you think you could. The actual list, checked. If you cannot complete this list, stop here and fix it first, because everything after this step reduces your options.
# recovery.md, kept somewhere you can reach WITHOUT this account
# recovery codes : do I have them, where, and have I tried one?
# recovery email : can I log into it right now, separately?
# recovery phone : is the number current?
# second factor #2 : is there more than one, on a different device?
# provider support : what do they require to prove identity?Test one recovery code if the provider lets you. An untested recovery code is a belief, not a backup. Most providers invalidate a used code and show you the remaining ones, which is a fair price for knowing.
2. Get a second factor working before you make the first one mandatory
Two independent ways in, then tighten. One way in, then tighten, is how lockouts happen.
# target state BEFORE enforcing anything:
# factor A : hardware key or authenticator on your everyday device
# factor B : a SECOND key, or an authenticator on a different device
# plus : printed recovery codes, stored offlineIf you are buying hardware keys, buy two at the same time. A single key is a single point of failure that you have voluntarily installed, and the second one costs less than an afternoon of recovery.
3. Read the current screen, out loud, and name what it changes
Before pressing the button, say what you expect to happen and then find that sentence on the page. If the page does not say it, you are about to do something other than what you planned.
# the three questions, every time
# does this ADD a method, or REPLACE the existing one?
# after saving, which methods remain usable?
# does this invalidate my recovery codes?That third question catches a real trap: several providers regenerate recovery codes when you change factors, silently making the printout in your drawer worthless. If the answer is yes, print the new ones in the same sitting.
4. Enrol the second device in the same session
Do not plan to come back to it. Enrolling the second factor is the step that gets postponed, and the gap between "I will do it tomorrow" and "I cannot log in" is where the whole problem lives.
5. Prove the second path works from a cold start
This is the step that would have saved my evening. Open a private window, or a different browser, or a different machine, and log in using only the second method. No existing session, no remembered device.
# a logged-in tab proves nothing: it was authenticated before your change
# 1. private window
# 2. sign in using ONLY the second factor
# 3. then do it again with a recovery code
# 4. only now consider the change finished6. Store the secret separately from the thing it unlocks
Recovery codes in the password manager that the account protects is a loop. Printed and in a drawer beats perfectly organised and unreachable. The general principle, and what belongs in an offline kit, is the subject of the next log.
7. Write down the date and what the screen said
Not the steps. The steps will rot, which is the entire problem. Record what state you left the account in, so next time you are checking a claim rather than recalling a procedure.
# accounts.md
# 2026-09 provider X
# factors: hardware key (everyday), hardware key (spare, drawer)
# recovery codes reprinted this date, old set invalidated by the change
# NOTE: enabling the key REPLACED the app code method on this providerThe honest catch: none of this makes the provider's interface stable. It will move again. What it does is make you a person who reads the new one instead of a person who remembers the old one.
Related: every automation gets its own key applies the same separation to machines rather than people.