Azure log forensics limits: retention and missing logs

TL;DR. Azure keeps the Activity Log for 90 days, then deletes it. Resource logs — Key Vault, storage, and most data-plane activity — are off by default and only exist from the moment a diagnostic setting was created. Flow logs must be enabled per NSG or VNet. Tenant-level events like elevateAccess are not in subscription exports. Rules are heuristics with thresholds and learning periods. None of this makes Azure forensics hopeless; it makes it important to write down exactly what you had, and to phrase conclusions accordingly.

Every Azure report I write has a section called "Scope and limitations". It is not boilerplate. It is where the reader learns whether "no evidence of data access" means "we checked and nothing happened" or "there was nothing to check".

Retention: the 90-day clock

Microsoft states that Azure "retains activity log events for 90 days and then deletes them" (Activity Log in Azure Monitor). The REST API requires both ends of your time range to fall inside that window. Consequences:

An intrusion discovered on day 100 has lost its first ten days of control-plane history, unless a diagnostic setting exported the Activity Log to Log Analytics (retention configurable, up to 12 years per Microsoft), a storage account or Event Hubs.
The resource creator is only recorded in the Activity Log. After 90 days without an export, "who created this VM?" may be unanswerable.
Exporting early is the single most valuable action in the first hour (export guide).

Resource logs have no platform retention at all: they live wherever the diagnostic setting sends them, with that destination's retention.

Missing sources: logging that was never on

Question	Log needed	On by default?	If it was off
Who changed what in Azure?	Activity Log	Yes (90 days)	—
Who read which Key Vault secret?	Key Vault `AuditEvent`	No	Unanswerable; rotate every reachable secret
Which blobs were downloaded?	`StorageRead` / `StorageBlobLogs`	No	Unanswerable from Azure; assume the account's content exposed
Did a VM talk to the attacker?	NSG / VNet flow logs	No	Look at the VM itself, firewall or proxy logs
How did the identity get compromised?	Entra ID sign-in and audit logs	Yes (retention depends on licence)	Separate investigation (m365forensics.com)
What ran on the VM?	Guest OS logs, disk	Depends on the VM	Disk forensics

The analyzer's coverage block makes this explicit: sources "not provided", rules that "could not run" and why. Copy it into your report.

Gaps created by the attacker

Deleted diagnostic settings create a gap from the deletion timestamp onwards; disabled Defender plans stop detections; deleted log blobs remove history from an archive. These are different from "never enabled": the deletion itself is evidence, logged in the Activity Log. See defense evasion.

Even with every log enabled:

Run Command script contents are generally not in the Activity Log (Run Command attacks).
SAS creation signed client-side is not logged anywhere; Microsoft says it is "not possible to audit the generation of SAS tokens" (SAS overview).
Flow logs carry no payloads and do not see Internet clients talking straight to PaaS endpoints (flow logs).
Read operations on the control plane (listing resources, reading configuration) are typically not in the Activity Log, so reconnaissance is mostly invisible.
Tenant-level events, such as elevateAccess, are in the tenant-level log, not in subscription exports.
Latency. Microsoft gives 3 to 20 minutes for Activity Log availability and up to 10 minutes for Key Vault logs; an export taken during an active incident can miss the last minutes.
Log Analytics case differences. Microsoft notes values in AzureActivity may differ in case; string comparisons must be case-insensitive.

Limits of the analyzer

Honest about the tool too:

It only sees what you load. No API access to your tenant, by design.
First-seen rules need more than 72 hours of history before the suspicious activity. With a short export, AZ-KV-001, AZ-ID-001, AZ-ID-002 and AZ-VM-004 cannot run.
Thresholds can be evaded. Bulk download needs 50 distinct blobs in an hour from one identity and IP; secret enumeration needs 8 distinct objects in an hour. A patient attacker stays under them.
Legitimate automation matches rules. Every rule documents its known false positives.
Formats. Avro (Event Hubs Capture) and Parquet are not read; the portal CSV is best effort; UTF-16 must be converted.
Display cap. Beyond 100,000 events the table stops listing, but every event is still analysed and counted.
Entra ID is out of scope. Identity lives in m365forensics.com.

Writing the conclusion

Wording I use, depending on what was available:

Situation	Defensible wording
Key Vault logs present for the whole period, no suspicious reads	"No evidence of secret access by the compromised identity in Key Vault audit logs covering <range>."
Key Vault logs absent	"Key Vault audit logging was not enabled; secret access cannot be determined. All secrets accessible to the identity are treated as exposed."
Logs deleted mid-incident	"Key Vault logging was disabled by the attacker at <time>; activity after that time cannot be determined."
Clean verdict, full coverage	"No detection matched in <sources> for <range>. This does not exclude activity below detection thresholds."

The verdict of any automated tool is the start of that paragraph, not its conclusion.

FAQ

How long does Azure keep the Activity Log?

90 days. After that Azure deletes the events. Longer retention requires a diagnostic setting that sends the Activity Log to a Log Analytics workspace, a storage account or Event Hubs.

Can I get Key Vault or storage access logs for a period when logging was off?

No. Resource logs are only written while a diagnostic setting sends them somewhere. Enabling one now does not backfill the past.

Does a Clean verdict mean the subscription was not compromised?

No. It means no detection rule matched in the logs provided. Check which sources were present, which rules could not run, and whether the retention window covers the suspected period.