Defender for Cloud Secure Score¶
Secure Score is Microsoft Defender for Cloud's single-number summary of security posture. It shows how much of the Microsoft Cloud Security Benchmark (MCSB) your resources currently meet. It is useful for seeing trends and deciding priorities, but it is a ratio that Microsoft, your estate and your viewing scope can all move. A score that goes from 80% to 50% to 60% in three weeks usually means the thing being measured changed, not that security got suddenly worse and then partly better.
What it is¶
Defender for Cloud continuously assesses resources against the Microsoft Cloud Security Benchmark (MCSB). Each failed check becomes a recommendation, for example "Storage accounts should restrict network access". Recommendations are grouped into security controls, such as Secure management ports, Enable MFA or Restrict unauthorized network access. Each control is worth a maximum number of points.
| Term | Meaning |
|---|---|
| Recommendation | One check, evaluated per resource. Each resource is healthy, unhealthy or not applicable. |
| Security control | A group of related recommendations with a maximum score. The group reflects one real risk. |
| Control score | Max points × (healthy resources ÷ all assessed resources in that control). You get partial credit. |
| Secure Score | The sum of control scores ÷ the sum of maximum scores, shown as a percentage. |
Secure Score is calculated per subscription. Scores for a management group or the whole tenant combine the subscriptions you can see, weighted by their size.
Two versions of the score
Microsoft is introducing a newer, risk-based cloud secure score in the Microsoft Defender portal. It also weighs how critical and exposed each asset is. The classic control-based score in the Azure portal works as described above. Don't compare numbers from the two: they are calculated differently.
Where the recommendations come from in this tenant¶
The score is driven by Defender's own MCSB policy assignment, SecurityCenterBuiltIn ("ASC Default"). Defender creates it automatically on every subscription. The tenant also assigns MCSB through EPAC (psa-sec-mcsb-001) for compliance reporting, but that assignment does not feed the score.
The azure-mcsb-overrides deployment turns off controls that can never be met under the tenant's operating model. An example is "more than one owner on subscriptions", which is permanently non-compliant because Owner is granted just-in-time through PIM. Disabling a control removes it from the calculation, so changing the override list changes the score. Sandboxes are not included in the overrides.
Why it exists¶
- One view of posture across many subscriptions. It shows where things stand without reading hundreds of recommendations.
- Prioritisation. Each control's "potential score increase" shows which fixes improve posture most. Fixing one high-value control usually beats many low-value recommendations.
- Trend and accountability. Tracked per subscription or management group over time, it shows whether each area is getting better or worse.
It is not a compliance certificate, a count of vulnerabilities, or a measure of threat activity. A tenant can score 90% and still hold a single critical exposure.
Why the score jumps week to week¶
Secure Score is a fraction: healthy ÷ total, per control, then combined across controls and subscriptions. The top and bottom of that fraction can both change for reasons that have nothing to do with your security work. In a small tenant, a handful of resources carries a lot of weight, so the swings are larger.
Common causes¶
| What happened | Effect on the score | Why |
|---|---|---|
| A new subscription or workload was deployed | ⬇ Often large | New resources are usually unhealthy until hardened, and until they are first assessed. A new subscription also adds its own weight to the combined score. |
| A Defender plan was switched on, for example Defender for Servers | ⬇ | The plan adds recommendations, such as endpoint protection and vulnerability assessment, that didn't count before. There are more ways to fail. |
| Microsoft changed the benchmark | ⬇ or ⬆ with no change on your side | New recommendations are added, preview recommendations become generally available and start to count, and control weights change. |
| The viewing scope changed | ⬇ or ⬆ | The portal and reports only include subscriptions the viewer can see. If JIT reader access expired, the portal subscription filter changed, or a report ran with a different identity, a different estate was measured. |
| Exemptions expired or were added | ⬇ or ⬆ | An exempted resource leaves the calculation. When the exemption expires, it counts as unhealthy again. |
Controls were disabled or re-enabled (azure-mcsb-overrides) |
⬆ or ⬇ | The whole control enters or leaves the calculation. |
| Resources were deleted | ⬆ or ⬇ | Deleting unhealthy resources raises the score. Deleting healthy ones leaves the unhealthy ones as a larger share. |
| Fixes and regressions | ⬆ then ⬇ | A setting fixed in the portal is reverted by the next Terraform apply, or a new deployment uses an old module version. |
| Assessment timing | ⬇ or ⬆ temporarily | Most recommendations refresh within about 24 hours, but some take longer. A snapshot taken mid-refresh mixes old and new results. |
| Policy remediation ran | ⬆ | DeployIfNotExists remediation tasks, which are run by hand in this tenant because assignments use DoNotEnforce, fix many resources at once. |
Worked example: 80% → 50% → 60%¶
A small estate, measured once a week:
| Week | What changed | Healthy / total checks | Score |
|---|---|---|---|
| 1 | Only the management subscription, which is mostly hardened | 40 / 50 | 80% |
| 2 | A workload subscription is vended with 20 new resources, and Defender for Servers is enabled on it. That adds about 30 new checks, and nearly all are unhealthy on day one. | 45 / 90 | 50% |
| 3 | Quick wins fixed on the new resources (TLS, public access, diagnostic settings). Two recommendations that can't apply get exemptions, so they leave the total. | 53 / 88 | 60% |
The management subscription got no worse between weeks 1 and 2. The estate being measured got bigger, and the new part was not yet hardened. The score in week 3 reflects real progress, but from a new baseline.
(This is simplified to one pool of checks. The real score weights each control separately, but the effect is the same.)
Reading the score properly¶
- Always report the score together with its denominator. Include the number of subscriptions in scope, the number of assessed resources, and the healthy and unhealthy counts. A score without these can't be compared from week to week.
- Explain every swing of more than about 5 points. Check the causes table first. Most swings are denominator or scope changes.
- Track per subscription and per control, not only the tenant total. A tenant-wide drop is usually one new subscription or one newly counted control.
- Aim for a band, not a number. For example: "Platform subscriptions stay above 75%. New workload subscriptions reach 70% within 30 days of vending."
- Work on recommendations, not the score. Disabling controls or adding exemptions to lift the number hides risk. Use exemptions only for real non-applicability or accepted risk, and give them an expiry date.
Tracking it over time¶
Query the current score for every subscription the identity can see with Azure Resource Graph:
securityresources
| where type == "microsoft.security/securescores"
| extend pct = todouble(properties.score.percentage) * 100,
current = todouble(properties.score.current),
maxScore = todouble(properties.score.max),
weight = toint(properties.weight)
| project subscriptionId, pct = round(pct, 1), current, maxScore, weight
| order by pct asc
For a history, turn on Defender for Cloud continuous export of Secure score and Security controls to the central log-platform-prod workspace. That creates the SecureScores and SecureScoreControls tables, which can be queried and trended alongside the Activity Log. Keep in mind:
- The AzGovViz analyzer's Platform Secure Score pillar reported 0 in its last run because it had no Secure Score data, not because posture was zero. Continuous export, or running the reporting identity with visibility of every subscription, gives it real data.
- Record which identity collected each data point, and its scope. If the scope changes, the trend breaks.