Identity Telemetry Requirements: Minimum Logs to Keep

Most identity investigations stall not for lack of analysts but for lack of logs: the sign-in that started it aged out after seven days, the service principal's activity was never collected, or the cloud call shows a role but not the person or workload behind it. Identity telemetry is the set of authentication, authorisation, credential lifecycle and privileged activity records that let you answer who or what acted, with which credential, from where, and what changed. This guide defines a minimum set for investigations covering both people and non-human identities: the fields every event needs, the sources and event types to collect, default retention traps by platform, correlation keys, and how to measure coverage. It is for SOC, detection engineering and identity teams who want to find blind spots before an incident rather than during one. For turning identity findings into intelligence, see the Threat Intelligence for Identity and NHI Guide; this page is about the raw material underneath.

Key takeaways

Define the questions first. Every identity log must help answer five questions: which identity, which credential, from where, what it did, and what it changed. If a source cannot answer one of them, record that as a known gap.
Defaults are shorter than investigations. Entra ID keeps sign-in and audit logs for 7 days on the free tier and 30 days on P1 and P2, CloudTrail event history keeps 90 days of management events, and retention upgrades are not retroactive.
Non-human identities log differently. Service principal and managed identity sign-ins sit in separate Entra logs, AWS role sessions name a role rather than a person unless sourceIdentity is required, and Google Cloud may redact the caller IP of internal callers.
Some of the most useful logs are off by default. Google Cloud Data Access audit logs, AWS data events and Microsoft Graph activity logs all need explicit enablement or archiving before they exist.
Measure coverage, not volume. Track the share of identity providers, clouds, SaaS platforms and secrets stores whose identity events reach the SIEM with the minimum fields and at least 12 months of retention.

The five investigative questions

Identity incidents follow a familiar arc: a credential is obtained (phished, sprayed, leaked, stolen from an infostealer log or a CI system), used to authenticate, used to act, and then used to persist. Investigators reconstruct that arc from logs, and each stage needs a different record.

Question	Evidence that answers it	Typical gap
Which identity acted?	User ID or UPN, service principal or app ID, role ARN plus session name, service account email	Shared accounts; role sessions with meaningless session names
With which credential?	Authentication method, credential or key ID, token type, MFA result	Logs that record the account but not which of its secrets or keys was used
From where?	Source IP, ASN, device ID, user agent, location, network or private endpoint	Redacted or proxy IPs; no device identity for workloads
What did it do?	API calls, resources read, data access events, mailbox and file access	Data access logging disabled or licence-gated
What did it change?	Credential additions, role assignments, consent grants, federation and policy changes, new accounts	Changes made in a tenant or account outside the logging scope

These questions map directly to NIST SP 800-53 AU-3 Content of Audit Records, which requires records to establish what type of event occurred, when, where, the source, the outcome, and the identity of any individuals, subjects or entities involved.

Minimum fields for every identity event

OMB memorandum M-21-31, the US federal logging maturity model, lists minimum logging data for each event where applicable: an accurate timestamp, status code, device identifier, session or transaction ID, autonomous system number, source and destination IPv4 and IPv6 addresses, response time, additional headers, username or user ID, command executed, key-value pairs and a unique event identifier. It specifies UTC timestamps with millisecond precision. Applied to identity events, that becomes:

Field	Why investigators need it	Identity-specific notes
Timestamp (UTC, milliseconds)	Ordering events across systems	Normalise at ingest; record both event time and ingest time
Actor identifier and actor type	Who acted, and whether it was a person, workload, service or delegate	Keep immutable IDs (object ID, principal ID) as well as display names
Credential or key identifier	Which secret, certificate, key or token was used	Essential for NHIs with several credentials; scope a leak to one key
Authentication method and result	Password, MFA factor, certificate, federated token, client secret	Include failure reasons, not only success
Session or correlation ID	Linking sign-in to the actions that followed	The single most important join key in identity investigations
Source network and device	Locating the actor and spotting proxies	Capture ASN; note redaction rules per platform
Target resource and action	What was accessed or changed	Application, API, role, mailbox, secret path
Outcome and status code	Distinguishing attempts from successes	Denied actions are often the earliest signal
Delegation chain	The human or workload behind an assumed role or on-behalf-of call	For AI agents, the user the agent acted for and the tool it used

Minimum log sources and their defaults

The table lists the identity sources most investigations need, the events that matter, and the default retention or enablement trap to fix before an incident.

Source	Must-collect identity events	Default or trap
Microsoft Entra ID	Interactive, non-interactive, service principal and managed identity sign-ins; audit log (role assignments, app and credential changes, consents, federation)	7 days on Free, 30 days on P1/P2; risky sign-ins 90 days on P2; Microsoft Graph activity logs need P1/P2 and are not retained unless sent to storage or analytics
Active Directory domain controllers	4624, 4625, 4648, 4672 logons; 4768, 4769, 4771 Kerberos; 4776 credential validation; 4720, 4724, 4738, 4740 account changes; 4728, 4732, 4756 group additions; 4662, 5136 directory object changes	Local event log sizes roll over quickly; advanced audit policy must be configured
Okta	System Log: sign-ins, factor changes, admin actions, policy edits, API token use, OAuth activity	90 days in the System Log; streams are best effort (see the Okta System Log Detection Guide)
AWS	CloudTrail management events (IAM, STS, Identity Center), data events for sensitive stores	Event history: 90 days, management events only, per Region; trails or CloudTrail Lake needed for longer retention, data events and organisation-wide coverage
Google Cloud	Admin Activity and System Event logs; Data Access logs for IAM, Secret Manager and data services	Data Access logs disabled by default except BigQuery; `_Required` bucket 400 days, `_Default` 30 days
Microsoft 365	Unified Audit Log including mailbox access events	Retention managed in Microsoft Purview, separate from Entra licensing
GitHub	Organisation and enterprise audit log, token and app events	180 days, three months shown by default; stream to external storage for longer (see the GitHub Audit Log Detection Guide)
Secrets managers and PAM	Secret reads, check-outs, token creation, policy changes	Often not forwarded at all; see Secrets Access Logging and Detection
Kubernetes	API server audit events for service account tokens, RBAC changes, secrets reads	Audit policy must be configured; managed services need it enabled
Critical SaaS	Admin, API token, OAuth app and integration events	Retention and API access frequently depend on the licence tier

One rule cuts across all of them: retention upgrades do not bring back expired data. Microsoft states that moving from Entra ID Free to P1 or P2 only shows data still inside the 7-day free window. The same is true of enabling Google Cloud Data Access logs or AWS data events after the fact. The Log Source Coverage Matrix Template is a good place to record each source's status.

Telemetry for non-human identities

Service accounts, workload identities, API keys and AI agents generate most identity events in a modern estate, and they break assumptions built for people.

Entra workload identities: service principal sign-ins (authentication with a certificate or client secret, such as the client credentials flow) appear in their own log, grouped by service principal, status, IP and resource. Managed identity sign-ins are excluded from it and appear only in the managed identity sign-in log. Collect both; legacy sign-in views show interactive user sign-ins only.
AWS role sessions: for AssumedRole events the person is not named. CloudTrail's sessionContext.sourceIdentity carries the original identity, but only when administrators require it in STS; otherwise attribution relies on the session name in principalId and the sessionIssuer. accessKeyId may be absent, so do not rely on it alone, and invokedBy marks actions taken by AWS services.
Google Cloud service accounts: the caller identity sits in AuthenticationInfo, while RequestMetadata.callerIp may read "private" for internal Google service calls or "gce-internal-ip" for VMs in other projects, so network attribution needs VPC flow logs.
API keys and tokens: many SaaS audit logs record the token's name or ID only if you named it meaningfully; enforce naming that includes owner and purpose.
AI agents: record the agent identity, the human it acted for, the tool or MCP server called and the downstream credential used, so that one action can be traced end to end. The Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs guide covers the method.

The NHI-specific events that most often reveal compromise are credential additions to existing applications, new consent grants, new role assignments to workloads, and first use of a dormant credential. An NHI inventory is the denominator for coverage: see NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments and NHI Dormancy Detection.

Retention, integrity and time

Retention baseline: M-21-31 sets minimums of 12 months in active storage and 18 months in cold storage for its highest-criticality categories, which include identity and credential management and privileged identity management logs. Commercial organisations can use this as a defensible benchmark; intrusions are frequently discovered months after initial access.
Integrity: store copies outside the tenant or account an attacker may control, with write-once or locked buckets, and restrict who can change diagnostic settings, trails and sinks (NIST SP 800-53 AU-9 Protection of Audit Information).
Time: normalise to UTC and synchronise sources (AU-8 Time Stamps). A five-minute skew between an identity provider and a cloud log is enough to misorder a token theft and its first use.
Scope: include non-production tenants, test accounts and acquired environments. Attackers choose them precisely because logging there is weaker.

The Log Management and Retention Guide covers storage tiers and cost.

Correlation keys that join the story

Join	Key	Where it appears
Sign-in to subsequent activity	Session or correlation ID; AWS `signInSessionArn`	Identity provider sign-in logs, CloudTrail `sessionContext`
Federated user to cloud role	`sourceIdentity`, role session name, SAML or OIDC subject	STS events, CloudTrail, cloud audit logs
Workload to credential	Key ID, certificate thumbprint, client ID	Service principal sign-ins, secrets manager logs
Identity Center user to action	`onBehalfOf.userId` and identity store ARN	CloudTrail `IdentityCenterUser` events
Person across systems	Immutable directory ID mapped to every platform account	Identity governance inventory

Build the mapping table of identities to platform accounts before an incident; reconstructing it under pressure is slow and error prone. See the Identity Threat Hunting Guide for queries that use these joins.

How to implement

Inventory sources (weeks 1 to 2): list every identity provider, directory, cloud account, SaaS platform with admin or API access, secrets store and CI system, with owner, licence tier and current retention.
Close default gaps: export Entra sign-in (all four types), audit and Graph activity logs through diagnostic settings; create organisation CloudTrail trails; enable Google Cloud Data Access logs for IAM and secret services; configure domain controller advanced audit policy.
Centralise and normalise: send to the SIEM or a security data lake, map fields to a common schema (actor, actor type, credential ID, session ID, source, target, outcome) and convert to UTC.
Test with an exercise: run a scripted scenario in a test tenant (sign in with a test service principal, assume a role, read a secret, add a credential) and confirm each step is attributable end to end within your SLA.
Set retention: at least 12 months searchable for identity categories, longer in cold storage; lock storage against deletion.
Alert on gaps: monitor ingestion volume per source and alert when a source goes quiet, because a stopped feed is also what an attacker who disables logging produces.
Roll back safely: if new data access logging drives unacceptable cost, narrow it to sensitive services rather than switching it off, and record the residual gap.

Small organisations should prioritise the identity provider, the main cloud account and email: three sources answer most questions, and paying for the licence tier that keeps 30 days or more of sign-ins is cheaper than an investigation without them. Large organisations need the full matrix, ownership per source, and coverage reported to the risk committee alongside detection metrics.

Detection and measurement

Source coverage: percentage of in-scope identity sources forwarding to the SIEM, target 100 per cent for tier 1.
Field completeness: share of identity events with actor ID, credential ID, session ID and source IP populated.
Retention compliance: sources meeting the 12-month searchable target.
NHI attribution rate: share of workload actions attributable to a named owner and credential.
Time to answer: minutes to answer the five investigative questions in a tabletop exercise.
Silent source alerts: number of feeds that stopped for more than an hour, and time to restore.

Framework mapping

Requirement	NIST SP 800-53 Rev 5	NIST CSF 2.0	CIS Controls v8.1	MITRE ATT&CK techniques it exposes
Event content and fields	AU-3, AU-8	PR.PS-04	8.5 Collect detailed audit logs	T1078 Valid Accounts
Source enablement	AU-2, AU-12	PR.PS-04	8.2 Collect audit logs	T1110.003 Password Spraying, T1621 MFA Request Generation
Retention and protection	AU-11, AU-9	PR.PS-04	8.10 Retain audit logs	T1606.002 SAML Tokens
Correlation and review	AU-6(3), SI-4	DE.AE-03, DE.CM-03	8.11 Conduct audit log reviews	T1550.001 Application Access Token
Account and credential change logging	AC-2(4)	DE.CM-09	8.5	T1098.001 Additional Cloud Credentials, T1098.003 Additional Cloud Roles
Directory and Kerberos events	AU-12	DE.CM-01	8.2	T1558.003 Kerberoasting, T1003.006 DCSync

Common failure patterns

Collecting only interactive sign-ins: non-interactive, service principal and managed identity sign-ins hold most NHI activity and most token replay.
Relying on console defaults: 7 or 30 days of sign-ins, 90 days of CloudTrail event history, discovered after the incident began months ago.
Licence-gated evidence: the event that proves data access exists only in a premium tier nobody bought.
Roles without people: assumed-role activity with generic session names and no sourceIdentity, so no action can be pinned to a human.
Test tenants out of scope: weaker logging in the environments attackers target first.
Logs stored where the attacker is: a global administrator can change diagnostic settings or delete the workspace that holds the evidence.

Lessons from incidents

In the Storm-0558 intrusion, the US State Department detected anomalous mailbox access through a custom alert on the MailItemsAccessed audit event, which it could see because it held a licence with premium audit logging; organisations without it could not see the same activity, and Microsoft later expanded logging to all customers. See the Microsoft Storm-0558 breach analysis. In the Midnight Blizzard intrusion, a password spray through residential proxies compromised an account in a legacy test tenant, and a legacy OAuth application with elevated access was used to create new applications and grant mailbox access; the lessons were to log test tenants like production and to alert on new app registrations, new credentials on existing apps and consent grants. See the Midnight Blizzard breach analysis.

Practitioner checklist

Write down the five investigative questions and test each identity source against them.
Export all four Entra sign-in log types, the audit log and Graph activity logs to long-term storage.
Create organisation-wide CloudTrail trails and require sourceIdentity on role sessions.
Enable Google Cloud Data Access logs for IAM, Secret Manager and sensitive data services.
Configure domain controller audit policy for logon, Kerberos, account and group change events.
Forward secrets manager, PAM, CI/CD and critical SaaS audit logs.
Keep identity logs searchable for at least 12 months, in storage the identity admins cannot delete.
Normalise to UTC and keep immutable IDs, credential IDs and session IDs.
Alert when any identity source stops sending.
Run a tabletop each year that times how long the five questions take to answer.

Identity Telemetry Requirements: The Minimum Logs Every Identity Investigation Needs