A conversation to be had about Microsoft 365, Entra, and Azure . . .
If you walk into just about any community bank today and ask what their core systems are, you’ll hear some version of Microsoft 365, Entra ID, and Azure. Email, authentication, file storage, collaboration, even pieces of security all live there now. And to be clear, that’s not a bad thing. Microsoft has built an incredibly powerful ecosystem, and in many ways, it’s more secure than what most organizations could realistically build on their own.
But there’s a conversation we don’t have often enough. What happens when so much of your operation depends on one ecosystem?

This isn’t about being anti-Microsoft. We work in it every day. This is about understanding where the real risks are, because they’ve shifted.
There was a time when we talked about firewalls as the perimeter. That’s gone. Today, your perimeter is your identity system, and for most banks, that’s Entra ID. If someone gets control of that, they don’t have to break in anymore. They just log in. We’ve seen scenarios, and even real vulnerabilities, where attackers can impersonate users, elevate privileges, and move through an environment without triggering the kinds of alarms you’d expect. No malware. No obvious indicators. Just activity that looks normal. That’s what makes this different. When identity is compromised, the attacker doesn’t look like an attacker. They look like your staff.
And here’s the part that’s a little frustrating. Most of the incidents we see still aren’t sophisticated attacks. They’re configuration issues. Too many global admins. Permissions that were granted and never revisited. Legacy authentication still hanging around because something might break if it’s turned off. Cloud platforms are incredibly flexible, and that’s one of their strengths. But that flexibility also creates a lot of ways to accidentally leave doors open. In our world, it’s usually not one big mistake. It’s ten small ones that line up just right.
We also tend to separate security from availability, but in the cloud, you really can’t do that anymore. If Microsoft has an outage, or even a partial disruption, what happens at your bank? Can your staff authenticate? Can they access email? Do your internal processes still function? We’ve seen situations where identity services hiccup and suddenly people can’t log in to anything. That’s not just an IT inconvenience. That’s a business interruption. And for banks, that matters.
Another thing that sneaks up on people is the level of trust involved in the ecosystem. When you adopt Microsoft 365 or Azure, you’re not just trusting Microsoft. You’re also trusting every third-party application connected to your tenant, every vendor with delegated access, and every integration that someone approved two years ago and hasn’t looked at since. We’ve investigated incidents where the initial access didn’t come from phishing or brute force. It came through a trusted connection. That’s the nature of the cloud. It’s interconnected by design.
At the same time, attackers have changed how they operate. They’re not always dropping ransomware right away or deploying noisy tools. More often, they log in, look around, escalate privileges, and blend in. Sometimes they sit quietly for days or weeks. And when they do move, they use built-in tools like PowerShell, APIs, and admin portals. These are things your team uses every day. That makes detection harder, because now you’re not just looking for bad activity. You’re trying to identify unusual normal activity.
There’s also a piece of this that people don’t always like to talk about, and that’s concentration risk. There’s a real operational benefit to standardizing on Microsoft. It simplifies things, integrates well, and reduces complexity. But it also increases dependency. When your identity, email, file storage, endpoint security, and even logging are all tied into one ecosystem, you’ve streamlined your environment, but you’ve also concentrated your risk. So if something goes wrong, whether it’s a misconfiguration, a compromise, or even a platform issue, it can have a wider impact, faster. That doesn’t mean you shouldn’t use Microsoft. It just means you need to understand how much of your risk is now tied to one place.
So what do you do about it?
First, treat Entra ID like critical infrastructure, because it is. Be aggressive about limiting global admins, enforce strong and phishing-resistant MFA, and pay close attention to changes in identity and permissions. Second, make sure you have visibility outside of Microsoft’s native tools. They provide a lot of data, but seeing alerts isn’t the same as understanding what’s happening. Pull logs into a platform where you can correlate activity and actually investigate it. Third, assume something will get through and design your controls accordingly. Use conditional access with context, implement just-in-time privilege where you can, and keep a close eye on service accounts and app registrations. Fourth, pressure test your dependency on the cloud. Ask what happens if you can’t access Microsoft for a few hours and actually walk through it. Most organizations find gaps pretty quickly. And finally, take a hard look at third-party access. Review what’s connected to your tenant, what permissions those connections have, and whether you still need them. There’s almost always something in there that doesn’t belong anymore.
At the end of the day, the move to Microsoft 365, Entra, and Azure didn’t eliminate risk. It changed where it lives. For community banks, the ones that get this right aren’t the ones chasing every new tool. They’re the ones who understand that identity is now the control plane, that visibility matters more than ever, and that small missteps in the cloud can have big consequences.
It’s not about whether the platform is secure. It’s about whether you’re using it securely.