Microsoft ships Entra ID — formerly Azure Active Directory — with default settings designed to balance usability and security for the broadest possible range of organizations. For an enterprise with a dedicated security team and a mature identity governance program, those defaults are a starting point that gets customized before the tenant goes into production. For most of the regulated SMBs your clients are, those defaults may still be in place months or years after the tenant was first configured — and some of them represent significant security gaps.
This is not a theoretical problem. Identity-based attacks are consistently the leading cause of cloud security incidents. Business email compromise through compromised Microsoft 365 credentials, unauthorized access to Azure resources through overprivileged service accounts, lateral movement through guest account relationships — these are not advanced nation-state techniques. They exploit configurations that many organizations accept because no one ever reviewed them against a security baseline.
As the MSP responsible for these environments, a structured Entra ID security review is both a defensible security service and a direct contribution to your clients’ compliance posture. CMMC, HIPAA, PCI DSS, SOC 2, and NIST CSF all have controls that map to identity and access management. The gaps this article describes are not just technical issues — they are compliance evidence gaps.
Why Default Settings Are a Recurring Problem, Not a One-Time Fix
The standard advice is to review your Entra configuration once and harden it against a baseline. That advice misses the fundamental challenge of cloud identity environments: they drift. Settings change when someone in IT solves a ticket by relaxing a policy. Guest accounts accumulate as project collaborations end and cleanup never happens. Conditional Access policies get exceptions added to resolve a user complaint and those exceptions never get reviewed. Service principals get created for a vendor integration and sit with broad permissions long after the integration is decommissioned.
Cloud configuration drift is not a sign of a bad IT team. It is the natural consequence of a dynamic environment managed under operational pressure without a systematic review cadence. The same organization that hardened their tenant in 2023 may have a materially different security posture in 2026 — not because anyone made a bad decision, but because dozens of small decisions accumulated without a review process to catch them.
This is why cloud security review needs to be a recurring service with a defined cadence, not an annual project. A configuration that was compliant in January may not be compliant in June if a new guest was added with overpermissive roles, a legacy authentication protocol was re-enabled to support an old application, or a Conditional Access exclusion was added during a travel emergency and never removed. Detecting those changes — ideally within days, not months — is what turns a cloud security review from a point-in-time assessment into continuous protection.
The Default Settings and Common Gaps Worth Reviewing
What follows is not an exhaustive list of every Entra security setting. It is the areas where default configurations or common operational decisions most frequently create meaningful security gaps for regulated SMB clients — the ones that come up repeatedly in cloud security reviews and that map most directly to compliance control requirements.
Multi-Factor Authentication coverage and Conditional Access policy gaps
MFA is not a binary — it is not simply enabled or disabled across the tenant. The more operationally relevant question is which users are covered by which MFA requirements under which conditions, and whether there are gaps in that coverage that a threat actor could exploit. The specific areas to inspect: whether all privileged roles require phishing-resistant MFA (not just any second factor), whether Conditional Access policies have exclusions that cover more users than originally intended, and whether legacy authentication protocols — Basic Auth, older SMTP AUTH configurations — are blocked tenant-wide or selectively enabled for specific mailboxes or applications.
Legacy authentication is the gap that shows up most consistently. Microsoft has deprecated Basic Authentication in Exchange Online, but legacy auth protocols can still be enabled for specific workloads, and some older client configurations or third-party integrations re-enable them without the IT team realizing the security implication. Legacy auth bypasses modern authentication entirely, which means MFA policies do not apply to those sessions. An attacker with a valid credential can authenticate via legacy auth and produce a fully valid session token regardless of what the Conditional Access policies say.
Privileged role assignments and Privileged Identity Management
Global Administrator is the highest-privilege role in an Entra tenant, and it is routinely over-assigned. Common findings: more than two to four Global Administrator accounts in a tenant of any size; service accounts or shared mailboxes assigned Global Admin because it was easier than scoping a more limited role; accounts assigned Global Admin for a project that concluded and the assignment was never removed; and no use of Privileged Identity Management for just-in-time elevation of privileged roles.
Privileged Identity Management — available with Entra ID P2 or Microsoft 365 E3/E5 licensing — allows privileged role assignments to be time-limited and require explicit activation with justification and MFA. Without PIM, privileged role assignments are permanent and persistent. An account that is permanently assigned Global Admin is a high-value target in any BEC or credential compromise scenario. An account that can elevate to Global Admin for a four-hour window with MFA and an approval workflow is a substantially harder target for the same threat actor.
Beyond Global Administrator, the review should include Exchange Administrator, SharePoint Administrator, and Security Administrator assignments — these are elevated enough to enable significant damage if compromised, but frequently assigned more broadly than Global Admin reviews catch.
Guest account inventory and external collaboration settings
Guest accounts in Entra ID represent external identities — vendors, consultants, contractors, partners — who have been granted some form of access to the tenant. The default settings for guest access are permissive: guests can enumerate other guests in the directory, see group memberships, and in some configurations access resources that were not intended to be shared externally. The default guest invitation settings allow any member of the tenant to invite external guests, which means the guest account inventory can grow substantially without IT visibility.
For regulated clients, the guest account picture matters for compliance. CMMC, HIPAA, and PCI DSS all have access control requirements that apply to external parties with access to regulated data or systems. A guest account with Teams access to a SharePoint library that contains HIPAA-protected health information is an access control finding, not just a housekeeping issue. The review should cover: total guest account count and active vs. inactive status, which resources guests have access to, whether guests have access to any resources that contain regulated data, and whether the tenant-wide guest invitation settings restrict who can invite externals.
Conditional Access policy completeness and exception hygiene
Conditional Access policies are only as strong as their coverage. Common gaps that show up in reviews: policies that apply to most users but exclude break-glass accounts or service accounts in ways that create exploitable paths; policies that require compliant devices for some scenarios but have named location exclusions that effectively bypass device compliance for remote workers; sign-in risk policies configured but set to audit mode rather than enforcement; and policies that were effective when written but have not been reviewed against the current user and application inventory.
Policy exceptions are the most common source of Conditional Access drift. An exception added for a traveling executive becomes permanent. An IP range added as a trusted location for an old office is never removed after a facility closure. A break-glass account excluded from all Conditional Access policies — which is appropriate — is also the highest-value target if compromised, and the monitoring and protection around that account needs to reflect its status.
Application registrations and service principal permissions
Application registrations and service principals represent non-human identities in the tenant — third-party applications, automation scripts, vendor integrations, and internal tools that have been granted API permissions to operate within the environment. The default behavior allows any user in the tenant to register applications, which means the app registration inventory can grow without centralized visibility or governance.
The specific review areas: whether users are permitted to register applications without admin approval; which applications have been granted admin consent to tenant-wide API permissions (as opposed to user-delegated permissions); whether any service principals have permissions that are broader than their documented function; and whether any application registrations are associated with vendors or integrations that are no longer active. An application with tenant-wide Mail.Read or Files.ReadWrite.All permissions that was granted admin consent for a project two years ago and has never been used since is a persistent privilege that belongs in neither the environment nor the evidence package your client hands to an auditor.
Security defaults and Microsoft Secure Score gaps
Microsoft Secure Score is a useful starting baseline, but it has two limitations that MSPs need to account for. First, it reflects Microsoft’s general recommendations, not the specific requirements of your client’s compliance framework. A client can have a Secure Score of 70 and still have significant CMMC or HIPAA gaps because Secure Score is not a compliance assessment. Second, Secure Score recommendations are additive — they tell you what to turn on, but they do not always surface what should be turned off or tightened. A high score does not mean a clean tenant.
For tenants that have Security Defaults enabled rather than Conditional Access policies — typically smaller tenants or those migrated without a configuration review — the review should assess whether Security Defaults are providing adequate coverage for the client’s specific risk profile, or whether the transition to a full Conditional Access policy set is warranted. Security Defaults provide a floor. For regulated clients with CMMC, HIPAA, or PCI DSS obligations, that floor is often below the required ceiling.
Sign-in and audit log configuration and retention
Entra ID generates sign-in logs and audit logs that are essential for incident response, compliance evidence, and detection of anomalous activity. The default retention for these logs in Entra ID is 30 days for sign-in logs and 30 days for audit logs in the free tier, and 90 days with a P1 or P2 license. For clients with HIPAA, CMMC, or PCI DSS obligations, 30 or 90 days is typically insufficient. HIPAA requires audit controls with documentation of system activity over a longer period. CMMC AU practices require audit log retention sufficient to reconstruct security-relevant events.
The review should confirm whether logs are being forwarded to a SIEM or long-term storage solution outside of Entra, what the effective retention period is for sign-in and audit data, and whether the logging configuration captures the events required by the client’s applicable compliance framework. A client who cannot produce 12 months of sign-in history for a specific account during an audit or incident investigation has a compliance gap that no amount of Conditional Access policy cleanup will address.
What to Review Before Your Next QBR
The QBR is the natural moment to surface cloud identity findings to a client — both because it is a structured conversation about business outcomes and because it creates a recurring rhythm that prevents the review from slipping into annual-scramble territory. A structured Entra review ahead of each QBR gives you specific, client-named findings to discuss rather than generic security posture observations.
The pre-QBR Entra review should cover these areas at minimum, organized in the order that maps most directly to compliance requirements and business risk:
MFA coverage audit. Pull the current list of users without registered MFA methods. Filter for users with access to regulated data or systems. Any user in that filtered list who lacks MFA registration is an active, specific risk to surface in the QBR — with a name, a role, and the compliance control it implicates.
Privileged role review. Pull the current list of all Global Administrator, Exchange Administrator, SharePoint Administrator, and Security Administrator role assignments. Compare to the prior quarter’s list. Any new assignments, any assignments to accounts that are not primary IT staff, or any count above four Global Admins should be flagged for discussion.
Guest account activity review. Pull all guest accounts and filter for those with no sign-in activity in the past 90 days. Stale guest accounts are both a security risk and a compliance evidence gap. Present the count to the client and recommend a review-and-remove cycle before the QBR meeting.
Conditional Access exception review. Review all active Conditional Access policy exclusions. Any exclusion that covers more than two or three named accounts, or any exclusion added more than 90 days ago that has not been re-evaluated, is a finding worth discussing.
Legacy authentication status. Confirm whether legacy authentication is blocked via Conditional Access across all protocols for all users. If any legacy auth-capable flows are active, identify the application or user that requires it and whether a modern alternative is available.
App permissions review. Pull admin-consented application permissions and flag any applications with broad graph API permissions (Mail.Read, Files.ReadWrite.All, Directory.ReadWrite.All, or similar) that are not actively documented and business-justified.
Log retention verification. Confirm that sign-in and audit logs are being forwarded to a retention solution outside of the default 30/90-day Entra window, and that the retention period meets the requirement for the client’s applicable compliance framework.
The QBR presentation of these findings should frame each item in business terms: which risk it represents, which compliance obligation it is relevant to, and what remediation looks like in practical terms. “Your Exchange Administrator role is assigned to six accounts, and three of them have not been active in the past six months” is a more useful client communication than a generic statement about privileged access hygiene.
Connecting Identity Findings to Compliance Evidence
An Entra ID security review is not just a technical exercise — it is compliance evidence generation. Every finding you document, every remediation you complete, and every configuration you validate against a security baseline produces evidence that maps to specific framework controls across CMMC, HIPAA, PCI DSS, SOC 2, and NIST CSF.
For CMMC-obligated clients, the identity review covers Access Control (AC) practices around least privilege, account management, and remote access; Identification and Authentication (IA) practices around MFA, password management, and identifier management; Audit and Accountability (AU) practices around log retention and access audit trails; and Configuration Management (CM) practices around configuration baselines and change tracking. A structured identity review that produces documented findings against these domains is contributing directly to the evidence package the client needs for their SPRS submission and eventual C3PAO assessment.
For HIPAA-obligated clients, the identity review maps to the Access Control (§164.312(a)(1)) and Audit Controls (§164.312(b)) implementation specifications under the Technical Safeguards. The guest account review and privileged role review are direct contributions to the Access Control requirement for unique user identification and access to electronic protected health information.
For SOC 2 clients in the certification process, the Logical and Physical Access Controls criterion is one of the most evidence-intensive sections of the audit. Quarterly Entra reviews with documented findings, remediation records, and user access certifications are exactly the type of evidence a SOC 2 auditor reviews under CC6.1 through CC6.7.
The practical implication: the Entra review your team does before each QBR should produce a structured, dated document — not just notes in a ticket — that can be incorporated into the quarterly compliance evidence package. A dated document showing that privileged role assignments were reviewed, guest accounts were audited, and Conditional Access policies were validated is audit-ready evidence. Notes in a PSA ticket are not.
Operationalizing the Review
A structured Entra ID security review needs three things to be a repeatable managed service rather than an ad hoc project: a defined checklist that runs the same way every time, tooling that surfaces configuration changes and drift without requiring manual queries, and a documentation workflow that produces dated evidence rather than undated notes.
The checklist is the starting point. A checklist that your team works through the same way for every client, every quarter, produces consistent output — consistent enough that a compliance auditor reviewing two years of quarterly evidence packages can see a continuous, structured practice rather than a series of unrelated snapshots.
Tooling that detects configuration drift between reviews closes the gap between quarterly review cycles. A Conditional Access policy that gets a new exception in week two of the quarter should not wait until week thirteen to surface. Cloud security configuration monitoring — daily or continuous, depending on the client’s risk profile and service tier — gives your team visibility into changes as they happen rather than changes that have been in place for 90 days by the time you review them.
→ The SentinelBaseline Platform page covers cloud and identity security review cadence across service tiers — from monthly review at Baseline to daily cloud drift detection at higher tiers — and how those outputs integrate with compliance framework mapping.
The documentation workflow ensures that what the review finds becomes evidence. The output of each review should be a dated findings document organized by review area, with the current status, any changes from the prior review, and remediation actions taken or recommended. That document — stored in your documentation system and shared with the client — is what turns a recurring review into a continuous compliance evidence record.
→ Southern Sentinel’s channel-exclusive model is built specifically for MSPs serving regulated SMBs — the platform provides the cloud and identity security review infrastructure; your team provides the client relationship and remediation delivery. The billable hours from findings remediation stay with your practice.
If you want to see how the platform’s cloud identity review, Entra configuration monitoring, and compliance-mapped reporting work in practice — and how to structure this as a recurring, billable service for your M365 client base — book a 30-minute demo.
Frequently Asked Questions
How often should an Entra ID security review be conducted?
For regulated clients — CMMC, HIPAA, PCI DSS — a structured review should happen at minimum quarterly, aligned to the QBR cycle. For clients with higher risk profiles or more dynamic environments, monthly review is more appropriate. Between structured reviews, continuous or daily configuration drift detection fills the gap — surfacing changes to Conditional Access policies, role assignments, and guest account status as they happen rather than waiting for the scheduled review date. The review cadence should match the client’s compliance requirements and how frequently their environment changes, not a convenient scheduling interval for your team.
What licenses are required to review and remediate these settings?
Most of the review areas in this article are accessible with any Entra ID tier, including the free tier included with Microsoft 365 Business Basic. Conditional Access policies and Privileged Identity Management require Entra ID P1 and P2 respectively — P1 is included in Microsoft 365 Business Premium, and P2 is included in Microsoft 365 E5 or available as an add-on. Sign-in log retention beyond 30 days requires P1 or P2. For clients on Business Basic or Business Standard without P1, the absence of Conditional Access is itself a significant finding — the conversation about licensing is part of the remediation discussion, not a separate conversation.
How do I explain Entra security review findings to a non-technical client?
Frame findings in terms of the risk they represent and the specific compliance obligation they affect, not in technical configuration language. “Six accounts have permanent Global Administrator access, including two that have not signed in for four months — if either of those accounts is compromised, an attacker has full administrative access to your entire Microsoft 365 environment with no additional barriers” is a communication a non-technical client understands and can act on. The technical remediation detail — removing stale assignments, implementing PIM for active admins — goes in the service notes, not the client conversation. The business risk goes in the QBR.
What is cloud drift and why does it matter between reviews?
Cloud configuration drift is the gradual divergence of a cloud environment from its intended security baseline — caused by the accumulation of small operational decisions, exceptions, and workarounds that each seem reasonable in isolation but degrade the overall security posture over time. It matters between reviews because a quarterly review cadence means 90 days of potential drift before detection. A Conditional Access exception added in week one is active for the remaining 12 weeks of the quarter before you review it. A new guest account added with overpermissive access operates without scrutiny for the same period. Continuous drift detection — alerting when configurations change outside of an approved change process — reduces that exposure window from weeks to hours.
Does an Entra ID review require special permissions in the client tenant?
Reading most of the configuration areas covered in this article requires Global Reader, Security Reader, or a combination of role-specific read permissions. You do not need Global Administrator access to conduct the review — read-only roles are sufficient for assessment purposes. For any remediation actions — removing role assignments, modifying Conditional Access policies, revoking application permissions — more elevated permissions are required, and those actions should follow your standard change management process with client awareness and approval before execution. The review and the remediation are separate activities with different permission requirements.
How do these findings relate to Microsoft Secure Score?
Microsoft Secure Score captures many of the same configuration areas but has important limitations as a compliance tool. It reflects Microsoft’s general recommendations, not the specific requirements of CMMC, HIPAA, or PCI DSS. It does not surface guest account inventory issues, stale role assignments, or Conditional Access exception accumulation in the same granular way a structured review does. It also cannot tell you whether log retention meets a specific compliance framework’s requirements. Use Secure Score as a quick directional indicator — a tenant scoring below 50 almost certainly has significant gaps — but do not use it as a substitute for a structured review. Compliance auditors and C3PAO assessors will ask about specific controls, not about your Secure Score.