At some point every Microsoft 365 admin has opened the Defender portal and found their Secure Score a few points lower than the week before, with no change ticket, no incident and no explanation. The first instinct is to hunt for whoever broke something. Usually nobody did.
The score is a percentage: points you've earned divided by points currently available to your tenant. Microsoft adds new improvement actions to the catalog all the time, and every new action grows the denominator. Your configuration stayed exactly the same, the bar moved, and your percentage fell. Nothing in the portal announces this loudly, which is why the overnight drop produces so many confused Monday mornings.
That mechanism is worth understanding properly, because it's a clue to what the score fundamentally is. Secure Score measures your tenant against a moving catalog of recommended configuration. It does that job well. It just isn't the same job as measuring what's happening in your tenant, and the distance between those two is where most real incidents live.
What Secure Score is and where it lives
Secure Score sits in the Microsoft Defender portal and rates your security posture across identity, apps, devices and data. The unit of measurement is the improvement action: require MFA for administrative roles, block legacy authentication, ensure mailbox auditing is on, and a few hundred more, each worth a fixed number of points. Complete the action and you get the points. The score recalculates roughly daily.
It deserves more credit than security vendors usually give it. The remediation guidance attached to each action is written by the people who build the products, the ranking reflects real attack telemetry, and the portal deep-links you straight to the setting that needs changing. For a tenant that has never done a hardening pass, working down the Secure Score list is genuinely one of the best first moves available, and it costs nothing.
How the percentage actually moves
Four things move the number, and only the first one is the one people expect.
You complete actions. The numerator grows. This is the intended loop.
Microsoft grows the catalog. New improvement actions appear as products evolve, the denominator grows, and your percentage drops with no change on your side. Licensing works the same way: add a product and its actions join your available total, so a new purchase can lower your percentage before it improves anything.
Coverage shifts underneath you. Plenty of actions are scored proportionally rather than all-or-nothing. An action like MFA registration awards points based on the share of users covered, so a hiring wave dilutes your coverage and quietly shaves points while every policy stays untouched. The score is partly a ratio of people, and people change.
You accept a risk. Actions can be marked as risk accepted or resolved through a third party, which removes them from your available points instead of counting as failure. Used honestly, this keeps the score meaningful for your actual environment.
If you take one operational habit from this section: investigate score drops by opening the history tab and checking whether the available points changed, before auditing your own configuration. Most mystery drops are the catalog, not the tenant.
What counts as a good score
There's no defensible absolute answer, and anyone quoting one is guessing. The percentage depends on which products you license, which actions Microsoft has added lately, and how much of the catalog even applies to you.
The honest anchors are relative. The portal shows comparative averages for all organizations, for your seat-count band and for your industry, and being well ahead of your peer band means considerably more than any round number. The second anchor is your own trend. A tenant moving from 48 to 61 percent over a quarter is in much better shape than one sitting still at 70, because the first number describes a team that's working the list.
A configured control is a promise
Here's the part that matters once the basics are handled. Every point in Secure Score is awarded for a state of configuration. You enabled the policy, you turned on the audit setting, you required the compliance check. The points arrive at the moment the configuration exists.
What the configuration does after that moment is a separate question, and it's a question about behavior.
Conditional Access is the cleanest example. You build a policy requiring MFA, scope it, enable it, and collect the points. Meanwhile the actual sign-ins arriving at your tenant every hour each either fall under that policy or don't. Excluded accounts, unscoped apps, guests from partner tenants, service accounts that predate the policy, a legacy protocol someone kept alive for one old device. Every one of those is a real authentication that your configured control never touched.
Secure Score can't see any of that, and it shouldn't be expected to. Scoring configuration means scoring intent, and the policy's intent is fine. Whether this morning's three thousand sign-ins actually flowed through it is an observation, and observations require something to be watching the sign-ins themselves.
The uncomfortable consequence: the score stays green through precisely the scenario it exists to prevent. The one sign-in that walks around the policy is invisible to a measure of the policy.
The facts no configuration can carry
Once you look for them, tenant facts that no configuration state can express are everywhere.
Whether an account is actually dormant is a fact about its sign-in history, not about any setting. Whether restricted data is actually reachable by the whole company depends on years of accumulated sharing decisions, none of which appear in any admin center. Whether the AI agents operating in your tenant have an accountable human owner is a governance fact that has no checkbox at all. Whether outbound mail carrying sensitive attachments is flowing to free consumer mailboxes is visible only in the mail flow itself.
These aren't exotic edge cases. They're the ordinary questions an auditor or an incident responder asks first, and every one of them is answered by watching activity and permissions over time rather than by reading settings.
Keep the two measurements apart
The tempting product decision is to blend configuration and observation into one friendly number. It's the wrong decision, and it's worth being precise about why.
Take device compliance, or dormant accounts, or sensitivity label protection. Each can be measured from the configured side and from the observed side, and the two verdicts can disagree. A compliance policy exists, yet unmanaged devices are touching mail. A label policy exists, yet labeled files sit reachable by everyone. That disagreement is the single most valuable thing either measurement can tell you, and a merged score arithmetically cancels it out. Green plus red averages to a yellow that describes nothing.
Kept side by side, the same pair becomes a diagnosis. Configured but not covering reality means enforcement has a hole. Observed as fine but unconfigured means you're relying on luck that will eventually run out. Two numbers carry the finding; one number buries it.
A number is not a worklist
The other failure mode of security scores has nothing to do with measurement. The score gets screenshotted into a slide deck once a month, everyone nods, and no specific person leaves the meeting with a specific next action.
What converts a score into work is ranking by points still on the table. Every incomplete control, whatever its source, ordered by what completing it is worth, with the evidence and the fix one click away. The top of that list is, by construction, the most valuable thing your team can do next, and even a five-minute gap between meetings is enough to start it. Controls that genuinely don't apply need a waiver with a written note, so they leave the total honestly instead of sitting at the bottom of the list as permanent noise.
Boards, meanwhile, ask two questions: how do we compare to peers, and which direction are we moving. Peer averages answer the first. A daily history of the score, kept over months and shown next to the count of remediation actions applied, answers the second with the work attached to the trend.
How 1Security does it
The Security score screen in 1Security shows both halves of the truth side by side, deliberately unmerged.
The Microsoft half is Secure Score exactly as the Defender portal reports it: the same points, Microsoft's own remediation guidance, tiers and threat tags, the comparative averages for your size band and industry, and deep links into the portal. Nothing reinterpreted. It needs one optional read-only permission, granted with a single re-consent, and until then the screen simply runs on the other half alone.
The 1Security half is scored from what the platform observes in the tenant: restricted data actually reachable, accounts actually dormant, agents without an accountable owner, sign-ins actually outside Conditional Access coverage, ingestion freshness and unhandled critical anomalies. It adds whole categories that configuration scoring has no view of, with AI and agents first among them. Where both providers measure the same fact, they stay as two separate controls, because the disagreement between them is the finding.
Everything lands in one worklist ranked by points still on the table, with an "if you only have five minutes" shortlist at the top. Each 1Security control carries its measured evidence, like 14 of 92 agents lacking an owner, plus the compliance articles the fix would move, so an improvement shows up simultaneously in the score and in ISO 27001 or NIS2 readiness. Ninety days of daily history covers both halves, and the whole thing is available over the REST API and MCP for whatever reporting pipeline you already run.
Frequently asked questions
Is 65 percent a good Secure Score? Compared to what? Against your industry average it might be excellent. The percentage alone doesn't say enough, because your available points depend on your licenses and on when Microsoft last expanded the catalog. Watch your peer comparison and your trend instead of chasing a round number.
Why did my Secure Score drop when nothing changed? Almost always because available points grew: Microsoft added improvement actions, or a new license brought new actions into scope. Proportionally scored actions can also drift as headcount and device counts change. Check the points history before auditing configuration.
Should we aim for 100 percent? No. Some actions won't fit your environment, and forcing them for points inverts the purpose of the exercise. Complete what applies, waive what doesn't with a written reason, and spend the remaining effort on the facts configuration can't see.
Does a high Secure Score mean we're secure? It means your configuration matches Microsoft's recommendations, which is a real and valuable statement about intent. Whether behavior in the tenant matches that intent is a separate measurement, and you want both, side by side, precisely because they can disagree.
