Lesson 32 — Microsoft Entra Identity Secure Score
Microsoft Entra Identity Secure Score provides a percentage-based view of how closely a tenant aligns with Microsoft's identity security recommendations.
The score is not a guarantee that the environment is secure, and it is not a direct prediction of compromise. It is a prioritisation and measurement tool that helps identity teams identify improvement opportunities, compare current controls with recommended practices and track posture over time.
This lesson explains how to read the score, interpret recommendations and point values, distinguish posture from compliance, investigate score changes, prioritise remediation and build an evidence-based identity security improvement programme.
What you will learn
This lesson explains how to use Identity Secure Score and Microsoft Entra recommendations to assess, prioritise, implement and verify identity security improvements.
Learning objectives
After completing this lesson, you should be able to use Microsoft Entra Identity Secure Score as a practical identity security management tool.
- Explain what Identity Secure Score measures.
- Distinguish Identity Secure Score from Microsoft Secure Score.
- Interpret recommendations, points and implementation status.
- Understand why a score can rise or fall.
- Prioritise improvements by risk, effort and dependency.
- Validate recommendations against the tenant design.
- Track remediation evidence and posture trends.
- Build a repeatable Identity Secure Score review process.
The problem this solves
Identity teams often know that security can be improved but struggle to decide where to begin, how to measure progress and how to explain priorities to leadership.
Identity Secure Score turns recommended controls into a visible improvement backlog with measurable points and historical trends.
Identity Secure Score lifecycle
What Identity Secure Score is
Identity Secure Score is shown as a percentage indicating how closely the tenant aligns with Microsoft's current identity security recommendations.
It gives administrators a repeatable way to measure posture, plan improvements and observe change over time.
What it is not
The score is not a penetration test, certification, compliance result or promise that an attacker cannot succeed.
A high score can coexist with unmanaged risks outside the evaluated controls, while a lower score can reflect legitimate architectural exceptions.
Score interpretation
| Score tells you | Score does not tell you |
|---|---|
| Alignment with evaluated Microsoft identity recommendations | The exact probability of a breach |
| Which recommended actions may improve posture | Whether every recommendation is appropriate for your tenant |
| How posture changes over time | Whether all regulatory obligations are satisfied |
| Where available improvement points remain | Whether operational implementation was safe and complete |
| A common measurement for improvement planning | A replacement for risk assessment or security testing |
Identity Secure Score versus Microsoft Secure Score
Identity Secure Score focuses on Microsoft Entra identity recommendations and is available through the Microsoft Entra experience.
Microsoft Secure Score in the Defender portal provides a broader security-posture measurement across supported Microsoft security controls.
Why the distinction matters
The two scores may use related improvement concepts but should not be treated as interchangeable values.
Always record which portal, score and recommendation set is being discussed in reports and tickets.
Score comparison
| Measurement | Primary focus | Use it for |
|---|---|---|
| Identity Secure Score | Microsoft Entra identity security recommendations | Identity posture planning and tenant-specific improvement |
| Microsoft Secure Score | Broader Microsoft security posture and improvement actions | Cross-product security management and executive reporting |
| Compliance score | Assessment against compliance controls and standards | Compliance-management planning and evidence |
| Identity risk | Risk signals associated with users and sign-ins | Detection, investigation and Conditional Access response |
How recommendations work
Microsoft Entra evaluates supported configuration signals and presents recommendations tailored to the tenant.
Each recommendation can include an explanation, affected configuration, security value, implementation guidance and associated score points.
Recommendation questions
- What risk is this control intended to reduce?
- Which identities or applications are affected?
- Is the recommendation licensed and technically available?
- Does another control already address the risk?
- What could break during implementation?
- How will success be verified?
Recommendation review workflow
Points and percentages
Recommendations contribute available improvement points. The percentage reflects the points achieved compared with the points currently available to the tenant.
The score can change when controls are implemented, configurations regress or Microsoft changes the available recommendation set.
Do not chase points blindly
A recommendation with many points may be important, but point value alone is not a complete risk calculation.
Prioritisation should also consider privileged exposure, attack likelihood, affected population, implementation effort and existing controls.
Risk-based prioritisation
| Factor | Question | Priority effect |
|---|---|---|
| Privilege | Does the issue expose administrators or sensitive roles? | Raise priority |
| Population | Does it affect every user or a small controlled group? | Increase with blast radius |
| Attack path | Does it enable common credential or token attacks? | Raise priority |
| Existing control | Is the same risk already reduced another way? | May lower urgency |
| Implementation risk | Could the change disrupt authentication or business access? | Require staged deployment |
| Effort | Can a meaningful risk reduction be achieved quickly? | Favour safe quick wins |
Common identity improvement themes
Recommendations commonly focus on stronger authentication, reduced legacy exposure, privileged-account protection, access governance and modern identity controls.
The exact recommendation set can change as Microsoft updates the service and evaluates the tenant.
Typical review areas
- Multifactor authentication
- Privileged-role protection
- Legacy authentication reduction
- Self-service password reset
- Conditional Access coverage
- Application and consent governance
- Guest and external access
- Identity lifecycle controls
Prioritisation matrix
| Risk | Effort | Recommended handling |
|---|---|---|
| High | Low | Implement as an urgent quick win after validation |
| High | High | Create a controlled remediation project with executive ownership |
| Medium | Low | Schedule into the next improvement cycle |
| Medium | High | Compare benefit, dependency and compensating controls |
| Low | Low | Implement where safe and operationally efficient |
| Low | High | Defer or accept with documented rationale |
Score changes
A rising score can indicate implemented controls, broader coverage or updated assessment results.
A falling score can indicate configuration regression, a newly applicable recommendation, a changed calculation or additional points becoming available.
Investigate the change—not just the number
Compare recommendation-level status before and after the score movement.
The overall percentage may fall even when no control was removed if the total available points or recommendation catalogue changed.
Score-change investigation
Implementation status
Do not assume a recommendation is complete merely because a project ticket was closed.
Confirm that the intended control is active, covers the correct identities and applications, and is recognised by the assessment.
Propagation and reassessment
Configuration changes may not appear in the score immediately. Allow for service processing and reassessment before concluding that implementation failed.
Retain direct configuration evidence rather than relying solely on the score update.
Implementation evidence package
| Evidence | Purpose |
|---|---|
| Recommendation title and identifier | Defines the exact improvement being addressed |
| Pre-change configuration | Records the original exposure and rollback state |
| Approved change record | Shows ownership, scope and timing |
| Pilot and test results | Demonstrates safe operational behaviour |
| Post-change configuration | Proves the control is active |
| Score or recommendation update | Confirms reassessment where applicable |
| Exception or residual risk | Documents incomplete coverage and ownership |
Exceptions and compensating controls
Some recommendations may not be immediately suitable because of legacy applications, emergency accounts, operational dependencies or licensing constraints.
Record the reason, affected population, compensating controls, risk owner and review date.
Do not hide legitimate exceptions
A lower score with transparent, controlled exceptions is more trustworthy than a higher score achieved through unsafe configuration or inaccurate reporting.
Exceptions should remain visible until the underlying dependency is removed.
Exception workflow
Score and compliance
Identity Secure Score can support a security and compliance programme by showing progress against recommended controls.
It does not establish compliance by itself. Regulatory and contractual requirements must be mapped and evidenced independently.
Score and Zero Trust
Recommendations can help strengthen Zero Trust identity principles such as explicit verification, least privilege and assumption of breach.
The score should be combined with Conditional Access, Identity Protection, access reviews, PIM, workload identity governance and operational monitoring.
Reporting to leadership
Report the score alongside completed controls, material residual risks, exceptions, planned improvements and notable regressions.
A single percentage without explanation can create a misleading impression of security maturity.
Useful reporting measures
- Current score and trend
- High-risk open recommendations
- Points gained during the period
- Regressions and their causes
- Approved exceptions
- Controls awaiting licensing or application remediation
Monthly review workflow
Agent Foskett investigation: “The score dropped overnight…”
Security indicators
- A previously completed high-value recommendation regresses.
- MFA or privileged-role protection loses coverage.
- Legacy authentication exposure reappears.
- Conditional Access policies are disabled or excluded broadly.
- Score changes follow an unapproved configuration update.
- Exceptions remain open after their review dates.
Operational indicators
- The score changes without a recorded explanation.
- Recommendations have no assigned owner.
- Completed projects are not recognised after reassessment.
- Teams optimise points without testing user impact.
- Reports show only the percentage and omit residual risks.
- Recommendation reviews stop for several months.
Identity Secure Score review checklist
| Review | Question | Evidence |
|---|---|---|
| Trend | Why did the score change? | History and recommendation-level comparison |
| New actions | Which new recommendations now apply? | Recommendation catalogue and dates |
| Risk | Which open action reduces the most important identity risk? | Risk-based priority assessment |
| Progress | Are implemented controls active and correctly scoped? | Configuration and test evidence |
| Exceptions | Are deferrals approved and still justified? | Risk owner and review date |
| Ownership | Does every planned improvement have an owner? | Action register and target date |
Common mistakes
- Treating the score as a guarantee of security.
- Confusing Identity Secure Score with Microsoft Secure Score.
- Prioritising only by point value.
- Implementing recommendations without a pilot.
- Ignoring licensing and application dependencies.
- Assuming every score drop means a control was removed.
- Reporting a percentage without explaining residual risk.
Best practices
- Review recommendations on a regular schedule.
- Prioritise privileged and broad identity exposure.
- Test high-impact authentication changes in stages.
- Keep implementation and exception evidence.
- Investigate recommendation-level changes behind the score.
- Combine score data with incidents, audits and risk signals.
- Use trends to measure improvement—not to chase perfection.
Key takeaways
- Identity Secure Score is a percentage indicating alignment with Microsoft's identity security recommendations.
- It is a posture-management tool, not a guarantee, compliance result or breach prediction.
- Identity Secure Score and Microsoft Secure Score are related but distinct measurements.
- Recommendations should be validated against tenant architecture, licensing and operational risk.
- Improvement points help measure progress but should not replace risk-based prioritisation.
- A score can fall because controls regress or because the available recommendation baseline changes.
- Implementation should include testing, evidence, reassessment and target verification.
- Legitimate exceptions require compensating controls, ownership and review dates.
- Leadership reporting should explain trends, open risks, improvements and exceptions.
- The best use of Identity Secure Score is a repeatable, evidence-based security improvement programme.
Related Agent Foskett resources
Continue learning
Microsoft Entra Identity Secure Score
Microsoft Entra Identity Secure Score is a percentage-based indicator of alignment with Microsoft identity security recommendations. It helps organisations measure identity posture, prioritise improvement actions and track progress over time.
Microsoft Entra Academy Lesson 32 — Identity Secure Score
This Agent Foskett lesson explains how to interpret Identity Secure Score, review recommendation points, investigate score changes, prioritise remediation, document exceptions and build a repeatable identity security improvement programme.
