I4.3 Authentication Logs
Learn how defenders review fictional sign-ins, failures, lockouts, MFA challenges, password changes, sessions, source context, and identity patterns without treating one event as proof of intent.
Lesson Progress
Authentication Logs
High School Intermediate • I4: Logs and Event Monitoring • Lesson 3 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Failed Sign-In Is an Event, Not an Accusation
Authentication failures can come from mistyped passwords, stale saved credentials, expired secrets, disabled accounts, policy blocks, service retries, travel, unsupported clients, or suspicious activity. Defenders compare the full workflow before deciding what the pattern means.
Weak response
“There were five failures, so the account is compromised.”
Strong response
“Preserve the failures, check reason codes, device, source, application, MFA, account changes, owner context, and later sessions before assigning cause.”
Objective 1
Explain what authentication logs record and how sign-in, session, MFA, password, lockout, and account-change events fit together.
Objective 2
Interpret fictional authentication results using account, source, device, application, reason code, MFA state, session, and expected-use context.
Objective 3
Distinguish normal failures, stale credentials, mistyped passwords, service retries, travel, approved support activity, and review-required patterns.
Objective 4
Separate what authentication evidence directly proves from what still requires endpoint, application, network, change, owner, or user context.
Objective 5
Build a professional fictional Authentication Review Report with facts, conclusions, alternate explanations, gaps, confidence, and safe next actions.
Why This Matters
Identity Evidence Connects Accounts, Devices, Applications, Policies, and Sessions
Authentication logs help defenders understand who or what claimed an identity, where the attempt originated, which application requested access, what policy applied, whether MFA completed, and whether a session was created. No single field tells the whole story.
Authentication Event Types
Read the Full Identity Workflow
Successful sign-in
Common records
Account, time, source, device, application, authentication method, result, session, and policy outcome.
Defender questions
Was the account expected, was the device recognized, did MFA complete, and did the application session match normal activity?
Limitation
A successful sign-in proves the workflow completed, not that the physical user or purpose is known with certainty.
Failed sign-in
Common records
Account, time, source, device, application, failure reason, attempt count, and policy response.
Defender questions
Was the password mistyped, stale, expired, disabled, locked, reused by a service, or submitted from an unusual source?
Limitation
A failure does not automatically prove attack activity or compromise.
MFA challenge
Common records
Challenge issued, factor type, approval or denial, device, source, time, and session relationship.
Defender questions
Did the challenge follow an expected sign-in, was it approved, denied, timed out, repeated, or reported as unexpected?
Limitation
Approval supports the sign-in sequence but does not identify the physical person with absolute certainty.
Account lockout
Common records
Account, threshold, time, source pattern, duration, unlock action, and related failures.
Defender questions
Did failures come from one device, many devices, a service, a saved credential, or an approved test?
Limitation
The lockout confirms a control response, not the cause of the failures.
Password reset or change
Common records
Account, requester, approver, method, time, source, ticket, and completion state.
Defender questions
Was the change expected, approved, verified, and followed by successful use from the normal device?
Limitation
A ticket or reset record does not prove every later authentication event is legitimate.
Session creation or termination
Common records
Account, application, device, source, token or session identifier, start, end, expiration, and revocation.
Defender questions
Did the session follow expected authentication, remain active too long, end normally, or continue after an account change?
Limitation
Session evidence may not show every action performed within the session.
Privilege or group change
Common records
Account, group, role, administrator, time, source, approval, and result.
Defender questions
Was the change approved, role-appropriate, temporary, reviewed, and removed when no longer needed?
Limitation
The event confirms the recorded change, not whether the resulting access was used.
Service or application authentication
Common records
Service identity, application, device, credential source, result, retry count, schedule, and dependency.
Defender questions
Is the identity approved, owned, scoped, scheduled, and using current credentials?
Limitation
Repeated retries may reflect a stale secret or dependency rather than a human sign-in pattern.
Core Concept
Authentication Is a Sequence, Not a Single Record
A complete review may include password changes, sign-in attempts, MFA challenges, device checks, policy decisions, session creation, application access, session refresh, and termination. Defenders connect those records before writing a conclusion.
Claim
Which account or service identity requested access?
Verify
Which password, key, token, certificate, or MFA factor was checked?
Decide
Which policy allowed, blocked, or challenged the request?
Create
Was a session or token created successfully?
Monitor
What later session, application, endpoint, or change evidence followed?
Authentication Event Anatomy
Ten Fields That Shape Sign-In Meaning
Account
The user, administrator, service identity, guest, shared, or temporary account involved.
Defender use
Compare status, owner, role, privilege, groups, expiration, and expected applications.
Caution
The account label does not prove the physical person or complete purpose.
Result
Success, failure, challenge, denial, lockout, expiration, timeout, or partial completion.
Defender use
Separate attempted sign-in from completed authentication and from session creation.
Caution
Success is not automatically approved, and failure is not automatically malicious.
Reason
The source-defined explanation such as bad password, expired credential, disabled account, policy block, or MFA failure.
Defender use
Narrow the likely cause and identify the next evidence source.
Caution
Reason codes may be broad, source-specific, or incomplete.
Source
The fictional address, device, network, location, application, or service where the attempt originated.
Defender use
Compare the attempt with expected devices, networks, applications, travel, and schedules.
Caution
Source data can be shared, translated, proxied, delayed, or mapped imprecisely.
Device
The workstation, phone, server, browser, client, or managed endpoint associated with the attempt.
Defender use
Connect sign-in records with device ownership, health, history, and endpoint evidence.
Caution
A device name may be reused, stale, missing, or inferred by the platform.
Application
The service, portal, client, mail application, VPN, cloud resource, or business system requesting authentication.
Defender use
Identify which workflow produced the event and whether the application was expected.
Caution
One account may authenticate to several linked applications through a shared identity system.
MFA state
Challenge issued, factor type, approval, denial, timeout, bypass, or unavailable state.
Defender use
Understand whether additional verification was requested and completed.
Caution
A successful primary sign-in may not mean MFA was required for that exact workflow.
Session identifier
A value connecting authentication, token, application, and session events.
Defender use
Correlate the sign-in with later session creation, access, refresh, termination, or revocation.
Caution
Not every platform exposes the same identifier across all records.
Time
Event, collection, ingestion, and review timestamps associated with the authentication workflow.
Defender use
Build the sequence and compare failures, resets, MFA, sessions, and later activity.
Caution
Time zones, drift, precision, and collection delay can affect order.
Policy outcome
Allow, block, require MFA, require compliant device, require trusted network, or other access decision.
Defender use
Explain why the same password may succeed in one context and fail in another.
Caution
Policy labels need rule, scope, exception, owner, and configuration context.
Pattern Analysis
Expected and Suspicious Patterns Need Context
One or two failed sign-ins from the usual device
Possible expected context
Mistyped password, keyboard layout issue, recent reset, expired credential, or temporary connectivity problem.
Review signals
Repeated continuation, later success from a different device, lockout, unusual application, or no owner explanation.
Strong response
Correlate device, reason code, password-change history, MFA, support report, and later success.
Many failures from one application after a password reset
Possible expected context
Old stored credential in mail, sync, backup, task, service, or mobile application.
Review signals
Failures continue after credential update, source changes, many accounts affected, or service ownership is unknown.
Strong response
Identify the application or service, update the approved secret, validate recovery, and monitor for recurrence.
One account from many sources
Possible expected context
Multiple managed devices, VPN, mobile network, shared service infrastructure, or approved remote work.
Review signals
Rapid source changes, unfamiliar devices, failed MFA, unusual applications, or privilege-sensitive activity.
Strong response
Compare device inventory, travel, VPN, application, session, owner, and endpoint evidence.
Many accounts from one source
Possible expected context
Shared portal, proxy, VPN gateway, application server, identity broker, or classroom lab system.
Review signals
High failure rate, disabled accounts, unusual timing, no approved service, or policy blocks.
Strong response
Identify the shared infrastructure, application owner, request pattern, reason codes, and expected account population.
Repeated MFA denials
Possible expected context
User confusion, duplicate prompts, poor connectivity, old session, or an application retry.
Review signals
Unexpected prompts, many accounts, new device, password reset, successful sign-in without owner confirmation, or later privilege change.
Strong response
Preserve challenge, sign-in, device, source, session, owner report, and policy evidence; follow approved escalation.
Sign-in outside normal hours
Possible expected context
Travel, deadline work, scheduled job, support, maintenance, backup, or different time zone.
Review signals
Privileged account, unusual device, sensitive application, repeated failures, no change record, or impossible sequence.
Strong response
Add user role, schedule, travel, device, application, privilege, owner, and maintenance context.
Successful sign-in after many failures
Possible expected context
Correct password entered after mistakes, stale credential fixed, account unlocked, or service secret updated.
Review signals
Different source or device, failed MFA, immediate account changes, new session, or sensitive access.
Strong response
Compare the successful event with the preceding failures, source, device, MFA, password history, and session activity.
Service account authenticates interactively
Possible expected context
Approved administrative test or support validation.
Review signals
No ticket, unknown owner, broad privilege, new device, unusual time, or repeated interactive use.
Strong response
Verify ownership, approved purpose, allowed sign-in type, privilege, application dependency, and account policy.
Evidence Matrix
What Authentication Evidence Can and Cannot Prove
Evidence source
Authentication event
Can support
Account, source, device, application, method, result, reason, policy, and time recorded by the identity system.
Limitation
Does not prove the physical person, full intent, endpoint state, or every action after sign-in.
Evidence source
MFA event
Can support
Challenge type, approval, denial, timeout, device, time, and relationship to a sign-in.
Limitation
Approval does not guarantee that the user understood the request or that every session action was approved.
Evidence source
Endpoint record
Can support
Device health, user session, application process, local sign-in, browser, and protection context.
Limitation
May be delayed, incomplete, unavailable, or limited to the managed endpoint.
Evidence source
Application session log
Can support
Session creation, token use, application access, request, expiration, and termination.
Limitation
May not show the original password event or every linked identity-system decision.
Evidence source
Password or account-change record
Can support
Approved reset, credential change, disablement, unlock, group change, owner, and ticket context.
Limitation
Does not prove all later activity was expected or that stale credentials were updated everywhere.
Evidence source
Network or VPN record
Can support
Connection source, gateway, remote-access session, device, duration, and network context.
Limitation
Shared gateways, translation, proxies, and mobile networks can hide the original source.
Evidence source
User or owner report
Can support
Expected activity, travel, device use, observed prompts, password change, business need, and impact.
Limitation
Reports may be incomplete, approximate, delayed, or mistaken.
Evidence source
Support or change ticket
Can support
Authorization, owner, reason, maintenance window, expected workflow, test, and validation.
Limitation
Documentation may not match the exact technical sequence.
Defensive Workflow
Review Authentication in Six Steps
Define the identity question
Identify the fictional account, application, device, time window, owner, privilege, and review objective.
Preserve authentication evidence
Capture event time, account, source, device, application, result, reason, MFA, session, and policy outcome.
Normalize and sequence
Align time zones, offsets, precision, collection delay, and event order across authentication, MFA, application, and endpoint sources.
Add identity context
Compare account status, role, privilege, groups, owner, expected devices, schedule, travel, and application use.
Correlate related sources
Connect password changes, lockouts, MFA, sessions, endpoint records, network activity, tickets, and user reports.
Document and escalate safely
Separate facts, conclusions, alternate explanations, gaps, confidence, impact, owner, and authorized next action.
Correlated Authentication Timeline
Combine Identity, Application, MFA, Support, and Change Evidence
07:55:00
Change ticket
Approved password reset begins for training-user-31
Provides authorized owner and change context before the authentication events.
07:57:14
Identity
Password reset completed successfully
Confirms the identity platform recorded the credential change.
07:58:03
Authentication
Failed sign-in from training-laptop-31
Shows one unsuccessful attempt from the user's expected device.
07:58:06
Mail application
Stored credential rejected
Adds application evidence that can explain the authentication failure.
07:58:21
Authentication
Second failed sign-in from the same device and application
Supports an automatic retry pattern but still requires context.
07:59:02
Support
User reports mail password was not updated
Provides human context matching the application evidence.
07:59:27
Mail application
Stored credential updated
Shows the application configuration changed before successful authentication.
07:59:31
Authentication
Successful sign-in from training-laptop-31
Confirms the expected device authenticated after the stored credential changed.
07:59:35
MFA
Approved challenge completed
Corroborates the successful sign-in workflow with a second control.
08:10:00
Monitoring
No additional failures observed
Supports the stale-credential explanation and confirms the pattern stopped.
Key Vocabulary
Authentication Review Terms
Authentication
The process of verifying a claimed identity before access is granted.
Authorization
The decision about what an authenticated identity is allowed to access or do.
Sign-in success
A record that the authentication workflow completed successfully under the shown conditions.
Sign-in failure
A record that an authentication attempt did not complete successfully.
MFA
A second or additional verification factor used with the primary sign-in method.
Session
An authenticated period of activity associated with an account, device, application, or service.
Lockout
A control that temporarily blocks authentication after defined failed-attempt conditions.
Reason code
A source-defined value that explains why authentication succeeded, failed, or was challenged.
Source context
The fictional device, address, location, application, network, or service associated with the attempt.
Service identity
A nonhuman account used by an application, service, task, or automated process.
Password reset
An approved process that replaces or recovers an account credential.
Impossible travel
A monitoring pattern where sign-ins appear too far apart geographically to be explained by normal travel timing.
Fake Dashboard
Fake Authentication Review Dashboard
Training dashboard for the fictional Northstar Learning Services identity environment.
Successful sign-ins
128
Most match approved users, devices, applications, MFA, and normal schedules.
Failed sign-ins
23
Fourteen are linked to stale credentials, five to mistyped passwords, and four remain under review.
MFA denials
3
Two were user-reported accidental prompts and one requires additional session and device evidence.
Fake SOC Alert
Repeated Failures Follow an Approved Password Reset
Source: Fake Identity Monitoring Platform • Time: 08:12 AM
Fake Log Panel
Fake Authentication Timeline
07:55:00 CHANGE account='training-user-31' action='password_reset_started' approved='true' 07:57:14 IDENTITY account='training-user-31' action='password_reset_completed' result='success' 07:58:03 AUTH account='training-user-31' device='training-laptop-31' result='failed' 07:58:06 APPLICATION name='mail-client' result='stored_credential_rejected' 07:58:21 AUTH account='training-user-31' device='training-laptop-31' result='failed' 07:59:02 SUPPORT report='mail_password_not_updated' 07:59:27 APPLICATION name='mail-client' action='stored_credential_updated' 07:59:31 AUTH account='training-user-31' device='training-laptop-31' result='success' 07:59:35 MFA account='training-user-31' result='approved' 08:10:00 MONITOR account='training-user-31' additional_failures='0'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
What Is the Strongest Authentication Conclusion?
Which conclusion is best supported?
Common Mistakes
Mistakes That Weaken Authentication Analysis
Safe Practice Lab
Review a Fictional Authentication Pattern
Fictional Environment
Meadowbrook Identity Review
Review eighteen fictional records involving one user account, one service identity, two managed devices, one mail client, one cloud application, MFA, a password reset, a lockout, and a support ticket.
Required Analysis
- Preserve every original authentication record.
- Normalize time and order the events.
- Identify account, source, device, application, reason, MFA, session, and policy fields.
- Separate user and service-account activity.
- Compare expected devices, schedules, applications, and password-change context.
- Write confirmed facts, likely explanations, alternates, gaps, confidence, and impact.
- Recommend a safe owner and authorized next action.
Scenario Decision Lab
Unexpected MFA Prompts Are Reported
A fictional user reports three MFA prompts they did not expect. The authentication platform shows failed primary sign-ins from a new source, and no successful session is recorded.
Scenario Decision Lab
A Service Account Produces Repeated Failures
A fictional backup service account produces a failed sign-in every five minutes after an approved password rotation. The failures stop when the service owner updates the stored secret, and the next scheduled backup succeeds.
Defender Habits
Authentication Logs Checklist
Check Your Understanding
I4.3 Mini Quiz: Authentication Logs
Choose your answers first. Explanations appear only after submission.
1. What does a successful sign-in directly prove?
2. What is a common expected cause of failures immediately after a password reset?
3. Why should MFA events be reviewed with authentication events?
4. What does an account lockout prove?
5. Why can one account appear from many source addresses?
6. What is the strongest response to repeated unexpected MFA denials?
7. Which source best helps explain whether failures came from a saved mail password?
Portfolio Prompt
Portfolio Prompt
Create a fictional Authentication Review Report containing at least twenty events across authentication, MFA, application, endpoint, network, password-change, session, and support sources. Include account type, source, device, application, result, reason, policy, session, normalized time, expected-use context, confirmed facts, likely explanations, alternate explanations, evidence gaps, confidence, impact, owner, and safe next action.
Key Takeaways
What You Should Remember
Navigation