Most businesses that use Microsoft 365 (M365) assume they are covered. They pay for the subscription, they get the apps, and somewhere in the background Microsoft is handling security. That assumption is costing companies real money, real data, and in some cases their entire business.

The truth is that Microsoft provides the platform. Securing how your organization uses that platform is your responsibility. And Microsoft ships M365 with dozens of settings that are either turned off by default or configured in ways that prioritize ease of use over protection. A company that never audits those settings is operating with the doors unlocked.

This is not a theoretical concern. Business email compromise (BEC) — attacks where criminals gain access to corporate email accounts and impersonate executives or vendors — cost U.S. businesses over $2.9 billion last year according to the FBI. The majority of those attacks exploit exactly the gaps covered in this article.

Audit Logging Is Disabled by Default in Many Tenants

Before you can investigate a security incident, you need logs. Microsoft 365 includes a Unified Audit Log (UAL) that records user activity across Exchange, SharePoint, OneDrive, Teams, and other M365 services. The problem is that in many configurations, this logging is not turned on by default, and even when it is, the default retention period is only 90 days.

Ninety days sounds like a lot until you consider that the average time between a breach and its discovery is well over 100 days. By the time you realize something went wrong, the evidence has already expired.

Worse, many smaller Microsoft 365 plans do not include advanced audit logging at all. Features like MailItemsAccess — which tells you exactly which emails an attacker read during a compromise — are only available in higher-tier licenses. If you do not know what license tier you have, there is a real chance you are flying blind.

An M365 security audit should confirm that unified audit logging is enabled, that retention is extended to at least 180 days, and that your license tier supports the logging granularity your business actually needs. A managed SOC that monitors M365 logs in real time can catch suspicious activity before it escalates — but only if those logs are actually being generated and retained.

Mailbox Forwarding Rules: The Silent Data Drain

This is one of the most common and most damaging gaps in M365 security, and most business owners have never heard of it.

When an attacker gains access to an M365 account — through a phishing email, a reused password, or a credential stuffing attack — one of the first things they do is create an inbox rule. That rule silently forwards every incoming email to an external address the attacker controls. The compromised user never sees anything unusual. Their email appears to work normally. Meanwhile, every invoice, contract, wire transfer request, and internal communication is being copied to a criminal in real time.

These rules are easy to create and easy to miss. Microsoft does not alert you when a new forwarding rule is added. The rule often hides emails from the inbox so the victim never sees the forwarded copies. It can persist for months before anyone notices.

The fix requires two things: a policy that blocks external forwarding at the tenant level, and regular auditing of existing inbox rules to catch anything that slipped through. Neither of these is configured by default.

Legacy Authentication Protocols Open a Side Door

Modern M365 security is built around multi-factor authentication (MFA) — a second verification step beyond just a password. When you log in and Microsoft texts you a code, that is MFA at work. It stops the vast majority of credential-based attacks cold.

The problem is that legacy authentication protocols — older connection methods used by outdated email clients and applications — do not support MFA at all. If legacy authentication is enabled in your tenant (and in most organizations it is, because Microsoft still enables it for compatibility reasons), an attacker can use a stolen username and password to connect through those old protocols and completely bypass your MFA controls.

Basic Authentication (Basic Auth), which is the most common legacy protocol, was supposed to be fully retired by Microsoft in late 2022. But many tenants still have it enabled through specific service accounts or because administrators never confirmed the retirement applied to their configuration. Post-October 2022 tenants have Basic Auth disabled, but older tenants that were grandfathered in may still have it active.

An M365 hardening review should confirm that all legacy authentication protocols are blocked via Conditional Access (CA) policies, and that no service accounts are being used as exceptions to that rule.

Conditional Access Policies Are Not Configured by Default

Conditional Access is Microsoft's system for applying rules to how and when users can authenticate. It lets you say things like: only allow logins from company devices, block access from foreign countries, require MFA for all administrator accounts, or flag logins from unusual locations.

None of this is turned on when you first set up M365. Out of the box, anyone with a valid username and password can log in from any device, anywhere in the world.

For a business with employees in McKinney, TX, there is no legitimate reason a login should succeed from an IP address in Eastern Europe at 3 a.m. But without Conditional Access policies, Microsoft will process that login without question.

Baseline Conditional Access policies should include requiring MFA for all users (not just administrators), blocking legacy authentication, requiring compliant or hybrid-joined devices for access to sensitive data, and triggering alerts for impossible travel — where the same account appears to log in from two geographically distant locations within minutes of each other.

MFA Gaps: Not Everyone Is Enrolled, and Not All MFA Is Equal

Most organizations that have implemented MFA have not implemented it for everyone. It is common to find that MFA is enforced for administrators but optional for regular users. Or that it was required during onboarding but not enforced for accounts created before the policy existed. Contractors and vendor accounts are frequently overlooked entirely.

There is also a meaningful difference between MFA methods. Receiving a code via SMS (text message) is better than nothing, but it is vulnerable to SIM swapping — a social engineering attack where criminals convince a mobile carrier to transfer your phone number to their SIM card. Authenticator apps like Microsoft Authenticator generate time-based codes that are not vulnerable to SIM swapping. Hardware security keys like YubiKeys are the strongest option available.

A proper email security program accounts for these distinctions. Layering additional controls on top of native M365 protections fills the gaps that MFA enrollment inconsistencies leave open.

Data Loss Prevention Is Not Configured

Data Loss Prevention (DLP) is a set of policies that prevent sensitive information from leaving your organization through email or file sharing. A properly configured DLP policy will block or warn when someone tries to email a file containing credit card numbers, Social Security numbers, or protected health information (PHI).

Microsoft includes DLP capability in M365 Business Premium and higher, but the policies are not pre-configured. An organization that has never set up DLP rules has no automated protection against employees accidentally — or intentionally — sending sensitive data to the wrong place.

For businesses in regulated industries, this is not just a security issue. Under the Health Insurance Portability and Accountability Act (HIPAA), the Payment Card Industry Data Security Standard (PCI DSS), and other frameworks, you are required to demonstrate controls that prevent unauthorized disclosure of regulated data. An M365 environment with DLP unconfigured is an immediate finding in any compliance audit. Your compliance posture is directly tied to how well your M365 environment is configured.

Shared Mailboxes Are a Security Blind Spot

Shared mailboxes — accounts like info@yourcompany.com or billing@yourcompany.com that multiple employees access — represent a category of accounts that most organizations manage carelessly.

The typical shared mailbox has no MFA enforcement because it is not set up as a user account with individual credentials. Multiple people often know the password. When an employee with access leaves the company, their access to the shared mailbox is frequently not removed because it is not tied to their personal account. There is no audit trail of who logged into the shared mailbox or what they did there.

From a security standpoint, shared mailboxes need to follow the same access controls as individual accounts. Access should be granted through delegation (where individual user accounts are given access) rather than through shared credentials. Former employees should have delegation removed as part of offboarding. Logins to shared mailboxes should appear in audit logs tied to the individual user who accessed them.

What an M365 Security Audit Actually Covers

A proper M365 security audit — sometimes called an M365 hardening review — goes through the Microsoft Secure Score dashboard, examines all active Conditional Access policies, audits existing inbox rules across all mailboxes, checks DLP policy configuration, reviews MFA enrollment by user, verifies logging retention settings, and tests for legacy authentication exposure.

Microsoft Secure Score is a useful starting point. It grades your tenant against Microsoft's own benchmarks and shows specific recommended actions. But Secure Score does not replace a human review. It does not tell you that your billing@company.com shared mailbox has had an external forwarding rule running for three months. It does not tell you which users have MFA enrolled but have chosen SMS instead of an authenticator app.

Organizations subject to regulatory oversight — healthcare, financial services, professional services handling client data — should treat M365 security configuration as a documented control within their compliance program. Gaps in M365 configuration are gaps in your compliance posture, and auditors are increasingly asking specifically about cloud productivity platform security controls.

The Business Risk in Plain Language

Every gap covered in this article maps to a direct business outcome. Disabled audit logging means you cannot prove what happened or when during a breach — which matters enormously for breach notification obligations and cyber insurance claims. Unmonitored forwarding rules mean months of confidential communications in a criminal's hands before you know anything is wrong. Legacy authentication gaps mean your MFA investment provides incomplete protection. Misconfigured DLP means a regulatory fine or a breach notification letter to your customers.

These are not IT problems. They are business risk problems that happen to live inside an IT system.

If your organization uses Microsoft 365 and has never had a formal security audit of your M365 tenant configuration, the gaps described here almost certainly exist in your environment. The question is not whether you have them — it is how long they have been there.

Our pricing page outlines plans that include M365 monitoring and configuration review. If you want to know exactly where your M365 environment stands, contact Innovation Network Design. We work with businesses in McKinney, the Dallas-Fort Worth (DFW) area, and across North Texas to identify and close the security gaps that put companies at real risk.

Microsoft 365 Security Gaps Most Businesses Miss