IAM Authentication Events Are Absent From Most SIEM Detection Pipelines.

The IAM layer generates the earliest detectable signal of a credential attack. Before any account is compromised, before any privileged session is opened, before any data is accessed, the attack produces a pattern in the authentication event stream: MFA failure spikes across multiple distinct account identifiers, account lockout clusters on targeted identifiers, or anomalous recovery attempt volume against accounts the attacker does not own.

That signal is present in the IAM platform’s event log. In most organisations, it does not reach the SIEM. Not because the SIEM cannot evaluate it, but because the IAM authentication event stream is not connected to the detection pipeline in a form that detection rules can consume in real time.

The architectural reason is specific. SIEM deployments are built around log sources with standardised connectors and documented formats: Windows Event Logs, firewall syslog, endpoint detection telemetry, and cloud provider audit logs. IAM authentication events are less standardised across vendors. Getting them into a SIEM has historically required custom log parsing, manual export pipelines with significant latency, or professional services integrations that are expensive to build and maintain. None of these produces a real-time structured event stream. The detection gap is an integration architecture problem, not a SIEM capability problem.

This blog covers what the credential attack signal looks like in the IAM authentication event stream at the technical level, why the three conventional integration approaches all fail to close the detection gap, and what a structured API feed from the IAM layer changes for detection rule design and SIEM integration.

Why Conventional IAM-to-SIEM Integration Approaches Fail

Custom Log Parsing

Raw log parsing requires building regex patterns against the IAM platform’s native log format. The patterns work until the log format changes, which happens with platform version updates. The maintenance overhead is ongoing. More critically, the output of raw log parsing is rarely clean enough for threshold-based detection rules: field extraction inconsistencies produce false positives at rates that make the rules operationally useless.

Manual Export Pipelines

Scheduled batch exports run on a defined interval. Hourly is common. The detection latency introduced by a one-hour export interval means that a credential stuffing attack that runs for 40 minutes and stops has exited the active attack window before the data reaches the detection layer. The SIEM fires on historical data. The attacker is gone.

Professional Services Integrations

Custom integrations built by professional services teams are accurate but brittle. When the IAM platform updates or the SIEM changes versions, the integration requires rework. Most organisations that have gone this route maintain a connector that is perpetually one version behind. The integration exists on paper. The event data it delivers is incomplete or delayed in practice.

What Credential Attacks Look Like in the IAM Authentication Event Stream

Credential Stuffing: MFA Failure Rate Across Distinct Account Identifiers

Credential stuffing uses username and password combinations from breach databases. The attacker does not know which credentials are still valid, so they attempt to authenticate across a large number of distinct account identifiers. Against an organisation with MFA enforcement, valid primary credentials are blocked at the MFA challenge. The result in the authentication event stream is a spike in MFA failures across many distinct actor identifiers within a short time window.

Each individual failure is routine. The pattern across dozens of distinct identifiers within minutes is not. A detection rule evaluating MFA failure rate across distinct account identifiers within a rolling time window fires on this pattern before any account is compromised. The rule needs the event stream.

Brute Force: Lockout Clusters on Specific Identifiers

Brute force attacks target specific account identifiers with repeated authentication attempts. Most lockout policies trigger between 5 and 10 failed attempts. The attack produces a sequence of authentication failures on a single identifier ending in a lockout event. A single lockout is routine. Multiple lockouts on distinct identifiers within a short window, or repeated lockouts on the same identifier following manual unlocks, is a brute force signal. Detection rules built on lockout event data with time-window clustering logic identify this pattern. The data needs to be in the SIEM.

Account Recovery Exploitation: Anomalous Recovery Attempt Volume

Social engineering attacks targeting recovery flows initiate recovery requests across a set of target accounts. The volume of recovery attempts across distinct identifiers in a short window is anomalous against any reasonable baseline. This signal does not appear in network logs, endpoint telemetry, or firewall data. It only exists in the IAM authentication event stream. Most SIEM deployments have no recovery attempt data from the IAM layer at all.

What the Akku MFA Failures and Lockout API Exposes

Akku’s Locked Accounts, MFA Failures and Recovery Attempts API provides a structured JSON event stream covering all three signal types. Each MFA failure event includes event_type, actor_id, timestamp (ISO 8601 with millisecond precision), mfa_method (TOTP, push, hardware_token, or FIDO2), failure_reason (wrong_code, expired_code, or method_unavailable), outcome, source_ip, geo_location, and risk_context from the adaptive MFA evaluation. Each lockout event includes actor_id, timestamp, failed attempt count, and source_ip. Each recovery attempt event includes actor_id, timestamp, recovery method, and outcome.

The API supports real-time streaming retrieval and batch polling with intervals as short as one minute. For SIEM deployments consuming streaming event data, events are available as they are written to the audit log. For polling integrations, one-minute intervals reduce detection latency to a fraction of what hourly batch exports produce.

The schema is consistent with Akku’s standard audit log field definitions, making it compatible with SIEM parsing rules already built for the Akku audit log format without requiring separate field extraction logic.

What Detection Rules This Data Enables

Credential Stuffing Detection in Splunk SPL and Microsoft Sentinel KQL

In Splunk SPL, a credential stuffing detection rule on this event stream is a standard stats count(distinct actor_id) by time_bucket query with a where clause on the count exceeding a defined threshold. In Microsoft Sentinel KQL, the equivalent is a summarize dcount(actor_id) by bin(TimeGenerated, 10m) query with a where clause on the distinct count. Both are native query constructs in their respective platforms. No custom detection logic is required. The threshold is calibrated against the normal baseline MFA failure rate in the specific environment.

Adaptive MFA Risk Context as a Detection Signal

Akku’s adaptive MFA evaluates contextual risk signals before triggering the MFA challenge: geo-location relative to the user’s baseline, IP reputation, time-of-day, and device familiarity. The outcome of this evaluation is included in the risk_context field of each event. Detection rules can weight MFA failures differently based on this context. A failure from a known device at a normal time contributes a lower risk signal than a failure from an unrecognised device at 3am from a high-risk IP. This reduces false positives from legitimate users who occasionally fail the MFA challenge while maintaining sensitivity to attack patterns.

How This Connects to the Login Metrics API

The MFA Failures and Lockout API provides event-level signal data for detection rules. Akku’s Login Metrics API provides aggregate authentication health metrics for operational monitoring: total login counts, success rates, failure rates, and 24-hour trend data. Used together, the event-level API feeds SIEM detection rules and the metrics API feeds operational dashboards and threshold alerting. The two APIs address different points in the detection and response chain. Both are needed for complete authentication visibility.

What to Check About Your Current Detection Coverage

Query your SIEM for detection rules that reference your IAM platform as a data source. Count the rules that use MFA failure data as an input. Count the rules that use account lockout event data. Count the rules that reference recovery attempt activity.

If the answer to all three is zero, the detection stack has no coverage for credential-based attacks operating at the authentication layer. For financial services organisations under RBI’s near-real-time monitoring requirements, and for ITeS and BPO organisations where client data protection obligations require active authentication anomaly monitoring, the absence of IAM event data in the SIEM is a regulatory gap as well as an operational one.

See Akku IAM Authentication Architecture | Explore Akku MFA Capabilities | Talk to the Akku Team

Questions Security Operations Teams Ask About IAM and SIEM Integration

Q: What is the specific JSON schema for the MFA Failures and Lockout API output?

A: Each event object includes event_id (unique immutable identifier), event_type (mfa.failure, account.locked, or recovery.attempted), timestamp (ISO 8601 with millisecond precision), actor_id (Akku IAM user identifier), mfa_method (TOTP, push, hardware_token, or FIDO2 for MFA failure events), failure_reason (wrong_code, expired_code, or method_unavailable for MFA failure events), outcome (failure or blocked), source_ip, geo_location, and risk_context (adaptive MFA risk signals evaluated for the authentication attempt). The schema is consistent with Akku’s standard audit log field definitions, making it compatible with SIEM parsing rules already built for the Akku audit log format.

Q: Can these detection rules be built in Splunk SPL or Microsoft Sentinel KQL without custom development?

A: Yes. In Splunk SPL, credential stuffing detection is a standard stats count(distinct actor_id) by time_bucket query with a where clause on the count. In Microsoft Sentinel KQL, the equivalent is a summarize dcount(actor_id) by bin(TimeGenerated, 10m) query. Both are native constructs. The API output is structured to avoid requiring custom field extraction. Once the API feed is configured as a data source, detection rules can be built using the SIEM platform’s native query language.

Q: How does adaptive MFA reduce false positives in credential attack detection rules?

A: Akku’s adaptive MFA evaluates geo-location relative to the user’s baseline, IP reputation, time-of-day, and device familiarity before triggering the MFA challenge. The risk_context field in each event carries this evaluation. Detection rules can use this field to weight failures by context: a failure from a known device at a normal time is weighted lower than a failure from an unrecognised device at an unusual time from a high-risk IP. This reduces false positives from legitimate users who occasionally fail the MFA challenge while maintaining detection sensitivity for attack patterns.

Q: What is the latency between an authentication event occurring and it being available through the API?

A: Events are written to the Akku audit log in near-real time. The API reflects the current audit log state with low query latency. For streaming SIEM integrations, events are available as they are written. For polling integrations, intervals as short as one minute are supported. A credential stuffing attack running for 10 minutes produces event data available in the detection stack within minutes of the first failure, rather than at the next scheduled hourly batch export.

Q: How does this integrate with SOAR platforms for automated response?

A: The structured JSON output is compatible with SOAR platform ingestion. A common automated response pattern: the SIEM detection rule fires on an MFA failure threshold breach, triggers a SOAR playbook, the playbook queries the API for additional context on flagged actor identifiers (source IPs, failure methods, geo-locations), and based on that context either automatically locks flagged accounts and notifies the security team or escalates to a human analyst. The API supports both real-time queries for individual actor identifiers and batch queries for multiple identifiers.

Q: How does the MFA Failures API differ from the login activity data in the Akku admin console?

A: The admin console provides access to the full audit log through a user interface designed for manual review. The MFA Failures and Lockout API provides a programmatic event stream designed for machine consumption: structured JSON with consistent field names, event-level granularity, and real-time or batch retrieval. The distinction is between a log interface requiring a human to navigate and interpret, and an event stream that detection rules evaluate automatically against thresholds. The underlying data is the same. The format and delivery mechanism are designed for different consumers.