One password after someone else's breach: why "that is not us" fails

A company reads about a store or a forum breach and closes the tab: we are not registered there, our customers were not harmed. A week later someone signs in to company mail. The password was the same one the person used elsewhere. That is not "a hack of your site". It is reuse of a secret that already sits in someone else's database.

Checking whether an address showed up in known breaches is useful hygiene. It is not protection. Protection is different passwords and a second factor on what you cannot afford to lose: mail, hosting, the CMS, the domain registrar, ads. Your store's account area should also limit sign-in attempts, otherwise someone else's database will come visiting you.

What to do this week

• Change passwords that repeat between mail and the site. Start with the director and whoever pays contractors.
• Turn on a second factor. SMS is a weak fallback, not the main one.
• Look at failed sign-ins if the panel can show them. A series from different countries is already a signal.
• Do not publish "login admin, the password was emailed" in a client manual on the site.

In an audit Lexora looks for reuse and shared access, rather than collecting news about other people's breaches. If a sign-in already happened, that is response: sessions, secrets, what was exported. A pentest shows whether the account area can be tried in bulk. The basic audit is free for new clients and is often cheaper than one stolen ad budget.