How Does a Small Firm Implement Zero Trust in Microsoft 365?

How does a small firm implement zero trust in Microsoft 365?

One rule at a time. In Microsoft 365, zero trust is built mostly from conditional access policies: rules that check who is signing in, on which device, and to what, before letting anyone through. You turn on the rules that won't disrupt anyone first, test the harder ones in report-only mode, and keep going. Plan on months, not a weekend.

I've spent 30 years in IT, and I'd rather show you than tell you. This one isn't a client story. It's ours. Our engineer has been rolling out zero trust on HD Tech's own Microsoft 365, and here's what that actually looked like.

Why zero trust instead of just a password and MFA?

Old-style security works like a bouncer who knows you. You're in, and you can go anywhere in the club. Zero trust checks you at the door, then checks your wristband again at every room. Right person, right device, right place. If one of those doesn't line up, you don't get through, even with the correct username and password.

Microsoft sums it up in three principles: verify explicitly, use least privilege access, and assume breach. In practice, each policy is one layer. Stack enough layers and an attacker gets stopped at one of them.

What surprised us when we put up the gate?

How much was already coming through. The moment you put a check in front of Microsoft 365 that looks at devices, you see everything that has been signing in all along. We found more people and far more devices reaching our systems than we expected: personal phones, older laptops, an old test phone.

That's the point of zero trust: no surprises. But finding them creates friction, because every legitimate person still has to get their work done. Some computers needed a reset before they could join Microsoft Entra, Microsoft's sign-in and device system. Some people needed a new device. It touches everyone.

How do you roll out zero trust for a small business?

Here's the order we followed on our own systems:

• Start with the easy policies. Turn on the rules you know won't disrupt anyone. That builds momentum for the harder ones.
• Run the hard ones in report-only first. A report-only policy records who it would have blocked without blocking anyone. Microsoft recommends testing in report-only before switching a policy on. Even before a policy is enforced, its sign-in data shows you problems you'd otherwise miss.
• Work around devices you can't manage. A personal iPhone can't be brought under company control, so blocking it outright doesn't work. Instead, an app protection policy controls the Microsoft 365 apps on that phone, even though we don't control the phone itself.
• Keep an emergency way back in. A misconfigured policy can lock out the people who manage it. Microsoft's guidance is to exclude an emergency access account from these policies so you can always recover. We do, and we keep a list of every exclusion, because they're easy to forget.
• Use a map, not memory. Every policy has dozens of settings, and they interact. Our first attempt, about three years ago, stalled after three policies. There were too many what-ifs: Macs, Android phones, Chrome, Linux, a laptop on coffee-shop Wi-Fi. What got it moving was using AI tools to check each policy against each type of user and device, so we can see who would be blocked by what before we change anything.

What was the result?

We aren't finished, and we won't pretend otherwise. Some policies are on. Others are still in report-only while we sort out the people and devices they'd affect. What we have now is a clear view of who and what signs in to our Microsoft 365, a list of exceptions we chose on purpose, and a dashboard our support team uses to check whether a policy is behind someone's sign-in problem.

Moving toward zero trust counts. It's a process, not a switch, and every policy that's on is one more layer an attacker has to get through.

What should you ask your own IT provider?

Which conditional access policies are on in our Microsoft 365, and which are only reporting? Who is excluded, and why? What happens when someone signs in from a personal phone? If nobody can answer, you've found the gap, and it's fixable. Trust, yet verify.

Always on watch, Tom