Many businesses, especially those in highly regulated industries, choose Microsoft 365 for its enterprise-grade security. But Microsoft operates on a shared responsibility model, which means it secures the cloud infrastructure while users are responsible for how their environment is configured, licensed, and used. A lot of times, businesses miss gaps that leave the door open for attackers.
We asked our information security team that runs configuration reviews for our clients, including banks, credit unions, nonprofits, and manufacturers, to share the Microsoft 365 security misconfigurations they see most often. Based on their observations, it’s clear that most organizations take reasonable steps to secure their environments. But often, tenants drift as they grow, default security settings or passwords get left in place, or businesses stay on the wrong license tier which creates security gaps. This is why an independent assessment surfaces things internal teams might miss.
Here are the five most common Microsoft 365 security misconfigurations our team finds during reviews.
Microsoft 365 security controls are spread across licensing tiers, and it isn't always obvious what tools your license covers. If you're still getting to know the platform, read our Microsoft 365 guide to understand licensing and security.
Misconfiguration #1: Conditional Access gaps and MFA that isn’t enforced for everyone
This is the most common observation in our reports. We often find MFA enforced on administrators and a handful of other accounts, while the rest of the organization signs in with a password alone. We also routinely find tenants running on just a couple of Conditional Access policies, usually a Microsoft-managed MFA policy for admins and maybe a geographic restriction. Most organizations reasonably assume this is a Conditional Access strategy. However, it’s not. There’s typically no policy blocking legacy authentication, no device compliance requirement for sensitive apps, no session controls, and no risk-based policies at all.
The user risk and sign-in risk gap comes up in nearly every review we do. These are the policies that detect impossible travel, anonymous IP usage, and leaked credentials, and then automatically block or challenge the sign-in. Without them, Microsoft may flag a compromised account, but nothing happens.
Why it matters: Account takeover is the front door for most security incidents. Partial MFA coverage means an attacker only needs to find one of the accounts that isn’t covered, and credential-stuffing tools are very good at finding such accounts.
The licensing catch: Risk-based policies require Microsoft Entra ID P2. We have delivered reports where identity findings couldn’t be remediated at any configuration level because the tenant wasn’t licensed for the capability.
How to fix it: Enforce MFA for all users, not just admins. Block legacy authentication. Require compliant or hybrid-joined devices for access to sensitive applications. If you hold Entra ID P2, turn on the user risk and sign-in risk policies.
Misconfiguration #2: Any user can register apps and grant consent to third-party applications
By default, Microsoft 365 lets standard, non-administrative users register new applications in the tenant and consent to third-party apps requesting access to company data on their behalf. In review after review, we find both settings still at their defaults.
Why it matters: This is one of the more under-appreciated risks in the platform. Two things can go wrong:
- An attacker sends a convincing prompt, a user clicks "Accept," and a malicious app now has delegated access to their mailbox, files, or directory data. No password was stolen and no MFA prompt was bypassed, because the user authorized it.
- Even without an attacker, unvetted apps accumulate with permissions nobody reviewed. We have reviewed tenants where enterprise applications were still active with expired or forgotten credentials, which is both a security gap and an operational one.
How to fix it: Disable "Users can register applications" in Entra ID and restrict app registration to administrators or a small, governed group.
Misconfiguration #3: DLP and Defender preset policies are off, in audit mode, or never provisioned
Two related gaps usually appear together.
The first is Data Loss Prevention. We open Microsoft Purview expecting to review policies and find an empty list – no rules matching Social Security numbers, taxpayer identification numbers, or credit card data, and no policies scoped to Exchange, SharePoint, OneDrive, or Teams. In some organizations, DLP policies exist but were deployed in test or audit mode for a pilot period and never switched to enforcement, so violations are logged and nothing is blocked. In others, Purview was never provisioned in the tenant at all, meaning DLP policies can't be created even if someone wants to.
The second is Microsoft Defender for Office 365. The Standard and Strict preset security policies – Microsoft's own recommended anti-phishing and anti-malware baselines – are frequently disabled. Alongside that, we often find impersonation protection not fully applied to executive accounts and owned domains, and recommended security alerts disabled.
Why it matters: This combination means sensitive data can leave the tenant with no detection, while the phishing protections designed to stop the initial intrusion aren't turned on. For organizations under GLBA, PCI DSS, HIPAA, or CMMC, "we have DLP" and "our DLP is enforcing" are very different answers during an exam.
How to fix it: Enable the Standard preset policy for all users and Strict for high-risk accounts like finance and the executive team. Build a DLP policy covering the sensitive data types that matter to your business, run it in audit mode for two to four weeks to catch false positives, then enforce it. Set a date for the switch to enforcement and hold to it.
Misconfiguration #4: External sharing and guest access are more open than anyone realizes
We find SharePoint and OneDrive left at "New and existing guests," which means any internal user can invite an outside party into company content without approval or review. In Teams, external access frequently permits all domains rather than an approved list, and unmanaged external users are allowed to initiate contact with employees.
These settings are often defaults or they were loosened once for a specific project and never tightened again.
Why it matters: The traditional concern is data leaving through a link nobody tracked. That's still true. But there’s a newer dimension we now flag in every review: AI scales the radius of oversharing. Content that's broadly shared can be surfaced and summarized by Copilot. We’re also seeing organizations leave Data Security Posture Management for AI untouched, so there's no visibility into how AI features are engaging with sensitive data.
How to fix it: Lower the tenant sharing setting to "Existing guests" or "Only people in your organization," and maintain an allowlist for partners who genuinely need access. In Teams, replace open external access with a per-domain allowlist and disable accounts not managed by an organization. If you’ve deployed Copilot, audit oversharing before rollout.
Misconfiguration #5: Password protection is logging violations instead of blocking them
We often find Entra ID Password Protection sitting in audit mode. In audit mode, weak passwords are recorded and permitted. The control appears green on a checklist and does nothing in practice.
Two things typically compound it. The custom banned password list is disabled, so only Microsoft’s global list applies, which means organization-specific terms like the company name, a brand, or a location can still be used in passwords. These are precisely what an attacker guesses first. And lockout thresholds are often set high enough to give automated attacks meaningful room to work.
Here’s an important note for IT teams: password protection enabled for on-premises Windows Server Active Directory does not mean it’s enforced in the cloud. Enforcement in Entra ID is independent. Cloud-only accounts that aren't synced remain exposed, and an attacker can target them directly through the Microsoft 365 authentication surface.
Why it matters: Password spray attacks don't need a sophisticated exploit. They need one account using a predictable password. Audit mode guarantees those accounts exist and tells you about them only after the fact.
How to fix it: Switch Password Protection from Audit to Enforced. Build a custom banned password list that includes your company name, brands, locations, department names, and the seasonal patterns people actually use. Lower the lockout threshold to three to five attempts; and confirm enforcement covers cloud-only accounts.
None of these misconfigurations are exotic. And the organizations we review are rarely careless; they have security programs and capable IT teams. The gaps form in the background as tenants grow and employees move on.
When you build the environment, you know what you intended it to do, which makes it easy to look at a setting and see the intent instead of the current state.
It’s also worth noting that a Microsoft 365 configuration review is a point-in-time snapshot. The tenant you have today is not the one you will have after a licensing change, a new integration, or a Copilot rollout. This is why we recommend reviewing configurations at least annually, and any time something major changes.
