Have you ever turned on a new security policy in M365… only to get a flood of Monday morning tickets from unhappy users? If that sounds familiar, you're not alone. Today, we're going to cover 10 critical settings that lock down your tenant, but won’t lock out your users. The trick is balancing ironclad security with usability—and we’ll show you exactly how to do it without the usual pain.The Security Setting Everyone ForgetsMost admins feel confident once they’ve set strong password requirements. Complexity rules are in place, expiration is turned on, and minimum length checks out. It looks solid on paper, but here’s the catch—attackers don’t actually care how complex those passwords are if the system doesn’t demand anything more during sign-in. That one missing layer is exactly where most tenants stay vulnerable, even if the admin thinks the basics are covered. The assumption is simple: if users must create long, complex passwords, that’s enough to keep intruders out. But attackers have changed the game. Password spray attacks are automated, fast, and usually successful against at least a handful of accounts in even the most mature organizations. The truth is, complexity requirements don’t stop an attacker from trying endless combinations across many accounts. And if a single password is weak—or reused somewhere else—that’s often all it takes. One tenant I worked on learned this the hard way. They had standard password policies in place, thought they were in the clear, and moved on to more visible projects. It wasn’t until their helpdesk started drowning in reports of missing emails that they realized something was wrong. A single compromised user account had been sending thousands of phishing messages internally and externally for days. The attacker didn’t need to crack a difficult password from scratch. Instead, they tried common patterns across every user, and eventually one hit. Because nothing else was configured, that account was fair game. Stories like that aren’t rare. Microsoft has published insights showing that the overwhelming majority of successful credential-based attacks target tenants without any additional identity protections. Numbers vary, but the pattern is crystal clear: password-only defenses eventually fail, no matter how strict the characters and symbols are. Attackers rely on that blind spot, because they know it’s surprisingly common for organizations to overlook. So what’s the actual setting that gets skipped? It’s the consistent application of multi-factor authentication through conditional access. Microsoft even provides a baseline MFA configuration, yet many admins hold back from turning it on. Sometimes the hesitation comes from thinking it will be a nightmare for users. Other times it’s because conditional access feels like a big design project, touching every login scenario across the entire tenant. Either way, hesitation leaves a door cracked open. Admins often picture the worst-case backlash: Monday morning chaos, phones lighting up with complaints, executives locked out of their inbox. That fear of disruption leads to postponing the change, sometimes indefinitely. But here’s what most of us don’t realize at first—once MFA and conditional access are enforced, end-users barely notice in practice. Modern apps handle the sign-in flow smoothly, and once a device is trusted, prompts drop down to a quick tap or notification check. Think about it like this: attackers don’t target just the CEO account. They’ll happily compromise an intern’s mailbox if it lets them pivot further into the company. With that perspective, a single well-placed conditional access rule has an outsized impact. It isn’t about locking everything down so tightly that work grinds to a halt. It’s about requiring just enough verification to stem the most common attacks before they gain any traction. The real kicker is how effective this simple switch can be. Enabling baseline MFA combined with policies to block legacy authentication stops the vast majority of credential-based compromises right at the gate. Attackers thrive on weak links. Remove those, and you eliminate entire categories of risk without overhauling your environment. It’s like going from leaving the office door open overnight to hiring a guard—except the guard doesn’t interfere with your staff walking in every morning. This is why skipping MFA and conditional access ends up being the most dangerous oversight. Not because it’s technically complex, but because it feels deceptively optional. The default assumption is that security must always equal friction. That mindset leaves many tenants exposed for far too long. And yet, it doesn’t have to be either/or. Smart identity policies add a wall of protection without burying users in prompts. Which raises the bigger question—if identity is this easy to improve, what about the rest of the environment? Collaboration is where most businesses walk the tightrope of usability versus protection. And when it comes to Teams and SharePoint sharing, the stakes can get even higher than a compromised password.Collaboration Without LeaksSharing keeps the business moving, but the convenience comes with a hidden risk. One wrong link shared outside the tenant can be all it takes for confidential data to escape. In Teams or SharePoint, collaboration flows fast, and that’s the good part. The challenge is that the same speed allows mistakes to spread just as quickly. Nobody sets out to expose financial figures or HR reports, but the platform makes a single click enough to push sensitive files beyond company boundaries. You’ve probably seen this scenario play out: someone in finance drops a spreadsheet into a Teams chat, meaning to share it only with their manager. Instead, the link gave external access to a supplier who happened to be part of the channel. That supplier now has visibility into salary data and budget breakdowns that were never intended to leave internal walls. By the time the admin steps in, it’s already too late—copies are made, attachments are in inboxes, and the cleanup effort becomes more about damage control than prevention. This kind of misstep is not as rare as people would hope. Everyday file sharing is at the center of knowledge work, and with that volume comes error. Data leaves organizations unintentionally far more often than through deliberate theft. A huge percentage of users working in Microsoft 365 admit at some point they’ve sent the wrong file or granted more permission than intended. Cloud collaboration makes it simple to work across projects and borders, but simplicity is also what enables these slips. So how do you keep the benefits of sharing without creating a constant leak? Microsoft has put several layers in the toolbox to address exactly that. Sharing controls are the foundation—admins can define whether links default to internal, people with existing access, or anyone with the link. Then come sensitivity labels, which travel with the document and adjust behavior whether the file is stored in OneDrive, Teams, or emailed as an attachment. On top of that, there’s Data Loss Prevention, which lets you watch for patterns like personal information, financial identifiers, or even project-specific keywords. Instead of blocking productivity outright, DLP can step in with a friendly warning that says, “Are you sure you want to send this externally?” Users need that balance because if controls feel restrictive, they’ll start looking for workarounds. IT wants certainty, users want to keep their flow, and those goals sound like they clash. The reality is, when policies are written in plain language, most people understand instantly what’s at stake and correct themselves before sending. A popup that speaks human language—“This file contains customer records”—lands much better than abstract codes or technical warnings. Of course, without those guardrails, the risk stretches beyond embarrassment. One accidental share can cross into regulatory trouble or contract breaches. Consider a healthcare organization where a misplaced file violates patient privacy law, or a financial institution that unintentionally provides external access to trade-sensitive data. In cases like that, the clean-up cost includes fines, legal reviews, and trust lost with partners and clients. What started as a harmless share link now has material business fallout that could have been avoided by setting better defaults. The good news is, prevention here doesn’t require draconian rules. A well-tuned DLP policy can be specific to business context. Maybe legal documents can’t ever leave the tenant, but marketing materials can be sent broadly. If the policies guide users with clarity and stop only the real risks, they feel less like roadblocks and more like safety rails. The moment an employee gets a notification explaining why a file can’t be shared, and the wording makes sense, you’ve raised awareness without halting productivity. That kind of configuration not only reduces risk but also redirects the conversation between IT and business units. Instead of saying “no” to every request, admins can show they’ve created space for secure sharing. Over time, that builds trust because teams see IT as an enabler, not a blocker. Monday mornings don’t turn into ticket marathons because users understand the prompts and quickly adjust their behavior. So the lesson here is straightforward: design your collaboration model with smart defaults, use sensitivity labels to enforce context, and let DLP policies communicate in clear, user-friendly terms. You’ll avoid the endless cycle of accidental oversharing while keeping people productive. And once collaboration guardrails are in place, attention returns to identity. Because if file leaks are one side of the puzzle, the other side is stopping attackers before they even reach the data—and there’s one conditional access policy that does more of that heavy lifting than almost anything else.The 80% Fix

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.