A reverse check finds every account linked to one breach, by address, login, nickname or password.
john.d@aceme.example••••••••••••third-party storeAn employee moved from a previous job and signed up at a shop with a work e-mail and the same password. The shop was breached: the password was accepted at the portal.
Passwords were changed and the incident was closed. But breached databases end up on forums, and new attackers run the reverse check again and return to the company.
Not just a change: a unique password for every service. A variant of an old pattern will end up in a dictionary again.
Passkeys and a second factor on the portal and admin sign-ins. A matching password alone will not open the door, and a short session lifetime and device binding protect against session theft.
The admin and test accounts and accounts from a previous job: disable them or bring them under control before the next round.
The breach contains a record with the login john.d@aceme.example and a password that the attacker now knows. The password was replaced and the incident was marked closed. But only one address was checked, and the password is already known to more than the company.
From one identifier (an address, a login or a nickname), the reverse check opens new accounts: a previous employer, a personal e-mail, forum accounts. The nickname mutates the same way: john_d, john_d87, johndoe_2025. One account yields 300 to 500 new data items. If a computer has an infostealer, sessions and site assets are taken from the account, and the reverse check reveals even more links.
The age of a password does not matter. A password a person has used for years, or a predictable variant like "2025!", is cracked quickly by rule-based brute-force tools. We see this scenario incident after incident.
An employee moved from a previous job and signed up at an online shop with a work e-mail and the same password. The shop was breached, and the password was accepted at the corporate portal. A standard breach check does not show this path. The same happens with vendors: an account on a service, created for a company task such as buying cloud hosting, gets linked to the company even without its e-mail in the registration. The compromise happens at the vendor, not on the main domain.
Passwords were changed and the incident was closed. But breached databases end up on forums, and new attackers run the reverse check again and return to the company. A company usually closes what it knows about: corporate e-mail and known access. Personal notes that mention the company stay open, and an attacker can come back through them.
A one-time code does not help if the attacker already works with an issued session. Phishing-resistant sign-in methods (passkeys), a short session lifetime and device binding protect against this.
What to do: a unique password for every service; passkeys and a second factor on the portal and admin sign-ins; disable or bring under control the forgotten admin and test accounts and the accounts from a previous job.
Illustration. Domains, logins and passwords are fictional (aceme example). "300 to 500 new data items per account" is a benchmark from investigation practice, not a measurement of a specific service.