Top Microsoft 365 security misconfigurations and how to fix them

Microsoft 365's most common security misconfigurations are gaps most organizations can close with settings the platform already includes, from unenforced MFA to Copilot surfacing years of unreviewed file sharing. None of these require a bigger security budget to fix. They require someone to actually configure the controls Microsoft already ships. The full list of 10 is below.

‍

This list started as five items. It's grown to ten because the misconfigurations that actually cause breaches haven't changed, but the platform has: the modern SaaS attack surface in Microsoft 365 now extends to AI features that didn't exist when this list was five items long. These oversights apply across Microsoft 365 Enterprise, Business, and Education tenants alike.

‍

Key takeaways

• Enforcing MFA for every user is still the highest-impact single change you can make. Microsoft has reported that over 99.9% of compromised accounts had MFA disabled.
• Legacy authentication protocols like POP3 and IMAP bypass MFA entirely, so blocking them isn't optional once MFA is in place.
• Conditional Access, DLP, and audit logging are native controls most tenants already have access to and simply never finish configuring.
• Over-permissive SharePoint, OneDrive, and guest sharing settings create data exposure Microsoft 365 won't catch on its own.
• Copilot and AI oversharing are the newest misconfiguration risk: Copilot doesn't create bad sharing settings, it just makes them visible at scale.

The 10 Microsoft 365 misconfigurations at a glance

‍

1. MFA not enforced for all users

‍

The problem

Many Microsoft 365 tenants still don't require multi-factor authentication for every user. MFA isn't enforced by default unless Security Defaults or Conditional Access policies are turned on, which means someone can still sign in with a password alone.

‍

Why it's risky

Passwords alone don't hold up against phishing, credential stuffing, and password spray attacks. Microsoft has reported that over 99.9% of compromised accounts had MFA disabled. Once an attacker has valid credentials, they can sign in like any other user, especially if legacy protocols are also enabled (more on that next).

‍

How to fix it

• Require MFA for all sign-ins with Conditional Access policies. Avoid blanket exclusions.
• Turn on Security Defaults if you're not using Conditional Access; it enforces MFA and blocks legacy auth with a single switch.
• Favor phishing-resistant methods, push notifications or FIDO2 keys, over SMS.
• Train users on why an MFA prompt they didn't request is a warning sign, not an annoyance to dismiss.

Enforcing MFA is still the single most effective step you can take to secure Microsoft 365. It turns a stolen password into a dead end.

‍

2. Legacy authentication still allowed

‍

The problem

Legacy protocols like POP3, IMAP, and SMTP AUTH don't support modern authentication, including MFA. Microsoft has been phasing them out for years, but plenty of tenants still have one or more enabled, often without anyone noticing.

‍

Why it's risky

Legacy protocols are a favorite target for password spray attacks because they let attackers bypass MFA entirely. A well-configured MFA policy means nothing if a single legacy protocol is left open as a side door.

‍

How to fix it

• Block legacy authentication through Conditional Access policies or Security Defaults.
• Disable unused protocols, POP, IMAP, and SMTP AUTH, in Exchange Online.
• Upgrade any application that still depends on legacy auth to a version that supports OAuth.
• If legacy access is genuinely required, scope the exception tightly to specific accounts and IP ranges, and set a review date to remove it.

Disabling legacy authentication is what makes MFA and Conditional Access actually work as intended, instead of leaving a bypass in place.

‍

3. Too many Global Admins

‍

The problem

It's common for organizations to hand the Global Admin role to more people than they need: a shared admin account, staff who kept privileges after changing roles, or admins doing daily work from an account that also holds tenant-wide access.

‍

Why it's risky

A Global Admin account can change security settings, access user data, and create new accounts, which makes every one of them a high-value target. If an attacker compromises even one, the entire tenant is exposed. Using that same account to check email or browse the internet only adds more ways for it to get compromised in the first place.

‍

How to fix it

• Keep Global Admin accounts to 2–4 people, and assign narrower roles, like Exchange Administrator, wherever they'll do.
• Use dedicated admin accounts, separate from everyday logins, with no email access.
• Turn on Privileged Identity Management (PIM) as part of a broader effort to govern privileged account access across your tenant, so elevated access is temporary and logged rather than standing.
• Set up break-glass emergency access accounts, cloud-only and excluded from Conditional Access, and monitor them closely.

The fewer standing Global Admins you have, the fewer paths an attacker can exploit. Treat least privilege as a survival strategy for the tenant, not a compliance checkbox.

‍

4. Over-permissive sharing in SharePoint and OneDrive

‍

The problem

By default, Microsoft 365 lets users share files through anonymous links that don't require sign-in, often with the link type set to "Anyone with the link." Teams also allows external guests by default unless an admin restricts it.

‍

Why it's risky

Anonymous links can be forwarded to anyone, with no audit trail of who opened them, which makes it easy for sensitive data to leak out unnoticed. Left unchecked, this becomes guest access sprawl: external accounts nobody remembers granting, still holding access long after the project that justified them ended. If OneDrive syncs to unmanaged devices, that data can also end up on a personal machine outside your organization's controls, or stay there after someone leaves.

‍

How to fix it

• Turn off anonymous links by setting external sharing to "New and existing guests" or stricter.
• Change the default link type to "Specific people" so sharing requires naming a recipient.
• Review external sharing and guest accounts on a set schedule, not just when someone asks; use built-in reports or PowerShell.
• Restrict who can share externally to specific teams or managers.
• Apply Sensitivity Labels and DLP to sensitive content so protection travels with the file even if someone tries to share it broadly.

Collaboration doesn't have to mean open season on your data. Set sharing defaults that protect sensitive files by default, then review them on a schedule instead of by accident.

‍

5. Inadequate email security configuration

‍

The problem

Many Microsoft 365 tenants leave SPF, DKIM, and DMARC unset and anti-phishing policies at their defaults in Exchange Online Protection or Microsoft Defender for Office 365. Email is still the most common entry point for phishing, malware, and business email compromise, and Microsoft 365's built-in controls for it only work once someone actually configures them.

‍

Why it's risky

Without proper email authentication, attackers can spoof your domain to target customers, partners, or employees. Default anti-phishing settings let more malicious email reach inboxes than a tuned policy would. If auto-forwarding is enabled or inbox rules go unmonitored, an attacker who compromises one mailbox can quietly exfiltrate data or hide evidence for weeks before anyone notices.

‍

How to fix it

• Set up SPF, enable DKIM signing per domain, and publish a DMARC record, starting at p = none to monitor, then moving to quarantine or reject.
• Harden anti-phishing and anti-spam policies in Microsoft 365 Defender: configure impersonation protection, enable Safe Links and Safe Attachments, and tighten spam thresholds beyond the defaults.
• Block automatic forwarding to external recipients unless there's a specific, documented reason for it.
• Audit inbox rules on high-risk accounts regularly, and turn on mailbox auditing and sign-in risk detection.

A misconfigured email stack leaves the door open to phishing and spoofing. Authentication protocols and tuned anti-phishing policies close the most common attack vector before it reaches a user's inbox.

‍

6. No Conditional Access policies beyond basic MFA

‍

The problem

Some tenants stop at "MFA is on" and never build out Conditional Access beyond that one policy. Conditional Access is Microsoft 365's policy engine for evaluating sign-in risk, device compliance, location, and application, not just whether someone entered a one-time code, and most organizations use only a fraction of what it can do.

‍

Why it's risky

Without location-, device-, and risk-based policies, a compromised credential from an unmanaged device or an unexpected country can still get in as long as MFA is satisfied. That's exactly the gap attackers using stolen session tokens or MFA-fatigue tactics rely on. This is also where Zero Trust breaks down in practice: the model depends on evaluating every sign-in on its own merits, not on a single static rule.

‍

How to fix it

• Require compliant or hybrid-joined devices for access to sensitive apps.
• Block or challenge sign-ins from unfamiliar locations and anonymous IP addresses, including known VPN and Tor ranges.
• Apply sign-in and user risk policies through Microsoft Entra ID Protection, and require a password reset or MFA re-registration on high-risk sign-ins.
• Scope guest access with its own Conditional Access policies rather than leaving it under the same rules as full-time employees.

Conditional Access is where a Zero Trust model's "verify every time" principle actually gets enforced, well beyond what a single MFA policy covers.

‍

7. No DLP policies configured

‍

The problem

Many Microsoft 365 tenants have never turned on Data Loss Prevention (DLP), or built only a token policy that doesn't match what the business actually handles. Microsoft Purview includes DLP tools that can detect and block sensitive data, credit card numbers, health records, source code, from leaving the organization through email, Teams, or SharePoint, but only once someone configures them.

‍

Why it's risky

Without DLP, sensitive data can leave through an ordinary channel, an email attachment, a shared link, a Teams message, with no policy in place to catch it. That's a compliance problem as much as a security one: regulations like HIPAA and GDPR expect organizations to demonstrate active controls over how regulated data moves, not just a policy that assumes employees know better.

‍

How to fix it

• Start with Microsoft Purview's built-in sensitive information types for the data categories that matter most to your industry, financial account numbers, health identifiers, source code, and expand from there.
• Apply Sensitivity Labels so protection follows the file, not just the location it started in.
• Set policies to block or warn, not just log, once you've confirmed they're not firing on legitimate business activity.
• Review DLP incident reports on a schedule so policy tuning is a routine task, not a reaction to an incident.

An unconfigured DLP policy is a standing gap. Sensitive data can leave through any ordinary channel, an email, a shared link, a chat message, until someone turns the control on.

‍

8. Audit logging left off or unmonitored

‍

The problem

Microsoft 365 unified audit logging captures sign-ins, file access, admin actions, and mailbox changes, but it isn't automatically reviewed, and in some tenants it isn't even fully enabled. Even where logging is on, many organizations never build the alerting or review process that turns a log into something useful.

‍

Why it's risky

A log nobody reads doesn't prevent anything. It only helps after the fact, and only if it was capturing the right events in the first place. Attackers count on activity going unnoticed: a new mailbox forwarding rule, an off-hours admin action, a mass file download all leave a trace, but only if someone or something is watching for it.

‍

How to fix it

• Confirm unified audit logging is enabled at the tenant level and set to the retention period your compliance requirements demand.
• Build alerts for high-risk events specifically, new forwarding rules, mailbox permission changes, Global Admin role assignments, rather than relying on general log review.
• Route Microsoft 365 audit data into a SIEM or a dedicated monitoring tool if your team doesn't have the bandwidth to review the native portal regularly.
• Set a recurring cadence, monthly at minimum, to check that logging and alerting are still capturing what you expect.

Audit logs only earn their name once someone is actually reviewing them. Otherwise they're just storage.

‍

9. OAuth consent phishing and overprivileged app grants

‍

The problem

Every time someone clicks "Accept" on an app requesting Microsoft 365 permissions, that's a trust decision, and most organizations have no process for reviewing what was actually granted. Consent phishing takes advantage of this directly: an attacker sends a link to a fake but legitimate-looking OAuth consent screen, and once a user approves it, the malicious app gets a token with real access, no password needed, no MFA prompt to bypass.

‍

Why it's risky

An overprivileged app grant doesn't expire the way a stolen password does. It sits in the tenant with standing access to mail, files, or directory data until someone finds and revokes it, and most organizations aren't looking.

‍

How to fix it

• Restrict user consent so only admin-approved apps can request permissions, rather than leaving consent open to any user.
• Review existing OAuth app grants on a schedule, not just when onboarding a new app, and revoke anything unused or over-scoped as part of an ongoing OAuth risk management process.
• Require admin consent workflows for any app requesting high-risk permissions like mail read/write or full directory access.
• Train users to recognize a consent phishing prompt the same way they'd recognize a credential phishing email, since it doesn't look like a typical attack.

Every OAuth grant is a standing trust decision, and an unreviewed one is functionally the same as an unreviewed admin account.

‍

10. Copilot and AI oversharing risk

‍

The problem

Copilot surfaces years of existing SharePoint, OneDrive, and Teams oversharing at scale, the moment someone asks it a relevant question. It works this way by design: Copilot answers questions by pulling from whatever content a user already has permission to see. A file with an overly broad sharing link that sat unnoticed for years can now show up, summarized, in a Copilot answer to someone who was never meant to see it.

‍

Why it's risky

Permission sprawl that used to require someone to actually search for a file now surfaces itself the moment a relevant question gets asked. Organizations that haven't cleaned up SharePoint and OneDrive sharing before turning on Copilot are effectively handing it a shortcut to every misconfiguration in items 4, 6, and 7 above.

‍

How to fix it

• Run a permissions and sharing-link cleanup across SharePoint and OneDrive before enabling Copilot broadly, not after.
• Use Sensitivity Labels and DLP so Copilot respects the same data boundaries as everything else in the tenant.
• Restrict Copilot's access to specific sites or content types during rollout, then expand deliberately.
• Monitor Copilot adoption and usage as part of your broader AI security and governance practice, the same way you'd monitor any other new access path into sensitive data, not as a separate, one-time project.

Copilot makes years of unreviewed sharing settings finally show their work, which is why the cleanup has to happen before rollout, not after.

‍

Where Microsoft Secure Score fits in

‍

Microsoft Secure Score is a useful baseline: it scores your tenant against Microsoft's own recommendations and gives you a prioritized list of settings to change. It's a reasonable starting point for a tenant that hasn't been reviewed in a while.

‍

It's not a complete answer, though. Secure Score measures configuration against Microsoft's checklist at a single point in time. It won't tell you which OAuth grants have gone unused, which guest accounts have gone stale, or which files Copilot can now surface that shouldn't be visible to begin with, and its view stops at the edge of Microsoft 365 rather than covering the rest of your SaaS estate.

‍

How Nudge Security can help

Microsoft 365 offers a wide range of security controls, but as this list shows, most of them require deliberate configuration to actually do their job. Defaults aren't secure by default, legacy settings linger unnoticed, and Microsoft keeps adding new controls (Copilot governance among the newest), which makes it hard to keep pace with a checklist alone.

‍

Nudge Security delivers continuous security posture management for Microsoft 365 as one piece of a broader SaaS attack surface management view spanning your entire SaaS environment. That means catching:

• Missing or misconfigured email authentication (SPF, DKIM, DMARC)
• Weak MFA enforcement and legacy authentication still enabled
• Overprivileged accounts and third-party app grants, including OAuth consent risk
• Inactive accounts or mailboxes that still hold standing access
• Public sharing of SharePoint sites, OneDrive files, or Teams content

Because Nudge tracks AI adoption alongside everything else in your SaaS estate, it also flags Copilot and other AI tools as they get adopted, before an oversharing issue becomes a Copilot answer someone shouldn't have seen.

‍

See how Nudge Security can help you find and fix Microsoft 365 misconfigurations before they turn into an incident. Start a free 14-day trial.

‍