The Logging You Will Actually Want in a Breach

Failed logins get logged almost everywhere because they are operationally noisy. The record that actually matters in an investigation is the successful sign-in, because once a credential is phished or a token is stolen, every action the attacker takes arrives dressed as a legitimate user. Tracing them means having, for every authentication: the account, the timestamp, the source IP, the user agent, the MFA method and its outcome, and whether a legacy protocol carried it.

In Entra ID this is more subtle than it looks. The interactive sign-in log is the visible tier; non-interactive sign-ins, service principal sign-ins and managed identity activity are separate feeds, and they are precisely where token replay and persistence live. Portal retention on entry-level licensing is measured in days, so route sign-in and audit logs to a Log Analytics workspace or a storage account rather than trusting the default window, and turn on the unified audit log in Purview for Exchange and SharePoint activity. On hybrid networks the domain controller security logs carry the equivalent story: logon events 4624 and 4625, and privileged logon event 4672, are the raw material of lateral movement tracing.

Initial access is a moment; persistence is a series of configuration changes, and every one of them is an admin action something can record. The business email compromise playbook is almost entirely control plane activity: an inbox rule that forwards invoices and deletes the originals, a mailbox delegation, an OAuth application granted read access to mail. In Entra ID the same pattern shows up as role assignments, fresh app registrations, or a new client secret quietly added to an application that already held legitimate permissions. The control plane record worth keeping is short and specific:

The last item is the one nearly everyone misses. A competent intruder who reaches admin will narrow or disable logging early, and the audit record of that change is often the only evidence that survives. Alert on it, and make sure the alert lands somewhere the same admin credentials cannot suppress.

Attackers do not operate on your log rotation schedule. Dwell times measured in weeks and months are routine, which means a 30-day retention window practically guarantees that by the time you notice, the initial access event has already rolled off. You will know you were breached without being able to say when, how, or through which account, and every downstream decision inherits that uncertainty.

This stops being an engineering preference and becomes a legal problem under the Notifiable Data Breaches scheme in Part IIIC of the Privacy Act 1988. Once you suspect an eligible data breach you have up to 30 days to assess it, and if it qualifies you notify the OAIC and affected individuals as soon as practicable. Scoping which individuals are affected is a log question. Without history you cannot prove the negative, so you end up notifying on worst-case assumptions: more people, more damage, more cost, all because the evidence expired.

The cost objection dissolves once you tier. Identity and audit logs are tiny next to application telemetry. Keep them queryable for at least 90 days and archived for 12 months or more; in Azure that is a Log Analytics retention setting plus an archive tier, or a lifecycle-managed storage account. Let the verbose, expensive streams (flow logs, debug-level application output) roll off early. Twelve months of identity history is the difference between an investigation and an educated guess.

The first act of a competent intruder with admin rights is housekeeping: Windows event logs cleared, shell history wiped, web server access logs truncated. Evidence has to leave the machine in near real time and land somewhere the stolen credentials cannot rewrite. That means a collection point with a separate permission boundary: a dedicated workspace or subscription where production admins hold read access at most, storage immutability policies where the platform supports them, and deletion rights held by nobody who signs in day to day.

The test is simple to state. Assume your most privileged credential is stolen. Can that identity edit or delete the history of its own actions? If yes, your tamper resistance is decorative. Centralisation is the other half of the same requirement: an intrusion only becomes visible as a story when identity, mailbox, endpoint and application logs sit in one queryable place with synchronised clocks, UTC timestamps and consistent user identifiers. For a Microsoft-centred business this does not demand a heavyweight SIEM; a single Log Analytics workspace with the right diagnostic settings and connectors covers a remarkable amount of ground.

Custom-built software is where investigation-grade logging most often does not exist at all, because framework defaults record requests and exceptions, not actors. If a line-of-business system holds anything worth stealing, it needs first-class audit events: which authenticated user exported the client list, changed the payout account, elevated a role, or viewed a record outside their usual pattern. Emit them as structured events with stable identifiers for the user, the action and the object, and ship them to the same central store as everything else. Retrofitting actor attribution into an application that never captured it is genuinely hard, which is why it is one of the first things we look for when building or reviewing software for clients.

The counterpart discipline is knowing what to keep out. Credentials, session tokens, full request bodies and personal information beyond a record identifier do not belong in logs. A log platform is a data store like any other under APP 11, and a breach of a log system stuffed with customer detail can itself be a notifiable event. Log identifiers, and let the investigator join back to the source system.

None of this needs to be discovered during a crisis. Pick one staff account and assume it was compromised 60 days ago. In an afternoon, try to produce: every sign-in on that account since then, every inbox rule it created, every admin action it performed, and every record it touched in your most sensitive application. Each place the honest answer is that you cannot know is your roadmap, and the order of this note is the order to fix things: authentication events first, then admin actions, then retention, then tamper resistance and central collection.

Logging is close to free before an incident and unobtainable after one. You can hire responders, stand up tooling and brief lawyers inside a week; the one thing nobody can buy you is history that was never written down.