Security assessment
How to improve Microsoft Secure Score without breaking users
Secure Score is a useful to-do list and a poor target. Here's how to work through it in an order that raises protection without a wave of help-desk tickets.
Part of our guide: Microsoft 365 security assessment checklist (2026)
Microsoft Secure Score is built into the Microsoft Defender portal. It lists recommended actions across identity, devices, apps and data, gives each a number of points, and shows the tenant's current score as a percentage of what's achievable with its licenses. Microsoft's documentation, Microsoft Secure Score, explains how it's calculated.
Used well, it's one of the fastest ways to find missing configuration. Used as a KPI to maximize, it leads to changes being pushed out without testing, and to the reasonable conclusion among staff that "security" means things breaking.
What Secure Score does and doesn't tell you
- It's configuration-based. Each action checks whether a setting or policy is in place, such as MFA required for admins, Safe Attachments enabled or legacy authentication blocked.
- It depends on licensing. Actions for products you don't own (for example Defender for Identity) may appear as not applicable or out of reach. Compare scores between tenants with care.
- Some actions give partial credit. For example, an MFA-related action can score in proportion to how many users are covered.
- It changes over time. Microsoft adds, retires and re-weights actions. A drop in the score doesn't always mean the tenant got worse. Check the history view for what changed.
- It doesn't see everything. Controls handled by another product, process or network design won't be detected automatically.
Microsoft Entra ID has its own identity secure score in the Entra admin center, focused on identity recommendations. The identity-related actions overlap with Microsoft Secure Score; use whichever your team already reviews, but don't report both as separate achievements.
A safe workflow for working through it
Export the list. In the Defender portal, open Exposure management › Secure Score (or Secure score, depending on your portal version), go to Recommended actions and export them. You now have a baseline with a date on it.
Add two columns: user impact and effort. For each action, write down who notices the change (nobody, admins only, some users, everyone) and what it takes (a toggle, a policy with testing, a project). The action's own "user impact" and "implementation" notes in the portal are a good starting point.
Group by who is affected. Admin-only changes can often go out this week. Changes that affect sign-in, devices or sharing need a pilot group and a message to staff.
Decide, then record the decision. Every action should end up with a status: Planned (with a date), Risk accepted (with a reason and an owner), Resolved through third party or Resolved through alternate mitigation (with a note on what covers it), or done. See assess your security posture with Secure Score for the status options.
Roll out in stages. Use the testing mode each feature offers: report-only for Conditional Access, audit mode for attack surface reduction rules, pilot groups for Intune and Defender policies.
Re-check. Score updates aren't instant; allow a day or more for completed actions to be detected before you conclude something didn't work.
Be honest with statuses
The third-party and alternate-mitigation statuses exist for good reasons: another tool genuinely may cover the control. They're also the easiest way to inflate a score. Only use them where you could show the evidence to an auditor, and write that evidence in the notes. A score that reflects reality is worth more than a higher one that doesn't.
Usually low impact: start here
These kinds of actions rarely change anything staff see, and they tend to close meaningful gaps:
- Audit and logging settings, such as confirming audit log ingestion and mailbox auditing are on.
- Admin-only controls, such as requiring MFA for admin roles (once admins have registered methods) and reducing the number of Global Administrators.
- Email threat policies, such as applying the Defender for Office 365 Standard preset security policy, which is designed to be safe for most organizations.
- App consent controls, such as limiting user consent to verified publishers and low-risk permissions, with an admin consent workflow for everything else.
- Blocking external auto-forwarding in the outbound spam policy, after checking which mailboxes forward today.
"Usually" matters: check each one against the tenant. A single business process that relies on auto-forwarding, for example, turns a toggle into a small project.
Needs a rollout plan
| Type of action | Who notices | How to roll it out |
|---|---|---|
| MFA for all users | Everyone, once | Registration campaign first, then a Conditional Access policy in report-only, then enforce. See our Conditional Access baseline. |
| Block legacy authentication | Users of old apps and devices | Find legacy sign-ins first; replace or reconfigure those clients. See blocking legacy authentication. |
| Attack surface reduction rules | Users of some macros, scripts and line-of-business apps | Audit mode, review events, add targeted exclusions, then block. |
| Device compliance and encryption | Users on unmanaged or old devices | Compliance policies with a grace period before any access block. See the Intune compliance baseline. |
| Sharing restrictions | Teams working with outside parties | Report current external sharing, agree exceptions, change defaults first and existing links later. See external sharing. |
Tracking and reporting progress
Leadership usually wants one number. Give them the score, but always with context:
- The trend, with the date of each measurement, and a note when Microsoft changed the scoring.
- What changed: the actions completed since last time and the risks they reduce, in plain language.
- What's next, with dates, and what's been deliberately accepted and why.
Avoid targets like "reach 80%". Different licenses give different maximums, and a target invites the status shortcuts described above. A target like "no admin without phishing-resistant MFA by March" is measurable and actually reduces risk.
Common questions
What is a good Secure Score?
There isn't a universal number. The maximum depends on the tenant's licenses, and some actions don't fit every organization. A better question is whether every action has an owner and a decision. A tenant at a modest score with every high-impact identity action done is in better shape than one with a higher score built on low-value toggles and optimistic statuses.
Why did our score drop when we didn't change anything?
Usually one of three things: Microsoft added new recommended actions (which raises the maximum and lowers your percentage), coverage changed (for example, new users who haven't registered for MFA), or a license change made new actions applicable. Check the history view before investigating further.
Should we compare our score with other organizations?
The portal shows comparisons with organizations of similar size. They're interesting context, but tenants differ in licensing and in which actions they've marked as not applicable, so avoid presenting the comparison as a ranking.
How often should we review it?
Monthly for the team doing the work, and quarterly for leadership, alongside a full assessment that covers what Secure Score doesn't, such as sharing exposure, stale accounts and unused licenses. Our assessment checklist lists those areas.
How M365Assessments helps
Every M365Assessments report includes the tenant's Microsoft Secure Score on the cover, next to findings from its own read-only checks of Entra ID, Intune and licensing. Each finding is ranked by severity and comes with a recommended fix, so you get the "what should we do first" view Secure Score alone doesn't give. Comparing assessments shows what changed between runs. See how the report is organized.