MyRecon OSINTWhy a new breach alert can describe an old incident
A breach alert received today can refer to an incident from years ago. Before deciding what happened, separate the date of access, the date the organisation disclosed it, the date a breach catalogue added the record and the date you received an alert. Each answers a different question.
Four dates, four meanings
| Date | What it tells you | What it cannot prove |
|---|---|---|
| Breach date | When the recorded incident occurred, sometimes approximately | The day your individual record was accessed |
| Disclosure date | When the organisation or source announced the incident | That access started on that day |
| Catalogue addition | When a provider added the incident to its searchable collection | That the organisation suffered another incident |
| Your notification | When you were informed or a monitor found a change | That your account was used by somebody else |
Read an alert in order
- Open the organisation's official notice independently of the message link.
- Identify the incident period and whether the date is approximate.
- Record which information categories the notice says concern you.
- Compare the breach name and incident date with earlier notices before treating it as a second incident.
- Write down the action you took and when you will recheck it.
An illustrative example: a company reports a 2022 incident in 2026 and a catalogue adds the record a week later. A daily update should include that newly added record even though the underlying incident is old. Changing its breach date to 2026 would make the timeline less accurate.
How MyRecon labels the record
The public breach API keeps breach_date and added_date separate. The latest-record feed sorts by addition date, while an incident archive can sort by breach date. The feed's generated value describes the publication of that JSON response; it is not the date every incident happened.
These distinctions follow the Have I Been Pwned breach model. Provider coverage is limited to records it has received and published. A daily refresh cannot discover an incident that no source has disclosed.
Turn the timeline into a practical decision
For an old password exposure, establish whether that password was still reused after the incident. For a personal-detail exposure, identify which accounts use those details for recovery. Keep uncertainty visible: an alert records known exposure, while unfamiliar sign-ins require a separate account review. Do not label every alert as a current account takeover.
Continue with reading a breach notification, checking your email, or the breach archive.
Use these checks for your own accounts or work you are authorised to do. MyRecon reports public-source results; a matching handle is not proof that two accounts belong to the same person. See our terms and privacy policy.