You're paying for Microsoft 365. You're probably not configured for it. Here's what we find in almost every tenant we audit — and exactly how to fix each one.
Microsoft 365 is the backbone of most small businesses we work with — email, files, Teams, the whole stack. And that's exactly why it's such a critical target for attackers. When your M365 tenant gets compromised, it's not just email at risk. It's your entire business communication history, your documents, your contacts, and in many cases a direct path into your financial systems through business email compromise.
Here's the frustrating part: most of the damage is preventable. Not with expensive software or complicated configurations — with a handful of settings that are either disabled by default or left misconfigured during setup. We do M365 security audits as part of our onboarding process with new clients, and we find the same problems over and over again, regardless of business size.
I'm going to walk you through the six settings we find misconfigured most often. Some of these take five minutes to fix. All of them matter more than you'd think.
This is the big one. Stolen passwords are behind the overwhelming majority of M365 account compromises we see. An attacker buys a credential dump off the dark web, tries your email address with a few common passwords, and they're in. If that sounds far-fetched, it isn't — it happens to small businesses every single week.
Multi-factor authentication (MFA) stops this cold. Even if an attacker has your password, they can't log in without the second factor — typically a code from an authenticator app on your phone. Microsoft's own data puts the success rate at blocking 99.9% of account compromise attacks. That's not a small improvement. That's essentially a solved problem, if you turn it on.
So why do so many businesses have it off? A few reasons. Microsoft doesn't enforce it by default on all plans. Some IT people set it up for admins but leave regular users unprotected. And plenty of businesses had someone set up M365 years ago and never revisited the security settings.
Log into the Microsoft 365 admin center at admin.microsoft.com. Go to Users → Active Users and look for "Multi-factor authentication" in the top menu. From there you can see who has it enabled and who doesn't.
Better yet, if you're on Microsoft 365 Business Premium, use Security Defaults or full Conditional Access policies. Security Defaults is the quick win — it enables MFA for all users and blocks legacy authentication in one click. Go to the Azure Active Directory admin center, navigate to Properties, and look for "Manage Security Defaults" at the bottom.
Yes, this requires your team to set up an authenticator app. Yes, a few people will grumble. Do it anyway. The inconvenience of MFA is nothing compared to the disruption of a compromised account.
This one is less obvious but surprisingly dangerous. "Legacy authentication" refers to older email protocols — things like basic SMTP authentication, POP3, IMAP, and older Exchange ActiveSync connections — that don't support modern authentication methods, including MFA.
Here's why that matters: if legacy authentication is enabled on your tenant, an attacker can bypass MFA entirely by connecting via one of these older protocols. They just need your username and password. Your MFA requirement doesn't apply to that connection path at all.
We've seen this be the exact vector attackers used to get into tenants that had MFA enabled. The business thought they were protected. Legacy authentication was still on. The attacker knew to look for that gap.
In the Azure AD admin center, go to Security → Conditional Access and create a policy that blocks legacy authentication protocols for all users. If you enabled Security Defaults as described above, this is already handled — one of the reasons Security Defaults is worth enabling if you're not doing full Conditional Access yet.
Before you block legacy authentication, do a quick check: go to Azure AD → Sign-in logs and filter for "Legacy authentication client" to see if anything in your environment is still using these protocols. Old printers and scanners that email via SMTP are common culprits. Those will need to be updated or reconfigured to use modern authentication or a dedicated SMTP relay before you block legacy auth tenant-wide.
SharePoint and OneDrive make file sharing easy. Almost too easy. The default sharing settings in many M365 tenants allow what Microsoft calls "Anyone" links — meaning anyone who receives that link, anywhere on the internet, can access the file. No login required. No M365 account needed. Just the link.
We've had clients share invoices, employee contracts, and customer data this way without realizing the implications. The link goes to one person, that person forwards it, it ends up somewhere unexpected. There's no access log, no expiration, no accountability. It's a file you've effectively published to the internet.
And it gets worse: if a link like this gets indexed by search engines (it happens more than you'd think), or shared somewhere public, that file is essentially public. We've found sensitive business documents this way during security reviews.
In the SharePoint admin center, go to Policies → Sharing. You'll see an external sharing slider for SharePoint and OneDrive. For most small businesses, the right setting is "New and existing guests" at most — which requires recipients to authenticate before accessing shared files. Even better for sensitive industries: set it to "Only people in your organization" and require people to explicitly request exceptions.
You can also set a default expiration on sharing links (90 days is a reasonable starting point) so old links stop working automatically. That setting lives in the same section under "Advanced settings."
Let me paint a scenario. An employee's account gets compromised. The attacker quietly reads emails for a few weeks, then uses that access to pull off a business email compromise scam. You find out after the fact and need to figure out exactly what they accessed, what they changed, and where they went.
If audit logging is off, you have almost nothing to work with. You can't tell which mailboxes they accessed. You can't see what files they downloaded from SharePoint. You can't track what email rules they created. Your ability to contain the damage and meet any legal notification obligations is severely hampered.
Microsoft now enables unified audit logging by default on newer tenants, but plenty of tenants set up before this change still have it off. And even on newer tenants, many businesses don't realize they need to configure what they're logging or how long logs are retained.
In the Microsoft Purview compliance portal (compliance.microsoft.com), go to Audit. If you see a banner saying "Start recording user and admin activity," click it. That's audit logging off — turn it on.
For retention: by default, audit logs are kept for 90 days on Microsoft 365 Business plans. If you have compliance requirements or just want more runway for incident investigations, Microsoft 365 Business Premium extends this to one year. That's one of the tangible security benefits of the Premium tier that many businesses overlook.
Also worth enabling: mailbox auditing for all users, which logs actions taken on email (including by administrators). In PowerShell: Set-OrganizationConfig -AuditDisabled $false. Your IT person can run this in under five minutes.
Two different businesses, two different problems. One client had no retention policies at all — a departing employee deleted years of emails and files before leaving, and there was no way to recover them. Another client had a well-meaning IT person set a 30-day retention policy on email, not realizing this would automatically and permanently delete anything older than 30 days from every mailbox in the company. They lost three years of email history before anyone caught it.
Retention policies determine how long content is kept and what happens to it after that period. Done right, they ensure you meet any legal hold requirements, keep critical business records, and have options for recovery when something is deleted. Done wrong — or not at all — they're either a liability or a false sense of security.
Retention policies live in the Microsoft Purview compliance portal under Data lifecycle management → Retention policies. Before you create or change anything, think through three questions:
If you don't have an IT person who's worked with Purview before, get help with this one. The stakes are high enough that a misconfigured retention policy is genuinely worse than no policy at all.
This one is a behavior problem as much as a settings problem. We regularly see business owners and IT people using their Global Administrator account — the account with the keys to the entire M365 kingdom — as their regular daily-use email account. They check email from it, browse the web on the same machine, maybe even use it for personal stuff.
The risk is straightforward. If an admin account gets phished or compromised, the attacker doesn't just have access to email. They have full control of the entire M365 tenant. They can create new users, read any mailbox, delete anything, change security settings, and lock everyone else out. We've seen this happen. It's a very bad day.
The fix is simple in concept, if slightly annoying in practice: create dedicated admin accounts that are used only for administration. Something like admin@yourdomain.com, with no email license attached — just admin privileges. Your IT people log in to that account only when they need to do admin tasks. Their regular @yourdomain.com account has standard user privileges.
Also on this topic: limit the number of Global Admins. Most small businesses only need one or two. Assign the minimum role that actually gets the job done — Exchange Admin for email management, SharePoint Admin for file management, and so on. The principle of least privilege applies to M365 just as much as any other system.
If reading through this list left you feeling like your M365 tenant is a ticking time bomb, take a breath. These are fixable problems. And the highest-impact ones — MFA and blocking legacy authentication — can be addressed in an afternoon.
Here's the order we'd prioritize if you're starting from scratch:
First, today: Enable MFA for all users. This one change has the biggest security ROI of anything on this list. If you have Security Defaults available, enable it. If you're on Business Premium, set up Conditional Access policies instead — they give you more control.
This week: Review your external sharing settings and tighten them. Check whether audit logging is on. If it's off, turn it on now so you're capturing activity going forward.
This month: Get your retention policies in order. Review your admin accounts and make sure nobody is doing daily work from a Global Admin account. Look at your legacy authentication sign-in logs and develop a plan to block them once you've handled any legacy devices.
None of this requires expensive add-ons or custom development. It's all configuration work inside tools you're already paying for. If you want help doing a proper M365 security audit, that's something we do as part of our managed IT services — or as a standalone assessment if you just want to know where you stand.
The uncomfortable truth is that most M365 breaches we see weren't inevitable. They happened because a few default settings were never reviewed. The attackers aren't usually sophisticated — they're just trying the easy path, and the easy path is often unlocked.