Identity Logging Gaps

A retail technology vendor's identity platform generated comprehensive authentication logs , every successful login was recorded with timestamp, user, source IP, and authentication method. During an incident investigation following a customer data breach, the forensic team needed to reconstruct the attacker's access pattern. The successful authentication that preceded the breach was in the log. What the log did not capture: the sixty-eight failed authentication attempts for the same account in the preceding four hours, which would have revealed a credential stuffing attack in progress; the impossible travel alert that should have fired when the successful authentication came from Singapore forty minutes after a previous session had been active from London; the authorisation denials the attacker received when attempting to access restricted resources before finding an insufficiently restricted path; and the session token persistence that allowed the attacker's session to remain valid for eleven hours without reauthentication. The authentication log accurately recorded successful logins. The identity risk narrative , the attack in progress, the anomalies, the authorisation failures, the session management issues , was distributed across logging systems that were either not configured, not retained, or not correlated in the investigation.

What are Identity Logging Gaps, Really?

Identity logging is the comprehensive capture of all identity-related events in an environment , authentication attempts (both successful and failed), authorisation decisions (access granted and denied), session lifecycle events (session creation, extension, expiry, and termination), privileged action records (what privileged users did during privileged sessions), and anomaly signals (impossible travel, unusual access patterns, concurrent sessions from different locations). The gap arises when identity logging is scoped to successful authentication events and does not capture the broader event landscape that provides the context required for threat detection, incident investigation, and compliance demonstration.

Failed authentication logging is the most immediately consequential gap. Credential stuffing, password spraying, and brute force attacks are characterised by large numbers of failed authentication attempts before a successful one. An organisation that logs only successful authentications cannot detect these attack patterns in progress , the attack is visible only in failed attempt logs that do not exist. By the time a successful authentication appears in the log, the attack has been underway for hours or days with no detection signal. The absence of failed authentication logging does not prevent the breach; it prevents detection of the attack pattern that preceded it.

Authorisation logging , recording access denied events alongside access granted events , provides a different but equally important visibility layer. When an attacker who has successfully authenticated attempts to access resources they are not authorised for, those denial events are the map of the attacker's exploration within the environment. An attacker who receives denial after denial on high-value resources before finding an insufficiently restricted path leaves a trail that authorisation logging captures. Without authorisation logging, the investigation sees only the path the attacker succeeded in taking, not the paths they attempted and were blocked from , context that is valuable for understanding the attack scope and tightening the access controls that were in the attacker's way.

• Failed authentication events not logged , credential stuffing and brute force attacks undetectable
• Authorisation denial events not captured , attacker exploration of the access boundary invisible
• Session anomaly detection signals not logged , impossible travel and concurrent session events not captured
• Session lifecycle events not recorded , session creation, extension, and token persistence not logged
• Insufficient log retention , identity logs retained for periods shorter than breach dwell times, destroying investigation evidence

Why this matters

Identity logging gaps matter for TPRM because vendors who access customer environments need comprehensive identity logging to detect attacks against their own environments before those attacks reach customer data. A vendor who logs only successful authentications cannot detect the credential stuffing attack that is working through their user population in real time , the attack is invisible until it succeeds, at which point the attacker's initial access to vendor systems provides a pathway to customer environments.

The forensic consequence is the dimension most immediately relevant to regulatory and contractual obligations. When a vendor breach is investigated, the investigation's scope and findings depend critically on log completeness. A vendor who can reconstruct the complete attack timeline , failed attempts, successful compromise, movement through the environment, data access events , provides a comprehensive incident report. A vendor whose logs captured only successful authentications provides an incomplete picture of what happened, what data was accessed, and how long the attacker was present. The regulatory filing that describes 'unknown scope due to insufficient logging' is a direct consequence of identity logging gaps.

Where most teams get this wrong

The most consistent failure is confirming 'comprehensive authentication logging' without specifying whether failed attempts, authorisation decisions, and session anomalies are included. Successful authentication logging is a component of identity logging. Treating it as comprehensive identity logging confirms one event type while leaving the investigation context that requires multiple event types unaddressed.

• Confirming authentication logging without specifying event scope
• Failed authentication events assumed to be included , not specifically confirmed
• Authorisation events not assessed
• Log retention period not confirmed against investigation requirements
• SIEM correlation of identity events not assessed , whether logs are correlated for anomaly detection

What good looks like

Mature identity logging programs capture the full event landscape , failed and successful authentications, authorisation grants and denials, session lifecycle events, privileged action records, and anomaly signals , retained for periods sufficient to support investigation of breaches with extended dwell times, and correlated in a SIEM to enable real-time detection of attack patterns.

• Failed authentication logging , all failed attempts with account, source IP, timestamp, and failure reason
• Authorisation event logging , access granted and denied events with resource, user, and decision reason
• Session anomaly logging , impossible travel, concurrent sessions, unusual session duration
• Privileged action logging , commands, queries, and configuration changes during privileged sessions
• Log retention calibrated to dwell time , 90+ days minimum, longer for high-risk environments

Tooling

SIEM with Identity Analytics , Microsoft Sentinel, Splunk, Exabeam

SIEM platforms with identity analytics capabilities correlate the full identity event landscape , joining failed attempt logs, successful authentication events, authorisation records, and session anomaly signals into a unified detection surface. Microsoft Sentinel's UEBA component specifically correlates identity events across all log sources to detect anomalous patterns that individual log streams would not reveal. For TPRM practitioners, asking whether the vendor's SIEM correlates identity events across failed attempts, authorisation decisions, and session anomalies provides a specific identity detection capability question.

Identity Platform Logging , Microsoft Entra ID audit logs, Okta System Log, Ping Identity audit

Modern identity platforms generate comprehensive event logs when fully configured , authentication attempts, MFA events, authorisation decisions, session events, and administrative actions. The logging configuration determines which events are captured and forwarded to SIEM. For TPRM practitioners, asking what event types are captured in the vendor's identity platform logs and whether all event types are forwarded to their SIEM provides a specific log completeness question.

Governance challenges

The governance challenge with identity log completeness is the volume and cost problem. Comprehensive identity logging generates significant log volume , failed authentication attempts alone can number in the millions per day for large environments under active attack. Log storage and processing costs create pressure to scope logging to the events most frequently reviewed rather than the events most critical for investigation. The resolution is risk-tiered retention rather than uniform scope reduction: retain all event types for the minimum period required for real-time detection, retain high-value events (failed attempts, privileged actions, authorisation denials) for extended periods, and ensure that the investigation evidence that matters most has the longest retention.

• Confirm specific event types in scope , failed attempts, authorisation decisions, session anomalies
• Confirm log retention period against breach dwell time investigation requirements
• Assess SIEM correlation of identity event types for anomaly detection
• Ask about impossible travel and concurrent session detection , specific anomaly signals
• Include identity log completeness in incident response capability assessment

If you are a small team

Ask your highest-risk vendors three specific identity logging questions that go beyond authentication confirmation. First: are failed authentication attempts logged with the source IP and attempt count, and is that log forwarded to your SIEM with alerting on high-volume attempts? Second: are authorisation denial events logged , specifically, when a user is denied access to a resource, is that denial event captured? Third: what is the retention period for identity logs, and could you reconstruct a complete identity event timeline for an incident that began six months ago? Those three questions cover the failed attempt gap, the authorisation gap, and the retention gap in one conversation.

• Ask whether failed authentication attempts are logged and SIEM-correlated with alerting
• Ask whether authorisation denial events are captured
• Ask whether a six-month-old incident timeline could be reconstructed from available logs

What to require

Ask directly:

"Does your identity logging capture failed authentication attempts, authorisation denial events, and session anomalies such as impossible travel , or is your identity logging scoped primarily to successful authentication events?"

"What is the retention period for your identity event logs , specifically failed authentication attempts and authorisation records , and could you reconstruct a complete identity event timeline for an incident that began six months ago?"

Expect as evidence

• Identity log event scope documentation , event types captured
• Failed authentication logging confirmation with SIEM alerting
• Authorisation event logging confirmation
• Log retention period calibrated to investigation requirements

A vendor who confirms 'comprehensive authentication logging' should be asked specifically whether that logging includes failed attempts and authorisation denials. The successful authentication is the event that confirms access was granted. The sixty-eight failed attempts are the evidence the attack was underway. Without both, the log tells half the story.

How to evidence it

• Identity log scope documentation , event types and retention
• Failed authentication alerting confirmation
• SIEM correlation evidence for identity events
• Log retention period documentation

Key Takeaway

The successful authentication event tells you the attacker got in. The sixty-eight failed attempts before it tell you the attack was in progress for hours before anyone could have known. The impossible travel event between London and Singapore tells you the credentials were being used simultaneously from two locations. The authorisation denial events tell you what the attacker tried before finding an open path. Authentication logging without the surrounding event context is the final chapter of a story that begins chapters earlier. Comprehensive identity logging captures the full narrative , attack pattern, credential compromise, session anomalies, and authorisation boundary exploration. The investigation that needs to understand what happened requires all of it.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations