Microsoft Secure Score is one of the most underused operational assets in the Microsoft 365 stack. Most MSPs know it exists. Most have shown it in a QBR. Most do not run it as part of service delivery.
That is the mistake.
If you manage Microsoft 365 for small and midsize businesses, Secure Score is not best understood as a dashboard, a maturity grade, or a client-facing marketing number. It is a Microsoft-maintained, impact-weighted queue of hardening actions, with tenant history, trend data, comparison data, and a Graph API. In practical terms, it is a free source of prioritized security work that many MSPs already pay for through the licenses they sell, then ignore in day-to-day operations.
For SMB-focused MSPs, that matters because the biggest failure mode is not the lack of security tools. It is the lack of an ownership loop. A control regresses, an exception gets added, a legacy app forces a bad compromise, or a policy quietly gets weakened to solve a ticket. Secure Score usually notices the change. The MSP often does not. The issue is not visibility. The issue is that the visibility never enters the workflow.
This article explains how to fix that. We will cover what Secure Score actually measures, why many MSPs do not trust it, where it is operationally useful, where it is incomplete, and how to turn it into a repeatable SMB security process instead of another unused portal tile.
What Microsoft Secure Score Actually Is
Microsoft defines Secure Score as a measurement of an organization’s security posture. A higher score means the tenant has taken more of Microsoft’s recommended actions. Microsoft is also explicit about what the score is not: it is not an absolute measure of breach likelihood, and it should not be treated as a guarantee of security.
That disclaimer is important because it is where many MSP conversations go wrong. When teams argue about whether the score is “accurate,” they are usually asking the wrong question. The useful question is whether the recommendation set helps you prioritize hardening work inside the Microsoft 365 estate. In that role, it is often very useful.
Secure Score groups improvement actions across major areas such as identity, devices, apps, and data. In the Defender portal, you also get historical views, comparison trends, regression tracking, risk acceptance trends, and benchmarks against similar organizations. In Microsoft Graph, the secureScore resource exposes tenant-level score data and control-level score data. Microsoft documents that the secureScores collection retains 90 days of data by default and is sorted by createdDateTime.
For an MSP, that means three things. Microsoft is already maintaining the recommendation model for you. The model is weighted, so high-impact items rise above low-value cleanup work. The data is retrievable, so you are not limited to screenshots and manual review.
Why MSPs Distrust Secure Score
The skepticism is not irrational. MSPs have good reasons to be wary of vendor scoring systems.
Secure Score can be gamed. Some controls can be marked as addressed by third-party solutions. Some organizations can push the percentage higher without meaningfully improving real-world resilience. Some recommendations align cleanly with Microsoft’s commercial interests. And a tenant can look respectable in Secure Score while still being weak against a framework-based assessment such as CIS Microsoft 365 Foundations.
All of that is true.
It is also beside the point if you use Secure Score correctly.
The score itself is not the deliverable. The recommendation queue is the useful artifact.
If you stop treating Secure Score as a grade to defend and start treating it as a stream of prioritized hardening opportunities, most of the common objections lose force. Whether the overall number is inflated matters much less when the MSP’s process is built around four operational questions:
- What changed?
- Which recommendation regressed?
- Who owns the remediation?
- Is the exception documented if the control cannot be implemented?
That is the shift SMB MSPs need. Do not sell the number. Operate the queue.
Why This Matters More in SMB Than Enterprise
Enterprise security teams can afford parallel governance structures, dedicated platform owners, and formal architecture boards. Most SMB MSPs cannot. They are working across dozens or hundreds of tenants with a small engineering team, limited time for advisory work, and constant pressure to resolve issues quickly without breaking line-of-business applications.
That environment creates predictable drift:
- MFA gets partially rolled back to support a legacy workflow.
- Conditional Access exclusions accumulate because no one wants to block the owner on Monday morning.
- POP, IMAP, or SMTP AUTH remains enabled longer than intended.
- Admin accounts sprawl because shared support habits were never fully cleaned up.
- Secure defaults are deferred until “after onboarding” and then never revisited.
Secure Score will not solve those cultural problems by itself. But it does give the MSP a standardized, per-tenant signal that the drift happened. That is useful when the alternative is discovering the gap after a compromise, an audit finding, or a cyber insurance questionnaire.
For SMB clients, the outcome you want is not elegant theory. It is repeatable motion: detect regressions, turn them into tickets, assign ownership, track exceptions, and report change over time.
The Best Way to Think About Secure Score
The most useful framing for an SMB MSP is this:
Secure Score is a free, Microsoft-maintained, prioritized work queue for Microsoft 365 hardening.
That framing is better than “dashboard” for several reasons.
It turns advisory data into service delivery work
Most MSPs already know how to manage queues. They know how to triage, assign owners, set SLAs, escalate blockers, and review aging items. Once Secure Score is treated as a work source instead of a summary chart, it can be managed with the same disciplines as patching, backups, or incident response.
It gives smaller MSPs prioritization they did not have to build themselves
Building a credible cross-tenant security backlog from scratch is expensive. Microsoft has already done a significant part of that work by maintaining a recommendation catalog and weighting system for the Microsoft 365 estate. That does not replace judgment, but it removes a lot of low-value manual triage.
It creates a missing ownership loop
This is the central operational gap in many MSP practices. Somebody reviews the score at QBR time. Nobody owns the regressions between reviews. A queue model closes that gap by creating named responsibility.
What Secure Score Is Good At
Secure Score is most useful for four operational jobs.
1. Baseline hardening of Microsoft 365 tenants
For Business Premium-heavy client bases, Secure Score is a practical way to identify incomplete baseline work in identity, email, collaboration, and access control. It is especially useful during onboarding and during the first 90 days after standardization.
2. Detecting configuration regression
The most valuable Secure Score capability for MSP operations is not the headline number. It is the visibility into changes, regressions, and trends over time. Microsoft documents history views, score changes, regression trends, and risk acceptance trends in the Defender portal. Those features support a simple but important operating model: when the score moves for a meaningful reason, someone should know why.
3. Supporting client communication
Clients generally do not want a pile of raw control language. They want to know whether their tenant is improving, where material gaps remain, and what decisions are blocked by budget, licensing, or business risk tolerance. Secure Score gives MSPs a way to show movement while still tying the discussion to concrete recommendations.
4. Feeding automations and downstream workflows
The Graph API is what makes Secure Score operationally interesting. The secureScore and secureScoreControlProfile entities mean the data can be extracted, normalized, compared, and pushed into PSA tickets, reporting systems, Power BI, or an internal security dashboard.
What Secure Score Is Not Good At
If you overstate Secure Score, you will lose credibility fast.
It is not a complete security program.
It is not a replacement for CIS-based assessment, conditional access architecture review, privileged identity strategy, incident response readiness, or broader governance work.
It is not proof that a tenant is secure.
It is not enough on its own for cyber insurance, regulated compliance, or board-level assurance.
And it does not reliably represent controls outside the parts of the Microsoft estate it can actually observe and score.
The correct role is upstream triage. If a tenant is weak in Secure Score, it is almost certainly not ready for anyone to pretend the security program is mature. If a tenant is strong in Secure Score, that is useful evidence of operational discipline, but it is still not the same thing as a framework-level assessment.
The MSP Operating Model: How to Turn Secure Score Into Real Work
If you want this to matter, you need a workflow, not a portal habit.
The simplest operating model for SMB MSPs looks like this.
Daily or scheduled collection
Pull each managed tenant’s latest Secure Score data on a schedule. For most SMB practices, daily is enough. The point is not constant polling. The point is to avoid relying on somebody remembering to open the Defender portal.
At minimum, collect:
- current score
- max score
- controlScores
- createdDateTime
- comparison data where available
Because Microsoft retains 90 days in the secureScores collection by default, MSPs that want trend history beyond that should store snapshots in their own reporting or data platform.
Change detection
Compare the latest data with the prior snapshot. You are looking for:
- newly regressed controls
- high-impact recommendations not yet addressed
- large score drops
- repeated exceptions on the same control
This matters more than chasing every available point. A tenant that loses 8 points because a meaningful identity control regressed deserves faster attention than a tenant sitting 12 points below your target because of a lower-priority backlog item.
Ticket creation
Do not create tickets for every single recommendation blindly. That becomes noise.
Instead, define queue rules such as:
- create a ticket when a control regresses
- create a ticket when a high-impact control remains open beyond a threshold
- create a project task when multiple related controls point to the same architectural gap
- suppress informational items that do not change the actual risk picture
For SMB MSPs, the PSA categories should be simple: remediation, client decision required, license blocker, accepted risk, and monitoring only.
Ownership and SLA
Every generated item needs one owner. Not a team. Not “security.” One owner.
If the ticket requires client approval, assign a technical owner internally anyway. The owner is responsible for moving the item to a decision, not just waiting for the client to act.
Review cadence
The cadence that usually works is:
- weekly internal review of new regressions and aging items
- monthly or quarterly client review of trend movement and blocked recommendations
- onboarding review for every newly managed Microsoft 365 tenant
Without this rhythm, the queue becomes another ignored data source.
What Good Looks Like for an SMB MSP
For most SMB-focused MSPs, “good” is not a perfect score. Good looks like operational discipline.
A mature practice usually has the following traits:
- a defined Business Premium baseline for standard clients
- a target Secure Score range by client profile, not one universal number
- documented exceptions where business requirements block a recommendation
- automated collection and comparison of score history
- tickets generated from regressions or materially important open actions
- reporting that shows trend, ownership, and blocked items rather than just a percentage
This is a much stronger position than telling clients, “Your Secure Score is 71%,” with no explanation of what changed, what remains open, and what the MSP is doing about it.
Practical Guidance for Business Premium-Centric Client Bases
Many SMB MSPs serve clients that standardize on Microsoft 365 Business Premium. That is a useful licensing position because it enables a meaningful portion of the high-value identity and security controls most small clients actually need.
In that environment, Secure Score becomes particularly effective as a baseline enforcement tool.
Examples of actions that usually deserve attention early include:
- enforcing MFA for admins and users where appropriate
- blocking or reducing legacy authentication exposure
- implementing Conditional Access with minimal, well-governed exclusions
- hardening privileged roles and admin account practices
- reviewing risky exceptions in Exchange, SharePoint, Teams, and collaboration settings
- tightening access paths that grew organically during onboarding or support work
The goal is not to squeeze every point out of the platform. The goal is to reach a defensible, supportable baseline and then catch drift quickly.
A Practical Graph API Pattern for MSPs
The technical unlock is Microsoft Graph.
Microsoft documents the Secure Score entities in the Graph security API, including secureScores and secureScoreControlProfiles. That means an MSP can stop relying on manual portal checks and start pulling the data into its own tooling.
At a high level, the pattern is:
- authenticate to Microsoft Graph for the tenant context you manage
- pull the latest secureScores data
- store a normalized daily snapshot
- compare the latest snapshot to the previous one
- create or update PSA records based on meaningful changes
For example, the REST path for score history is:
GET https://graph.microsoft.com/v1.0/security/secureScores?$top=1
And for a specific score object:
GET https://graph.microsoft.com/v1.0/security/secureScores/{secureScoreId}
If you prefer PowerShell, a lightweight pattern with the Microsoft Graph PowerShell SDK is:
Import-Module Microsoft.Graph.Beta.Security
$latestScore = Get-MgBetaSecuritySecureScore -Top 1
$latestScore | Select-Object createdDateTime, currentScore, maxScore, vendorInformation
That example is intentionally simple. In production, an MSP should enrich it by extracting the control-level detail, normalizing the tenant identifier, storing the snapshot outside the 90-day retention window, and mapping meaningful changes to ticket logic.
Two cautions matter here.
First, the partner security score API is still documented in Graph beta. Microsoft explicitly notes that beta APIs can change and are not supported for production use. That makes it appropriate for research, internal visibility, and forward planning, but not something you should build a fragile client-facing dependency around without a fallback.
Second, do not confuse “we can query the score” with “we have an operational program.” The code is the easy part. The service workflow is the real work.
The Emerging MSP Angle: Microsoft Is Starting to Score the Partner Too
This is the part many MSPs are still underestimating.
Microsoft’s partner security score API preview exists to help partners understand the posture of their own tenant and their customer tenants. That is strategically important because it suggests the market is moving from optional tenant-level scoring toward partner-level accountability.
Even if the preview evolves before it reaches broader production maturity, the direction is clear. Microsoft wants partners to improve, monitor, and evidence security posture across customer estates, not just their own internal environment.
For SMB MSPs, the implication is straightforward: if you do not already have a method for turning customer posture data into operational action, you will eventually be judged as if you should.
Common MSP Mistakes to Avoid
There are a handful of failure patterns that show up repeatedly.
Showing the score without showing the work
If the QBR slide says 74% but you cannot explain the top regressions, top blockers, and next remediation steps, the number is decorative.
Chasing percentage points instead of risk reduction
Not every available point has equal operational value. Some changes are cheap but noisy. Some are strategically important but require client sign-off, licensing, or rollout planning. Mature MSPs do not let the metric outrank judgment.
Treating exceptions as invisible
Accepted risk is still risk. If a recommendation cannot be implemented because of a legacy app, business process, or licensing constraint, document it cleanly and review it on a schedule.
Leaving the score in the portal
If the only place Secure Score lives is inside someone’s browser tab, it is not part of operations. Export it, compare it, and attach action to it.
A 30-Day Rollout Plan for a Small MSP Team
If your MSP wants to operationalize Secure Score without overengineering it, use a staged rollout.
Week 1: Define the baseline
Decide which tenant types you serve and what “good enough” means for each. Separate standard Business Premium SMBs from regulated or higher-risk clients. Define which control categories matter most and which exceptions require formal documentation.
Week 2: Collect and store the data
Pull the latest Secure Score snapshots for a pilot group of tenants. Store the results somewhere you control so you keep history beyond Microsoft’s default retention window.
Week 3: Build ticket rules
Start with one rule only: create a ticket for meaningful regressions. Do not begin by flooding the PSA with every open recommendation. Tune for signal first.
Week 4: Review and report
Run the first internal security review. Validate that the created tickets were useful, not noisy. Adjust thresholds, add owner fields, and prepare a client-facing summary that focuses on movement, blockers, and decisions.
That is enough to move from passive observation to active management.
The Real Opportunity for SMB MSPs
The opportunity here is not that Secure Score is a perfect metric. It is that it is an available one, already present in the client estate, backed by Microsoft-maintained recommendations, visible in the Defender portal, and accessible through Graph.
For SMB MSPs, the winning move is not to argue endlessly about whether the number deserves trust. The winning move is to extract operational value from the recommendation set faster than competitors do.
The MSP that uses Secure Score as a workflow input can prove ownership, detect regressions, preserve history, and tie security posture directly to tasks, exceptions, and client decisions. The MSP that uses it only as a QBR screenshot gets none of that.
Secure Score is not the security program.
It is the free upstream queue that tells you where your Microsoft 365 hardening work should start, where it slipped, and where someone in your team needs to act next.
That is more useful than a dashboard. It is the beginning of an operating model.
Sources
CIAOPS 