Log every authentication success and failure, authorization denial, session anomaly, credential change and privileged action, with a stable actor ID, outcome, source and timestamp. Leave out passwords, tokens and session identifiers. This is the core evidence set for spotting account takeover and for reconstructing what an attacker did.
Why authentication first
If you can log only one family of events, pick this one. Most intrusions touch identity at some point: guessing, stuffing, stolen sessions, new devices, new keys. OWASP lists authentication successes and failures, authorization failures and session management failures among the events to log where possible.
The checklist
Sign in
- Successful and failed password attempts, with a failure reason code.
- Second factor challenge issued, passed, failed or skipped.
- Sign in from a new device, location or client type.
- Account lockout and unlock.
Session
- Session creation, renewal and termination.
- Session identifier tampering or reuse after logout. OWASP names cookie session identifier modification as a session management failure to record.
- Logout, and forced logout by an administrator.
Credential and recovery
- Password change and reset requests, with the channel used.
- Second factor enrolled, changed or removed.
- Recovery codes generated or used.
- API key, token or service credential created, rotated or revoked.
Authorization
- Access control denials, with the resource and the permission needed.
- Role or permission grants and removals.
- Use of shared or default accounts, which OWASP flags as a higher risk function.
Privileged activity
- User administration actions.
- Configuration changes to security settings.
- Access to sensitive data, and key use or rotation.
Fields for each event
Actor ID, target, action, outcome, reason, source IP, client information, request ID and UTC timestamp. See the fields security events need.
Exclusions
Per the OWASP cheat sheet, remove, mask, hash or encrypt passwords, access tokens, session identifiers and keys before logging. Never log a failed password attempt's submitted value. A user who types the password into the username box is more common than you would hope.
Do not reveal too much to the client
Log the precise failure reason internally, but return a generic message to the user. "Invalid credentials" in the response, unknown_user or bad_password in the log.
Turning the log into signals
Once the events exist, a few simple rules go a long way, as covered in five first detections from logs:
- Many failures across many accounts from one source.
- Many failures for one account from many sources.
- A success right after a burst of failures.
- A new second factor device added shortly after a password reset.
A caution on volume
OWASP warns about "alarm fog" when a checklist is applied blindly. Failed logins at normal rates are noise. Log them all, but alert on patterns.
Quick check
Should I log successful logins as well as failures?
Yes. Failures show attacks. Successes show what an attacker did after guessing right, and they are essential for building a timeline.
Do I log the username a person typed?
Be careful. It can be a mistyped password. Log it only if needed, and treat the field as untrusted, as covered in the log injection post.
Sources
Last reviewed: 19 October 2026.
