Key Metrics

Introduction

Endpoint security is judged on two numbers and neither of them describes an endpoint. They measure how quickly a queue is worked, which is a real thing worth measuring and is not the thing you are being asked about when somebody asks whether the estate is better than it was.

This section names what to measure instead. Every metric in it has the same property: it moves when you change a configuration, and the person reporting it is the person who can move it, so the distance between the work and the number is a day rather than a quarter.

You will finish able to produce five figures for your own estate, say what each one is not capable of showing, and recognize the two ways a metric improves without anything improving.

Mean time to detect is the interval between something happening and an alert being raised on it. Mean time to respond is the interval between that alert and a containment action. Both are worth having, both describe the operation rather than the estate, and both have a property that makes them dangerous as a headline: they average over whatever cases arrived.

That averaging is where the scenario comes from. A queue is mostly commodity: the same handful of alert types, most of them closable in seconds by a rule. Add auto-triage for those and the mean falls sharply, because you have changed the denominator's easy end. The targeted intrusion that takes four hours to notice is still taking four hours, and it contributes one row to an average that has just gained several thousand fast ones.

// The two numbers as they are usually reported, and the one that matters
SecurityAlert
| where TimeGenerated > ago(30d)
| extend Minutes = datetime_diff('minute', ClosedTime, TimeGenerated)
| summarize Mean = avg(Minutes),
            Median = percentile(Minutes, 50),
            SlowestDecile = percentile(Minutes, 90),
            Cases = count()

Run it with all four values rather than the first one. The mean and the median are what get reported; the ninetieth percentile is the population an intrusion actually sits in, and it is one more clause in a query somebody is already running.

There is a second problem with an average here, which is that the distribution is not one anybody would choose to summarize with a mean. Alert-handling times are heavily skewed: a very large number of cases resolving in seconds and a small number taking hours. A mean over that shape is dominated by the fast group and moves whenever the fast group's size changes, which is a property of your triage automation rather than of your security. A median tells you about the typical case and neither statistic tells you about the case you actually fear, which is the slowest one. If you report these at all, report the slowest decile alongside the mean, because that is the population an intrusion sits in.

Read the bottom two lines against the top one. The mean is 12 minutes and no case that mattered took anything like 12 minutes, because 84 per cent of the population is auto-closed noise. The eight cases in the last row are the ones a board is actually asking about, and every headline statistic in this section is arithmetically incapable of describing them.

None of which is an argument for dropping them. They are the right measurement for the operation and they belong in an operations review. The failure is using them to answer a question about the estate, and it happens because they are the two numbers the platform produces without being asked.

That last line is the perverse result worth carrying. Promote an ASR rule to block and the attempts it stops raise no alerts, so they leave the average entirely. The cases remaining are the harder ones, and both headline numbers get worse in the quarter you did the most useful work available to you.

The first prevention figure is enforcement coverage: how many rules are in block, on how many devices. Three of eighteen rules blocking on sixty per cent of an estate is roughly a tenth of the available prevention, and the target is never a hundred per cent, because some rules have genuine business conflicts that keep them in audit permanently. What the figure tracks is distance from the maximum you have decided is enforceable, which is a number you have to write down before the metric means anything.

The second is the block rate per rule per month, and it is the one that argues for you at a change board. A rule blocking two hundred attempts a month is two hundred techniques that did not proceed and two hundred alerts nobody had to triage. A rule blocking zero has two readings and they need separating: either the technique is not attempted here, or the rule is not reaching the devices you think it is.

// Enforcement coverage: devices blocking, against devices only auditing
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| summarize Blocked = countif(ActionType endswith "Blocked"),
            Audited = countif(ActionType endswith "Audited")
            by DeviceName
| summarize Blocking = dcountif(DeviceName, Blocked > 0),
            AuditOnly = dcountif(DeviceName, Blocked == 0 and Audited > 0),
            Seen = dcount(DeviceName)

Read the middle column against the first. Devices in the audit-only count are running rules that watched a technique succeed and wrote it down, and the ratio between those two columns is the single most useful prevention number you can put in front of somebody who controls change approval. It is also the number that improves fastest, because promoting one rule moves it for the whole fleet in an afternoon.

One caution on both figures, learned the expensive way in most estates. These are event-derived, so they describe devices that generated events in the window. A device that has been powered off for a month, or that stopped reporting in week two, appears in neither column and quietly shrinks your denominator. Reconcile the device count this query sees against your onboarded total before quoting either figure, because a coverage percentage that silently excludes the machines with problems is a percentage that only ever improves.

The third prevention figure is one nobody reports and it is worth adding: how long the rules currently in audit have been there. Not a rate, a set of dates. A rule audited for three weeks is a deployment in progress and a rule audited for two years is a decision that was never taken, and the two are indistinguishable in every other measurement here.

The detection figures answer a different question from the response ones: not how fast, but how much is covered at all. The first is blunt and it is the one most estates fail on. Count your custom detection rules. Zero means the layer runs entirely on built-in analytics, which catch commodity threats and documented tooling in default configuration and cannot catch an operator using your own administrative tools in a pattern only you would recognize as abnormal.

The second is the true positive rate per rule, and it is what turns detection from a pile of rules into an engineering practice. A rule confirmed genuine less than about a third of the time is costing more analyst attention than it returns and needs tuning or retiring. A rule above roughly four in five is reliable enough to be considered for automated response, which is the link between this metric and the automation decisions in ES7.

// True positive rate per custom detection, worst first
AlertInfo
| where Timestamp > ago(30d)
| where DetectionSource == "CustomDetection"
| summarize Total = count(),
            TP = countif(Classification == "TruePositive")
            by Title
| extend TPRate = round(TP * 100.0 / Total, 1)
| sort by TPRate asc

Zero rows is a finding rather than an error. It means the query found no custom detections to rate, which is the first figure above expressed as an absence. Where it does return rows, the ascending sort puts your tuning queue in order, and the rule at the top is the one costing your analysts the most attention for the least return.

The third detection figure is breadth: the share of the techniques in your own threat model covered by at least one rule, built-in or custom. It is the only one of the three that a faster SOC cannot move. Triage speed does not change coverage, and an estate detecting in twelve minutes across a fifth of the techniques that matter to it is detecting quickly and narrowly, which is a sentence worth being able to say out loud in a review.

Breadth also needs a denominator you chose rather than one you inherited. Measuring against the whole of ATT&CK produces a small percentage on every estate and tells you nothing, because most of the matrix describes platforms and situations you do not have. Measuring against the techniques in your own threat model gives a number that means something and requires you to have written the threat model down, which is why this figure is so often quoted against the full matrix instead.

Exposure score is a 0 to 100 figure from Defender Vulnerability Management describing how exposed the onboarded fleet is, and lower is better. The published bands are 0 to 29 for low, 30 to 69 for medium and 70 to 100 for high. It is refreshed daily, which makes it one of the few endpoint numbers that gives feedback on the same timescale as the work.

It is also routinely confused with Microsoft Secure Score for Devices, and the two are calculated independently. Exposure score is about vulnerability and configuration risk on the fleet; the secure score is about how well configured the devices are against a set of recommendations. They move for different reasons and quoting one while naming the other is common enough that it is worth checking which is on your own dashboard.

Now the part that matters for a metric rather than for a product. On 31 May 2026 Microsoft put an updated exposure score model into public preview, replacing a calculation that leaned mainly on CVSS severity with one combining several vulnerability risk signals, exploitability and asset context. Microsoft's own statement is the important half: when the updated model is enabled, the score may move up or down because the calculation changed, and that does not necessarily mean the posture changed. The bands did not move.

Read the rule in that rather than the numbers. A trend line spanning a model change compares two different calculations, so the first honest comparison is the quarter after the change. Treat the change date as a reset, say so in the report rather than in a footnote, and expect to be asked why the improvement you claimed last quarter has become uncomparable.

The general lesson is larger than one vendor's change and it applies to every number in this section. A metric is a measurement plus the method that produced it, and when the method changes the series breaks whether or not anybody announces it. That happens to vendor scores on a release note, and it happens to your own figures the moment somebody adjusts a query. Record with each series what produced it and the date that definition last changed, because a trend line is an argument about causation and it only holds while the method is constant.

This one has no rate and no average. Per endpoint, the evidence configuration is present or it is absent, and the metric is the share of the fleet where it is present. That makes it the simplest figure in this section to produce and the one most estates have never produced, because nothing prompts it: no alert fires when logging is missing, and the console reports the device healthy either way.

Partial is worth counting separately rather than folding into either column, because it is the state that misleads an investigation. A device with process auditing but no script block logging tells you a process started and nothing about what the script inside it did. A device with script block logging and default audit policy shows you scripts and not the logons that explain how the operator got there. Both look like readiness in a summary that counts devices with any logging at all.

PS C:\> $pol = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell"
PS C:\> $sb  = "$pol\ScriptBlockLogging"
PS C:\> $aud = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion" +
                "\Policies\System\Audit"
PS C:\> [pscustomobject]@{
            ScriptBlock  = (gp $sb  -EA 0).EnableScriptBlockLogging
            CmdLineAudit = (gp $aud -EA 0).ProcessCreationIncludeCmdLine_Enabled
        }

ScriptBlock CmdLineAudit
----------- ------------
                       1

That device is the partial case, and it is the commonest one. Command line capture is on, so process events carry what was run. Script block logging is unset, so a script executed inside one of those processes leaves only whatever the engine flagged on its own. Counting this device as ready would be wrong and counting it as absent would also be wrong, which is why the metric needs three columns.

Sample rather than survey, at least to begin with. Twenty devices chosen across hardware generations and business units will tell you the shape of the estate in an afternoon, and the failure modes in this layer cluster by device age and by which team built the image rather than by user. A full inventory is the right end state and it is a script somebody has to write; the sample is what tells you whether writing it is urgent.

One more property makes this figure different from the other five. Every other number in this section can be improved after you notice it is bad, and this one cannot be improved retroactively at all. A device with no script block logging on the day of an incident has no script block logging for that incident, permanently, whatever you configure the following week. It is the only metric here that measures a decision rather than a state, which is the argument for reporting it monthly on an estate where nothing about it has changed.

Producing these numbers is half the skill and the other half is reading somebody else's set of them. In practice you will spend more time being handed a report than writing one, and the failure mode is not falsified figures. It is a page where every line is correct and the conclusion drawn from it is not supported by any of them.

Here is Northgate's quarter as it went to the board. Read it as the audit committee asked you to: does the report support the conclusion the board drew from it. The notes underneath the metrics are not filler.

Classify it before deciding what to do, because the answer routes it. A report that is inaccurate goes to whoever produced it as a correction. A report that is accurate and misleading goes to whoever commissioned it as a change to what gets reported, and that is a longer conversation with a different person.

Be careful about how that conversation is opened, because the report is somebody's work and the finding is not that they did it badly. Everything on the page is correct and the metrics on it are the ones the platform surfaces by default. The argument to make is that the pack answers an operations question and is being read as an answer to an estate question, and the fix is four lines added rather than anything removed. A finding phrased as an addition gets accepted; the same finding phrased as an error gets defended.

What makes it misleading is structural rather than dishonest. Two of the five headline figures measure the queue, one measures deployment, and one changed its calculation mid-quarter. The four figures that would have described the estate's actual capability are present, correct, and in the notes rather than the summary, all reading zero.

Reading a report this way is a skill worth practicing deliberately, because it transfers. The questions are always the same three. Which of these figures moves when the operation changes rather than when the estate does. Which of them is satisfied by deployment rather than by configuration. And has anything about how a figure is calculated changed inside the period being compared. Any report that survives those three is telling you something; most do not, and the ones that do not are usually assembled rather than written.

That asymmetry is worth designing around rather than resenting. The four figures that answer the question cost a query each and then cost nothing, because a scheduled query produces them every month without anybody remembering to. Writing them once is the difference between a pack that assembles itself out of defaults and a pack that assembles itself out of what you decided mattered.

A metric read more often than it can change wastes attention and a metric read less often than it moves is a metric you learn about too late. The interval follows from the mechanism rather than from a reporting calendar, which is why the cadence below is not four equal-sized buckets.

Daily belongs to things that change without anybody deciding: sensor health, devices that stopped reporting, and the exposure score, which refreshes daily and is the only vendor number here fast enough to reward a daily look. Weekly belongs to work in progress: audit events on rules you are preparing to promote, and the true positive rate on any detection shipped in the last month, because that is the window in which tuning is cheap.

Monthly belongs to the figures that describe the layers: enforcement coverage, custom detection count, technique breadth and readiness share. None of those moves without somebody doing something, so reading them monthly is reading your own delivery. Quarterly belongs to the argument rather than the numbers: which layer is thinnest now, what it would cost to move it, and whether last quarter's promise was kept.

That last item is the one that makes the cadence worth keeping. A quarterly review that only reports the current state invites the same conversation every quarter, because nobody has to account for what was said last time. Recording the commitment beside the number turns the pack into a record of delivery, and it is also the fastest way to discover that a figure nobody can move is being reported because it always has been.

Produce the whole set once before deciding which of them to keep. Most estates find the exercise itself is the finding: four of the six take a query or a script that nobody has written, and the reason they are not reported is not that somebody judged them unimportant.

Keep the cadence shorter than feels comfortable for the first two months. The point of reading a figure you expect not to have moved is to find out whether your assumption about what moves it is right, and that is cheapest to discover early. Once a number has held still across four readings for a reason you can articulate, moving it to a longer interval is a decision rather than a drift.

The next section places these figures against the Microsoft products that generate them, and shows which parts of the stack you are entitled to but not receiving.