Every control in this series produces a record, and a control whose record no one keeps is a control you are only assuming works. Watching identity is the discipline of turning the directory’s exhaust, the sign-ins, the changes, the health of the authentication service itself, into something you can actually see, alert on, and answer questions with later. It is the least glamorous part of the design and the first one you will wish you had done properly, because it is the only part that can tell you what happened after it already has.
This is the twelfth and final article in the Entra ID series. The rest built the identity plane. This one is about observing it, and about the single decision that determines whether you can observe it at all.
The logs, and what each one is for
The directory emits a few distinct streams and it helps to know what each answers. The sign-in logs record authentications, and they are really four logs wearing one name: interactive user sign-ins, the non-interactive ones that applications perform on a user’s behalf, service principal sign-ins where an application authenticates as itself, and managed identity sign-ins. The audit log is the different and arguably more important record, because it captures changes rather than sign-ins, every modification to a policy, a role assignment, a group, a federation setting. The provisioning logs track the flow of accounts to and from connected applications. Between them, the sign-in logs tell you who came in and the audit log tells you who changed the place, and if you had to keep only one for security purposes it would be the audit log, because it is the system of record for who altered the controls everyone else depends on.
The decision that makes everything else possible
Here is the fact that has to land before any of the rest is useful. The logs kept inside the portal are retained for a short window, seven days on the free tier and thirty days with a premium license, with a couple of risk-related exceptions that run longer. That is all the history the platform keeps for you by default. Anything you might want to ask beyond that window, any investigation that reaches back a quarter, any correlation across months, is impossible unless you exported the logs from the beginning, because retention cannot be applied retroactively and data past the window is simply gone. This is why the export decision is the load-bearing one in the whole operations design, and why I treat it as day-one work rather than something to set up when you first need it. By the time you need it, the record you needed has already aged out.
Export runs through diagnostic settings to one of a few destinations, each suited to a different purpose. A Log Analytics workspace is the home for querying and for the workbooks; an Azure storage account is the cheap archive for long retention; an event hub is the pipe to a security information and event management platform. Most mature designs send to more than one, archiving cheaply while streaming the security-relevant categories to the analytics workspace or the wider operations platform. Two cautions belong with that choice. Ingestion and retention in these destinations cost real money, priced on volume, so this is a sizing exercise and not a switch you flip without a number in mind. And the non-interactive sign-ins are enormous, dwarfing the interactive ones, so streaming everything indiscriminately is how you turn a reasonable logging bill into an unreasonable one; filter deliberately to what you will actually use.
Retention cannot be applied retroactively. By the time you need the record, the record you needed has already aged out.
From raw logs to something you read
Exported logs are inputs, not answers, and the layer that turns them into answers is worth understanding. Workbooks are the built-in analytical views, covering things like where multifactor authentication has gaps, how Conditional Access is actually landing, which sign-ins still use legacy authentication, and, in the sensitive operations report, the specific high-consequence changes that most deserve watching. The dependency to note is that these workbooks read from a Log Analytics workspace, so they only work if you have already routed the logs there; the export decision from a moment ago is their prerequisite, not an optional enhancement. In the broader security operations picture, the identity logs increasingly converge with everything else in the unified Defender portal, where the tenant’s own security analytics platform now lives and correlates identity signals with endpoint and email. That consolidation is real and current, and it is the direction to build toward rather than standing up an identity-only monitoring island beside it.
Separate from the logs, and often overlooked, is the health of the authentication service itself. The platform now offers a health capability that watches core sign-in scenarios and reports on service availability against a monthly measure, a low-latency view of whether authentication is actually succeeding at the rates it should, distinct from the after-the-fact record the logs provide. The scenario alerting side of this is still maturing, labeled preview as I write, so I position it as a promising signal to layer on rather than the backbone of an alerting strategy. The backbone remains the logs and the alerts you build from them.
What to actually watch for
Collecting everything and watching nothing is a common and expensive failure, so it is worth being concrete about the events that warrant an alert rather than merely a record. Any use of a break-glass account should page someone immediately, because those accounts exist for emergencies and their sign-in is either an emergency or an intrusion, and there is no benign third case. Changes to privileged role assignments, and activations that fall outside the normal pattern, deserve attention because they are the moves an attacker makes to entrench. Modifications to Conditional Access policies belong on the list, since weakening a policy is a quieter and more durable attack than any single sign-in. Grants of application consent, particularly the high-privilege permissions handed to a service principal, are a favored persistence mechanism and should not pass unremarked. And new federation relationships or added domains are among the most serious signals of all, because control of federation is control of authentication itself. These are drawn straight from the audit and sign-in logs, which is the practical proof that the export decision and the alerting strategy are the same decision seen from two ends.
Where the series leaves you
Across twelve articles this series has followed identity from the shape of a tenant through the origins of accounts, the structure of the directory, the credentials that prove who people are, the risk engine that doubts them, the privilege model that constrains administrators, the roles and delegation that scope authority, the governed access and lifecycle that keep it correct, the external trust decisions that extend the perimeter, and now the observation that ties the whole thing back to something you can see. The consistent theme, if there is one, is that identity is not a product you turn on but a control plane you design, and that nearly every default is a decision someone else made for their convenience rather than your security. The work is in knowing which defaults to keep and which to overturn, and in being able, afterward, to prove which you did. That last part is what this article was about, and it is the one that makes all the others accountable.
Entra ID
‹ Previous: [E 11] External Identities: B2B, Cross-Tenant Access, and Direct Connect
