.jpg)
Deirdre Hennigar
Subject matter expert
Overview
Microsoft Secure Score can turn a sprawling Microsoft environment into a practical list of security improvements. It can also invite the wrong conversation when the percentage becomes the objective.
Microsoft describes Secure Score as a numerical summary of security posture based on configurations, user behaviour, and other security-related measurements. It represents the extent to which an organization has adopted controls that can help offset risk. Microsoft is equally clear about what the number is not: an absolute measurement of breach likelihood or a guarantee against compromise.
A concrete example: when a better score still leaves important risk
Consider an organization whose Secure Score increased after it deployed a new authentication policy across most of its workforce. From the dashboard, the improvement appeared significant. During a subsequent security review, however, the organization discovered that a privileged administrator and several operational accounts had been excluded from the policy.
The control covered nearly everyone, and the score reflected that progress. Yet the small group left outside the policy included identities capable of creating accounts, changing security settings, and accessing sensitive systems. From a business-risk perspective, that remaining exposure mattered more than the percentage suggested.
The organization corrected two unintended exclusions, documented the exceptions that were operationally necessary, and tested the relevant sign-in path. The Secure Score increase remained useful, but the more meaningful outcome was that a high-impact route to compromise had been reduced and the control had been proven to work.
The short version
Use the score for
- Discovering Microsoft security recommendations.
- Tracking adoption and coverage over time.
- Assigning owners and planning improvements.
- Starting a risk-based security conversation.
Do not mistake it for
- Proof that controls work as intended.
- A complete view of every attack path.
- A guarantee that compromise will not occur.
- A universal target that must reach 100%.
The operating principle:
The goal is not to make the dashboard greener. It is to make compromise harder, detection faster, and the consequences smaller.
What actually contributes to the score
Secure Score brings together recommended actions across the Microsoft products visible to the tenant. In the Defender portal, those actions are organized into four broad groups.
Identity
Accounts, authentication, administrative roles, access policies, and other controls that shape who can sign in and what they can do.
Device
Endpoint configuration, exposure, protection, and vulnerability-management actions reported through supported Microsoft services.
Apps
Email and cloud application controls, including actions associated with Microsoft 365 and Defender for Cloud Apps.
Data
Information-protection controls that help reduce inappropriate access, sharing, or loss of sensitive information.
Points can be awarded for configuring a recommended feature, completing a security-related task, or recording that a recommendation is addressed through a non-Microsoft product or an alternate mitigation. The available recommendations depend on the products and data connected to the tenant.
Most recommendations are scored in one of two ways. A binary action awards its points only when the action is fully completed. A proportional action awards partial credit according to coverage across users, devices, or other resources.
Why scores rise, fall, lag, or fail to load
A score is the output of a measurement system, not a direct reading from every control at the instant you open the page. Microsoft says the Secure Score experience updates its displayed information and also synchronizes daily to receive system data. Completed recommended actions can take 24 to 48 hours to appear, while some Microsoft Teams and Entra recommendation states follow their own monthly or weekly refresh cycles.
The score can also move because the measurement context changed. Microsoft may add or revise a recommendation. A newly connected workload can bring more possible points into scope. The number of users or devices evaluated by a proportional control can change. A licence or product deployment can expose additional recommendations.
This creates two apparently contradictory situations. A security team can improve a meaningful control and temporarily see no change. It can also do good work while the percentage falls because the denominator or evaluated population changed.
When the number moves unexpectedly, start with the history and recommendation details. Ask what changed in the achieved points, possible points, evaluated population, connected products, and status data before treating the movement as a security event.
Partial coverage can hide meaningful exposure
Partial scoring is useful because it recognizes progress. It can also compress an important operational fact into a reassuring fraction.
If a control protects 50 of 100 users, a proportional recommendation may award about half of its available points. The score records progress. The security team still needs to explain who the other 50 users are, why they remain outside the control, and whether any of them have privileged or high-impact access.
50% covered
Coverage should therefore be read in both directions. “Ninety-five percent protected” sounds strong; “five percent unprotected” prompts the questions that matter. Are those exclusions intentional? Do they include administrators, service accounts, shared devices, emergency access accounts, or systems that cannot tolerate the default policy? Is an alternate control actually operating?
The remaining slice is not always the least important slice. In the earlier example, the authentication policy covered most users, but a single excluded privileged administrator represented greater potential business impact than many lower-risk accounts combined. A small gap around a privileged identity or critical workstation can matter more than broad coverage of lower-impact assets.
Why 100% is rarely the right objective
A perfect score can be incompatible with how an organization works. Some recommendations require licensing, architectural changes, user disruption, or operational prerequisites that are not appropriate for every environment. Others may conflict with a legitimate business process or be addressed by a control Microsoft cannot observe.
Chasing every point can also distort priority. A team may complete several easy, low-impact recommendations while leaving a difficult control on a probable attack path unresolved. The dashboard becomes greener, but the outcome an attacker can achieve has not changed enough.
Microsoft's own Identity Secure Score guidance advises organizations to focus on high-importance recommendations that are relevant to them instead of aiming for a specific minimum score. A mature target is not “100%.” It is complete treatment of the recommendations that matter: implemented, planned with accountable dates, or consciously accepted with evidence and review.
Prioritize recommendations by attack impact
The default ranking is useful for finding achievable improvements. Microsoft says ranking considers points remaining, implementation difficulty, user impact, and complexity. That is not the same as an organization-specific risk ranking.
Add business and attack context before scheduling the work.
1
Start with attack impact
Ask what an attacker could achieve if the gap were exploited. Prioritize privileged identities, phishing-resistant authentication, legacy authentication, endpoint coverage, email compromise, external sharing, role hygiene, and detection visibility.
2
Measure exposure
Identify the users, devices, applications, and critical systems outside the control. Count the gap, then examine the importance of what remains exposed.
3
Consider feasibility
Account for prerequisites, licences, user impact, operational ownership, and implementation complexity. Use these factors to sequence the work.
4
Validate the outcome
Confirm assignment, enforcement, logging, alert delivery, and resistance to likely bypasses. Evidence that the control changes an attack outcome is stronger than points alone.
Configuration is not validation
Secure Score is strongest at answering a configuration question: does Microsoft detect that the recommended action has been adopted? Security leaders need a second answer: does the control operate correctly against the attack behaviour it is supposed to stop or reveal?
A policy can exist and still be scoped to the wrong group. A device control can be deployed while a critical endpoint remains unhealthy. An alert can fire into a queue no one owns. Multifactor authentication can be enabled while administrators still rely on methods vulnerable to phishing. A recommendation can be marked as resolved through an alternate mitigation that no one has tested in a year.
Validation should confirm that:
- The policy is assigned to the intended identities, devices, and applications.
- Exclusions are documented, minimal, and periodically reviewed.
- The control is enforced, not merely configured.
- Expected telemetry and alerts reach a monitored destination.
- Responders know what to do when the control detects suspicious behaviour.
- Safe testing demonstrates that the control prevents, detects, or contains the relevant technique.
In the earlier scenario, seeing the authentication policy in the tenant established only that it had been configured. Reviewing its scope exposed the unintended exclusions, while safe testing demonstrated whether the policy actually blocked the relevant sign-in path and produced an alert for responders.
The distinction is simple: configuration creates an intended state; validation produces evidence about the real state.
Report progress to leadership without hiding the risk
Secure Score can be a useful executive metric when it is presented as a trend with context. A percentage by itself invites false certainty. Pair it with measures that show what changed and why it matters.
Score and trend
Show the current achieved and possible points, the direction over time, and any material denominator or product-scope changes.
Risk reduction delivered
Name the high-impact controls completed and the attack paths, identities, devices, or data they protect.
Coverage and exceptions
Report the protected population, what remains outside the control, and whether exclusions are intentional and owned.
Accepted and deferred risk
Summarize important risk acceptances, alternate mitigations, licensing dependencies, target dates, and accountable owners.
Validation evidence
Include the results of configuration reviews, control tests, breach-and-attack exercises, alert-routing checks, and remediation retests. This explains whether the improvement changed an attack outcome—not only whether it changed the dashboard.
Returning to the earlier example, a practical leadership statement might read: “Secure Score increased from 61% to 68%. More importantly, all privileged administrators are now covered by the new authentication policy, two unintended exclusions were removed, and validation confirmed that the tested sign-in path was blocked and alerted. Three lower-impact recommendations remain risk accepted with review dates.”
That is more informative than “we gained seven points” because it connects the metric to coverage, attack impact, evidence, and remaining risk.
Turn posture management into demonstrated resilience
Secure Score is a useful source of direction. It helps teams discover recommended controls, organize work, track adoption, and explain progress. The mistake is asking it to answer questions it was not designed to answer.
Posture management identifies where controls should exist. Breach-and-attack validation tests whether those controls change the result when realistic techniques meet the environment. Used together, they create a stronger operating loop: prioritize the likely attack path, implement the control, confirm coverage, test the outcome, remediate what failed, and test again.
That is the journey worth measuring. Not the shortest path to 100%, but a defensible path toward making compromise harder, detection faster, and the consequences smaller.
Sources
- Microsoft Learn Microsoft Secure Score
- Microsoft Learn Assess your security posture with Microsoft Secure Score
- Microsoft Learn What is the Identity Secure Score?