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, because they are public knowledge. Each breach is listed once; when the identity turns up in the same breach more than once it carries a ×N badge, and the headline adds the number of entries, for example "28 breaches · 100 entries",
• the infostealer infections that captured it, each linking to the infected device,
• first seen and last seen, and the latest capture date against when the feed detected it. Those are two different facts and both are shown.

In the Identities workspace, and on the Overview's top exposed identities, each figure is labelled by what it counts:

• infections are counted as distinct machines, with the number of stealer-log records shown under it, because one machine can leave several records (an Overview row shows the stealer-log records alone),
• unique combo passwords are the distinct passwords for the identity found in combolists (not a number of combolists),
• last breach published is the publish date of the newest breach, and last captured the newest infostealer capture, each under its own name.

Posture bands

The score falls in one of seven bands, and the badge and ring are coloured by band, from calm to alarming:

Band	Score	Colour
Very low	0–14	green
Low	15–24	green
Medium-low	25–44	violet
Medium	45–64	amber
Medium-high	65–70	amber
High	71–84	red
Very high	85–100	red

A riskier band is never a calmer colour than a less risky one, and only the two lowest bands are green. A posture that has not been rated yet shows as a neutral grey badge.

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 entries, so capped counters are labelled 100+ rather than passed off as exact. See the exact-or-N+ rule.

The Identities workspace

Identities lists the exposed identities across your domains. The list stays on the left, and each row carries a risk dot. Umbra scores the people on screen: a row is scored only once you scroll it into view, and each score is kept for the session, so nothing is looked up twice.

• A scored row's dot takes its posture band's colour, the same colours as the posture badge.
• Before that the dot is an empty grey ring: not scored yet, scoring, unavailable when the lookup failed (it is not tried again until you reload the page, unless the reputation feed was too busy to answer: then it is tried again the next time the row comes back on screen; temporarily unavailable when Umbra's exposure data source is down on our side), or withheld for a colleague on an unverified domain, where only your own row is scored. Hover the dot to see which.
• A person captured on your sites is never scored: their dot reads Not scored: captured on your site, not an address on your domains. See Who gets a score.

The Risk sort lists the scored rows first, riskiest first, and the rest after them in the order you sorted by last. The order is set when you pick the sort, search or filter: a score that lands after that colours its dot in place and the row keeps its position, so the list never moves while you read it. A note under the count says how many rows the order ranked by score, and once new scores have landed it offers Re-rank (with how many are new) to sort again. The sort ranks the people you have looked at, not the whole domain.

Selecting a row opens that person's dossier on the right, the whole person on one screen:

• a sticky header with the address, the posture badge, the first-exposed, last breach published and last captured dates, and Copy link,
• four headline figures, each with its date: Infected machines, Credentials, Breaches and Combo passwords,
• the infected machines, each with the logins stolen from it nested under it. Captures whose machine is not listed go under Other stealer-log records rather than being dropped,
• the breach and combolist credentials, grouped by year and titled by their source. A credential, or a login stolen from a machine, links to Where this password is reused when the feed gave it a record id,
• a Status card, a What to do checklist, and the breach history.

The checklist is built from the data on the page. Each item states a fact that stays true either way, with a suggested action under it, and is ticked Done once every record behind it is marked Resolved. For example, 2 logins stolen from 7b41e2c9… on 26 Sep lists each stolen login as a chip with its service and the password's last characters (sso.example.test •••ux2), linked to that service's page, and is followed by Suggested: clean or reimage it, then change these 2 passwords on the sites shown. Past three chips, a +N more chip jumps to that machine under Infected machines, or to the section itself when the machine's block is hidden by the Show more fold or a filter. A breach or combolist item names the password by its last characters instead, as in Password ending •••_88 exposed in Database Leak, or 3 passwords exposed in … with one chip each when a source holds several; a password the feed sent without last characters still counts there, gets no chip, and keeps the advice to reset it anywhere it was reused. It cannot name a site: the record names the breach, not where the account is, so the suggestion is to change it on every account still using a password ending in those characters. When the feed sent no last characters, the item keeps reading Password exposed in Database Leak, then Suggested: reset it, and anywhere it was reused. On Free, an infection reads A machine this person uses was infected…, since which machine is a Pro detail; stolen logins show their services but never a password's last characters, which are a Pro detail too; and nothing from the last 30 days is named or counted anywhere in the dossier. For a colleague on a domain you have not verified, the dossier asks you to verify the domain by DNS instead.

The Status card rolls the person's records up, for example 1 of 4 resolved. Their row in the list shows the same rollup over the records loaded for the domain, labelled in loaded records, so it can count fewer records than the card. A status still belongs to each record: a new breach or capture is a new record, Active. An admin can Mark all resolved, with an optional note, for every Active record in the person's list. While the list still has pages to load, the card says k of K loaded and the action covers only the loaded records. Members and viewers see the rollup read-only.

On narrower screens the layout gives way. Below 1280 px the checklist and the breach history drop under the machines. Below 1024 px the list becomes a searchable dropdown above the dossier. Below 640 px the list and the dossier are two screens with a back link, and the dossier leads with the checklist and folds the credentials and the breach history.

Every count sits next to the list it opens and equals that list's length, or carries a + when the list is capped or has more pages. On the identity list, hovering a row's figures names them: exposed credentials in the loaded exposures, how many were captured by infostealer malware, and the date of the newest loaded record.

Who gets a score

Umbra scores an identity when it is an address whose domain, the part after the last @, is exactly one of your domains. A subdomain is not its parent: a@eu.example.test is not scored while only example.test is registered.

On a domain you have verified, the loaded records also hold people captured signing in to your own sites with a bare username or an address on another domain. They are not identities of your domains, so Umbra cannot score them or look up their full history. The Identities list keeps them apart with a switch at its top:

• Your domains (N), the default: your identities, each scored once on screen. An employee the site search happened to find is here too.
• Your sites (M): the people captured on your sites, counted as people in the loaded records, not as the records the Overview's Captured on your sites box counts. Search, the Infostealer filter and the sorts work within the group, and there is no Risk sort, since nobody here has a score.

A link to one of those people opens Your sites with them selected. Their dossier shows a Captured on your site chip, a note in place of the risk figures, and their records under Captures in the loaded records, with the Status card and the What to do checklist built from those records alone. The Overview's Top exposed identities lists only people Umbra can score, and when the newest infostealer capture's victim is one of those people, its card shows Captured on your site instead of a detection date. Devices, Services and Sources still count everyone captured.

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, meaning indexed, so the device page will have captures,
• metadata only, meaning the feed reports the infection but no log is indexed yet,
• not checked yet, meaning unknown, shown in a neutral colour. The chip is itself the button that spends the lookup, and opening the machine answers it too (the chip reads checking… meanwhile).

A machine that holds captures of the identity you opened is labelled stealer log · N captures for this identity without any click. That count comes from the identity's own credential lookup, so it costs nothing, and it is only this identity's share of the machine. It reads N+ while that lookup has more pages.

A failed lookup stays not checked yet. It is never cached as "metadata only".