Identity Exposure
Identity Exposure covers two related things:
- Breach records - credentials and personal data for your domains that have appeared in known breaches.
- Identity inventory - who and what can authenticate into your environment, and with what privileges.
The first is exposure that has already happened elsewhere. The second is what an attacker could use it against.
Breach records
Once a domain is verified, the platform searches breach corpora and dark web sources for credentials and data associated with it.
SCREENSHOT: the Breach Records view.
Verification is required, and is the gate for this entire section - it exists so nobody can point breach monitoring at a domain they do not control. Until a domain is verified, none of this runs for it. See Getting started.
Reading a breach record
The instinct is to sort by breach date and dismiss anything old. Resist it.
What matters is whether the credential is still valid, not when it leaked. A password from a 2019 breach that someone still uses is a live credential. An eight-year-old breach containing a password nobody reuses is not.
So the useful questions are:
- Does this account still exist?
- Is this password still in use, here or anywhere reachable?
- Does the account have MFA?
The last one is usually the fastest mitigation. A breached credential on an account with MFA is a much smaller problem than one without, and enabling it takes less time than determining whether a password was reused.
Vendor breach summary
Aggregate counts across your domains rather than individual records - useful for tracking exposure over time without handling the underlying data.
Entra ID correlation
Joins breach records against your Entra ID directory, so you see which breached addresses correspond to accounts that actually exist.
This is the view that turns a list into work. A breach corpus contains addresses that were never real, left years ago, or belong to someone else at a similar domain. Correlation narrows it to the accounts you can act on.
Identity inventory
What can authenticate, and what it can do. Vendor-agnostic where the underlying directories allow it, so one question spans several.
| View | Covers |
|---|---|
| Users | AWS IAM users and Entra ID members |
| Groups | Entra ID groups |
| Applications | Entra ID app registrations and their secrets |
| Service identities | Entra ID service principals |
| Roles | Entra ID directory roles and their assignments |
| Role assignments | Who holds what |
| Access policies | Entra ID conditional access |
| Identity providers | Tenant-level federated identity stores, including AWS IAM Identity Center |
Where to look first
Service identities and app registrations. Non-human identities are where over-privilege accumulates, because nobody reviews them at leavers' time and they rarely have MFA. App registration secrets in particular expire quietly and get replaced with longer-lived ones.
Role assignments. Directory roles granted for one task and never removed.
Conditional access policies. Worth reading as a set rather than individually - the interesting question is what combination of conditions leaves a path with no policy covering it.
Bringing the two together
The combination is what makes this section worth more than either half:
- A breached credential for an account that exists and has a privileged role and no MFA is an incident waiting to happen, and each of those three facts comes from a different view.
- A breached credential for an account that was deleted two years ago is noise.
Correlation does the first join for you. The inventory is where you do the rest.
API
The endpoints behind this section are in the API reference.
Next
- Getting started - verifying a domain
- Identity providers - your own single sign-on
- Investigations - identity activity over time