Microsoft 365 + Entra ID Hardening for Regulated Mid-Market: The Twelve Controls Auditors Walk First

Why identity is where the audit starts A SOC 2, HITRUST, or HIPAA assessor walking into a regulated mid-market organization on Microsoft 365 does not, as the popular narrative suggests, start with the firewall, the network topology, or the data-loss prevention rules. They start with identity. The reason is structural: every workflow, every data-access decision, every administrative action, every workforce on/offboarding event lives in Entra ID first and shows up everywhere else second. If the identity layer is loose, every downstream control inherits the same looseness. If the identity layer is tight, the rest of the audit becomes evidence collection rather than gap analysis. We run identity-led tenant reviews on every Microsoft 365 engagement that touches a regulated workload. The pattern across mid-market healthcare, regulated SaaS, financial services, and PE-backed portfolio companies is consistent. The same twelve controls produce the same findings. The orgs that pass the audit cleanly have walked the twelve before the assessor does. The orgs that produce remediation exhibits during the engagement have either skipped one of the twelve or implemented it loosely enough that the evidence does not survive the auditor's first follow-up question. This is the reference for the twelve. Each control is mapped to the SOC 2 Trust Services Criteria, HITRUST CSF, and HIPAA Security Rule citations the assessor will tie it to. Each is paired with the configuration evidence the audit will ask for and the most common implementation mistake we audit. The list is not exhaustive, Entra has hundreds of toggles, but it is the twelve that produce ninety percent of the audit findings we see, in the order an assessor walks them. The twelve controls, in audit order 1. MFA on every account, with phishing-resistant methods on privileged ones The first question. Multi-factor authentication on one hundred percent of accounts. Phishing-resistant methods (FIDO2 security keys, Windows Hello for Business, certificate-based authentication) on every account with administrative or privileged access. The control maps to SOC 2 CC6.1, HITRUST 01.b, and HIPAA §164.312(d), person or entity authentication. The audit question is not "do you have MFA enabled." The audit question is "produce the evidence that every account is enrolled, and that the privileged tier uses methods resistant to phishing." Two artifacts answer it: the Authentication Methods report from Entra (filtered to show enrollment status per user) and the Conditional Access policy that enforces phishing-resistant MFA on the privileged role assignments. Most tenants we audit have MFA enabled at the policy level but have not enforced phishing-resistant methods on the global administrators, the SharePoint administrators, the Exchange administrators, or the privileged role activation paths. The exception list writes itself. The most common implementation mistake: SMS or voice MFA on accounts that hold any administrative privilege. SMS-based MFA was deprecated as a primary authenticator in NIST 800-63B revision drafts, and a Microsoft-published 2024 advisory noted that SMS-based factors are bypassed in the great majority of observed account-takeover incidents involving admins. The audit will not block on the legacy NIST language; the audit will block on the absence of a phishing-resistant tier for privileged users. 2. Conditional Access policies covering every sign-in surface Every sign-in path into the tenant has to be governed by a Conditional Access policy. Web sign-in, modern-auth client sign-in, legacy-auth client sign-in, and the implicit sign-in surfaces (device registration, password change, app token refresh) each need a policy that names the audience, the session controls, and the access controls. The control maps to SOC 2 CC6.6, HITRUST 01.j, and HIPAA §164.312(a)(1), access control. The auditor's evidence request is the export of the Conditional Access policy state, every policy, the user/group scope, the application scope, the conditions, the access controls, and the report-only versus enabled flag. The artifact has to be current, not from the prior assessment cycle, and the change log on the policies has to be clean. The implementation mistake: legacy authentication is not blocked tenant-wide. Even if Exchange Online has set authentication policies disabling legacy auth, the absence of a Conditional Access policy that explicitly blocks legacy clients is an audit finding. The compensating control, "we use mailbox-level authentication policies", does not survive the assessor's pull on the report-only Conditional Access logs that show legacy sign-ins still being attempted. 3. Privileged Identity Management on every directory and Azure role Standing administrative access is the single largest unaddressed audit finding we see in mid-market Microsoft tenants. Every administrative role, Global Administrator, Privileged Role Administrator, Exchange Administrator, SharePoint Administrator, Compliance Administrator, the dozens of Entra and Microsoft 365 administrative roles, should be eligible-only, activated through Privileged Identity Management with an approval, a justification, and a time-bounded window. The control maps to SOC 2 CC6.3, HITRUST 01.q, and HIPAA §164.308(a)(4), information access management. The auditor will ask for the PIM configuration export, the activation logs for the last evaluation period, and the access reviews that have closed in the last twelve months. The orgs that have not deployed PIM ship a list of permanent administrators that the auditor will read as a structural finding, sometimes with a request for compensating controls and a remediation calendar before issuance. The implementation mistake: PIM enabled on Entra roles but not on Azure resource roles. The assessor will pull both surfaces. A clean PIM posture covers the directory roles AND the Azure subscription/management group/resource roles where any administrative privilege is assigned. 4. Two break-glass accounts with documented procedures Every tenant needs two emergency-access accounts (commonly called break-glass accounts), Global Administrator role-assigned, excluded from the standard Conditional Access policies, password rotation under physical-token control, sign-in alerting on every successful sign-in. Two accounts, not one, so a single account compromise does not lock the org out of its own tenant. The control maps to SOC 2 CC6.3, HITRUST 01.q, and HIPAA §164.308(a)(7), contingency operations. The audit evidence is the configuration record for both accounts, the documented procedure for credential storage and rotation, the alerting configuration that fires on every break-glass sign-in, and a recent test record showing the procedure was exercised. Tenants that have one break-glass account, or have configured break-glass accounts and never tested them, surface as findings. 5. Audit log retention at the right tier, with the queryable evidence path Microsoft 365 Audit (formerly Unified Audit Log) is the regulator's first request when an investigation touches the tenant. Standard tier retention is ninety days; Audit Premium extends to one year by default and supports up to ten years on appropriate licenses. Most regulated mid-market organizations need at least one-year retention to clear the typical assessor's evidence window, and orgs in healthcare with HIPAA breach-investigation obligations frequently need six years. The control maps to SOC 2 CC7.2, HITRUST 09.aa, and HIPAA §164.312(b), audit controls. The auditor will run a structured query, typically a date-bounded extract for a named user, a named record set, or a named action, against the audit log. If the response is "we cannot produce that range" or "the log only covers the last ninety days," the finding is structural. License the right tier, configure the retention, document the query path, and rehearse the structured pull before the audit asks for it. The implementation mistake: relying on Microsoft Sentinel or a third-party SIEM as the only retention surface and not configuring the native audit log retention. The auditor's request is for the M365 audit log, not the SIEM extract. The SIEM extract is a useful supplement; it is not the answer. 6. App registrations and consent governance Every OAuth-registered application in the tenant, line-of-business apps, Microsoft 365 add-ins, third-party SaaS integrations, Power Platform connectors, has a permission scope and a consent grant. In a tenant with default settings, any user can consent to any third-party application asking for low-impact permissions, and a workflow that asks for high-impact permissions can sit in pending approval forever. The control maps to SOC 2 CC6.6, HITRUST 09.s, and HIPAA §164.308(a)(4), information access management. The audit evidence is the App Registrations and Enterprise Applications inventory with permission scopes, consent grants, and last-sign-in timestamps; the configured admin consent workflow with current approver and SLA; and the user consent settings restricted to low-impact, verified-publisher applications. The implementation mistake: leaving user consent at "users can consent to any application." Every regulated mid-market tenant we have audited with this default configuration has at least one app registration with high-impact permissions consented to in error, and the audit finding follows. 7. Guest access and external collaboration scoped to verified domains External collaboration, Teams external access, SharePoint external sharing, Entra B2B guest invitations, is one of the surfaces an auditor walks late but a regulator walks early. The default tenant configuration permits collaboration with any external domain, with email invites, with default-licensing on guest accounts. For a regulated workload that should usually be tightened to verified domains, sponsored guests, time-bounded access, and a quarterly access review. The control maps to SOC 2 CC6.1, HITRUST 09.s, and HIPAA §164.308(a)(4). Audit evidence: the External Collaboration Settings export, the SharePoint External Sharing configuration at the tenant and per-site level, the guest user inventory with last sign-in, and the access review on guest accounts. The implementation mistake: tenant-wide unrestricted external sharing for "operational convenience." The compensating control argument is rarely accepted. The tenant configuration is a finding; the named exception cases (a partner workflow, an M&A due-diligence room) get narrow per-site exceptions with documented approval. 8. Identity Protection risk-based policies on user and sign-in risk Entra ID Protection (P2 license) produces user-risk and sign-in-risk signals based on Microsoft's threat-intelligence pipeline, anomalous-sign-in detection, and impossible-travel heuristics. The risk signals feed Conditional Access policies that automatically require additional MFA, force a password change, or block sign-in on a risk threshold. The control maps to SOC 2 CC7.2, HITRUST 09.ad, and HIPAA §164.308(a)(1)(ii)(D), information system activity review. The audit evidence is the configured user-risk policy, the configured sign-in-risk policy, the report-only state if any, and the recent risk-event remediation log. Mid-market tenants that have not licensed Entra P2 have a real procurement decision to make: the audit posture is meaningfully easier with the risk signals than without. Compensating controls are possible, third-party identity-protection products, manual review against sign-in logs, but the operational cost is higher and the audit conversation is harder. 9. Unified device posture: Intune compliance, hybrid join, MDM enrollment Every device that signs in to the tenant should be either compliant per an Intune compliance policy or excluded from access by Conditional Access. The Conditional Access "require compliant device" or "require Hybrid Azure AD-joined device" grant control is the gate; Intune compliance policies are the standard that determines the gate's pass condition. The control maps to SOC 2 CC6.6, HITRUST 09.j, and HIPAA §164.310(d), device and media controls. The audit evidence is the Intune compliance policy export, the Conditional Access policy enforcing device compliance, the device inventory by compliance state, and the exclusion documentation for any non-compliant device class. The implementation mistake: requiring Hybrid Azure AD-joined devices in environments with significant macOS or BYOD usage. The "require compliant device" grant control is more flexible and works across Windows, macOS, iOS, Android, and Linux compliance policies; orgs that have insisted on hybrid join for everything end up with shadow-IT compensating practices that produce findings of their own. 10. Sensitivity labels and DLP for the regulated record set Microsoft Purview Information Protection sensitivity labels, paired with Data Loss Prevention policies, are the data-classification and data-flow control surface inside Microsoft 365. For regulated mid-market organizations, the audit-relevant baseline is: a labeling taxonomy that names the regulated record class explicitly (PHI, PCI, regulated proprietary data), automated labels for known record patterns (HIPAA identifiers, payment-card numbers, regulated-industry-specific identifiers), and DLP policies that trigger on the labels at the egress points (email, Teams chat, SharePoint sharing, endpoint copy/paste). The control maps to SOC 2 CC6.7, HITRUST 06.c, and HIPAA §164.502(b), minimum necessary, plus §164.312(e), transmission security. The audit evidence is the Purview taxonomy export, the DLP policy export with conditions and actions, the recent DLP incident log, and the user-side experience (label availability, classification prompts, justification workflows on overrides). The implementation mistake we see most often: labels deployed without the corresponding DLP policies. The taxonomy exists; the enforcement does not. The auditor will read the gap as a control with no testable surface. 11. Custom security attributes and access reviews on the regulated workforce Entra ID custom security attributes, typed, structured fields on user and service principal objects, let an organization tag a workforce member with a regulated-data clearance, a classified-project assignment, a HIPAA-covered-workforce flag, or any other compliance-relevant attribute. Access reviews then cycle on those attributes, certifying continued eligibility on the cadence the regulation requires. The control maps to SOC 2 CC6.2, HITRUST 01.d, and HIPAA §164.308(a)(3)(ii)(B), workforce clearance procedures. The audit evidence is the custom attribute schema, the assignment of attributes to the regulated workforce, and the access reviews scoped on those attributes with recent completion records. This control is the one most mid-market tenants do not yet operate. The Microsoft tooling is recent (custom security attributes graduated to general availability through 2024, and access reviews on those attributes have matured through 2025). The audit posture moves materially when this control is in place, the workforce clearance evidence becomes structured rather than narrative. 12. The change log for everything above The twelfth control is the meta-control. Every change to any of the eleven above, a Conditional Access policy edit, a PIM configuration change, a sensitivity-label taxonomy update, a break-glass procedure rotation, has to be captured in a change record with the change description, the approver, the executor, and the date. Microsoft 365 native audit logs the configuration changes; the gap is the approval and justification record that ties the technical change to a control owner. The control maps to SOC 2 CC8.1, HITRUST 09.b, and HIPAA §164.308(a)(8), evaluation. Audit evidence: the change-management procedure, recent change records cross-referenced to the tenant audit log entries, and the evidence that the change-management process is exercised on the cadence the procedure requires. The implementation mistake: no formal change record on tenant configuration changes because "the audit log captures it." The audit log captures the change. The auditor's request is for the change record that authorizes it. Both have to exist. How the twelve map to the audit walkthrough A SOC 2 Type II assessor running a controls-walkthrough on a Microsoft 365 tenant will, in our experience, work the twelve in roughly the order above, identity first, audit log next, app and data controls in the middle, change management at the end. A HITRUST r2 assessor will walk the same surface but request more granular evidence per control (HITRUST is more prescriptive than SOC 2 in identity and access). A HIPAA Security Rule assessment will tie each control to the cited section and ask for the documentation that maps the control to the rule. For a regulated mid-market organization with multiple frameworks in scope, the right move is to produce the twelve-control evidence package once and map it to all three frameworks simultaneously. The evidence is the same; the framework citations are different. The orgs that operate in this mode reduce audit-cycle effort materially, the same artifact answers the same question regardless of which assessor pulls it. The companion to this Field Guide is the Azure Security Review Method for the Azure-resource side of the same tenant, the Microsoft 365 Compliance + Audit Readiness Field Guide for the Purview and audit-log evidence surface, and the SOC 2 Type II first-time customer Field Guide for the framework-level audit posture inside which the identity controls sit. What we recommend A regulated mid-market organization with an audit cycle starting in the next ninety days should walk the twelve in three phases. Week one: produce the evidence as it stands today. Pull the Authentication Methods report, the Conditional Access export, the PIM configuration, the audit log retention setting, the App Registrations and Enterprise Applications inventory, the External Collaboration settings, the Identity Protection policy state, the Intune compliance policy and Conditional Access grant, the Purview labels and DLP policies, the custom security attributes and access reviews, and the recent change records. The evidence package is the working baseline. Week two: gap-analyze against the twelve. For each control, score the current state against the audit-passing threshold. The twelve produce a structured scorecard: the controls that pass cleanly, the controls that need configuration tightening, and the controls that need a license upgrade or a process implementation. Week three: build the remediation calendar. Each gap gets a target close date, a control owner, and an evidence artifact that will answer the auditor's question once the close is in place. The calendar is the artifact the executive sponsor takes to the audit committee or the board's risk committee. Without it, the audit becomes a discovery exercise. With it, the audit becomes a confirmation exercise. The twelve are not exotic. The discipline is familiar. The audit posture compounds the moment the evidence package is structured. Walk the twelve before the assessor does.