An alert fires at 2am on an account called `svc-datawarehouse-prod`. Your SecOps detection and response
platform raised it from the directory's sign-in logs. The information you know at this point is the account authenticated from a host it has never used, and the logon was interactive rather than the scheduled service logon its nightly job produces.
That detection alert is basically the end of what it can tell you. The analyst on shift now
has to decide whether to escalate, and answering that takes five things the alert does not carry.
- Is this a person or a service
- Who owns it
- Is it supposed to have administrative rights
- What critical resources does it have access to
- Did any of that change recently
Where those answers live
Most of them live in systems owned by teams outside the SOC.
The account type is a guess from the naming convention. A `svc-` prefix usually means service,
right up until you find the three `svc-` accounts a contractor created for himself in 2021. Naming is a convention, not a
governed attribute.
Ownership is in a ServiceNow ticket from 2023, or in the head of someone who left, or nowhere.
Whether it should hold admin rights depends on what it was provisioned for, and that intent sits
with the application owner, usually in an email thread from a project two years ago.
What it can reach means resolving group memberships and nested groups into roles, and roles into
permissions on specific resources, across every system in the path. By hand. At 2am.
Whether anything changed recently is the question that usually has no answer at all. Most
identity controls hold current state and overwrite it, and a periodic scan records what is true at
scan time while discarding what was true before. There is no earlier version to compare against.
Every one of those answers belongs to a team that is asleep. So the alert becomes a thread that runs
into the next business day, and the decision it was supposed to trigger gets made two days later by
someone reading a summary.
The dismissals cost as much as the escalations
Slow escalation is the visible cost. But the underlying cost is that an analyst cannot confidently dismiss
the alert either.
Without knowing whether that account is supposed to hold admin rights, the safe move is to leave the
ticket open. Enough of those and the queue fills with things nobody can close, which is how the ones
that matter get lost. Microsoft and Omdia's State of the SOC research, published in February 2026, put the share of alerts that go uninvestigated at 42 percent, with analysts pivoting across an average of 10.9 consoles to assemble context.
Identity alerts sit at the worst end of that, because identity is the domain where the context needed
to close an alert is spread across the most systems and owned by the fewest people who are awake at 2am when
it fires.
What it looks like when the answers arrive with the alert
Stitching data together across several consoles is nearly impossible. But the same alert, with the identity context already attached, in the console the analyst is already in, could look something like:
- `svc-datawarehouse-prod` is classified as a service account rather than a person
- Owned by the data platform team, with a named individual accountable
- Holds administrative rights on two databases. The peer service accounts in the same job function hold administrative rights on none
- Reaches a named list of resources, with the path written out: added to a group, the group is assigned to a role, the role carries the permission on the database
- Was added to that group eleven days ago, by a named actor
Those are the five answers that decide whether this gets escalated, available in the first two minutes instead of on the second day.
How the context gets there
Hydden collects identity data from every system you run, including the ones that do not emit their own audit logs when
something changes. In this case, the change is derived by comparing what the system returns now against what it returned last time, so a group membership that appeared with no log entry behind it still becomes an event with a timestamp. It matches up the accounts belonging to the same person or service, and keeps every change rather
than overwriting the last known state.
Then it forwards that context to your SOC platform as OCSF or syslog. They enter the triage path and the playbooks a team already runs, rather than showing up as a new alert type nobody has automation for. OCSF is the vendor-neutral event schema, so identity events land in whatever platform you run and behave like any other source. So no new console with new alert queue. The account type, the owner, the entitlements, whether the access is unusual compared to peer accounts, and the recent changes all become fields an analyst can pivot on, and that a detection engineer can take action against.
Faster decisions
The point of identity context on an alert is a faster escalate or dismiss, made by the person on shift, with reasons they can write down. For years, your teammates in SecOps have been requesting this identity data be made available in the platform they live in every day. Hydden supplies those identity answers before the analyst goes looking for them.
To see what your identity alerts look like with the answers attached, schedule a demo.
Frequently asked questions
What identity context does an analyst actually need on an alert?
Five things: whether the account belongs to a person or a service, who is accountable for it, whether its privileges are expected, what it can reach, and what changed recently. Those five decide escalate or dismiss. Most identity alerts arrive with none of them, which is why they take days rather than minutes.
Why do identity alerts take so long to triage?
Because the context lives outside the security tooling. Ownership sits in tickets or in someone's memory, entitlements sit across several systems that have to be resolved by hand, and the history needed to say what changed was usually never kept. The analyst ends up assembling the answer from other teams instead of reading it.
Is this a SIEM?
Your SOC platform stays where detections run, where cases live and where the data lake sits. Hydden holds the identity record and sends identity events and findings into that platform in an open format, so the context shows up alongside everything else rather than in another console.
How does identity data get into our existing SOC platform?
As OCSF 1.3 or syslog, which means it lands in whatever platform a team already runs and behaves like any other source. Analysts pivot on it in searches they already write, and detection engineers can build rules against identity change events the same way they do against endpoint or network events.
Can this tell an analyst whether an account's access is unusual?
It can compare an account to its peers and flag access that stands out, such as a service account holding administrative rights that similar service accounts do not have. That comparison is about the access an account holds rather than about how it has been behaving.