Common Microsoft 365 Security Mistakes We See in SMB Environments
The recurring Microsoft 365 misconfigurations we find during SMB security baseline reviews - what they look like, why they happen, and how to fix them.
We run Microsoft 365 baseline reviews for SMBs almost every week, across Ottawa, Toronto and the GTA. The findings are remarkably consistent. The same five or six issues show up in tenants that were set up by office managers, by internal IT generalists, and by previous MSPs alike. None of these mistakes are exotic. They are the result of M365 being secure-by-configuration rather than secure-by-default, and of nobody owning the security posture after the initial rollout.
Below are the issues we find most often, with the operational reasoning behind why they matter and what a clean fix looks like in a real SMB environment.
Mistake 1: MFA enabled but not enforced
The most common finding. The MFA toggle is on in the admin centre, most users have set up Authenticator, and leadership believes the company is covered. When we look at sign-in logs, we typically find 10 to 30 percent of authentications still happening without MFA - legacy auth from old Outlook profiles, IMAP from a phone, a shared mailbox that was never enrolled, or a service account quietly running with a password from 2019.
The fix is Conditional Access policies that require MFA for all users, all apps, with a narrow break-glass account excluded. Run the policy in report-only mode for a week first, review the sign-in logs, then enforce. This single change blocks the majority of credential-stuffing and password-spray attacks against SMB tenants.
Mistake 2: Legacy authentication still allowed
Even with MFA enforced, legacy authentication protocols (POP3, IMAP, SMTP AUTH, older Office clients) can bypass modern security policies. Microsoft has been disabling these gradually for years, but tenants created before the cutoff often still have exceptions in place. Attackers know this and probe for it.
Block legacy auth via Conditional Access. If something breaks, it is usually a printer scanning to email or an old line-of-business app - both of which should be reconfigured to use SMTP relay with modern auth, not granted a permanent legacy bypass.
Mistake 3: Global Admin sprawl
We routinely find SMB tenants with five, eight, sometimes twelve Global Admin accounts. The IT lead, the previous IT person, the MSP, two consultants who helped with a migration in 2022, and a service account that nobody can identify. Each one is a full-tenant takeover risk.
The right pattern is two break-glass Global Admin accounts (cloud-only, long passwords, MFA, monitored), and role-based access for everyone else - User Administrator, Exchange Administrator, Intune Administrator, and so on. Privileged Identity Management (PIM) elevates admins just-in-time when they actually need the role.
Mistake 5: No mailbox auditing or sign-in alerts
When a mailbox is compromised, the only way to understand what the attacker did is mailbox audit logs and unified audit logs. We frequently find these disabled, or enabled but with no alerting layered on top. By the time the user notices the suspicious activity, the audit window may have rolled over.
Enable mailbox auditing for all users, turn on the unified audit log, and configure alert policies for high-risk events: impossible-travel sign-ins, mass file downloads from OneDrive, inbox rule creation that forwards externally, and elevation of Global Admin privileges.
Mistake 6: SPF, DKIM and DMARC not configured
Almost every SMB tenant we review has SPF set to a permissive policy, DKIM disabled, and DMARC either missing or in p=none mode forever. The practical result is that attackers can spoof your domain in phishing emails to your own staff, your customers and your suppliers - and your domain has no enforced policy to stop it.
Publish a tight SPF record, enable DKIM signing in Exchange Online, and roll DMARC from p=none through p=quarantine to p=reject over a few months. Use a DMARC reporting tool to catch legitimate senders before enforcing.
Mistake 7: Intune deployed but devices not actually compliant
Intune was rolled out, devices were enrolled, and compliance policies were created. We then find that the policies are empty, that non-compliance just sends a notification nobody reads, or that Conditional Access does not actually require device compliance to access M365 data. The result is unmanaged personal devices syncing tenant data freely.
Define real compliance criteria - disk encryption, OS version, screen lock, antivirus active - and make device compliance a hard Conditional Access requirement for accessing email and SharePoint. Non-compliant devices should be blocked, not warned.
Bottom line
None of these mistakes require a specialist to fix. They require someone who owns the Microsoft 365 security posture and has time to work through the configuration with intent. In most SMBs that role is unfilled, and the gaps compound year over year. A proper baseline review takes a senior engineer a day or two and closes the majority of them permanently.