Practical recovery

Changed your password, but the old breach is still showing?

Why historical breach records can remain after a password change, how to read the dates and when another security action is warranted.

By securemypassword.co.uk · · 4 min read
Practical guide · reviewed 30 October 2026
Sources checked 30 October 2026. This is a dated account; later findings may change the picture.

Why the record remains

A historical breach record can remain after you change a password. The record describes an earlier exposure; the password change is an action taken afterwards. Seeing the same entry again does not, by itself, mean the change failed or that someone currently has access to your account.

Start with the dates

A breach can have several dates. The incident date describes when the reported exposure happened. A notification date describes when somebody was told about it. The date a dataset enters a checking service describes when that source made it searchable. None of those is necessarily the day you changed your password.

HIBP's FAQ explains that its historical records do not depend on whether a password has subsequently been changed. Our Assurance Retraite explainer gives a dated example of why an older incident and a later addition can appear together.

You can write these dates on separate lines before deciding whether anything is new. Add a fourth line for your own completed action. That small distinction can turn a worrying repeated result into a question you can actually answer.

A hypothetical example

Imagine you see a record about an old shopping service. The hypothetical breach happened in 2013. In 2026, you changed the shopping password and replaced it on another account where you had reused it. A later check still shows the 2013 entry.

Your note now reads: historical record 2013; relevant password changes 2026. The continued listing tells you the historical record remains searchable. It does not confirm whether every necessary action was completed, whether your replacement is unique, or whether anyone has a current session. Those are separate questions.

This example is invented to explain the distinction. It is not a customer's record or evidence about a particular retailer.

Use an action list, not a disappearing result, as the finish line

A useful completion note says what you actually did: for example, “changed the reused password through the provider's official settings”. It should not say “account proved safe” merely because you ticked a task.

Our account guidance helps organise recovery steps. Progress recorded here stays in this browser; it does not change the provider's account or independently verify its security. Keep enough non-sensitive detail to recognise the action later, without writing down passwords or recovery codes.

For example, “reviewed the notice; password was unique; no incident-specific reset requested” records a decision. “Everything fixed” hides the reasoning. The first note is easier to revisit if the organisation later publishes different advice.

Work through the evidence in order

1. Open the record's source and confirm which incident it describes.

2. Compare its dates with your earlier notes. Separate a genuinely different notice from the same historical entry.

3. Follow current advice from the affected organisation through a route you found independently.

4. If an exposed password is still used, replace it and any reused copies. Keep replacements unique.

5. Record only the actions you finished. Leave unanswered questions visible.

The NCSC's breach guidance is a useful reference for choosing account actions and checking unexpected messages. Our help page explains how to interpret the service's results.

What another password check can tell you

The password tool asks a separate question about whether an entered password appears in the password source. An email dataset listing passwords does not establish that your exact or current password was in your individual record. Neither check is a live test of account access.

Do not send a password to somebody offering to remove a breach entry. Removing an address from a search service is not evidence that leaked copies elsewhere have vanished.

What remains unknown

A historical result alone cannot establish your present account security. Start with the specific unanswered question, rather than repeatedly trying to make the old entry disappear. Read the evidence, complete the relevant official steps, and keep your progress note separate from the historical record.

Choose your next step

Email checks require ownership verification. Dataset matches do not prove current account access or your exact password. Password checks cannot identify the account a password came from. This is guidance, not incident response or personalised legal advice.

Sources & editorial notes

Our explanation draws on the public notices linked above. We do not host leaked datasets, independently confirm individual records or imply these incidents are all searchable here. For personal incident questions, use the affected organisation’s official channels. Corrections: hello@dayadata.co.uk.

Related reading