Microsoft Secure Score: a useful roadmap, a misleading target
Secure Score is often the first figure shown to the executive committee when discussing Microsoft 365 security. It has the merit of existing and of being tracked over time. But we regularly come across tenants with a flattering score and major weaknesses, and the reverse. You need to know what it measures, and what it does not.
How the score is calculated
Secure Score, available in the Defender portal, adds up points awarded for recommended actions: enabling a protection, turning off a risky setting, applying a policy. Each action has a maximum value, and the score is expressed as a percentage of the total available.
Some actions are binary; others award partial points according to the proportion of users or devices covered. Actions are grouped by category: identity, data, devices, apps. The list depends on the products and licences in the tenant, and it changes: when Microsoft adds recommendations, the maximum score changes and the percentage can drop without anything having been modified. Data is not updated instantly; a change can take up to a day or two to show.
Why a high score can be misleading
The score measures whether configurations are present, not how effective they are. Several situations distort the picture:
- a Conditional Access policy requiring MFA exists but excludes a large group of users or apps;
- a protection is enabled with exceptions that strip it of any real value;
- actions have been marked as handled by a third-party solution without anyone checking;
- major risks are not covered by the recommendations at all: dangerous Active Directory delegations, apps with excessive permissions, privileged service accounts, broken leaver processes.
Secure Score describes the gap against Microsoft's recommendations for its own products. It does not replace attack path analysis, a privilege review or a test of incident response.
Third-party and alternate mitigations
For each action you can change its status:
- Resolved through third party or resolved through alternate mitigation: the points are awarded, because another measure covers the risk;
- Risk accepted: no points are awarded; the decision is simply recorded;
- Planned: the action is placed on the roadmap.
These statuses are legitimate: a third-party email filter or a different device management tool can genuinely meet the need. But they are declarative. Nothing checks that the third-party solution exists, is correctly configured and covers the whole scope.
A simple checkpoint. Export the list of actions marked as resolved through a third party or an alternate mitigation. For each one, ask for evidence of the compensating measure and the name of its owner. In our audits, this check alone often reveals significant gaps.
A numeric target has side effects
Setting a score target, such as "reach 80%", encourages teams to prioritise easy actions worth many points and to mark awkward ones as handled. The score goes up; the real risk barely moves. It is the classic effect of any indicator turned into a target.
The comparisons with similar organisations offered in the portal should be read with the same caution: they say nothing about the threats specific to your sector or your actual exposure.
Using it as a roadmap
Used well, Secure Score is an excellent steering tool:
- start from the list of actions and rank them according to your own risk analysis, not just by points;
- take into account the user impact and implementation effort shown for each action;
- assign each action to an owner with a deadline, using the "planned" status;
- document every accepted risk with a review date;
- track the history to show progress, explaining changes caused by updates to the baseline.
Show the executive committee roadmap progress and accepted risks rather than an isolated percentage.
What an audit checks
- The current score, its history and changes caused by baseline updates.
- Actions marked as resolved through a third party or alternate mitigation, and the evidence behind them.
- Accepted risks, their justification and their review date.
- The gap between validated actions and the actual configuration, especially exclusions.
- Whether a roadmap exists with owners and deadlines.
- Significant risks that Secure Score does not cover.