After a Breach: A Calm Sequence for Passwords and Two-Factor Codes
A breach notice tends to produce one of two reactions: panic, or a decision that nothing can be done. Both are unhelpful. The useful response is a short sequence with a clear order, because the risk from a leaked credential is not uniform across your accounts and the effort you spend should follow the risk. This guide assumes you have a password manager; if you do not, the first step is to start one before working through the rest.
Table of contents
- What a breach notice actually tells you
- The first hour
- Rotation order: triage, not a blanket sweep
- Moving two-factor authentication without a lockout
- What not to do
- Turning it into a routine
- FAQ
- Bottom line
What a breach notice actually tells you
Notices vary in precision. Some say a specific field was exposed, such as email addresses and hashed passwords; others say only that an unspecified set of records was accessed. Hashed does not mean safe: the protection depends on the hashing scheme and whether a per-user salt was used, and neither is usually stated in the first notice.
What matters to you is narrower: could somebody use what was taken to sign in as you elsewhere? That depends on whether the password was reused, whether a second factor protects the account, and whether session tokens or recovery answers were also exposed. A leaked password for an account with a unique password and a working second factor is a nuisance. The same password reused across a dozen services is an incident.
Treat the notice as a prompt to check specific things, not as a verdict. Watch for follow-up notices, which often contain more detail than the first, and be sceptical of messages that arrive by email asking you to “verify” the affected account — breach announcements are routinely used as phishing bait.
The first hour
- Go to the service directly, by typing the address or using a bookmark, never by following a link in the notice.
- Change the password on the affected account to a new unique value generated by the manager, and save it before submitting.
- Sign out other sessions where the service offers that control; changing a password does not always revoke an active session token.
- Check the account's recovery details — recovery email, phone number, and recovery questions — for changes you did not make.
- Note what the notice said was exposed, so you can decide whether adjacent accounts need the same treatment.
If the same password was used anywhere else, those accounts join the queue immediately. A password manager's reused-password report is the fastest way to find them, which is one reason these reports are worth looking at before an incident rather than during one.
Rotation order: triage, not a blanket sweep
Changing every password you own is satisfying and mostly wasted effort. Work down a short priority list instead.
- 1. The primary email account. Whoever controls it can reset almost everything else. Give it a unique password and a strong second factor first.
- 2. Accounts with payment or stored value, and the mobile carrier account, which is a common route into number-based recovery.
- 3. Any account that reused the exposed password, including old ones you had forgotten about.
- 4. Accounts where the same email address and a weak or absent second factor are the only protection.
- 5. Everything else, gradually, as part of normal maintenance rather than an all-night session.
The ordering reflects how account recovery chains work, not how important a service feels. An obscure forum account that shares your email password is a bigger problem than a shopping account with a unique password and a hardware key.
Moving two-factor authentication without a lockout
If a phone was lost or a breach exposed authentication seeds, two-factor methods need to move too. The failure mode here is self-inflicted: disabling an old method before a new one is confirmed leaves you locked out of the very account you are trying to protect.
Add the new method first, verify it by signing in on a second device, save the new recovery codes somewhere outside the vault entry for that account, and only then remove the old method. Where a service supports hardware security keys, register at least two and store them in different places. Where it only offers SMS, note that as a reason to prioritise the account's password strength rather than as a settled protection.
What not to do
Do not reuse a newly generated password anywhere, do not email credentials to yourself, and do not store recovery codes as a note inside the same vault without a second copy elsewhere. Do not assume a password change revoked active sessions; check the session list. And do not pay attention to unsolicited messages offering to “check if you were affected” by asking for your login.
It is also worth resisting the urge to delete the affected account immediately. Deletion can remove your ability to see what happened, dispute charges, or recover linked purchases. Secure it first, then decide whether you still want it.
Turning it into a routine
The durable fix is structural rather than reactive: a unique generated password for every account, a second factor on the handful of accounts that unlock the rest, and a quick review of reused-password and exposed-password reports in your manager. That way a future breach notice becomes a two-minute task on one account, not an inventory of your whole digital life.
Keep a short record of which accounts hold recovery power over others. It need not be elaborate — a note listing your primary email, carrier, and password manager, with where their second factors live, is enough to make the next incident orderly.
FAQ
Should I change every password after any breach?
No. Change the affected account and any account that reused that password, then work through the accounts with recovery power over others. Unique passwords elsewhere are not affected by a breach at a different service, and rotating them adds effort without reducing that risk.
Does changing my password sign out an attacker?
Not always. Some services invalidate existing sessions on a password change and some do not. Look for an explicit control such as 'sign out all other devices' and use it, then review the active session list if one is available.
Are SMS codes good enough as a second factor?
They are better than no second factor, but they are vulnerable to number-porting and interception in a way that app-based codes and hardware keys are not. At minimum, use them on the primary email and financial accounts only until something stronger is available, and note the carrier account as a priority to protect.
What if the breach exposed my recovery answers?
Treat those as credentials that are now public: replace them with generated values stored in the manager, wherever the service allows. Answers that are factual, such as a parent's name, cannot be changed and should be treated as unusable secrets going forward.
Bottom line
A breach notice is a prompt for a short, ordered sequence, not a verdict and not an emergency that requires changing everything. Secure the affected account from the service's own site, revoke sessions, check recovery details, then follow the chain outward: primary email, payment and carrier accounts, anything that reused the password, and then the rest in due course. Move second-factor methods carefully, with the new one verified before the old one is removed. If your manager already gives every account a unique password, most of this work disappears — which is the strongest argument for doing that maintenance before the next notice arrives.
If you want to compare current plans in this category, the link below goes to our own product page.