Most identity security reporting counts things that exist. Rules enabled, policies deployed, coverage percentages, registration rates. Every one of those numbers can be accurate while an estate is exactly as exposed as it was before, because none of them measures whether anything was caught.
This module is the orientation for a course about the other question. It sets out where identity signal actually comes from, what a detection is once you look past the query, why most identity detections cannot tell you anything on their own evidence, and what it means to operate an identity estate rather than configure one. It also introduces Northgate Engineering, the 810-person estate every example in this course is drawn from, and the tenant setup you need if you want to follow along in your own.
Nothing here assumes you have taken another course. Every concept this course uses is explained the first time it appears.
Where this module goes
0.1 to 0.3 are the argument: what separates a control that is switched on from one that is working, where the signal lives, and what a detection actually is.
0.4 to 0.6 are the ground: the attacks that reach a tenant with MFA enabled, why the evidence for them is ambiguous, and the identities nobody owns.
0.7 to 0.10 are the practicalities: what running an estate involves, the three surfaces you work through, how coverage is measured honestly, and the lab.
Do I already know this material?
Six scenarios across the full range of this course, from which table an identity attack leaves a record in to designing a detection estate somebody else has to run. Answer them to find out where you sit, and whether this course fits or will sharpen judgment you already have.
An account is disabled the day a contractor leaves. Six weeks later it is found to have been reading a SharePoint site throughout. A query of SigninLogs for that account over ninety days returned nothing. What happened?
The account was re-enabled and disabled again without being logged.
SigninLogs retention was shorter than ninety days, so the records aged out.
An application the contractor consented to holds a refresh token, so the access is non-interactive and appears in a different table entirely.
Disabling an account stops the person signing in. It does not revoke a grant the person made, and offline_access gives the application a refresh token. Every one of those accesses was logged, in AADNonInteractiveUserSignInLogs.
Disabled accounts are excluded from sign-in logging by design.
A tenant reports 94 per cent identity coverage, up from 91 last quarter. The calculation is correct and the data is current. Why might that number still be misleading?
Percentages are inherently unreliable for security reporting.
Its denominator is users, which excludes the service principals and managed identities that no user-scoped policy reaches, and the rise can come from hiring rather than from any security work.
Most tenants hold more non-human identities than human ones. A coverage figure taken over users describes the smaller half, and both its numerator and denominator grow with headcount, so the ratio drifts upward on its own.
Coverage should always be reported as an absolute count rather than a ratio.
A three-point rise is within the margin of error for any estate measurement.
Two AuditLogs entries eleven days apart both read "Add service principal credentials", both by the same Application Administrator, both adding a two-year secret. One is a scheduled rotation and one is an attacker. Which field separates them?
The result code, which differs for programmatic and interactive changes.
The client application, which records whether the portal or Graph was used.
The correlation ID, which links the change back to its originating session.
None of them. The records are identical, and what separates them sits outside the audit log entirely.
The attack is the legitimate action performed by the wrong person, so the record is the same. What resolves it is a change ticket, the expiry of the credential being replaced, or the session that made it.
A Sentinel rule for token replay is enabled, correctly written, and has produced nothing in ninety days. What is the first thing to check?
Whether the table it queries is being ingested at all, since a query against an absent table returns an empty set rather than an error.
A rule executing successfully against nothing is not an error, so it shows healthy in every rule report. The check is to compare the tables your rules depend on against the categories your tenant actually emits, in Diagnostic settings.
Whether the rule's schedule overlaps its lookback window.
Whether the analytics rule has drifted from its template version.
Nothing. A rule that has not fired in ninety days is evidence the control is working.
You are designing a detection that fires when a privileged role is assigned outside PIM, and joins against your change management system to suppress documented changes. What is the strongest argument against relying on that join?
Change systems rarely expose an API, so the join has to be manual.
An attacker with access to the change system can create the record that clears their own change, so an unauthenticated write path makes the suppression a liability rather than a control.
The join has to be against a source the attacker cannot write to. Queryable and trustworthy are separate properties, and a detection that suppresses on an unverified record is worse than one with no join at all.
Timing skew between the two systems makes correlation unreliable.
Change records do not carry enough detail to match a specific role assignment.
A Conditional Access rollout plan targets eight directory roles and states that 38 of 41 holders are already registered for a phishing-resistant method, so the blast radius is three. The estate also holds eleven accounts eligible for those roles through PIM and four service accounts with Exchange Administrator. What is wrong with the plan?
Nothing. Eligible accounts are out of scope until they hold the role.
The plan should have targeted groups rather than roles, which would have caught the service accounts.
The blast radius is understated: eligible users enter scope at the moment of activation, and the service accounts cannot present a phishing-resistant method at all because there is nobody to present one.
Counting current role holders misses everyone who can become one, and it misses the population for which the control is impossible rather than merely unregistered. Both land at the worst moment, which is during an activation somebody needed urgently.
Report-only for fourteen days is too short a window to establish impact.
This course is for you.
You will go from the four tables identity signal lives in, through writing detections for the attacks that defeat a tenant with MFA enabled, to governing the workload identities nothing reaches and running the estate that produces the signal.
Start the course
You have the fundamentals. The value here is the harder half.
You know where identity signal lives and why a rule can be correct and inert, so the payoff is the back half: detection engineering against ambiguous evidence, workload and external identity governance, log routing designed rather than defaulted, a recovery position that has been tested, and correlating identity across the Defender estate.
Start with detection engineering
You clearly know much of this already.
You are reading identity evidence the way somebody does who has been burned by it. What this course adds is the parts that are nobody's job: the workload population no control reaches, the ingestion decision that quietly kills a detection, and a coverage figure you can defend to somebody who will act on it.
Sharpen it into a method
By the end of this module you will be able to say what this course is for and whether it is the one you need. The modules after it assume nothing except that you read this one.
