Microsoft Secure Score: Is Your Microsoft 365 Environment Actually Secure?

A business opens Microsoft Secure Score for the first time. The dashboard shows a percentage and a list of recommended actions — administrator MFA, legacy authentication, guest access, mailbox forwarding, application consent, privileged roles, device configuration, SharePoint sharing, audit controls, phishing protection.

The business sees the number and draws a conclusion. If the score is low, Microsoft 365 must be insecure. If the score is high, the environment must be safe. Neither conclusion is reliable without context.

A low score may reflect missing licences, products not yet configured, legitimate business exceptions, unreviewed recommendations or genuine security weaknesses — and often a combination of all five. A high score may exist alongside compromised accounts, weak operational procedures, poor backup, unmanaged administrators, risky third-party applications, stale guest users, configuration drift or untested incident response.

What Microsoft Secure Score is

Microsoft currently describes Microsoft Secure Score as a numerical summary of an organisation's security posture across supported Microsoft services. It reflects selected security configurations, user behaviour, completed recommended actions, enabled Microsoft services and current licensing.

The score is available through the Microsoft Defender portal. The current direct route is security.microsoft.com/securescore — verify this remains current before directing others to it. Accessing the score requires an appropriate role, such as Global Administrator, Security Administrator, Security Reader or Global Reader.

Microsoft states that Secure Score is not an absolute measure of how likely the organisation or its data is to be breached. It measures recommended control adoption, not security outcomes.

Secure Score covers recommendations across four broad areas — Identity, Devices, Apps and Data — though the recommendations available to a specific organisation depend on the Microsoft products in use, assigned licences, enabled services, device onboarding, tenant configuration and security products deployed.

What Microsoft Secure Score is not

Secure Score is not a security certification. It is not proof that Microsoft 365 is secure. It is not a predictor of whether a breach will occur. A specific score does not guarantee protection.

Secure Score is also not the same as Microsoft Secure Score for Devices, which measures device posture separately through Microsoft Defender for Endpoint. It is not the same as Defender for Cloud Secure Score, which measures cloud workload security across Azure and connected environments.

Microsoft Secure Score cannot, by itself, confirm that every recommendation suits the organisation, that controls were implemented correctly, that exceptions remain justified, that administrators follow secure procedures, that users understand security changes, that settings will stay secure, that attackers are not already present, that third-party applications are trustworthy, that backups work, that incidents will be detected, that incident response will work, that the organisation complies with every framework or that the business will not suffer a breach.

How the score is calculated

Microsoft awards points for implementing supported recommended actions. Each recommendation carries a maximum point value. The achieved score is calculated as achieved points divided by maximum available points, expressed as a percentage.

Partial credit may be awarded where an action is partially complete — for example, where MFA is enforced for some users but not all. Recommendation weighting varies: some controls carry more points than others, reflecting their significance across Microsoft's security model.

The score updates on a scheduled basis — not immediately on every configuration change. Microsoft's documentation notes that scoring may take up to 24 hours to reflect changes. Verify current update frequency before assuming a change will appear in the score immediately.

Each recommendation shows a status — such as To Address, Planned, Risk Accepted, Resolved Through Third Party or Resolved Through Alternate Mitigation. Marking an action as Planned or Risk Accepted does not implement the control. It records a decision and may adjust the achievable or planned score display.

Current, planned and achievable scores

The Secure Score dashboard currently shows several score variants. Verify the current terminology in the Microsoft Defender portal before relying on these descriptions.

The current licence score represents the points potentially available using the organisation's existing Microsoft licences. The achievable score accounts for current licensing, exclusions and accepted risks — what could realistically be reached given those constraints. The planned score projects where the score would reach if all planned improvement actions were completed.

These distinctions matter because the maximum visible score often includes recommendations that require licences the organisation does not hold. Comparing a current score against an unadjusted maximum can create a misleading gap.

Identity recommendations

Identity recommendations form a significant part of the Secure Score for most Microsoft 365 organisations. They may currently concern administrator MFA, authentication methods, privileged roles, legacy authentication, user risk policies, access policies and guest controls.

Microsoft 365 identity weaknesses can include too many administrators, inactive administrator accounts, missing or weak MFA, legacy authentication protocols that bypass modern controls, broad guest access, excessive application permissions, unmanaged service accounts, poor joiner and leaver processes, stale external users, weak Conditional Access, risky mailbox forwarding, unreviewed emergency accounts and inadequate role separation.

Attackers may not need to exploit a server when they can steal credentials, abuse OAuth application consent, take over an authenticated session, exploit weak authentication methods, use excessive privileges, maintain access through mailbox forwarding or access data through a guest account. Identity controls that reduce these paths are often where the most meaningful security investment can be made.

Device recommendations

Device recommendations depend on whether devices are enrolled in Microsoft Intune or onboarded to Microsoft Defender for Endpoint. They may concern operating-system controls, application security settings, account configuration, endpoint protection, attack-surface reduction rules and vulnerability recommendations.

Device recommendations are scored separately within Secure Score for Devices in some contexts. Verify the current relationship between Microsoft Secure Score and device scoring before drawing conclusions from device-related points.

Application and email recommendations

Application and email recommendations may concern Exchange Online settings, Microsoft Defender for Office 365, cloud application controls, consent settings, mailbox configuration and anti-phishing controls. These may include anti-phishing policy configuration, Safe Links, Safe Attachments, external mailbox forwarding restrictions, mailbox auditing and impersonation protection.

Email authentication controls — SPF, DKIM and DMARC — reduce the risk of attackers sending messages that appear to come from the organisation's domain. These controls are distinct from Secure Score recommendations in some contexts. Verify current coverage.

Data recommendations

Data recommendations may involve information protection settings, data-loss prevention policies, sensitivity labels and SharePoint and OneDrive external sharing controls. They typically require Microsoft Purview licences and configuration. Some recommendations in this area carry significant licensing dependencies.

Verify all current recommendation examples before acting on them. Microsoft adds and removes recommendations as services and security guidance evolve. A recommendation present in the dashboard today may not have existed twelve months ago.

Why 100% is not always the right target

Some recommendations may require licences not currently held, affect legacy applications, conflict with a justified business requirement, require phased deployment, duplicate another control, have limited relevance to the organisation, create unacceptable operational impact, need additional testing or be subject to documented risk acceptance.

This does not mean weak standards are acceptable. It means that every exception should be a deliberate, documented decision. The business should be able to justify why a recommendation was not implemented, who accepted the risk, what compensating controls exist and when the decision will be reviewed.

Secure Score versus real security

Secure Score can help with identifying configuration gaps, prioritising Microsoft recommendations, tracking progress, showing trends, supporting governance discussions and highlighting licence limitations.

It cannot confirm that no account is compromised, that staff resist phishing, that backups work, that administrators follow secure procedure, that suppliers are secure, that applications are trustworthy, that incident response works, that every risk has been assessed, that controls remain correctly configured or that regulatory requirements are satisfied.

Secure Score measures Microsoft-recognised control adoption — not every technical, human or commercial risk affecting the business.

How to prioritise recommended actions

A large point value does not automatically mean the recommendation should be implemented first. Priority should consider likelihood, potential impact, active threats, administrator exposure, user impact, application dependencies, business criticality, ease of implementation, compensating controls already in place and current incidents.

A practical prioritisation model for most organisations:

• Priority 1 — Privileged access: administrator MFA, excessive Global Administrators, emergency accounts, dormant privileged users, unsafe role assignments
• Priority 2 — Easy account attack paths: legacy authentication, weak authentication methods, risky mailbox forwarding, poor guest access, excessive consent permissions
• Priority 3 — Email and phishing: anti-phishing policy, impersonation protection, Safe Links, Safe Attachments, mailbox auditing, external forwarding restrictions
• Priority 4 — Devices: unsupported operating systems, missing endpoint security, weak local administrator controls, vulnerability exposure
• Priority 5 — Data and sharing: anonymous links, broad SharePoint access, unclassified sensitive data, weak external-sharing controls
• Priority 6 — Governance: logging, alerting, review ownership, exception records, security reporting

Licensing and score limitations

The recommendations visible in Secure Score depend on the Microsoft products in use, assigned licences, enabled services, device onboarding, tenant configuration and security products deployed. An organisation on Microsoft 365 Business Basic will see different recommendations from one on Microsoft 365 Business Premium.

Some high-value recommendations — including phishing-resistant MFA, certain Conditional Access policies and advanced information protection controls — require licences such as Microsoft Entra ID P1, Entra ID P2 or Microsoft 365 Business Premium. Verify which licences are required before planning improvements that assume capabilities the organisation does not currently hold.

Testing security changes

A security change may affect legacy applications, shared devices, scanners, mobile access, service accounts, third-party email systems, remote access, contractors, guests, emergency access or automated processes. A recommendation is not implemented successfully until security improves without creating an unmanaged business failure.

Recommended deployment sequence: understand the recommendation; identify affected users and applications; confirm Microsoft licensing; define success and rollback criteria; test with a representative pilot group; monitor sign-ins and application impact; deploy in phases; record exceptions; verify technical enforcement; confirm the score update; monitor for configuration drift.

Exceptions and risk acceptance

A risk acceptance decision should document the business reason, the named risk owner, any compensating controls in place, and a review date. Marking a recommendation as Risk Accepted in the dashboard records a decision — it does not implement a control or remove the underlying risk.

A compensating control is a different control used to reduce the same or a similar risk. For example, a business that cannot immediately block all legacy authentication protocols may document that the affected accounts are reviewed weekly, access is limited to specific IP addresses and anomalous sign-ins trigger alerts. That is different from an ignored recommendation.

Why security settings drift

Security posture can deteriorate after improvement work. A policy is disabled during troubleshooting. An administrator adds an exception. A new application requires older access methods. A guest is never removed. A temporary administrator becomes permanent. A Conditional Access exclusion expands quietly. Mailbox forwarding is enabled. A new Microsoft feature uses a weaker default. Licences change. Microsoft changes a recommendation. Suppliers modify settings. Staff bypass the standard process.

Configuration drift is normal. The response is change control, documented baselines, regular assessment, automated reporting, configuration enforcement where appropriate, exception expiry dates, named owners, alerting and periodic access reviews.

From Secure Score to continuous hardening

A one-off Secure Score review does not provide permanent protection. Security settings change, licences change, Microsoft recommendations change and the organisation changes. Hardening — reducing unnecessary access, weak settings and avoidable attack opportunities — is a continuous process.

Continuous hardening requires a regular cycle: measure the current score and underlying controls; identify changes; prioritise the highest-impact improvements; test changes before deployment; verify technical enforcement; document exceptions; monitor for drift; and review again on a scheduled basis.

What Identity Security Posture Management means

Identity Security Posture Management is a developing security category rather than a specific product. ISPM generally describes tools, processes or managed services intended to help organisations assess identity configurations continuously, identify risky access, identify excessive privileges, identify weak authentication, detect configuration drift, prioritise remediation, enforce approved security baselines, document exceptions and report changes over time.

Identity threat detection and response is a related but distinct capability — it concerns detecting and responding to suspicious or malicious identity activity, not measuring or improving configuration. ISPM addresses configuration weakness; threat detection addresses active attacks. Both matter and neither replaces the other.

Internal review, automated platforms and managed services

There are three broad operating models for managing Microsoft 365 security posture:

Internal review: the organisation reviews Secure Score and implements changes using internal staff or its IT provider. Potential advantages include direct control, lower additional tooling cost and close knowledge of business systems. Potential limitations include dependence on available expertise, irregular reviews, undetected configuration drift and remediation that competes with other priorities.

Automated posture platform: software continuously assesses settings and may automate approved remediation. Potential advantages include regular assessment, consistent reporting, faster drift detection and repeatable baselines. Potential limitations include the need for configuration and oversight, additional licensing costs, automation that can create disruption when poorly controlled, and the organisation remaining responsible for impact and exceptions.

Managed posture service: a provider operates some or all of the assessment, prioritisation and remediation process. Potential advantages include specialist knowledge, regular review, operational support and multi-tenant capability. Potential limitations include supplier access that must be controlled, variable service scope, organisational responsibility that remains in place, and exit and access-removal arrangements that require planning.

What a managed posture service may add

Some organisations may choose a managed identity-security posture service rather than operating the complete process internally. Potential benefits may include regular configuration assessment, specialist Microsoft 365 security knowledge, prioritised remediation guidance, controlled policy deployment, configuration-drift monitoring, review of administrators and privileged access, review of guest users, review of authentication methods, review of application permissions, review of mailbox and sharing risks, exception tracking and recurring reporting.

Potentially suitable organisations may include: small internal IT teams; organisations without dedicated Microsoft security expertise; businesses supported by a managed IT provider; company groups operating several tenants; businesses going through mergers or acquisitions; organisations where previous improvements did not remain in place; and businesses needing regular evidence of review.

How to assess an identity posture service

When assessing an ISPM platform or managed service, useful questions include:

• Which Microsoft 365 services are assessed?
• Which identities are included — users, administrators, guests and application identities?
• Which controls are monitored and which settings can be changed?
• Does remediation require explicit approval?
• Can the organisation define its own security baseline?
• How are user and application impacts tested before deployment?
• How quickly is configuration drift detected?
• Can exceptions be documented with expiry dates?
• What reports are provided and can configuration evidence be exported?
• Are all changes fully logged and can changes be rolled back?
• What Microsoft licences are required?
• Who owns the service identity and what access does the supplier receive?
• How is privileged access protected and is just-in-time access supported?
• How is supplier access removed when the contract ends?
• Is threat detection included, or posture management only?
• Who remains accountable for approving changes?

What ISPM does not replace

Identity Security Posture Management does not automatically replace identity threat detection and response, endpoint detection and response, security-awareness training, email security, independent backup, vulnerability management, incident response, cyber insurance, access reviews, legal and compliance advice, administrative ownership, business continuity or human approval.

A practical 90-day improvement plan

Days 1–30: Measure. Record the current Secure Score. Record the major recommended actions. Identify all administrator accounts. Review MFA. Review legacy authentication. Review guest users. Review mailbox forwarding. Confirm Microsoft licences. Identify business-critical applications. Assign a named security owner.

Days 31–60: Improve. Reduce unnecessary administrators. Strengthen administrator MFA. Test Conditional Access policies. Block unsafe legacy access where possible. Review external sharing. Review application consent. Address high-priority email controls. Document exceptions with owners and review dates. Communicate changes to affected staff.

Days 61–90: Maintain. Review score movement. Verify controls are technically enforced. Monitor failed sign-ins and user impact. Establish regular reporting. Set exception expiry dates. Review security-tooling gaps. Decide whether internal, automated or managed posture monitoring is required going forward. Schedule the next review.

Microsoft 365 security review checklist

Is your Microsoft Secure Score improving for the right reasons?

• Score: Do we know the current score and available maximum? Do we understand licence limitations? Are trends reviewed?
• Identities: Are administrators protected by MFA? Are privileged roles limited? Are guest users reviewed? Is legacy authentication blocked where possible? Are emergency accounts controlled?
• Applications: Are enterprise applications reviewed? Are OAuth permissions reviewed? Are unused applications removed? Are consent settings controlled?
• Email: Is external forwarding reviewed? Are anti-phishing controls configured? Are SPF, DKIM and DMARC maintained? Are mailbox permissions reviewed?
• Sharing: Are SharePoint and OneDrive external links reviewed? Are anonymous links controlled? Does every external guest have an owner?
• Devices: Are devices supported? Is endpoint security deployed? Are local administrators controlled? Are vulnerabilities reviewed?
• Operations: Are changes tested? Are exceptions documented? Is configuration drift monitored? Is there a named security owner? Is backup tested? Is incident response documented?

Warning signs

The organisation may be chasing score instead of improving security where any of these apply:

• 100% is treated as the only objective
• Controls are enabled without testing
• Nobody understands the recommendation being implemented
• Points drive priority instead of risk
• Licences are purchased solely for score
• Exceptions have no named owner
• Planned actions never complete
• Accepted risks have no review dates
• Secure Score is reviewed only annually
• Administrator accounts remain excessive
• Guests are ignored
• Application permissions are ignored
• Backup is not tested
• Threat alerts are not monitored
• Configuration drift is not detected
• Users repeatedly bypass controls
• Suppliers make undocumented changes
• The score rises but incidents continue
• Nobody can explain which attack paths were actually closed

Practical business implications

• Secure Score is a useful starting point — it helps identify Microsoft-recommended improvements
• The score is not a guarantee — it does not predict whether a breach will occur
• Licensing affects the result — recommendations depend on Microsoft services and subscriptions
• Identity should come first — administrator and authentication weaknesses create high-value attack paths
• Points should not control priority — business risk and attack likelihood matter more
• Testing is essential — some controls can disrupt users and applications
• Exceptions need governance — a justified exception is different from an ignored recommendation
• Configuration drift is normal — secure settings require ongoing verification
• ISPM may support continuous control — internal processes, automated platforms or managed services may help maintain approved settings
• Secure Score does not replace security operations — monitoring, backup, incident response and user training remain necessary

The IT Club view

Microsoft Secure Score is useful because it gives businesses somewhere practical to start. It translates complex Microsoft 365 configuration into recommendations, points, categories, trends and comparisons. That accessibility makes it a reasonable entry point for a security conversation.

But its simplicity creates a risk. A business may begin managing the number instead of managing security. When points become the objective, controls get enabled without testing, exceptions accumulate without owners, drift goes unnoticed and the score rises while the real control position weakens.

IT Club recommends recording the current score and understanding the licences behind it; prioritising privileged identities first; addressing realistic attack paths; testing each change before deploying it; documenting exceptions with owners and review dates; reviewing guests and application permissions regularly; monitoring configuration drift; combining posture with threat detection; maintaining independent backup; assigning ownership; and reviewing progress through an Operational Heartbeat.

A Secure Score review should result in clearer ownership, stronger controls and fewer easy routes into Microsoft 365 — not merely a better percentage.

Microsoft Secure Score is a useful measure of recommended Microsoft control adoption, but it is not proof that the organisation is secure. Meaningful improvement requires risk-based prioritisation, controlled deployment, documented exceptions and continuous monitoring for configuration drift.