A vulnerability list is a set of facts with no argument attached. Ten thousand findings, sorted by severity, tell you nothing about which of them an attacker could actually chain into something that matters, and every security team I have worked with has felt the gap between the queue they are working and the compromise they are afraid of. Security Exposure Management closes that gap by changing the question. It stops asking what is broken and starts asking what is reachable, from where, ending at what. The console is the least interesting part of it. The reframing is the product, and once you have seen your estate drawn as routes rather than as a list, the list stops feeling like the job.
The graph underneath
Everything here rests on one structure: a graph of your estate in which devices, identities, cloud resources and software-as-a-service applications are nodes, and the relationships between them are edges. That graph is assembled from whichever Defender workloads you have deployed, which is the first thing to understand about its value. It is not a scanner producing a fixed output. It is a model whose usefulness scales with how much of your estate is represented in it, and Microsoft says as much when it warns that attack paths might not be fully representative if the workloads involved are not licensed and integrated. A tenant with endpoints but no identity coverage gets a map with a continent missing, and the map will not tell you which continent.
What the graph produces first is attack paths, and their construction differs in a way worth knowing. Cloud paths begin at externally exploitable entry points, and the platform performs active reachability scanning to validate that an exposure really is accessible from outside rather than merely theoretically so. On-premises paths run the other direction and terminate at what Microsoft calls End Game assets, which it names precisely: Domain Admins, Enterprise Admins, Administrators and domain controllers. Hybrid paths, which cross from on-premises into cloud, have been part of the product since it became generally available in November 2024 and were enhanced in November 2025 when cloud posture management folded in. That validated-reachability property is what separates this from a decade of theoretical attack-path tools, most of which produced a graph so dense with hypothetical routes that nobody read the second page.
The two derived views are where the operational value sits. Choke points identify the assets that appear across many paths, which is the answer to the question every remediation programme is actually asking: if I can only fix one thing this month, which one collapses the most routes. Blast radius runs the other way, from a compromised asset outward to what it reaches. I find choke points the more valuable of the two by a wide margin, because they convert an unranked queue into a ranked one on a basis a non-specialist can follow. Telling a change board that one server sits on forty attack paths is an argument. Telling them it has a severity nine vulnerability is a number they have learned to discount.
A choke point converts an unranked queue into a ranked one on a basis a change board can actually follow.
Criticality is the input you own, and almost nobody supplies it
The graph knows your topology. It does not know your business, and the mechanism through which you tell it is critical asset classification. Assets carry a criticality of very high, high, medium or low, and devices with no classification carry none. That value is not decoration. It feeds the rebuilt exposure score, it weights which attack paths are surfaced first, it drives the critical asset protection initiative, and it is visible in inventory and in hunting. It is, in other words, one of the few places in this entire suite where an hour of your judgement measurably improves the platform’s output.
Microsoft ships a growing catalogue of predefined classifications and has been extending it steadily: a Windows Server Update Services role in January 2026, application programming interfaces holding sensitive data in April, senior executive workstations in May, and in June a set covering identities holding widespread local administrator rights along with fifteen classifications for Microsoft software-as-a-service applications, which require Defender for Cloud Apps onboarding to populate. June also introduced something structurally new: AI agent became a fourth asset type alongside device, identity and cloud resource, currently carrying a single classification for executive-sponsored agents. One rule is not a lot. A new asset type in the graph is quite a lot, and it is the clearest signal available about where this product is going next.
The predefined set is a starting point and should be reviewed rather than accepted, because a classification that misfires in your estate is worse than none: it pushes attack paths you do not care about to the top of a list somebody is working through. The custom rules are where the real value is, and they are built from a query over your own attributes, which in practice means the naming convention you already maintain. If your tier-zero servers are identifiable by name, you can classify them in one rule, and everything downstream improves at once. One documented limit to design around: identity rules currently work against Active Directory groups rather than Entra ID groups, which is an awkward constraint for a cloud-first estate and worth checking before you plan around directory groups you keep in the cloud.
Initiatives, and reading them with the right expectations
Above the graph sits a management layer of initiatives: named programmes such as ransomware, business email compromise, Zero Trust, critical asset protection, and per-workload sets for endpoint, identity and cloud. Each carries metrics, each metric carries a weight you can set to high, medium, low or risk accepted, and the initiative score is a percentage rollup of those weighted metrics running from high exposure to none. You can set a target score, and the product tracks a fourteen-day trend and raises events when a score drops.
Two honesty notes belong with any use of this. The first is that the catalogue is not stable and Microsoft says so, warning that threat-based initiatives may have been temporarily removed and could return in future releases. That is unusually candid and it has a direct governance consequence: never build a report whose structure assumes a particular initiative exists, and never publish a count of them. The second is that the weights are yours. That is a genuine control, because it lets you say that a metric is not relevant to your estate, and it is also a genuine risk, because a set of weights tuned until the number looked acceptable is indistinguishable from a set tuned to reflect real priorities. Whoever sets weights should have to explain them, and setting one to risk accepted is a decision that deserves the same register as any other accepted risk.
The score underneath it all is mid-migration
The exposure score changed model in June 2026 and the change is real improvement. Prioritization now weights exploit prediction alongside severity, so a vulnerability people are actually exploiting outranks a theoretically worse one that nobody has weaponised. Asset scoring combines every relevant vulnerability rather than over-weighting the single worst, which stops one unfixable finding from pinning a machine at maximum forever. Internet-facing status and criticality both feed in, which is where the classification work pays back. The organisation score is the average of asset scores, and Microsoft does not publish the weighting, so the honest thing to do is describe the factors and never imply you can reproduce the arithmetic.
The part that needs saying out loud is that the migration is staged and, as I write, incomplete. Two models are live across the tenant estate. The documentation states that depending on rollout stage your tenant might show either experience, and there is no banner, no toggle and no documented way to establish which one you are looking at. So the score can move, and recommendation priorities can reorder, for reasons that have nothing to do with your environment. If you have committed this number to a board pack or a contractual target, say now that it is mid-migration, in writing, before it moves. Explaining that in advance is a briefing. Explaining it after a bad quarter is an excuse, and it will be heard as one.
What is generally available, what is not, and what it costs
The core of this product went generally available in November 2024 and the substantial capabilities are in that state: the attack surface map, attack paths with their choke point and blast radius views, critical asset management, initiatives and metrics, and the exposure graph with its hunting tables. It is not available in sovereign clouds, and Microsoft’s current wording is broader than the older list of specific government clouds: public cloud only, not available in national or sovereign clouds. Several things around the edges remain in preview, and the honest list matters more than the headline. The navigation migration for existing vulnerability management customers is still preview. Cloud software inventory is preview. A redesigned overview experience organised around resolving and monitoring is preview. And the data connector framework as a whole is still labelled preview even where individual connectors have shipped.
Those connectors are the one place money enters the picture, and the current position needs stating carefully because it is frequently reported wrong in both directions. Connectors for third-party security products and, since July 2026, for operational technology platforms from Armis, Dragos and Forescout, are available and are free while in preview. Microsoft has disclosed the pricing model, consumption-based according to the number of assets retrieved, and has not published prices, saying only that pricing will be announced before billing begins at general availability. So this is not free forever and it is not billing today. If you are building a business case that depends on ingesting a third-party vulnerability scanner, put a placeholder in it and expect to fill the number in later.
Everything else here carries no additional cost, and the licensing breadth is the genuinely unusual thing about this product. 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, as do Microsoft 365 E5, Business Premium, Defender for Business and several others. A tenant on bare E3 or Office 365 Plan 1 gets a limited, Secure-Score-only view. In practice that means most organisations with any Defender investment already own this outright and a good number have never opened it. It is the rare capability where the deployment question is not whether you can afford it but whether anybody has looked.
Where this pillar stops
The graph is queryable through advanced hunting, and the exposure node and edge tables are the surface for that. I will name them and go no further here, because a query language is a subject rather than an aside and it belongs to the capstone. Identity posture assessments and software-as-a-service posture appear in this console as inputs; their depth lives in the identity block and the cloud apps block respectively. Cloud security posture management from Defender for Cloud now shares this surface, which is worth knowing when you open the recommendations catalogue and find findings from a product this series does not cover.
None of this does anything until somebody classifies an asset, sets a weight and grants a role, and those are small, specific, consequential actions with an order that matters. That is the build sheet.
Defender XDR
‹ Previous: [D 6.1.1] Build Sheet: The Remediation Loop from Defender to Intune
Next: [D 6.2.1] Build Sheet: Standing Up Exposure Management ›
