By the end of this you have Exposure Management producing output that reflects your estate rather than Microsoft’s defaults: a role that grants the right people the right depth, a reviewed set of predefined classifications, at least one custom classification rule built from your own naming convention, a deliberately chosen initiative set with weights you can defend, and a hunting query that proves the graph sees a newly classified asset carrying the criticality you assigned it. It takes an afternoon. It is the highest-yield afternoon in this pillar, because criticality is the one input the platform cannot infer and every downstream ranking depends on it.
Before step 1. Any one of Defender for Endpoint, Defender for Identity, Defender for Cloud Apps, Defender for Office 365 Plan 2 or Defender for Cloud grants the full experience, so almost certainly you already have it. Unified role-based access control must be active for the roles below to be assignable. Device classification requires the Defender for Endpoint sensor at version 10.3740 or later, which is the one genuine prerequisite people trip on, so establish that first. The product is public cloud only and is not available in national or sovereign clouds. Nothing in this build costs anything; the only metered element in this product is third-party data connectors, which are not part of it.
Step 1: Establish sensor coverage before you trust anything
Classification of devices depends on a sensor version floor, and a fleet below it will classify partially and silently. Check it before you build rules, because a rule that appears to match nothing is indistinguishable from a rule you wrote wrongly.
// Sensor version coverage. Run in Defender advanced hunting.
// Devices below 10.3740 will not classify for critical asset management.
DeviceInfo
| summarize arg_max(Timestamp, ClientVersion) by DeviceName
| extend Major = toint(split(ClientVersion, ".")[0]),
Build = toint(split(ClientVersion, ".")[1])
| summarize Devices = count() by MeetsFloor = (Major > 10) or (Major == 10 and Build >= 3740)
| order by MeetsFloor ascExpected result is two rows with the overwhelming majority on the true side. The failure mode is a large false count that nobody looks at again, which produces an estate where classification quietly covers seventy percent of devices while every dashboard reports as though it covers all of them. Fix the sensor estate first or accept, in writing, that your criticality picture has a known hole.
Step 2: Grant the role, at the right depth
Create a custom role in the Defender portal’s permissions area rather than handing somebody a directory-wide administrator role, because this product has exactly the granularity you want and using it costs nothing. The permissions sit in the Posture management group under the Security posture category, and there are two of them.
| Setting | Value | Why |
|---|---|---|
| Exposure Management (read) | Assign to analysts, reporting roles and anyone who consumes attack paths | Full visibility of the map with no ability to change what it prioritises. This is the right default for most of the people who will use this product. |
| Exposure Management (manage) | Assign narrowly, to whoever owns classification and initiative weighting | Manage includes setting metric weights and target scores, which is the ability to change what the organisation’s exposure number means. Treat it as a governance permission, not an operational one. |
| Data source on the role | Microsoft Security Exposure Management | The permission does nothing without the data source assigned. A role that looks correct and grants nothing is almost always this. |
| Device group scope | All device groups, for anyone holding manage | Editing metric weights requires coverage of every device group at tenant level. A scoped role can read but will fail to write, and the failure is not obvious. |
| Core security settings (manage) | Only if the role will connect external attack surface vendors | Sensitive connector actions need this additional permission under Authorization and settings. Leave it off otherwise. |
Naming convention. Name roles for the function and the depth, not the person or the team: XDR-ExposureMgmt-Read and XDR-ExposureMgmt-Manage. Two roles, two Entra groups with matching names, membership managed in the directory. When somebody asks in a year who can change the exposure score’s meaning, the answer is one group membership query rather than a review of every custom role in the portal.
Build the role in the portal. A beta Graph surface for Defender role definitions does exist, and if you are building tenants repeatedly it is worth knowing about, but I would not automate on it today: it is beta rather than generally available, and Microsoft’s own permission tables for it disagree with themselves about which scope the Defender provider requires. Portal creation is the supported route and this is a once-per-tenant action.
# For reference only. Beta, and the required scope is documented
# inconsistently. Create the role in the portal instead.
POST https://graph.microsoft.com/beta/roleManagement/defender/roleDefinitionsStep 3: Review the predefined classifications rather than accepting them
Microsoft ships a catalogue of predefined classification rules covering devices, identities, cloud resources and, since June 2026, AI agents. These are on by default and they are good, but “good in general” and “correct in your estate” are different claims. Work through the catalogue once and make a deliberate decision on each rule, because a classification that misfires does active harm: it promotes attack paths you do not care about to the top of a list somebody is working, and the person working that list has no way to know the ranking is wrong.
The ones I check first are the identity rules covering widespread local administrator rights, which in an estate that has not yet finished a privilege reduction programme can classify a large population and flatten the signal; and the software-as-a-service application classifications added in June, of which there are fifteen covering the Microsoft estate, because those only populate if Defender for Cloud Apps is onboarded and will otherwise sit there classifying nothing while appearing configured. Each rule carries a default criticality that you can change, and changing it is often the better move than disabling the rule outright.
| Criticality | Reserve it for | Why |
|---|---|---|
| Very High | Assets whose compromise is an organisation-level event: tier-zero identity infrastructure, the certificate authority, the assets an attack path would call an End Game | Anything above a few dozen assets at this level means the level has stopped distinguishing anything. |
| High | Production systems the business notices within the hour | The working tier. Most of what genuinely matters lives here. |
| Medium | Assets with real but bounded impact, including most predefined defaults | A sensible landing place for a predefined rule you do not want to disable but do not want ranked above your own. |
| Low | Known-but-unimportant assets you still want visible | Better than leaving something unclassified, because it records that a decision was made. |
Step 4: Author one custom rule, from a convention you already have
Custom classification is created in the Defender portal under critical asset management in the rules area, and a rule needs a name, a description, and a set of query-builder conditions defined against devices, identities or cloud resources. You then preview the assets it matches before assigning a criticality. That preview step is the important one and people skip it: a rule that matches four thousand devices is telling you something is wrong with the rule, not that you have four thousand critical assets.
Worked example. An estate names its tier-zero servers with a T0- prefix, a convention introduced three years ago and applied consistently since. Two finance systems predate it and carry legacy names. The build is one rule plus two manual assignments.
| Field | Value | Why |
|---|---|---|
| Name | CRIT-Device-Tier0-Prefix | Names the asset type and the basis of the rule, so a later reviewer knows what it depends on without opening it. |
| Description | Devices matching the T0- naming standard, owner Platform Engineering, reviewed quarterly | Records the owner and the review cadence. The description is the only place either can live. |
| Query condition | Device name starts with T0- | Rides an existing convention rather than inventing a new one, which is why it will still be accurate next year. |
| Criticality | Very High | These are the assets an on-premises attack path terminates at. If they are not very high, nothing is. |
| Preview before saving | Expect a count matching your tier-zero inventory, within one or two | A count far above your inventory means the prefix is in use somewhere you did not expect. Investigate before saving, not after. |
Then assign the two legacy finance servers manually, at High rather than Very High, and note in your own documentation that they are exceptions to the convention. The manual assignment is the right tool for a handful of assets and the wrong tool for a category; if you find yourself manually classifying a dozen things that have something in common, that commonality is a rule.
Two limits to design around. Identity rules currently work against Active Directory groups rather than Entra ID groups, so a cloud-first estate cannot express identity criticality through the directory groups it actually maintains, and needs another attribute. And there is no application programming interface for any of this: classification rules are created in the portal only. Defender for Cloud offers an equivalent creation experience for resource criticality and the rules synchronise between the two, so if your cloud team already classifies resources there, check before duplicating the work.
Step 5: Choose an initiative set, deliberately
Every initiative is scored whether or not you are working it, which means an unchosen set produces a wall of percentages with no owner and no meaning. Pick a small number, assign each an owner, and ignore the rest until you have capacity. My defensible opener for a tenant new to this is three, and the reasoning matters more than the selection.
| Initiative | Why this one | Owner |
|---|---|---|
| Ransomware | The threat model almost every organisation is actually funded against, and the one an executive will ask about by name. | Security operations |
| Critical asset protection | It reads the classification work you did in step 4, so it is the initiative that tells you whether that work was any good. | Whoever owns classification |
| The endpoint workload initiative | Maps onto the pillar you have already built and staffed, so progress is achievable rather than aspirational. | Endpoint engineering |
Zero Trust is the obvious fourth and I deliberately leave it out of an opener, because it is a programme rather than a project and its score will barely move in the first two quarters, which teaches a new team that the numbers here do not respond to effort. Add it once something else has visibly improved. Note also that the catalogue is not stable: Microsoft warns that threat-based initiatives may be temporarily removed and return later, so do not build a report that breaks when one disappears, and never publish a count of initiatives as a metric.
Step 6: Set weights and one target score
Within an initiative, each metric carries a weight of high, medium or low, or can be set to risk accepted, and the initiative score is the weighted rollup. Setting a weight requires the manage permission with coverage of all device groups, which is why step 2 insisted on that scope. Set a target score on one initiative only to begin with, so there is a single number the organisation is actually trying to move.
| Setting | Value | Why |
|---|---|---|
| Metric weight | High, Medium or Low | Your statement of how much this metric matters here. Leave defaults alone unless you can say why they are wrong for your estate. |
| Risk accepted | Only with the same rigour as any other accepted risk | This removes a metric’s drag on the score. It is a risk acceptance wearing the clothes of a display preference, and it should be recorded in the same register as an exception. |
| Target score | One initiative, one target, set from where you actually are | A target set from the current score plus a realistic delta is a plan. A target of one hundred percent is a wish and will be read as one. |
None of step 5 or step 6 can be automated. There is no interface for initiatives, metrics, weights, target scores or attack paths, in any version. Whatever you configure here is configured by a person in a portal, and the only durable record of the reasoning is the one you write yourself.
Step 7: Prove the graph sees what you told it
The end-to-end test is a single question: did the criticality I assigned in step 4 reach the graph that everything downstream reads from. Confirm it three ways, in this order, because each rules out a different failure.
First, open the device page for one asset matched by your rule and confirm it shows the criticality you assigned rather than none. That proves the rule matched. Second, look at attack paths and confirm paths terminating at those assets are now surfaced ahead of others, which proves the classification is being consumed rather than merely stored. Third, and this is the one that leaves evidence, query the exposure graph directly.
// End-to-end test: does the graph hold the criticality you assigned?
// Run in Defender advanced hunting. Replace the device name with one
// your step 4 rule matched.
ExposureGraphNodes
| where set_has_element(Categories, "device")
| where NodeName =~ "t0-dc-01"
| where isnotnull(NodeProperties.rawData.criticalityLevel)
| project NodeId, NodeName, EntityIds,
CriticalityLevel = NodeProperties.rawData.criticalityLevel.criticalityLevelExpected result is a single row carrying a criticality value. An empty result has two distinct causes and they need separating: drop the criticality filter and re-run, and if the device now appears, the node is in the graph but unclassified, which points at the rule; if it still does not appear, the asset is not in the graph at all, which points at sensor coverage from step 1. That distinction is the whole diagnostic value of running this query rather than trusting the device page.
One deliberate omission. Microsoft’s own published examples compare the criticality value numerically and do so inconsistently, with adjacent examples using opposite comparisons, and separate documentation indicates lower numbers mean more critical. Because the direction is documented contradictorily, this sheet projects the value and does not filter on a threshold. Read the number for your own assets and establish the direction in your tenant before writing anything that depends on it. Printing a comparison here that turned out to be inverted would produce a query that silently returns exactly the wrong population, which is worse than no query.
The relationship table is the other half of the graph and is worth one exploratory query so you know what is there, walking outward from a classified asset to what connects to it.
// What connects to a critical asset. Orientation, not analysis:
// hunting depth belongs to the capstone.
ExposureGraphEdges
| where TargetNodeName =~ "t0-dc-01"
| project EdgeLabel, SourceNodeName, SourceNodeLabel, TargetNodeName
| take 50What this build cannot do
Almost all of it is portal work, and that is not an oversight to route around. There is no interface for classification rules, initiatives, metrics, weights, target scores or attack paths. The only programmatic reach into this product is the two exposure graph tables through advanced hunting, and if you drive those from a pipeline, call them through the Microsoft Graph hunting interface rather than the legacy endpoints, which stop returning data on the first of February 2027. Everything else is a person making a judgement and recording it, which for a product whose entire job is encoding what matters to your organisation is arguably the correct design.
What remains is the number that leaves this console entirely and reaches people who will never open it. Every pillar in this suite rolls up into one figure that gets reported upward, and that figure has properties worth understanding before somebody puts it on a slide. That is Secure Score.
Defender XDR
‹ Previous: [D 6.2] Security Exposure Management: The Attacker’s Map of Your Tenant
Next: [D 6.3] Secure Score: The Number the Board Sees ›
