What hundreds of Microsoft 365 deployments have taught me about cybersecurity

I’ve spent more than 20 years running IT and security for organizations across California and around the country. Over that time, my team has taken over, deployed and cleaned up Microsoft 365 environments for law firms, commercial real estate companies, manufacturers, healthcare practices and schools. We’ve supported more than 7,500 users along the way.

After working with that many tenants, the biggest takeaway is simple: most Microsoft 365 security problems aren’t especially sophisticated. Usually, a control was never turned on, only covered part of the organization, or somebody made an exception years ago to keep something working and it was never revisited. Microsoft gives organizations a lot to work with. More often than not, the problem is how the environment was configured and maintained, not a lack of security tools.

These are the issues we run into most often and the areas I’d look at first.

Most environments are still running on their original settings

When we first assess a tenant, we often find that nobody has really gone back through the security settings since it was originally set up. MFA may cover some users but not everybody. Legacy authentication is still allowed. There are too many global administrators. Nobody is quite sure when audit logging was last reviewed.

Last year we took over a 45-person medical practice that had been on Microsoft 365 for almost a decade. We found nine global administrator accounts, including two belonging to employees who had left years earlier. MFA was enabled, but only for the physicians. The front desk and billing staff, who handled the most patient data, had none.

Usually, nobody intentionally ignored security. The company grew, email kept working, people got busy and the original setup stayed in place. We see this constantly. Something working every day doesn’t necessarily mean it is configured the way you would want it configured today.

For a smaller organization without dedicated identity management, Microsoft’s security defaults are a good place to start. They require MFA and block legacy authentication without adding another license. As the environment gets more complex, and assuming the licensing supports it, conditional access gives you much more control over who can sign in, from where and from what device.

MFA is the starting point, not the finish line

At this point, most business leaders know MFA needs to be enabled. What still gets missed is the idea that turning it on somehow finishes the job.

Attackers have adjusted to MFA. Push fatigue attacks still work because eventually somebody may approve a prompt just to make it stop. Adversary-in-the-middle phishing kits can steal a live session token and get around standard MFA altogether. OAuth consent phishing is another issue: a user can be tricked into approving a malicious application through what looks like a legitimate Microsoft or Google consent screen. At that point, changing the user’s password may not even remove the access.

A few months ago, a paralegal at a law firm we support clicked what looked like a shared document from opposing counsel and signed in through a convincing Microsoft login page. She had MFA and completed the prompt, but the page was relaying her session in real time. Within minutes the attacker was in her mailbox from overseas. We caught it through an impossible-travel alert, revoked the session and reset the account before any client data left.

There are a handful of things we normally tighten up here. Use number matching in the authenticator app. Put administrators and other high-risk users on phishing-resistant methods such as FIDO2 keys or passkeys. Don’t let users approve any third-party application they want. And where licensing allows it, use conditional access so a password or stolen session by itself isn’t enough to get into the environment.

Legacy authentication remains the open side door

This one still surprises a lot of executives. They know MFA is enabled and assume that means every sign-in is protected. That isn’t always the case. Legacy protocols such as POP, IMAP and older SMTP connections don’t support MFA, which can leave a path around the control.

Microsoft has retired a lot of legacy authentication already, but we still come across exceptions that were left in place for an old scanner, a line-of-business application or sometimes one user’s device. Find out what actually still needs it, fix or replace that dependency, and close the exception. We have seen organizations leave a security hole open for years because of one multifunction printer.

Licensing determines what security is actually available

Licensing is another area that causes a surprising amount of confusion. Two plans can sound almost identical while giving the IT team very different security capabilities. Office 365 E3 and Microsoft 365 E3 are a good example: Microsoft 365 E3 includes Intune device management and Entra ID P1 conditional access, while Office 365 E3 does not.

We once had a healthcare client with a departing employee who kept a company laptop with patient records on it. Leadership assumed we could lock or wipe it remotely. We couldn’t. They were licensed for Office 365 E3, not Microsoft 365 E3, so the device had never been enrolled in Intune. We got the laptop back, but only after several uncomfortable days, and they upgraded their licensing the following week.

So before putting together a security roadmap, I would first confirm exactly what licenses are in place and what those licenses actually include. We’ve had more than one situation where leadership assumed a security capability was available simply because the Microsoft plan name sounded similar.

Email is still where most incidents begin

For us, email is still where a large percentage of incidents start. It may be a credential phishing page, a malicious link, or an inbox rule created after somebody has already gained access to the account.

Business email compromise is especially dangerous because the attacker often doesn’t do anything obvious right away. They get into a mailbox, create forwarding rules or hide replies, and wait. The goal may simply be to sit there until an invoice or wire transfer gives them an opportunity. According to the FBI’s Internet Crime Complaint Center, reported cybercrime losses reached $16.6 billion in 2024, and BEC continues to be one of the more expensive categories of fraud.

At one law firm, an attacker compromised a mailbox and created a rule that quietly moved any email containing “invoice” or “wire” into an unused folder. Two weeks later, a client received updated wiring instructions for a settlement payment from what looked like the firm’s own account. The client called to confirm before sending the funds, and that phone call is the only reason the money didn’t go out.

We normally put several controls around this. Block automatic forwarding to outside domains. Alert when inbox rules are created or changed. Most importantly, have an internal policy that any change to payment or wiring instructions gets confirmed verbally using a phone number you already know. That last one has nothing to do with cybersecurity software, but it can stop a very expensive mistake.

Privileged accounts need their own standard

The global administrator list should be short, intentional and documented. We also don’t want somebody using the same privileged account to read email and browse the web all day. It sounds basic, but we correct this all the time.

Use separate administrative accounts, put phishing-resistant MFA on them, and use just-in-time elevation where the licensing supports it. A compromised global administrator account gives an attacker an enormous amount of control, so we treat those accounts differently from a normal user.

Logging only helps if it’s configured before you need it

When something does happen, we immediately need to know what happened, when it started and what the attacker touched. If the right logging wasn’t enabled beforehand, or the retention period is too short, sometimes you simply can’t reconstruct the whole incident after the fact.

I’d much rather configure logging on day one and never use it than reconstruct an incident from partial data. CISA’s Secure Cloud Business Applications (SCuBA) baselines are an excellent, free reference for which settings to enable and how to verify them.

Where I would start

Microsoft 365 can be a very secure platform. In most environments we take over, the issue isn’t that Microsoft was missing some critical security feature. It’s usually a relatively short list of settings, permissions and exceptions that accumulated over time.

If I were reviewing an environment this quarter, these are the four things I would verify first:

1. Administrative access is minimal and protected with phishing-resistant MFA.
2. Legacy authentication is blocked.
3. MFA covers every user, and users can’t approve third-party apps unchecked.
4. You would have complete logs if something happened tomorrow.

Those four checks won’t solve every security problem, but they eliminate a lot of the issues we repeatedly find when we’re brought in to assess an environment or clean up after an incident.