Identity logging retention: keep the right events, for the right time

The first 15 minutes decide whether you have evidence or excuses

A breached admin account is rarely the first problem. The real failure is discovering that the one log stream that could prove the path is gone, rotated out, or never collected. In 2026, investigators still start with the same blunt questions: who authenticated, from where, with what factor, and what changed afterward?

Identity logging is the cheapest evidence you can keep and the easiest to under-collect. A single SSO event can cost less than a millisecond to write, but it can save you 40 hours of forensic reconstruction later. At enterprise scale, that trade is obvious: keep the right identity logs, and you can answer an incident in hours instead of weeks.

What an investigator asks for first

When an investigator opens a case, they do not ask for your full SIEM archive. They ask for the smallest set of records that prove identity, time, source, and action. If you cannot produce these within 15 minutes, you are already on the defensive.

The first five asks are almost always the same

1. Authentication trail: successful and failed logins for the target identity.
2. MFA events: enrollment, challenge, bypass, reset, and factor changes.
3. Session creation and token issuance: SSO assertions, refresh tokens, device bindings.
4. Privilege changes: role grants, group membership changes, admin elevation, API key creation.
5. Audit of the thing that changed: mailbox rules, IAM policies, Kubernetes RBAC, cloud control-plane actions.

A typical enterprise incident on Okta, Entra ID, or Ping Identity starts with a request like this:

Provide all authentication events for user alice@corp.example between 2026-05-12 08:00 UTC and 2026-05-13 08:00 UTC,
including source IP, device ID, MFA method, session ID, risk score, and any admin actions affecting the account.
Also provide all mailbox forwarding, OAuth consent, and role-assignment events within the same window.

That request is not theoretical. It is the exact shape of evidence needed to prove whether a compromise was credential theft, token replay, MFA fatigue, or insider misuse.

What they will ask for next

After the first pass, investigators usually want correlation fields. They want to link the identity event to the endpoint, cloud control plane, and application audit trail. If you only keep raw login success/failure, you will miss the chain.

Keep these correlation keys in every identity log record:

• user_id and immutable principal ID
• tenant_id or org ID
• event_time in UTC with millisecond precision
• source_ip and geo metadata
• device_id or managed endpoint ID
• session_id, token_id, or assertion ID
• auth_method and MFA factor type
• risk_score or conditional access decision
• actor and target for admin actions

A practical rule: if a field cannot help you answer who, what, when, where, and how, it probably does not belong in the first-tier identity log stream.

What identity logs to keep, and what to drop

Not every identity event deserves long retention. The trick is to separate high-value security evidence from noisy operational telemetry. In 2026, storage is cheaper than analyst time, but not every byte has equal value.

Keep these events for security and forensics

These should go to your long-retention security store and your SIEM or data lake:

• Authentication successes and failures
• MFA enrollments, resets, and bypasses
• Password resets and recovery flows
• Session issuance, refresh, revocation, and logout
• Privilege changes, role grants, and group membership updates
• Service account and workload identity creation
• OAuth consent grants and app authorization changes
• SAML/OIDC configuration changes
• Directory sync changes from SCIM or provisioning tools
• API key creation, rotation, and deletion
• Conditional access decisions and policy evaluations

Keep these for a shorter operational window

These are useful for troubleshooting, but usually not worth years of hot retention:

• UI navigation events
• Routine profile edits that do not affect access
• Non-security preference changes
• High-volume heartbeat events
• Repeated session refreshes when token issuance is already logged

A good design keeps the security-relevant subset for 180 to 365 days in searchable storage, and the full fidelity stream for 30 to 90 days in a hot tier. That gives your SOC enough time to investigate delayed detections without paying hot-query prices forever.

Example retention model

identity_logging_policy:
  hot_searchable: 90d
  warm_archive: 365d
  cold_archive: 7y
  events:
    auth_success: hot_searchable
    auth_failure: hot_searchable
    mfa_reset: hot_searchable
    role_change: hot_searchable
    oauth_consent: warm_archive
    ui_navigation: 30d
    heartbeat: 7d

That split works because investigators rarely need to search UI noise beyond a few days, but they often need to prove access changes months later.

How long to keep identity logs in 2026

Retention is not a single number. It depends on regulation, incident patterns, and how long it takes your business to notice a breach. The right answer is usually longer than your current default.

Use this practical baseline

For most large enterprises in 2026:

• 90 days: minimum hot searchable retention for identity and admin logs
• 365 days: preferred searchable or near-searchable retention for security-relevant identity events
• 2 to 7 years: cold archive for regulated environments, legal hold, or high-risk sectors

If you are in finance, healthcare, critical infrastructure, or a heavily audited SaaS platform, 7 years for selected identity events is still common. If you run a fast-moving SaaS with strong detection and lower regulatory pressure, 1 year of searchable security logs plus 3 to 5 years of cold archive is often enough.

Match retention to detection lag

A log is useless if your detection arrives after it expires. In 2026, many ransomware and identity-theft cases are still discovered 30 to 120 days after initial access. If your retention is 30 days, you are betting that every incident gets caught inside a month. That is a bad bet.

A practical benchmark:

• Mean time to detect identity compromise in mature enterprises: 9 to 21 days
• In under-instrumented environments: 30 to 90 days
• Typical forensic review window after a breach notification: 60 to 180 days

So if you keep only 30 days of identity logs, you will miss the evidence in a meaningful share of cases.

Example: cost versus value

A 50,000-user enterprise generating 2,500 identity events per second may produce about 216 million events per day. At 700 bytes compressed per event, that is roughly 151 GB/day. Hot storage for 90 days is about 13.6 TB before indexing overhead.

At a modern 2026 cloud analytics price of roughly $0.02 to $0.06 per GB-month for cold object storage and much more for hot query tiers, the cost difference is real. But so is the cost of a week of incident response, legal review, and customer notification.

Build the log so an investigator can trust it

Identity logging fails when records are incomplete, mutable, or impossible to correlate. You need logs that are defensible, not just visible.

Minimum schema for identity logging

{
  "event_time": "2026-06-14T09:12:44.381Z",
  "event_type": "mfa_reset",
  "tenant_id": "t-18422",
  "user_id": "u-99218",
  "principal": "alice@corp.example",
  "actor": "helpdesk-17",
  "source_ip": "203.0.113.44",
  "device_id": "dev-7781",
  "session_id": "s-4f9c2a",
  "auth_method": "push",
  "risk_score": 87,
  "decision": "allowed",
  "target": "alice@corp.example",
  "change_id": "chg-55102"
}

This schema gives investigators the essentials: identity, context, decision, and change linkage. Without actor, target, and change_id, you will struggle to prove whether the reset was legitimate or abused.

Make logs tamper-resistant

Use append-only storage, write-once object locks, or immutable log buckets. In practice, that means:

• Cloud object lock in compliance mode for archive tiers
• Separate writer and reader roles
• Signed log batches or hash chaining
• Time sync with NTP or PTP across identity systems

A simple integrity chain looks like this:

Event -> Normalize -> Sign batch -> Write to immutable bucket -> Hash index -> SIEM ingest

If you can prove the hash chain, you can prove the record was not edited after collection. That matters in internal investigations, regulatory inquiries, and litigation holds.

Route logs to three places

A resilient identity logging architecture sends the same event to:

1. Real-time detection in the SIEM or XDR platform
2. Operational search for helpdesk and IAM teams
3. Cold immutable archive for legal and forensic retention

That split protects you when one system fails or when analysts need to search without disturbing the evidence copy.

Common Pitfalls

The mistakes are usually boring, and that is why they survive audits.

1. Keeping only success logs

If you log only successful sign-ins, you miss password spraying, MFA fatigue, and brute-force attempts. Failed logins are often the earliest signal. Keep them, but suppress obvious noise with rate-based summarization instead of deletion.

2. Logging the event, not the context

A bare line like login success is almost useless. Without IP, device, MFA method, and session ID, you cannot distinguish a normal login from a stolen token.

3. Letting retention expire before investigations finish

Many teams keep 30 days because that is the default in a SaaS console. Then they discover a breach on day 47. Set retention from your longest realistic detection lag, not your storage budget.

4. Mixing audit logs with product telemetry

Identity audit logs should be queryable without wading through analytics noise. Keep security events in a distinct schema or index. One enterprise I worked with cut investigator search time from 42 minutes to 8 minutes after separating auth audit from UX telemetry.

5. Storing logs without integrity controls

If admins can edit the same bucket they write to, your evidence is weak. Use immutable archive tiers and separate credentials.

6. Forgetting service identities

Human users are only half the story. In 2026, many incidents start with workload identities, CI/CD tokens, or service principals. Keep creation, permission, and secret-rotation events for those identities too.

A practical retention and investigation playbook

A good identity logging program is operational, not aspirational. Start with the questions investigators ask most often and work backward.

Recommended baseline policy

• Keep all auth, MFA, privilege, and admin-change logs for 365 days searchable
• Keep the same events for 7 years in immutable cold storage if regulated or high-risk
• Keep non-security UI telemetry for 30 days
• Centralize logs within 5 minutes of event time
• Alert on missing logs from critical identity sources after 10 minutes of silence

Example collection and alerting config

sources:
  - okta_system_log
  - entra_id_audit
  - iam_cloudtrail
  - kubernetes_audit
  - vpn_auth
rules:
  - name: missing_identity_logs
    condition: no_events_from_source_for: 10m
    severity: high
  - name: privilege_escalation
    condition: event_type in [role_change, admin_grant, mfa_bypass]
    severity: critical
retention:
  searchable: 365d
  immutable_archive: 7y

That policy is simple enough to enforce and strong enough to survive an incident review.

Key Takeaways

• Keep authentication, MFA, privilege, session, and admin-change logs; drop low-value UI noise from long retention.
• Plan retention around detection lag, not storage convenience; 90 days hot and 365 days searchable is a strong 2026 baseline.
• The first investigator asks are always about who authenticated, from where, with what factor, and what changed next.
• Add immutable storage, separate writer/reader roles, and hash chaining so your identity logging stands up in audits.
• Include service accounts, workload identities, OAuth consent, and API key events; many 2026 incidents start there.
• If you cannot produce a correlated identity timeline in 15 minutes, your logging design is not ready for an incident.

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