Microsoft Security Score: How to Actually Improve It (Not Just Game It)

The Team That Went From 45% to 78% in Two Weeks Without Changing Anything

A security engineer showed me their tenant's Security Score history during a consulting engagement. They had increased from 45% to 78% in under two weeks. I asked which hardening work they had done. They had accepted risk on 47 recommendations, excluded 200-plus resources from 12 high-impact recommendations, and disabled MFA monitoring for a group they claimed were service accounts. The score jumped. The actual security posture had not changed. In fact it had declined, because the exclusions masked gaps that previously showed as remediable.

Microsoft Security Score is a useful signal when used honestly. Most mature teams I've worked with either ignore it entirely (leaving real value on the table) or manipulate it (creating false confidence). This guide covers what the score actually measures, which recommendations have meaningful security impact, and how to build a credible improvement program that survives scrutiny.

---

How Microsoft Security Score Is Calculated

The score is a ratio: points achieved divided by maximum possible points, expressed as a percentage. Microsoft assigns a point value to each recommendation based on a combination of factors: prevalence of the attack the recommendation prevents, difficulty of exploitation, and blast radius of a breach. Recommendations range from 1 point (minor configuration tweak) to over 30 points (MFA for all users).

Points are calculated per-recommendation across your tenant:

• Full points: All eligible users or resources are in the compliant state
• Partial points: A fraction of users or resources are compliant (typically proportional)
• Zero points: No eligible users or resources are compliant, or the recommendation is not yet addressed

The maximum possible score changes over time as Microsoft adds new recommendations and as your tenant grows. Adding users, devices, or apps adds new eligible resources to existing recommendations and increases your maximum.

What "Accept Risk" and "Exclude Resources" Actually Do

Both options reduce the denominator rather than fixing the underlying gap:

• Accept risk on a recommendation removes its points from the maximum possible score entirely for a period (you choose the duration)
• Exclude resources removes specific users, devices, or apps from the recommendation's scope

Neither makes the security gap disappear. The recommendation shows as addressed in the score, but the underlying configuration has not changed. Auditors who look past the score to the raw recommendation data will find every exclusion.

The legitimate use case for Accept Risk: you have a compensating control. If a recommendation asks for MFA and your tenant uses a phishing-resistant hardware token solution not yet detected by the Microsoft compliance APIs, Accept Risk with documentation is appropriate. The illegitimate use case: you know the recommendation is valid but implementing it requires effort.

---

Recommendations by Category and Real-World Impact

Identity (30-40% of Maximum Score in Most Tenants)

Identity recommendations consistently carry the highest point values because credential compromise is the most common initial access vector. These are the highest-return implementations:

The highest-impact action per implementation hour is blocking legacy authentication. It takes under 30 minutes via Conditional Access, permanently prevents a class of attacks, and typically earns 6 or more points.

Devices (20-30% of Maximum Score)

Device recommendations require Intune or Microsoft 365 MDM infrastructure. Organizations without Intune enrollment will see device recommendations show as available but non-actionable until MDM is in place.

If your organization has no Intune deployment, device recommendations represent a large potential score gain but require significant infrastructure investment first. Don't let the device score gap drive your Intune deployment decision; let Intune's broader value drive it, and treat the score improvement as a byproduct.

Applications (10-15% of Maximum Score)

Application recommendations primarily focus on OAuth app permissions and Entra ID application configurations.

The most overlooked recommendation in this category is disabling user consent for unverified applications. A single policy change or an admin consent workflow blocks an entire class of OAuth phishing attacks, and the implementation takes under 15 minutes.

---

The Fastest Legitimate Gains

In order of implementation time relative to points earned:

1. Block Legacy Authentication (30 minutes, 6+ points)

Create a Conditional Access policy blocking all legacy authentication protocols for all users. Exclude only specific service accounts that you've confirmed require basic auth, identified via the sign-in log analysis below.

Before blocking, run this KQL query to identify who is still using legacy auth and what services they are accessing:

SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed in (
    "Exchange ActiveSync",
    "IMAP4",
    "POP3",
    "SMTP",
    "Authenticated SMTP",
    "Other clients",
    "Exchange Web Services",
    "Older Office clients",
    "Exchange Online PowerShell",
    "Reporting Web Services",
    "Unknown"
    )
| summarize LastSeen = max(TimeGenerated), Count = count()
    by UserPrincipalName, ClientAppUsed, AppDisplayName
| order by Count desc

Review the results, build your exception list, then create the Conditional Access block targeting the Other clients client app condition. Run in Report-Only mode for one week before enforcing.

2. Enable Entra ID Identity Protection Risk Policies (2 hours, 10+ points)

Two policies with immediate impact:

• Sign-in risk policy: Require MFA when sign-in risk is Medium or above
• User risk policy: Require password change when user risk is High

These are available under Entra ID Identity Protection in the portal or via Microsoft Graph. The policies auto-apply to all licensed users without manual intervention per-user. The score reflects coverage once the policies are enabled and evaluated.

Using the Graph API to check if risk policies are currently configured:

# Check current risk policies via Graph (requires SecurityEvents.Read.All permission)
az rest --method GET   --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies"   --query "value[?contains(conditions.userRiskLevels, 'high') || contains(conditions.signInRiskLevels, 'medium')].[displayName,state]"   --output table

3. Remove Unused Service Principal Credentials (4-8 hours, 3-7 points)

# List service principals with credentials, sort by oldest end date
az ad sp list --all --output json | python3 -c "
import sys, json
from datetime import datetime, timezone
sps = json.load(sys.stdin)
for sp in sps[:50]:  # sample first 50; run in batches for large tenants
    try:
        result = __import__('subprocess').run(
            ['az', 'ad', 'sp', 'credential', 'list', '--id', sp['id'], '-o', 'json'],
            capture_output=True, text=True
        )
        creds = json.loads(result.stdout or '[]')
        for c in creds:
            end = c.get('endDateTime', '')
            if end:
                print(sp['displayName'], sp['appId'], c['keyId'][:8], end)
    except:
        pass
"

Any credential with an end date in the past is expired and should be removed immediately. Any credential on a service principal that has no sign-in activity in the past 90 days is a candidate for deprovisioning. Verify via sign-in logs before removing.

4. Enable PIM for Privileged Roles (1-2 days including testing, 5-8 points)

Privileged Identity Management converts standing admin assignments to just-in-time assignments. Eligible users request the role when needed, complete MFA and optionally receive approval, and the assignment expires after the configured window (default 8 hours).

Enable PIM for Global Administrator and Privileged Role Administrator first. Then expand to Security Administrator, Exchange Administrator, SharePoint Administrator, and Teams Administrator in subsequent weeks. These five roles cover the majority of high-impact standing privilege in most tenants.

# List current permanent (non-PIM) assignments for privileged roles
az rest --method GET   --uri "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$filter=roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'&$expand=principal"   --query "value[].{Principal:principal.displayName, PrincipalType:principal.@odata.type, AssignmentType:'Permanent'}"   --output table

The GUID 62e90394-69f5-4237-9190-012177145e10 is the built-in Global Administrator role. Replace with the appropriate role definition ID for other roles.

---

Tracking Progress with KQL

Microsoft stores Security Score history in Microsoft Graph, not natively in Log Analytics. Export score data to Log Analytics via the Graph API and a Logic App or Azure Function on a daily schedule. The Graph endpoint for score history:

# Pull last 90 days of daily score snapshots (requires SecurityEvents.Read.All)
curl -s -H "Authorization: Bearer <token>"   "https://graph.microsoft.com/v1.0/security/secureScores?$top=90" |   jq '.value[] | {date: .createdDateTime, score: .currentScore, maxScore: .maxScore, pct: (.currentScore/.maxScore*100|round)}'

While you build that pipeline, use these proxy KQL queries to track hardening activity:

// Track Conditional Access policy changes (monitors legacy auth block and risk policy rollout)
AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName == "Update conditional access policy"
    or OperationName == "Add conditional access policy"
| project TimeGenerated, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
    PolicyName = tostring(TargetResources[0].displayName),
    Result = ResultReason
| order by TimeGenerated desc

// Track PIM role activation events (confirms PIM is being used, not bypassed)
AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "RoleManagement"
| where OperationName has "Add eligible member to role"
    or OperationName has "Activate eligible assignment"
| extend RoleName = tostring(TargetResources[0].displayName)
| extend Requester = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, RoleName, Requester, OperationName
| order by TimeGenerated desc

// Track Identity Protection risk events (confirms risk policies are firing)
SigninLogs
| where TimeGenerated > ago(30d)
| where RiskLevelDuringSignIn in ("high", "medium")
| summarize RiskySignIns = count(), UniqueUsers = dcount(UserPrincipalName)
    by bin(TimeGenerated, 1d), RiskLevelDuringSignIn
| render timechart

---

What Not to Do

Do Not Accept Risk on Recommendations You Have Not Addressed

Accept Risk should document a compensating control, not acknowledge a backlog item. Track every accepted risk in your GRC tool with: the compensating control description, the risk owner by name, and a review date no more than 90 days out. Any accepted risk without a documented compensating control is a finding, not a legitimate score management action.

Do Not Exclude Resources to Hit a Score Target

Excluding resources is legitimate when a specific legacy system genuinely cannot comply with a requirement and you have a network isolation or compensating control documented. It is not legitimate when you want the score to look better for a quarterly review. The exclusions are visible in the raw recommendation data and will appear in any detailed audit of your score methodology.

Do Not Focus on Low-Point, High-Complexity Recommendations First

Some recommendations have complex prerequisites (Intune enrollment, Purview DLP deployment, Defender for Endpoint at scale) but relatively few points. Implement the infrastructure because it has security value; the score improvement is a byproduct. Sequencing your program around score impact alone leads to expensive, low-value implementation work.

Do Not Ignore Score Regression

Microsoft regularly adds new recommendations and changes point weights. A score of 75% three months ago may require additional work to maintain at 75% today, even if you haven't changed anything. Build a monthly review of newly added recommendations into your security operations calendar. Check the Recommended Actions page in the Microsoft Defender portal at the start of each month for net-new items.

---

Realistic Targets by Tenant Maturity

Do not treat Security Score as a compliance pass/fail metric. It is a relative hardening signal for your own tenant over time. Comparing scores between organizations without controlling for tenant size, product licensing, and accepted risks is not meaningful.

---

90-Day Improvement Program

Days 1-15: Assessment and quick wins

Pull the current recommendation list from Microsoft Defender portal (Security.microsoft.com, Security Score section) or via Graph API. Sort by impact score descending. Implement every recommendation under 2 hours of implementation time: legacy auth block, consent settings, unused credential cleanup. Document all existing accepted risks with compensating control and risk owner. Set review dates. Days 16-45: Identity and access hardening

Enable Identity Protection sign-in and user risk policies. Implement PIM for Global Administrator and Privileged Role Administrator in week 3, then expand to Security Administrator and Exchange Administrator in week 4. Complete MFA coverage: enable for all users first, then enforce phishing-resistant methods (FIDO2, Windows Hello for Business) for all admin accounts. Review and prune service principal credentials using the script above. Remove unused applications from Entra ID app registrations. Days 46-90: Device and application layer

Confirm Intune enrollment scope covers the populations referenced by device recommendations. Enable Defender for Endpoint sensor coverage for all enrolled devices. Work through device compliance policy recommendations in order of point value. Implement the admin consent workflow for OAuth applications. Run a quarterly OAuth app review: enumerate all apps with delegated or application permissions and validate each one against a known-good list.

At the end of 90 days, compare the score to the baseline and validate against the raw open recommendation count, not just the score percentage. A genuine 15-point improvement should show 15 fewer high-impact open recommendations, not the same recommendations with more accepted risks.

---

Hardening Checklist

• [ ] Legacy authentication blocked via Conditional Access for all users (exceptions documented from sign-in log analysis, reviewed quarterly)
• [ ] Sign-in risk policy enabled: MFA required at Medium risk threshold or above
• [ ] User risk policy enabled: password reset required at High risk threshold
• [ ] PIM enabled for Global Administrator and Privileged Role Administrator (week 1), then Security Administrator, Exchange Administrator, SharePoint Administrator (weeks 3-4)
• [ ] All service principal credentials reviewed: expired credentials removed, unused service principals deprovisioned
• [ ] User consent for unverified apps disabled (admin consent workflow enabled as the approved alternative)
• [ ] All accepted risks documented with compensating control, risk owner, and 90-day review date
• [ ] Resource exclusions documented with technical justification (not score management rationale)
• [ ] Monthly calendar entry for reviewing newly added Microsoft recommendations
• [ ] Security Score trend exported to Log Analytics via Graph API and Logic App
• [ ] Device recommendation gap analyzed: Intune enrollment scope confirmed relative to recommendation scope
• [ ] Defender for Endpoint sensor coverage at 90% or above of enrolled devices
• [ ] Quarterly OAuth app review scheduled: enumerate all delegated and application permissions against known-good list
• [ ] Score improvement validated against raw open recommendation count, not just percentage