Quick answer
Secure your email account first, even if a different site was breached — it is the recovery channel for everything else. Then change the exposed password everywhere it was reused, turn on multi-factor authentication, check your recovery settings, and sign out unfamiliar sessions. Do not change your email address, and do not delete the breached account before securing what it can unlock.
Before you start: what you are dealing with
A breach match means an identifier of yours was in data taken from a company. It does not mean your email account was accessed. If you have not already worked out which of those you are facing, how to read the result sorts it out in a couple of minutes and will change how urgent the rest of this is.
The steps below assume the realistic case: your address, and possibly a password, appeared in someone else's stolen data.
Do these now
1. Secure your email account first
This is out of order compared with most advice, and deliberately.
Your email account is the master key. "Forgot password" on nearly every other service sends a reset link to it. If an attacker controls your inbox, the strength of every other password stops mattering — they do not need to guess anything, they can simply request a reset.
So regardless of which site was breached: if your email password was the one exposed, or if you reused it anywhere, change the email password now, before touching anything else.
2. Change the exposed password everywhere it was used
The breach names one service. The exposure covers every place that password was reused, because attackers take breached username and password pairs and try them automatically across other sites. That technique is called credential stuffing, and it works precisely because reuse is common.
Make a list of everywhere you can remember using that password. Change each one, in this priority order:
- Email accounts
- Anything holding money: banking, payment services, brokerages
- Anything holding identity documents or health data
- Anything with your payment card stored: shopping, food delivery, subscriptions
- Social accounts, which are used to impersonate you to other people
- Everything else
A password manager makes this list for you, which is the practical argument for using one.
3. Make the new passwords unique, not clever
A new password that is a variant of the old one — the same word with a different number, or a symbol appended — is not a new password in any way that matters. Attack tooling tries variants automatically.
Current NIST guidance in SP 800-63B-4 sets a minimum of 15 characters where a password is the only factor, explicitly prohibits composition rules such as forced mixes of character types, and requires screening chosen passwords against blocklists of known compromised values. Length and uniqueness carry the weight; character-class gymnastics do not. Why uniqueness matters more than complexity covers the reasoning.
4. Turn on multi-factor authentication where it exists
Start with email, then money, then anything holding identity documents.
Prefer an authenticator app or a hardware security key. CISA notes that codes delivered by SMS and push notifications can be defeated by common bypass techniques, and that FIDO-based authentication is the phishing-resistant option. If you enrol in an app-based factor, check whether SMS is still enabled as a fallback — an unremoved fallback is a weaker door left in the same wall.
MFA is worth doing and it is not a cure. What MFA protects against, and what it does not is worth five minutes before you rely on it.
5. Check your recovery settings
This is the step most people skip, and it is the one that matters if someone did get in.
On your email account, check:
- Recovery email addresses
- Recovery phone numbers
- Backup codes, and whether any were used
- App passwords or connected applications you do not recognise
- Forwarding rules and filters, especially ones that forward or auto-delete messages
A password change does not remove any of these. An attacker who added a recovery address keeps access through it afterwards, and a forwarding rule quietly copies your mail to them indefinitely.
6. Sign out everything you do not recognise
Most major services list active sessions and devices. Sign out anything unfamiliar. Do this after the password change, so the new credential is what the reconnecting sessions have to satisfy.
Do these this week
These are worth doing and they are not emergencies. Separating them matters, because treating everything as urgent is how people stop after step two.
- Get a password manager, if you do not have one, and start migrating accounts as you use them rather than in one sitting.
- Check your other addresses. Old or secondary addresses are often the ones in older breaches, and they are frequently still recovery addresses for something important.
- Review what the breached service actually held. An email-only exposure and a passwords-plus-dates-of-birth exposure call for different follow-up.
- Watch for targeted phishing. Exposed data makes convincing messages easy to write: a real order number, a real address, a real recent purchase. Treat urgency in an unexpected message as a signal in itself, and reach services through their own app or a typed URL rather than a link.
- Freeze your credit file if government identifiers or financial data were exposed and your jurisdiction offers it. This is an identity-theft control rather than a credential one — the boundary is covered in breach checks versus identity theft protection.
What does not help
Being direct about this saves people real effort.
Changing your email address. The address is not the vulnerability. Changing it breaks your recovery paths and your account history, and the old address stays in the leaked dataset regardless. There is one narrow exception: if the address is receiving so much targeted abuse that it is unusable, that is a deliverability decision, not a security one.
Deleting the breached account. The data left before you deleted it. Deletion is reasonable if you no longer want the service, but do it after you have changed any reused password — otherwise you may lose your own access to an account you still need to secure elsewhere.
Changing the password to a variant. Covered above. It is not a change.
Paying for removal from breach data. No service can do this. Once a dataset has circulated it exists in copies nobody controls. What can change is whether the exposed information still works.
Rotating all your passwords on a schedule from now on. NIST explicitly advises against requiring periodic changes; forced rotation pushes people towards predictable patterns. Change on evidence of compromise, which is exactly what you are doing today.
If you think someone actually got in
Different situation, and the signs are in the account rather than in breach data: sent mail you did not send, changed settings, security alerts you did not trigger, contacts receiving messages from you.
If that is what you are seeing, treat recovery-channel cleanup as the priority — recovery addresses, forwarding rules, app passwords and active sessions — because an attacker who keeps any of those keeps access through your password change. Then work outwards to accounts that use this address for password resets.
Next step
If a password was involved, the immediate question is which of your other passwords are also on a public list. You can check a password without sending it: it is hashed in your browser and only a five-character fragment of that hash is transmitted, so the tool never receives the password itself.
For the wider picture — what breach data can and cannot show, and how often any of this is worth repeating — see the breach exposure guide.
Frequently asked questions
How urgent is this really?
If a password was exposed and reused, urgent — automated credential stuffing runs continuously and does not wait for you. If only an email address was exposed, it is not an emergency; expect more phishing and work through the list this week.
Do I need to change passwords on sites that were not breached?
Only where you reused the exposed password. Changing unrelated, unique passwords accomplishes nothing and consumes the effort you need for the ones that matter.
The breach was years ago. Does it still matter?
If the password is still in use anywhere, yes — the age of the dataset does not reduce the value of a working credential. If you have since changed it everywhere, the remaining exposure is the other fields in that record, which you cannot change and which mainly raise your phishing risk.
Should I tell anyone?
If it is a work address, tell whoever handles security at your organisation — they may need to check for reuse against company systems. For a personal address, there is no one to notify; the company that was breached has the disclosure obligation, not you.