Microsoft Secure Score is a starting line, not a finish line

Microsoft Secure Score is a genuinely useful tool. It turns a sprawling set of identity, device, and data controls into a single, trackable number - which makes it easy to show progress to a board or an insurer. But the number is a means, not the end. Used carelessly, it can push teams toward the controls that are easy to switch on rather than the ones that matter.

Why the number can mislead

Secure Score weights actions by Microsoft's general model of impact, not your specific environment. Two failure modes follow:

• Box-ticking. Enabling a recommendation to claim points - without rolling it out properly - raises the score while leaving the risk in place.
• Wrong order. Easy, low-impact actions get done first because they move the number, while harder, high-impact work (privileged access, Conditional Access coverage, legacy authentication) waits.

A more durable approach

Treat Secure Score as one input into a risk-ranked hardening plan:

1. Baseline first. Establish a Conditional Access baseline and close legacy authentication before optimising anything else.
2. Prioritise by real risk. Rank actions by exposure in your tenant - account takeover paths, oversharing, unmanaged devices - not just by points available.
3. Make it repeatable. Document the configuration so it survives staff changes and can be reapplied across tenants. This is where infrastructure-as-code and well-defined baselines earn their keep.
4. Re-measure. Use Secure Score to confirm the plan landed and to watch for drift - not to drive the plan.

Done this way, a score that climbs from the low ranges toward ~90% reflects real, repeatable hardening - exactly what a cyber-insurer or auditor wants to see.

The takeaway

A high Secure Score should be the evidence of good security work, not the goal that defines it. Anchor the work in risk, make it repeatable, and let the number follow.