Identity telemetry SIEMs miss: logs that stop breaches faster

The breach you miss is usually an identity event

In 2026, attackers rarely "hack in"; they log in, mint tokens, abuse trust, and move laterally with valid identities. In several post-incident reviews, the first real signal was not malware, but an identity telemetry gap: a missing token refresh event, a skipped conditional access decision, or a privileged role assignment that never reached the SIEM.

A common failure pattern is brutal in its simplicity: the SIEM has 50,000 authentication events per hour, but none of the session, token, or entitlement changes that explain what those authentications mean. That is how a 14-minute compromise becomes a 14-day investigation.

What identity telemetry your SIEM should ingest

Your SIEM should not just ingest "login success" and "login failure." It should ingest the control-plane events that define who can act, from where, with what assurance, and under which authorization state.

1) Authentication context, not just authentication results

Ingest the full auth decision chain:

• IdP sign-in logs with MFA method, device state, risk score, geo, IP reputation, and app target
• Conditional access decisions, including policy ID, grant controls, and failure reason
• Passwordless and phishing-resistant auth outcomes, such as FIDO2 and passkey usage
• Step-up authentication triggers and outcomes

Example: a finance user signs in from Toronto on a managed laptop at 09:12, then refreshes the same session from a Singapore ASN at 09:27. If your SIEM only sees "success," you miss the impossible travel plus token replay pattern. If it ingests the IdP risk score and CA decision, you can alert in under 90 seconds.

2) Session and token telemetry

This is the blind spot most teams still ignore. Ingest:

• Access token issuance and refresh events
• Refresh token rotation failures
• Token binding or proof-of-possession failures
• Session revocation and sign-out events
• OAuth consent grants and app authorization changes

A realistic 2026 benchmark: organizations that correlate token issuance with session revocation typically cut mean time to confirm token abuse from 3-5 hours to 20-40 minutes. That matters because modern adversaries often operate entirely inside valid sessions.

3) Privilege and entitlement changes

If you do not ingest identity governance telemetry, your SIEM is missing the moment access becomes dangerous. Pull in:

• Group membership changes
• Role assignments and removals
• Privileged access management checkout events
• Just-in-time elevation requests and approvals
• SCIM provisioning/deprovisioning actions
• Entitlement package assignments in IGA tools

A named scenario: an Azure AD / Entra ID Global Administrator role assignment created through a break-glass workflow at 02:14 should never look like a normal admin action. It should be tied to a ticket, an approver, and a time-bound expiration. Without that context, your analysts waste time on false positives or, worse, miss a real escalation.

4) Directory and federation changes

Identity attacks often start with trust manipulation. Ingest:

• Federation trust updates
• SAML signing certificate changes
• IdP metadata changes
• Domain join and device registration events
• Password policy changes and lockout policy changes
• Directory replication anomalies and sync failures

If a SAML certificate changes outside a maintenance window, that is not a routine admin event. It is a potential path to assertion forgery or IdP compromise. In one enterprise case, catching the certificate rollover outside change control reduced the blast radius from a likely org-wide takeover to a contained incident.

5) Endpoint identity signals

Identity telemetry becomes much stronger when tied to device posture:

• Device compliance state
• MDM enrollment and unenrollment
• Local admin elevation events
• Credential cache access and LSASS protection state
• Device certificate issuance and revocation
• Browser profile and extension risk signals for managed endpoints

A device marked compliant at sign-in but noncompliant 12 minutes later is a different risk story than a stable managed endpoint. Your SIEM should correlate those changes, not store them in separate dashboards.

6) SaaS and cloud identity activity

The identity plane now spans SaaS, cloud control planes, and CI/CD systems. Ingest:

• Admin actions in Microsoft 365, Google Workspace, Salesforce, Slack, and GitHub
• API token creation and rotation
• Service account key creation and deletion
• Cloud IAM policy changes
• Workload identity federation events
• CI/CD secret access and OIDC trust configuration changes

A cloud compromise often shows up first as a GitHub app installation, a new API token, or a workload identity trust update. If your SIEM only ingests cloud audit logs after the fact, you are late by design.

How to normalize identity telemetry so analysts can use it

Raw logs are not enough. The SIEM needs a normalized identity schema so detections can compare apples to apples across Entra ID, Okta, Ping, Google, AWS IAM, and your PAM stack.

Build a common identity event model

At minimum, normalize these fields:

• actor.id
• actor.type (user, service account, workload, admin)
• auth.method
• auth.assurance
• session.id
• device.id
• resource.id
• privilege.delta
• geo.location
• risk.score
• policy.decision

Here is a practical mapping example:

{
  "event_type": "signin",
  "actor.id": "j.singh@corp.example",
  "actor.type": "user",
  "auth.method": "fido2",
  "auth.assurance": "phishing-resistant",
  "session.id": "sess-8f21c",
  "device.id": "device-4412",
  "resource.id": "salesforce-prod",
  "geo.location": "CA-ON-Toronto",
  "risk.score": 18,
  "policy.decision": "allow"
}

Enrich at ingest, not at alert time

If you wait until alerting to enrich identity events, you burn analyst time and increase detection latency. Enrich on ingest with:

• HR status: active, terminated, contractor, leave of absence
• Privilege tier: standard, power user, admin, break-glass
• Asset criticality: workstation, jump host, domain controller, production SaaS
• User peer group baseline: finance, engineering, executives, support

A strong pipeline can enrich 10,000 identity events per second with sub-50 ms added latency if you keep lookups local or cache hot. Teams that enrich late usually see 300-800 ms extra per correlation, which becomes painful under bursty auth storms.

Use correlation keys that survive vendor differences

Different products name the same thing differently. Map around stable keys:

• user principal name or immutable user ID
• device UUID
• session or token identifier
• application client ID
• role or entitlement ID
• federated issuer ID

That lets you correlate a Google Workspace admin change with an AWS role assumption and a GitHub token creation without building a one-off rule for each product.

Detection patterns that depend on identity telemetry

The best identity telemetry is operationally useful only when it feeds detections that reduce noise and speed containment.

Token abuse and session hijacking

Detect:

• token refresh from a new ASN within minutes of issuance
• multiple geographies using the same session ID
• refresh token reuse after rotation
• session continuation after impossible travel plus device mismatch

Example detection logic:

rule: suspicious_token_reuse
when:
  event_type in ["token_refresh", "session_continue"]
  and session.id reused across distinct geo.location within 15m
  and device.id changed
  and risk.score >= 50
then:
  severity: high
  action: isolate_session, notify_soc

Organizations that implemented this style of detection in 2026 commonly report 30-60% fewer false positives than rules based only on IP reputation and failed logins.

Privilege escalation without change control

Look for:

• admin role assignment outside approved window
• JIT elevation without ticket linkage
• new service principal with broad directory permissions
• group nesting that grants indirect admin rights
• PAM checkout without corresponding change record

A useful threshold: if a privilege delta affects more than 250 users or grants tenant-wide access, treat it as a high-severity identity telemetry event even if the change is technically "successful."

Dormant account activation and account takeover

Attackers love accounts that have not logged in for 90+ days. Alert when:

• dormant accounts authenticate after long inactivity
• password reset and MFA reset occur in the same hour
• recovery email or phone changes precede sign-in
• a user switches from passkey to weaker fallback methods

In one enterprise environment, dormant-account alerts caught 11 real takeovers in a quarter, while the older password-failure rule set produced 2,400 alerts and almost no confirmed incidents.

Common Pitfalls

Treating identity logs as "just another source"

If identity telemetry lands in a generic log bucket, analysts will not trust it. Give it a dedicated parsing pipeline, clear field mapping, and high retention.

Ignoring token and session events

This is the most expensive mistake. Valid-session abuse is now one of the most common intrusion paths, and without token telemetry you only see the aftermath.

Over-indexing on failed logins

Failed logins are still useful, but they are weak on their own. A 2026 SOC that relies primarily on failures will drown in password spray noise and miss silent compromise.

Not ingesting admin and governance systems

Many teams ingest IdP logs but ignore IGA, PAM, and SCIM. That leaves the exact privilege changes that matter most outside the SIEM.

Failing to normalize identity across vendors

If each product uses a different user ID, session ID, and role label, your detections become brittle. Normalize early or expect endless rule rewrites.

A practical ingestion blueprint for 2026

A good architecture is simple enough to operate and strict enough to detect abuse.

[IdP / SSO] ---> [Normalizer] ---> [Identity Enrichment] ---> [SIEM]
      |                |                  |                    |
[IGA / PAM] -----------+------------------+--------------------+
      |                                     
[MDM / EDR] -------------------------------> [Correlation Store]
      |
[Cloud IAM / SaaS / CI-CD] ---------------> [Hot Detection Rules]

A realistic deployment pattern:

1. Stream IdP, PAM, IGA, and cloud IAM logs into a Kafka or Kinesis layer.
2. Normalize into one identity schema before SIEM indexing.
3. Enrich with HR, device, and asset context in a low-latency lookup service.
4. Keep 30-90 days of hot searchable identity telemetry.
5. Archive 12-18 months for investigations and control validation.

If your SIEM vendor charges by ingest volume, prioritize high-value identity events first. Most enterprises can reduce raw ingestion by 25-40% while improving detection quality by dropping duplicate auth noise and keeping session, privilege, and governance events.

Key Takeaways

• Ingest identity telemetry beyond logins: session, token, privilege, governance, and federation events.
• Normalize identity fields across vendors so detections survive product sprawl.
• Enrich identity telemetry at ingest with HR, device, and asset context.
• Prioritize detections for token abuse, privilege escalation, dormant account activation, and trust changes.
• Stop over-investing in failed logins; valid-session abuse is the bigger 2026 problem.
• Build a pipeline that keeps identity telemetry searchable for at least 30-90 days hot and 12-18 months archived.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.