Episode Details

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 c