# Dark Web Exposure: Reading breach detail

When an identity's email address or principal appears in a publicly known
third-party breach, Axiad Mesh raises a **Dark Web Exposure** risk on that
identity. Beyond raising the risk, Mesh shows you *which* breaches it found:
what was exposed, when the breach happened, when it was disclosed, and how
large it was.

This page explains how to read that detail. For how breach exposure is scored
and how it fans out to credentials, see
[Risks](../concepts/risks.md#human-identity-risks) and
[Risk scoring](../concepts/risk-scoring.md).

## Where breach detail appears

Breach detail lives in the risk drawer on an identity:

1. Open the **Identity risk assessment** dashboard and select an identity.
2. On the identity's detail page, select a Dark Web risk — either from the
   risk list or by selecting the risk badge next to the identity.
3. The drawer opens with the risk explanation, and, directly beneath it, the
   **Highlighted breaches** section.

Three risk types carry breach detail:

| Risk | Meaning |
| --- | --- |
| **Dark Web (Non-Sensitive)** | The identity appears in a breach that exposed personal information, but nothing sensitive and no credentials. |
| **Dark Web (Sensitive, No credentials)** | The breach exposed *sensitive* personal information — but not credentials. |
| **Dark Web (Possible password reuse)** | A credential risk fanned out from a breach that exposed credentials, so a reused password could be in play. |

Every other risk type is unaffected — the drawer looks exactly as it did
before.

## Highlighted breaches

An identity can appear in dozens of breaches. Rather than make you read all of
them to find the ones that matter, Mesh promotes two to the top of the drawer:

- **Most severe** — the breach with the highest severity.
- **Most recent** — the breach that happened most recently.

When one breach is both, Mesh shows a single card labeled **Most severe &
most recent** instead of repeating it.

Recency is judged on the breach date, falling back to the disclosed date when
a breach has no breach date. A breach with neither date can still be the most
severe, and it always appears in the full list.

All breach detail is labeled **Dark Web Intelligence**. Mesh normalizes what
its intelligence sources return into one shape, so the drawer reads the same
way regardless of which source supplied a given record.

## What a breach card shows

Each card carries the fields that source reported for that breach:

| Field | What it tells you |
| --- | --- |
| **Breach name** | The breached service or dataset. |
| **Domain** | The breached service's domain, when reported. |
| **Severity** | A severity badge, colored on the same scale used everywhere else in Mesh. |
| **Breach date** | When the breach itself occurred. |
| **Disclosed date** | When the breach became publicly known. |
| **Accounts** | How many accounts the breach affected, abbreviated — `152.4M`, `847K`, `1.2B`. Counts under a thousand are shown in full. |
| **Exposed data** | The categories of data exposed, such as email addresses, passwords, or physical addresses. |
| **Description** | The published narrative for the breach. Long descriptions are clamped to three lines; hover to read the rest. |

### The malware and stealer-log badge

Some records carry a **Malware / stealer log** badge. It means the breach data
was recovered from infostealer malware or a stealer-log dump rather than from a
website breach.

Read the badge as a statement about *where the breach data came from* — not as
a finding that this identity's own device is infected, and not as a statement
about this identity's own credential.

### When a field reads Unavailable

A field shows **Unavailable** when the intelligence source did not report that
value for that breach. It is expected, not an error, and it is per-record: the
same source may report a date for one breach and not for another.

Mesh deliberately shows **Unavailable** rather than a blank or a zero. An
account count of `0` would assert that the breach affected nobody, which is a
different claim from "the count was never published".

## The All breaches list

Select **View all breaches** on the highlighted section to open the full list
for that risk and identity. The list is a table:

- Columns: **Breach**, **Breach date**, **Disclosed**, **Exposed data**, and
  **Severity**.
- **Sort breaches by** toggles between **Most severe** and **Most recent**.
  Breaches with no usable date sort last under Most recent.
- Records are paginated, ten to a page.
- The subtitle counts the records — `12 records · Dark Web Intelligence`.

Very large exposures are capped. Mesh keeps the 100 most severe breach records
per risk and says so in the subtitle:
`Showing 100 of 431 records · Dark Web Intelligence`. The cap never drops a
more severe breach in favour of a less severe one, so the worst of an exposure
is always listed.

The risk itself is unaffected. Severity is derived from what the breaches
exposed, not from how many records are listed, so a capped list never changes
whether a risk fires or how it is scored.

Ordering is deterministic. Equal-severity breaches are ordered by recency and
then by name, and equal-date breaches by severity and then by name, so the
same identity always presents its breaches in the same order.

## When no detail is available

A Dark Web risk can be raised without per-breach detail behind it. In that
case the risk indication stays exactly as it is — the finding is real and the
score is unchanged — and the drawer says:

> Detailed breach information is unavailable for this risk.

Treat this as missing enrichment, not as a resolved risk.

## What Mesh does not show

- **Vendor names.** Mesh never identifies which intelligence provider supplied
  a record. Provider selection is a deployment decision, and the drawer is
  written to be read the same way whichever provider is in use.
- **Passwords or exposed values.** Mesh reports the *categories* of data a
  breach exposed. It never stores or displays the exposed values themselves.
- **A remediation control.** The drawer explains the risk and how to address
  it; acting on it — for example resetting affected credentials — is done in
  the system of record. Use **Investigate this risk in your system** to jump
  there. See [Remediation](../concepts/remediation.md).

## Related pages

- [Risks](../concepts/risks.md) — what Mesh looks for and how findings are raised.
- [Risk scoring](../concepts/risk-scoring.md) — how breach exposure contributes to a score.
- [Investigate a risky identity](../getting-started/investigate-risky-identity.md) — the end-to-end walkthrough.