I was mapping out access for a mid-sized engineering org a while back, and we hit a wall almost immediately: nobody could tell us, with confidence, how many accounts one senior engineer actually had.
By the time we finished counting, the answer was seven. Active Directory account. Okta identity. An AWS IAM role. A GitHub account with org-admin on two repos. Microsoft 365 access. A VPN identity. A privileged role in a cloud console nobody remembered granting.
Seven accounts. One person. And not one system in that stack had the full picture.
That's not a rare setup. It's basically the default now, especially for anyone touching infrastructure, CI/CD, or cloud resources regularly. And it creates a strange asymmetry: for your SOC, that's seven disconnected pieces of data sitting in seven different consoles. For an attacker who compromises just one of those seven, it's one identity with several paths into the org, and they only need to find the weakest one.
The Identity You Can See Isn't the Identity You Actually Have
Identity data is scattered by design. Directories, identity providers, cloud platforms, SaaS apps, HR systems, PAM tools, VPNs, databases — each one knows a slice of the truth about an account, and almost none of them know the whole story about the person or entity behind it.
Here's a scenario worth sitting with. A developer suddenly accesses a repository they've never touched. Around the same time, that same person authenticates from an unfamiliar location, picks up a new privilege, and reaches a cloud resource they don't normally go near.
Any one of those, alone, has a boring explanation. New project, new laptop, new access request that hasn't been revoked yet. But stacked together, on the same identity, in a short window, that combination starts looking a lot less boring. The hard part was never really detecting each event individually. Most tools can do that. The hard part is realizing all four events belong to the same person, and understanding what that person can actually reach if they've been compromised.
Accounts Aren't the Same Thing as Identities
Traditional identity monitoring hands security teams siloed views almost by default. Active Directory shows one account. Okta shows another. AWS shows a third. Every SaaS app you add stacks another account and another set of permissions on top.
Which creates a pretty basic mismatch: the security team sees accounts. What they actually need to understand is identities. That gap matters more as an org scales, because a dormant account can quietly become active, a privileged identity can start behaving differently, a service account can touch an application it's never touched before, and permissions can pile up on someone's profile for years without anyone reviewing why they're still there. Without something correlating those accounts back to one entity, all of that stays scattered across dashboards nobody's cross-referencing in real time.
Risk Isn't a Single Login Event
Not every identity carries the same weight. A standard employee account behaving exactly like it always does is a non-event. A privileged admin account suddenly reaching for something unfamiliar is not. A dormant account waking up isn't the same story as a service account running its normal, scheduled workload.
Treating all of these the same way, as isolated login events, is part of why alert fatigue exists in the first place. What actually matters is a continuously updated read on which identities are becoming risky right now, not a static list of who technically has an account.
Knowing an Identity Is Risky Isn't the Same as Knowing What It Can Reach
This is the part that's easy to skip past. A privileged identity connected to a dozen applications, several groups, and multiple cloud resources represents a very different level of exposure than a similarly "risky-looking" identity that's isolated to one low-value system. If either one gets compromised, the actual damage depends entirely on its access paths, not just on the fact that something looked unusual.
Being able to visualize that, what applications an identity touches, which groups it belongs to, what privileged access it holds, and what the realistic blast radius looks like if it's compromised, turns "this account triggered an alert" into something an analyst can actually act on.
Detection Is Only Half the Problem
Finding a risky identity is the easier half. The harder question is what happens in the minutes right after that.
If every high-risk identity requires a manual ticket, a handoff to another team, and three rounds of approval before anything happens, your response time is going to lose to an attacker who's already moving. This is exactly the kind of decision that benefits from being pre-approved and automated for high-confidence cases: lock the account, force MFA re-enrollment, clean up a dormant identity, contain a privileged account that's acting outside its normal pattern. Not to cut humans out of the loop, but to cut the unnecessary waiting out of the cases where the evidence is already clear.
Identity Attacks Rarely Look Like Malware
One of the more frustrating things about identity-based attacks is that they often skip the part your endpoint tools are built to catch. There's no malicious file, no obvious exploit. Just a valid credential, used in a way that doesn't quite match how it's normally used: impossible travel, an MFA bypass, credential stuffing, a privileged identity reaching somewhere it's never gone before.
Every one of those can look completely legitimate to a control that's only checking "is this credential valid." The behavior around the credential is usually where the real story is, which is exactly why this has to be a correlation problem, not a single-signal detection problem.
This Gets Worse, Not Better, at MSSP Scale
For a single enterprise, identity fragmentation might mean juggling a dozen systems. For an MSSP managing multiple customers, that same fragmentation exists per tenant, and it multiplies. Different identity providers, different directories, different cloud environments, different policies, times however many customers you're responsible for. Without a centralized way to score and monitor identity risk across tenants, analysts end up manually switching between disconnected consoles for every single customer, which doesn't scale past a handful of accounts.
Where I've Found This Actually Gets Solved
I'll be upfront: I work with Seceon. What convinced me this was worth writing about wasn't a feature list, it was watching how their aiSecurity UIDGuard360 handles the seven-accounts-one-person problem specifically. It resolves fragmented accounts across directories, cloud, HR, and SaaS sources into a single canonical identity, and scores risk continuously across credential, privilege, activity, access, behavioral, and compliance signals instead of treating every login as its own isolated event.
That's the shift that actually matters here. Not another dashboard, another data source connected to the pile. The difference between an analyst starting an investigation with "this account generated an alert" versus starting with "this person has these seven accounts, these privileges, and this level of risk right now" is enormous, and it's the difference that decides whether an investigation takes twenty minutes or two hours.
The Real Shift
Identity security has spent years focused on authentication, MFA, and access reviews. Those still matter. But modern identity attacks don't stop at the login screen. An attacker compromises an identity, reaches an application, touches cloud infrastructure, picks up a privileged role, and starts moving toward something valuable. The identity is the thread connecting every one of those steps.
Which means the real question was never just "how many identities do we have." It's closer to: who does this identity actually belong to, what can it reach, how does its behavior compare to normal, and what happens the moment something about it changes.
That's a harder problem than counting accounts. It's also the one that actually matters.
Top comments (0)