Microsoft 365 Secure Score: What Matters and What to Ignore

🛡️ Security & Compliance

Microsoft 365  ·  Secure Score  ·  Security Posture  ·  2026

Every Microsoft 365 tenant has a Secure Score. Most administrators have looked at it at least once, felt a vague sense of guilt about the number, and either chased points to make it go up or quietly stopped checking. Neither response is the right one.

Secure Score is a useful operational tool when read correctly — and a misleading one when treated as a security report card. A high score does not mean your tenant is safe. A low score does not mean you are compromised. What the score actually reflects is how many of Microsoft's generic recommended configurations your tenant has implemented. That is worth knowing, but it needs to be interpreted with context. This guide explains how to read the score, which recommendations genuinely reduce risk, which ones to deprioritise or ignore, and how to use Secure Score as a sustained operational practice rather than a one-time optimisation exercise.

📊

Secure Score is a configuration score, not a threat score. It measures how many of Microsoft's recommended settings are enabled in your tenant. It does not tell you whether you are currently under attack or compromised, whether controls are scoped optimally for your business context, or whether your Conditional Access policies are more sophisticated than the generic recommendations suggest.

⚠️

Not all recommended actions are relevant to your environment. Actions requiring licences you do not have, features targeting workloads you do not use, or controls that duplicate what you have already implemented through other means should be triaged carefully — not blindly addressed.

🎯

In most tenants, identity actions tend to deliver the strongest practical risk reduction early. MFA, phishing-resistant authentication, Conditional Access, and blocking legacy authentication consistently represent the highest-impact improvements across most configurations. Start there, not at the top of the ranked list.

🔄

Score can drop without any configuration change. Microsoft periodically adds new recommended actions, changes how existing ones are scored, and adjusts the maximum points. A score drop is not always a regression — check the History tab to understand what changed and why before reacting.

In this article

What Secure Score measures Anatomy of the dashboard Score categories Reading a recommended action What genuinely matters What to deprioritise Using the comparison view Operational rhythm Checklist

What Secure Score measures

Microsoft 365 Secure Score lives at security.microsoft.com → Microsoft Secure Score. It calculates a percentage based on how many points your tenant has earned out of the total points available — where each recommended action carries a point value, and you earn those points when the corresponding configuration is in place.

The score is a proxy for configuration coverage. It answers the question: of the security controls Microsoft recommends, how many does your tenant have enabled? That is a useful question. But it is a different question from: how well protected is your organisation? The two can diverge significantly in both directions. A heavily customised Conditional Access deployment with phishing-resistant authentication can score lower than a tenant that enabled every quick-win recommendation but has no coherent identity strategy. The score is a starting point for a conversation, not a conclusion.

The Secure Score Overview. The score (46.11%) reflects points achieved against total available. The breakdown shows performance by category — Identity at 37.28%, Data at 55.56%, Apps at 49.07% in this tenant. The Comparison panel on the right shows how the score benchmarks against organisations of similar size. Navigate to Microsoft Defender → Microsoft Secure Score.

⚠️

The score does not capture everything. Secure Score cannot see the quality of your Conditional Access policy design, RBAC assignment hygiene, network segmentation, third-party security tools, or how well your users have been trained. Two tenants with identical Secure Scores can have very different actual security postures. Use the score as one input alongside your own security assessments — not as a substitute for them.

Anatomy of the dashboard

The Secure Score dashboard has four tabs, each serving a different purpose. Understanding what each one is for prevents the most common misreading mistakes.

Overview is the landing tab. It shows your current score, the point breakdown by category, the top recommended actions by score impact, and a quick comparison against organisations of similar size. The "Actions to review" panel shows counts by status — how many are still to address, how many have been planned, and whether any have recently regressed. This tab gives you the situation at a glance but is not where you do the work.

Recommended actions is the operational tab. It lists every action contributing to your score, with columns for rank (Microsoft's suggested priority), score impact as a percentage, points achieved out of the maximum, status, whether you hold the required licence, category, product, and last sync date. This is where triage happens. The list can be sorted, filtered, and exported — export to CSV is useful when you want to work through the list with a team or document your decision-making on items you are marking as Risk accepted.

The Recommended actions tab — 73 items in this tenant, sortable by any column. The "Have license?" column is critical for triage: actions marked "No" require additional licensing before they can be addressed. Score impact shows the percentage gain each action would add. Points achieved shows current partial credit where applicable.

History shows your score trend as a line chart over time, with an activity log below it. The log records every point change — gains from completing actions, losses from regressions, and point adjustments when Microsoft adds or modifies recommendations. When your score unexpectedly changes, the History tab is where you diagnose why. A score drop attributed to "System" in the Attributed to column typically means Microsoft changed the scoring criteria, not that your configuration changed.

The History tab shows score progression over time. Each step in the chart corresponds to a configuration change logged below. In this tenant, the largest jump occurred in February when Safe Attachments and Safe Links were enabled — gaining over 11 points. The Attributed to column shows "System" for platform-initiated score recalculations.

Metrics & trends provides a richer view of the same data — a comparison trend chart overlaying your score against similar organisations, a regression trend showing whether any previously completed actions have degraded, and a risk acceptance trend showing how many actions have been marked as accepted risk over time. The "Score zones" feature on this tab lets you set internal thresholds for Good / Okay / Bad — useful if you want to surface this data in executive reporting with meaningful context rather than a raw percentage.

Metrics & trends gives a 90-day overview of score trajectory versus peers, regression events, and risk acceptance. The comparison trend shows this tenant tracking closely with similar-sized organisations. Score zones (left panel) can be customised to reflect internal targets — useful for management reporting.

Score categories

Secure Score organises recommended actions into categories that roughly map to security domains. Understanding what each category covers helps you focus improvement efforts on the areas most relevant to your risk profile.

Category	What it covers	Typical actions
Identity	User accounts, admin accounts, authentication methods, Conditional Access, Entra ID Protection	MFA coverage, legacy auth blocking, admin MFA, Identity Protection risk policies, password policies
Apps	Microsoft 365 application security — Defender for Office 365, Exchange Online Protection, Teams, SharePoint external sharing	Safe Attachments, Safe Links, anti-phishing policies, impersonation protection, attachment type filters
Data	Data classification, sensitivity labels, DLP policies, SharePoint and OneDrive sharing controls	Sensitivity labels published, DLP policies in enforce mode, SharePoint sharing restrictions
Device	Endpoint compliance, Defender for Endpoint, Intune-managed device configuration	Device compliance policies, Defender for Endpoint onboarding, attack surface reduction rules
Infrastructure	Azure resources, server workloads, cloud security posture (less relevant for most M365-only tenants)	Azure Security Center recommendations, resource configuration policies

The category breakdown in the Overview tab shows your percentage score within each category — not just your overall score. This is more useful than the headline number because it shows where the largest gaps are. A tenant that scores 80% on Apps but 35% on Identity has a clear priority: address the Identity gap before polishing App configurations further. Identity controls protect the accounts that access everything else.

Reading a recommended action

Clicking any item in the Recommended actions list opens a detail flyout. This is the most important part of the Secure Score interface for making good decisions — the list view alone does not give you enough context to triage correctly.

Action detail for "Ensure multifactor authentication is enabled for all users." The implementation status shows the specific gap — 27 of 35 users not registered with MFA — rather than a binary pass/fail. Points achieved (2.06/9) reflects partial credit. The Protects against section shows what threat categories this action addresses. Use the Implementation tab for step-by-step guidance.

The detail flyout has three tabs of its own. General shows the description, implementation status with the specific gap in your tenant, user impact, and a Details panel with points, category, product, and what threats the action protects against. Implementation provides step-by-step guidance and a direct link to the relevant admin centre page — this is useful for delegating remediation work. History shows a log of changes to this specific action's status over time.

The key fields to evaluate before acting on any recommendation are these: the implementation status (does it show a specific gap, or is it generic?), Have license? (is the required licence already assigned?), User impact (will this cause friction for end users?), and Points achieved (is there already partial credit, meaning part of the work is done?).

ℹ️

Partial credit is common and meaningful. Many actions do not score as binary pass/fail. The MFA action, for example, awards points proportional to the percentage of users registered — so a tenant with 80% MFA coverage gets partial points, not zero. Understanding partial scores helps you prioritise: an action with 7/9 points already earned needs less work than one at 0/8.

What genuinely matters

The actions below have the highest ratio of actual risk reduction to implementation effort. They represent the controls that consistently appear in incident post-mortems when Microsoft 365 tenants are compromised — meaning that not having them in place is a known, exploited gap, not a theoretical concern.

Identity — the highest priority category

Ensure MFA is enabled for all users HIGH

The single most impactful control in any M365 tenant. Password compromise does not lead to account takeover when MFA is required. Ideally enforced via Conditional Access policy rather than per-user MFA, which gives more granular control and supports phishing-resistant methods.

Ensure MFA is enabled for all admin roles HIGH

Admin accounts are the primary target in tenant takeover attacks. If only one group has MFA enforced before anything else, it must be admin accounts. No exceptions for break-glass accounts — document them separately and review access regularly.

Block legacy authentication HIGH

Legacy authentication protocols (SMTP AUTH, IMAP, POP3, basic auth) cannot enforce MFA. A significant proportion of password spray attacks specifically target legacy auth endpoints because they bypass modern authentication controls entirely. Block via Conditional Access.

Enable Entra ID Identity Protection risk policies HIGH

User risk and sign-in risk policies use Microsoft's threat intelligence to detect anomalous authentication — leaked credentials, impossible travel, unfamiliar locations. Enabling these policies adds automated response to detected account compromise. Requires Entra ID P2 or equivalent.

Apps — email and collaboration security

Enable Safe Attachments (Block mode) HIGH

Detonates email attachments in a sandbox before delivery. Block mode holds the message until detonation completes — slightly higher latency but significantly better protection than Dynamic Delivery for most organisations. Requires Defender for Office 365 Plan 1 or higher.

Enable Safe Links for Office applications HIGH

Rewrites URLs in email and Office documents, checking them at click time against Microsoft's threat intelligence. Protects against time-of-click URL switching — a common phishing technique where a URL is benign at delivery but malicious by the time the user clicks. Requires Defender for Office 365 Plan 1.

Enable anti-phishing impersonation protections HIGH

Impersonated domain and user protection catches emails that spoof your domain or key users (executives, finance). The Secure Score surfaces three separate actions here — impersonated domain protection, impersonated user protection, and mailbox intelligence — all of which should be configured together.

Enable the Common Attachment Types Filter HIGH

Blocks common malware delivery file types (.exe, .bat, .vbs, .js, .ps1, and others) at the mail gateway. Low user disruption, high protection value. Complement with a tuned list that covers your organisation's actual file type risk profile.

Data — classification and sharing controls

Data category actions vary significantly in implementation complexity and time-to-value. Sensitivity labels, once published, improve Copilot security posture, DLP policy accuracy, and compliance audit trails simultaneously — making them disproportionately valuable relative to their Secure Score point value. Restricting external SharePoint sharing and disabling anonymous calendar sharing are lower-effort actions that address specific oversharing vectors common in SMB tenants.

What to deprioritise or ignore

Not every Secure Score recommendation deserves immediate action. Several categories of actions are routinely lower priority than their ranking suggests, and some should be consciously deferred or marked as Risk accepted with documented justification.

Actions requiring licences you do not hold

The Recommended actions list has a Have license? column. Any action marked No in that column cannot be implemented without acquiring additional licensing. These actions contribute to the total maximum points but are not actionable in your current configuration. Filter them out during triage — they represent potential future improvements, not current gaps. Do not let them distort your view of what is achievable today.

Defender for Identity — without on-premises Active Directory

"Start your Defender for Identity deployment, installing sensors on Domain Controllers" appears in many tenant action lists and carries meaningful points. For cloud-only tenants or tenants that have completed Entra-only migration, this action is not applicable. Defender for Identity requires on-premises AD domain controllers to deploy sensors against. If your environment has no DCs, mark this as Risk accepted with a note that the environment is cloud-only.

The password expiration action

The action "Ensure the Password expiration policy is set to 'Set passwords to never expire'" appears near the top of many tenant lists and carries relatively high points. This recommendation aligns with current Microsoft and NIST guidance — frequent password rotations without MFA lead to weaker passwords through predictable patterns. However, if your organisation has compliance obligations that mandate periodic password changes, this is a case where you should mark as Risk accepted — documenting the specific regulatory or contractual requirement, and aligning the decision with your corporate security policy. The justification should reference documented external requirements, not just a general sector assumption.

Actions that duplicate existing controls

Secure Score evaluates configurations in isolation. If you have a Conditional Access policy that enforces MFA for all users in a more sophisticated way than the generic per-user MFA setting — for example, requiring phishing-resistant methods for privileged actions, or enforcing device compliance for external access — the Secure Score may still show the generic MFA action as partially incomplete. The score is measuring the specific configuration check it knows about, not the overall quality of your authentication architecture. Do not degrade a well-designed Conditional Access environment to satisfy a Secure Score check.

Score gaming — the "Risk accepted" trap

Marking an action as Risk accepted removes it from the "To address" count and can improve your visible score percentage. This is appropriate when you have a documented reason not to implement a recommendation — a licensing constraint, a business process dependency, a compensating control that addresses the same risk differently. It is not appropriate as a strategy to improve your score number while leaving genuine gaps unaddressed. If an action is marked as Risk accepted, the justification should be documented and reviewed at a defined cadence — typically annually or when the environment changes.

🚫

A high Secure Score is not a security guarantee. Tenants with 80%+ Secure Scores have been compromised because Secure Score does not measure whether Conditional Access policies are correctly scoped, whether admin accounts are actually protected in practice, or whether users have been socially engineered. The score measures configuration coverage. Real security also requires monitoring, incident response capability, and user awareness. Treat the score as a hygiene floor, not a ceiling.

Using the comparison view

The Overview tab includes a Comparison panel that shows your score against two benchmarks: organisations of a similar size and optionally your industry sector. The Metrics & trends tab shows this as a trend chart over time. Both are useful for contextualising your score — but neither should be used as a target.

The peer comparison tells you whether your tenant is in the same configuration range as comparable organisations. If you are significantly below the peer average, it is a reasonable indicator that there are common baseline controls not yet in place. If you are at or above the peer average, it means you are broadly in line with comparable environments — not that your configuration is optimal. The average across tenants includes many that have made the same prioritisation mistakes and left the same common gaps unaddressed.

A more useful way to read the comparison: if you are below the peer average, focus on the Identity category first, since MFA and Conditional Access coverage is typically the largest driver of below-average scores. If you are above the peer average but still have unaddressed Identity actions, the comparison result should not reduce your sense of urgency — it just means your peers have the same gap.

Operational rhythm

Secure Score is most valuable when reviewed on a regular cadence rather than treated as a one-time project. The recommended approach is a two-speed review cycle.

Monthly: Check the History tab for unexpected score changes. Any regression (a previously completed action that has dropped back) warrants investigation — it typically indicates a configuration change, a licence assignment change, or a Microsoft scoring update. Check the "Recently added" count on the Overview tab; new recommended actions are added as Microsoft releases new security features, and some of them represent genuinely important new controls.

Quarterly: Review the Recommended actions list with the team responsible for security configuration. Work through any new actions from the previous quarter, revisit Risk accepted items to confirm the justification is still valid, and check whether any previously unlicensed actions have become available due to licence changes. Export the list to CSV and attach it to your security review documentation.

One practical tip: the Export function in the Recommended actions tab produces a CSV with all columns including points, status, category, and product. This is useful for building a prioritised backlog in your project management tool, where each action can be assigned an owner, a target completion date, and a tracking status independently of what the Secure Score interface shows.

✅

Use Score zones to create internal accountability. The Metrics & trends tab allows you to configure custom score zones — Good, Okay, Bad — based on percentage thresholds that reflect your organisation's own security targets. Setting a Good threshold at, say, 70% gives the security team a concrete internal goal and makes the score visible to stakeholders in a way that communicates progress without requiring them to interpret raw points.

Secure Score triage checklist

• Filter the Recommended actions list by "Have license? = Yes" Start your triage with only actionable items. Actions requiring licences you do not hold cannot be addressed today — removing them from view prevents them from distorting your priorities.
• Address all Identity actions with "Have license? = Yes" first MFA coverage, admin account protection, legacy authentication blocking, and Identity Protection risk policies deliver the highest risk reduction per point. Complete these before moving to other categories.
• Enable Safe Attachments (Block mode), Safe Links, and anti-phishing protections If Defender for Office 365 Plan 1 is licensed, these three actions together address the most common email-borne attack vectors. Safe Attachments and Safe Links in particular have a direct, measurable impact on malware delivery and phishing click-through rates.
• Document every "Risk accepted" decision For each action marked as Risk accepted, record the reason, the date, and the owner. Schedule a review at least annually. Actions accepted due to licensing constraints should be revisited at each licence renewal cycle.
• Check the History tab after any score change Score changes attributed to "System" are Microsoft-initiated scoring updates, not configuration regressions. Score changes attributed to your admin account or "User" reflect actual configuration changes. Distinguish between the two before reacting.
• Set custom Score zones for internal reporting Configure Good / Okay / Bad thresholds in Metrics & trends that reflect your organisation's security targets. This makes the score meaningful to stakeholders who are not security specialists and creates accountability for improvement over time.
• Export the action list quarterly and assign owners Export Recommended actions to CSV and track remediation in your project management tool. Each action should have an assigned owner and a target completion date. The Secure Score interface alone does not provide enough workflow capability for sustained operational tracking.
• Do not treat Secure Score as a substitute for a security assessment Secure Score does not evaluate Conditional Access policy quality, RBAC hygiene, incident response capability, or user awareness. Use it as a configuration hygiene baseline, not as evidence of overall security posture.

---

Next steps

Keep building your security baseline

Secure Score gives you the configuration gap list. These guides help you close the most important ones.

Related articles

• Microsoft Entra Conditional Access: A Practical Deployment Guide
• Why Traditional MFA Fails: Enforcing Phishing-Resistant Access
• Microsoft Defender for Office 365 Plan 1 Is Now in E3: What You Get
• Microsoft 365 Business Premium Security Checklist for SMBs
• Microsoft Purview Insider Risk Management: The Admin Setup Guide