If your Microsoft 365 tenant talks to Dynamics 365, Azure, and a handful of other SaaS tools, the attack surface is bigger than you think. The scary part? Most Zero Trust rollouts focus on a single product, ignoring the domino effect across connected systems. In the next few minutes, we’ll walk through why that’s a problem — and how ‘Zero Trust by Design’ treats your M365 and D365 environment as one interdependent whole. Because fixing just one wall in a multi-room building won’t protect you when the roof’s on fire.Zero Trust Is Not Just MFAMost people think they’ve “gone Zero Trust” the moment MFA is turned on for everyone. It feels like a big win: every user gets prompted, every sign-in needs that second factor, and on paper, the environment looks secure. The problem is that this is often where the effort stops. M365 gets full attention during the rollout, but connected platforms like Dynamics 365 keep running on their own, often with different rules or none at all. That’s not just incomplete; it’s creating a false sense of safety. Here’s what that looks like in practice. An admin spends weeks building and testing conditional access for SharePoint, Teams, and Exchange Online. They force MFA on all sign-ins, block legacy authentication, and feel confident the tenant is locked down. But D365 is sitting off to the side, reliant on Azure AD for authentication but without the same policy scope. A user logging into a D365 environment through a bookmarked URL might never hit the same conditional access workflow—and the admin won’t notice until something goes wrong. This is where the gap starts costing you. Let’s say someone’s credentials are stolen through a phishing campaign. The attacker tries logging into SharePoint first. MFA kicks in, they fail, and you think the problem’s solved. But since D365’s conditional access rules aren’t matched to M365’s, that same attacker might connect directly to the finance module in Dynamics and walk straight in. The MFA “wall” exists, just not in front of every door. Suddenly, the unified defense you thought was in place is actually fragmented. In one example we saw, a misaligned policy allowed exactly that. A user’s SharePoint account was protected by strict sign-in requirements, but their Dynamics access wasn’t. The attacker bypassed SharePoint entirely, went into Dynamics, ran a report, and exported sensitive customer payment data. From the user’s perspective, nothing seemed wrong—they never even got a prompt saying their account had been accessed elsewhere. The attack was possible not because MFA was weak, but because it wasn’t consistently enforced everywhere it should have been. Microsoft’s own positioning makes it clear—Zero Trust isn’t “enable MFA and move on.” It’s a framework built on validating identity, verifying device compliance, and inspecting the session context continuously. MFA is just one piece of the identity pillar. If that pillar isn’t applied across every connected service, it fails to be a reliable control. And in a connected environment like M365 and D365, attackers only need to find one service where the control isn’t enforced. We worked with a finance team that learned this lesson the hard way. The CFO’s M365 account had MFA, and the IT team was strict on email access. But Dynamics 365 was configured differently. The attacker gained entry to the CFO’s account via a stolen refresh token from a less-secured third-party mobile app. M365 access was blocked, but token reuse in Dynamics wasn’t triggered by the same risk policy. They generated fraudulent invoices inside the finance module and pushed them through the normal approval flow. By the time the incident was discovered, the funds were already gone. Every post-incident review pointed to the same root cause—policy inconsistency. It’s not that MFA fails. It’s that the “edges” between integrated Microsoft services are often where policies don’t align. Users move between SharePoint, Outlook, OneDrive, Dynamics, and other connected SaaS apps without thinking about it. Attackers know this and test which doorway has the weakest lock. That’s why Zero Trust by Design is less about any single control and more about making sure every entry point enforces the same standards without exception. Conditional access rules, device health checks, session controls—they all need to be part of a unified, enforced baseline. When every Microsoft service applies the same level of scrutiny—validating identity, device, and session context on every interaction—you close off the “side doors” attackers look for. The MFA prompt on M365 means nothing if D365 silently waves the same user through five seconds later. The design goal is that every transaction, every login, every API call passes the same set of checks, no matter which product it touches. If alignment across workloads is the first fix, the real shift happens when these policies actually talk to each other in real time. That’s where Zero Trust moves from a checklist item to a living defense.When Systems Start Talking to Each OtherWhat if the conditional access policy you set up in Microsoft 365 could instantly trigger a security response in Dynamics 365—without you having to duplicate the rule or manually sync anything? That’s not the default reality for most environments. Usually, each system enforces its own set of rules in isolation. M365 might demand MFA for risky sign-ins, while D365 grants or denies functionality based solely on role permissions stored in its own model. They’re both pulling from the same Azure AD identities, but they’re not necessarily sharing the same live risk data with each other. This siloed approach means you can lock down one platform perfectly and still have blind spots in the other. Think about it: your M365 tenant sees a sign-in from a TOR exit node at 2 a.m., flags the account as high risk, and applies a block. But Dynamics? Unless its own controls are tied to that same real-time risk signal, it could let the session continue. The user’s token might still be valid for Dynamics despite being on the block list for M365. Now you’ve got a situation where one part of your environment is treating the account like it’s under attack while another is happy to process an invoice approval. The missed opportunity here is the ability for policies and risk scoring to propagate across both environments instantly. Microsoft actually gives you the foundation for this with Azure AD Conditional Access and D365 role-based security. Conditional Access evaluates sign-ins for risk in real time, using signals like unfamiliar locations, impossible travel patterns, or known-bad IP ranges. Role-based security in Dynamics then defines what a user can do once they’re in, down to the field level. When those two layers remain disconnected, you get policy gaps. But when they’re connected, an elevated risk flag in Azure AD can immediately change what that same account can do in Dynamics, without user intervention. Imagine this in action. A salesperson logs in from an unusual location. Azure AD flags them as medium risk and applies a conditional policy that requires step-up authentication for sensitive actions. Dynamics 365, instead of ignoring that context, consumes the Azure AD risk state and automatically locks down features like exporting customer lists or modifying pricing data until the session is verified. The enforcement happens in real time and doesn’t depend on someone manually pushing a change or rebuilding the same logic twice. It’s a bit like having two security guards at two different doors to your office. One sees someone trying the handle after hours, stops them, and radios the other guard to be on alert. If those guards don’t talk, the second one might happily wave the person in the side entrance while the first is still writing up the incident. Without cross-service signals, that’s exactly what can happen between M365 and D365—one door is locked, but the other is wide open. Technically, this kind of integration comes down to allowing risk signals from Azure AD to flow directly into D365 and become part of its access decision-making. Real-time claims about user risk, device compliance, or location can be included in the token presented to Dynamics. Then, Dynamics enforces role-level restrictions or denies specific operations based on those claims. This shortens the window an attacker has to exploit a compromised account from hours—or even days—to seconds. It also means your security policies stop being static documents and start acting like a shared nervous system across platforms. When access decisions in Dynamics reflect the exact same live security posture that Microsoft 365 sees, your defenses become coordinated instead of parallel. That coordination is what closes the micro-gaps attackers rely on. They can no longer move laterally between services without tripping the same alarms and hitting the same roadblocks in each one. But before you can enable that level of real-time signal sharing, you have to make sure the identities themselves are structured in a way that makes sense for both systems. That means segmenting them so each role, each type of data access, and each risk profile can be managed cleanly without breaking how work actually gets done.Identity Segmentation Without Breaking WorkflowsEveryone talks about locking down identities, but not many want to explore how to do it without wrecking productivity. Identity segmentation isn’t about making people jump through hoops for every click. It’s about designing access in a way that recognises not all users, data, or actions carry the same level of risk—and then applying controls that reflect that reality across Microsoft 365 and Dynamics 365. In practice, it means defining clear boundaries between groups based on what they do, the sensitivity of what they handle, and the risk they represent. It’s the difference between giving every user a master key or only the exact keys they actually need. In M365
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.
