Skip to main content

Identity risk scoring

Every exposed identity in your domains has a risk posture: a score and band computed from its exposure history, with the evidence right behind it. It answers the question "how bad is it for this person?" in one view.

The risk posture​

Open an identity (from Identities, from an exposure row, or by pasting an email into Investigate) and you get:

  • the score ring and posture band,
  • how many different breaches the identity's credentials appear in — breach names are always shown, on every plan (they are public knowledge),
  • the infostealer infections that captured it, each linking to the infected device,
  • first seen / last seen, and the latest capture date vs when the feed detected it — two different facts, both shown.

Your own identity's posture opens the console: the Overview's hero card answers "what is my exposure?" for the email you signed in with.

note

A per-identity risk profile lists at most 100 records, so capped counters are labelled 100+ rather than passed off as exact — the exact-or-N+ rule.

The Identities workspace — two layouts​

Identities lists the exposed identities across your domains. How you drill into one is your choice — pick a layout in Settings → Display → Identities layout; it is personal to you and changes nothing about the data:

  • Split pane — the identity list stays on the left, the detail on the right, with infections / breaches / credentials grouped by year and revealed with Show more as you go.
  • Drill columns — one Finder-style column per step (identity → section → item → detail → service), all kept on screen so you back out one column at a time instead of losing the trail. Arrow keys move between columns, and the URL captures the whole path — a deep link shares exactly what you were looking at.

Stealer-log coverage — resolved on demand​

For each infection, whether its stealer log is indexed in the searchable corpus is a separate fact from the infection itself, and resolving it costs one feed lookup per machine. Umbra asks before spending it. An infection shows one of three states:

  • stealer log N — indexed; the device page will have captures,
  • metadata only — the feed reports the infection but no log is indexed (yet),
  • not checked — unknown; the chip is the button that spends the lookup.

A bounded "check the visible ones" action resolves the states in view. A failed lookup stays not checked — it is never cached as "metadata only".