Identity and Access
Entra ID & Conditional Access Review for MSPs
Reviewing identity configuration across a portfolio of Microsoft 365 tenants is repetitive work, and repetitive work is where inconsistency creeps in. A written checklist keeps every Entra ID and Conditional Access review comparable from one customer to the next. This article walks through the checks that matter most, the misconfigurations MSPs find over and over, and how to keep per-tenant drift visible.
Why per-tenant identity review needs a checklist
Each customer tenant was configured by a different administrator, at a different time, against different guidance. Two tenants that look similar in the admin center can behave very differently at sign-in. Without a fixed set of questions, each review reflects whoever ran it rather than a consistent standard.
A checklist does three things. It makes reviews comparable across customers, so a portfolio-wide picture is possible. It makes findings defensible in a customer conversation, because you can show the same checks were applied everywhere. And it makes the review repeatable by any member of your team, not only the person who onboarded the customer.
Keep the checklist conceptual. Portal layouts and policy templates change; the questions you are answering do not. You are always asking: who can sign in, from where, with what, and what happens when the primary path fails.
Conditional Access: the policies to check every time
Conditional Access is evaluated as a set of policies, so review it as a set rather than one policy at a time. Work through these questions for each tenant:
- Coverage. Is there a baseline policy that requires multi-factor authentication for all users, or only for a subset? Report-only policies that were never moved to enforcement are a common gap.
- Exclusions. Every exclusion is a permanent hole until someone reviews it. List every excluded user, group, and role, and confirm each still has a current reason.
- Conditions. Are trusted locations defined sensibly, or is a broad IP range treated as trusted? Is there a policy that blocks legacy authentication, and is it enforced?
- Admin protection. Is there a policy that requires phishing-resistant or otherwise stronger authentication for privileged roles specifically?
- Session controls. Sign-in frequency and persistent browser session settings, especially for unmanaged devices.
- Gaps between policies. A user excluded from the MFA policy but included in nothing else has no second factor at all. Look for the accounts that fall through every gap.
MFA and authentication method gaps
Registration is not enforcement. A tenant can have MFA available while a meaningful share of users have never registered a method, or rely only on SMS. Check the authentication methods policy: which methods are enabled, which are mid-migration, and whether weaker methods such as SMS and voice are still a primary option.
Look for accounts with no strong method registered, service accounts using basic credentials, and shared mailboxes with interactive sign-in enabled. Confirm the tenant has moved from per-user MFA and security defaults toward Conditional Access, or has a deliberate reason not to.
Legacy authentication and protocol-level exposure
Legacy protocols such as older Exchange clients, IMAP, POP, and SMTP AUTH bypass Conditional Access entirely and cannot present a second factor. The review question is simple: is legacy authentication blocked, and does sign-in telemetry confirm nothing is still using it?
A block policy with active legacy sign-ins behind it means something will break when it is enforced. That is a finding and a remediation plan, not a reason to leave the door open. SMTP AUTH deserves its own line at both tenant and per-mailbox level; it is frequently re-enabled for a single device and never turned back off.
Break-glass accounts
Every tenant needs at least one emergency access account that is excluded from Conditional Access, so a misconfigured policy cannot lock everyone out. The checks: do break-glass accounts exist, are they excluded from all Conditional Access policies, are their credentials stored offline and known to more than one person, and is sign-in on these accounts monitored so any use is noticed immediately?
The failure modes MSPs find are consistent: no break-glass account at all, an account that has drifted into everyday use, or one that is not actually excluded from the policies it needs to survive.
Privileged roles and guest access
Count standing assignments to Global Administrator and other high-privilege roles, and compare that against how many people genuinely need them. Note whether privileged access is permanent or time-bound. Flag privileged accounts that also carry a mailbox and a license, since those are phishing targets with administrative rights attached.
For guest access, check how many guests exist, what they can enumerate, and whether invitations are restricted to administrators or open to all members. Stale guests from finished projects accumulate quietly and are rarely removed.
Tracking drift across tenants
A review is a point in time. Between reviews, an administrator disables a policy to troubleshoot, adds an exclusion "temporarily," or re-enables a legacy protocol for one device. The value of running these checks on a schedule rather than once is that you see the delta: a finding that appears three months after a clean review is far more actionable than the same finding discovered cold.
SecurityScore.me runs identity checks per customer workspace on a schedule and raises changes as severity-ranked findings, so drift surfaces in your Security Operations Center rather than at the next manual review. See Entra ID security for the identity specifics, Microsoft 365 security posture for how these checks fit posture management, and Microsoft 365 monitoring for running them across the portfolio on a schedule.
Frequently asked questions
Learn more
- Microsoft 365 security assessment checklist
The full-tenant checklist this identity review is one section of.
- Entra ID security
Identity posture reviewed across customer workspaces.
- Microsoft 365 security posture
Posture management and configuration drift across tenants.
- Microsoft 365 monitoring
Running identity checks consistently across the portfolio on a schedule.
- CVE prioritization: NVD vs CISA KEV vs EPSS
The vulnerability-triage side of the same per-customer review.
- External attack surface monitoring
The checks that cover what sits outside the tenant.
- MSP security monitoring: what to track across every tenant
Where identity drift fits alongside external monitoring and CVE exposure.