Every other measurement in this suite is read by people who understand it. Secure Score is different, because it is a single figure that aggregates identity, devices, applications and data into one number, and single numbers travel. It reaches steering committees, board packs, insurance questionnaires and, more than once in my experience, a contractual target. The moment a number leaves the people who understand it and reaches people who will be held to it, it stops being a measurement and becomes an incentive, and incentives get optimised. The interesting design question is therefore not how to raise your Secure Score. It is deciding what your organisation is permitted to do to it, and writing that down before somebody discovers on their own how easy the alternative is.
What actually feeds it
The score is built from recommended actions across four categories, each worth ten points or fewer, most scored as done or not done and some proportionally so that half your users covered by a control earns half the points. The categories are identity, covering Entra accounts and roles; device, which is Defender for Endpoint and vulnerability management; apps, covering email and cloud applications; and data, through information protection. Worth noting because it causes arguments: the label is apps, not cloud apps, although Microsoft’s own release notes have used the latter, and the documentation is internally inconsistent about the data category’s product name.
The list of products that contribute is published and specific, and it is worth reading rather than assuming, because it is both wider and narrower than people expect. It covers app governance, Entra ID, Citrix ShareFile, Defender for Endpoint, Defender for Identity, Defender for Office, Docusign, Exchange Online, GitHub, Defender for Cloud Apps, Purview Information Protection, Teams, Okta, Salesforce, ServiceNow, SharePoint Online and Zoom. Two observations follow. The wide part is that a properly connected estate is being scored on Salesforce and GitHub configuration, which is genuinely a whole-estate posture number rather than a Microsoft-only one. The narrow part is that Copilot appears nowhere on it, and that absence is a decision rather than staleness, because the page was revised in March 2026 and the omission survived. If somebody asks whether your Copilot deployment is reflected in the score, the answer today is no.
The roll-up, which is what this pillar owns
Every pillar in this series lands somewhere in that number, and knowing the map is what lets you answer the question people actually ask, which is why did the score move. Entra configuration and the identity posture assessments from Defender for Identity both roll into identity, and since March 2026 that category also holds a set of recommendations that used to sit under apps. Defender for Office, Exchange, SharePoint and Teams roll into apps, as do Defender for Cloud Apps and the connected third-party applications through its posture pipeline. And Defender for Endpoint with vulnerability management is the entire device category, which is a stronger statement than it looks.
It is stronger because of what happens when you try to act on a device-category action inside Secure Score: you cannot. The documentation is explicit that you cannot choose a status for a recommended action in the device category and will instead be directed to the corresponding vulnerability management security recommendation. That single redirect is this pillar’s whole architecture in one behaviour. Secure Score is the scoreboard. Vulnerability management is the workbench. The scoreboard deliberately refuses to let you change the score without going to the bench.
Secure Score is the scoreboard and vulnerability management is the workbench. The scoreboard refuses to let you change the score without going to the bench.
There is a door in that wall, though, and it is worth knowing precisely because it is where a well-meaning process goes wrong. An exception filed in vulnerability management at global scope does flow back: the Secure Score action updates with the exception justification, within a couple of hours. An exception scoped to particular device groups does not flow back, and the Secure Score action stays as still to address. So the device category is not immune to risk acceptance. The lever simply moves into another product, and it only pulls at global scope. A team that files careful, narrowly scoped exceptions will watch their Secure Score refuse to acknowledge any of that work, while a team that files broad ones will see the score improve. That is an incentive pointing in exactly the wrong direction, and it is the kind of thing you want to know before you set anybody a target.
Two instruments, opposite directions, same product
Underneath the device category sits Microsoft Secure Score for Devices, which is fed by configuration assessments across application, operating system, network, accounts and security controls, measured against collected benchmarks. It is a points score where higher is better, and it lives alongside the exposure score from the same product, which runs zero to a hundred where lower is better, and the two are calculated independently. I have laboured this point across three articles now because it is the single most common source of a bad conversation in this space, where two numbers moved in opposite directions and both were correct.
One caveat about the device score matters disproportionately to the audience for this series. The documentation states that Secure Score for Devices supports configurations set through Group Policy, and that because Intune support is currently partial, configurations set through Intune might show up as misconfigured. Read that twice if you run a cloud-managed estate. It means a device correctly configured by the management platform this entire guide is built around can be scored as though it were not, and that a Group Policy estate can outscore an Intune estate on identical settings. It is not a reason to change your management strategy. It is a reason not to let this number, unqualified, be the evidence of your endpoint posture.
The gaming surface, in Microsoft’s own words
Each recommended action carries a status, and the statuses do different things to the score in a way that is entirely defensible and entirely exploitable. Completed is awarded by Microsoft on the basis of its own data, and cannot be set by hand. Risk accepted awards zero points, which is correct, and is separately tracked on its own trend line, which is better than correct: accepted risk is visible as a category rather than hidden as an absence. Those two are sound.
The other two are the surface. Marking an action as resolved through a third party, or resolved through an alternate mitigation, awards the full points the action is worth, on your say-so. Microsoft is admirably direct about what that means, stating that it will have no visibility into the completeness of implementation when an action is marked either way. So the mechanism is: assert a compensating control, receive full credit, and no telemetry ever tests the assertion. I want to be clear that this is the right design. Microsoft cannot see your third-party tooling, and a scoring model that ignored compensating controls would drive organisations to buy Microsoft products they do not need. But a design that is right for the vendor creates an obligation for the customer, and that obligation is the point of this article.
The obligation is a policy, and it does not need to be long. Who is permitted to set an action to third-party or alternate mitigation. What evidence must exist at the time they do it, naming the specific product and configuration that constitutes the compensating control. Where that evidence lives. And when it gets re-tested, because the compensating control that was real in January is a licence somebody cancelled in June, and nothing in Secure Score will ever notice. Without that policy, the honest reading of a Secure Score is that it reflects your configuration plus an unaudited set of claims, and nobody reporting it upward usually says the second half out loud.
Reading the trend without fooling yourself
Two properties of this number make period-on-period comparison less meaningful than it appears. The first is cadence: the visualisations update in real time, the achieved points synchronise daily, a completed action can take a day or two to register, and recommendation states for Entra and Teams refresh weekly and monthly respectively. A month-end reading is therefore a blend of information of quite different ages, and a score checked the day after a large change is not yet telling you about that change.
The second is that Microsoft moves the furniture. In March 2026 a set of recommendations categorised under cloud apps were reclassified as identity-related and moved into the identity category. Microsoft’s own statement is that the total score remained unchanged while individual identity and app scores could change. If your reporting is at total level, nothing happened. If your reporting is by category, and most mature reporting is, then two of your four trend lines stepped for reasons that had nothing to do with your estate. Any category-level narrative that crosses that month is describing a taxonomy change as though it were a posture change. Annotate it, or do not report at that granularity.
There is a third property that changes how you should track this at all: the score is alive and its changelog is not. The what’s-new page for Secure Score has not had an entry since February 2024, yet at least three new recommendations shipped in 2026 alone. A recommendation for Secure Boot 2023 certificate readiness went generally available in May 2026, tied to a certificate expiry that same June. One reducing unnecessary inbound internet exposure on internet-facing devices went generally available in June 2026, enabled by default. A third, covering outbound traffic from a scripting host, entered preview in March. None of them appeared on the changelog; they arrived through the message centre. So new recommendations land in your tenant, scored and counted, and the page that exists to tell you about them will not. Your score can fall because Microsoft raised the bar, and the only reliable way to know is to read the message centre. Building a governance narrative on a number whose scoring rules change without notice is fine, as long as everybody knows that is what they are doing.
Who is allowed to touch it
Access to Secure Score under unified role-based access control is governed by the Exposure Management read and manage permissions, with Security Exposure Management as the data source. That detail is worth more than its operational weight, because it tells you what Microsoft thinks this thing is. Secure Score is no longer administered as its own product with its own roles; it is administered as a view of exposure management. Read alongside the November 2025 consolidation of cloud posture and vulnerability management under the same umbrella, the direction is not ambiguous. Exposure Management is becoming the posture surface, and Secure Score is becoming one of its outputs.
Two practical notes on that. Legacy directory roles continue to work, so nothing breaks on the day you activate the new model, and given the statuses discussed above I would treat the ability to change a recommended action’s status as a privilege worth granting narrowly rather than one that rides along with a broad administrator role. And if you pull this data for a dashboard, note that the unified model does not yet support the programmatic interface: Microsoft says to continue using directory roles for that and that support is planned later. The score and control profile endpoints themselves are current and not deprecated, so an automated pull is perfectly reasonable. It just has to authenticate the old way for now.
Where this pillar leaves you
This block opened by separating three instruments that get confused for one, and it closes on the one that leaves the building. The exposure score is operational and belongs to whoever patches. The initiative scores are programme management and belong to whoever runs the programme. Secure Score is governance, and the discipline it requires is not technical: decide who may assert a compensating control, require evidence when they do, re-test it on a schedule, annotate the months when Microsoft changed the rules, and never report a category trend across a recategorisation without saying so. Do that and this number is genuinely useful. Skip it and you have a figure that rises reliably and means less every quarter.
What none of these three instruments do is act. They measure, rank and report, and every one of them assumes a human reads the output and decides something. The last block in this series is about the layer that does not wait for that: correlation across every pillar at once, containment that fires without asking, one schema underneath all of it, and the parts of the platform you rent rather than own. That is what the suite was assembled to do, and the capstone is where it comes together.
Defender XDR
‹ Previous: [D 6.2.1] Build Sheet: Standing Up Exposure Management
Next: [D 7] The XDR Fabric: The Platform You Actually Own ›
