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 MFA
Most 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 Other
What 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 Workflows
Everyone 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 and D365, this segmentation usually takes the form of role-based access assignments tied to specific workloads. A marketing coordinator might only need Teams, SharePoint, and access to customer records in a read-only capacity within Dynamics, while someone in finance might be able to approve payments and pull sensitive reports. The principle is simple: the more privileged the action, the tighter the controls. The challenge is doing that without turning every login into a waiting game or making daily tasks painful. That’s the part that makes admins nervous.
The fear goes like this—if we start creating separate authentication paths for each role, users will be hit with constant prompts, workflows will slow down, and teams will push back hard. You roll out different multifactor requirements for sales and finance, and suddenly half your sales team is on the phone with IT because they can’t access a proposal during a client call. Or finance is launching Teams to collaborate on a budget, but their enhanced sign-in process kicks in for every single conversation thread.
But the flip side is worse. Without segmentation, an attacker who compromises the account of that same marketing coordinator has a much easier path to laterally move into high-value data. That’s why the goal isn’t to make everyone’s login harder—it’s to make the sensitive stuff harder to get to, while keeping low-risk actions smooth.
Here’s an example that works. Sales reps log in with standard MFA for day-to-day tools like Teams and Outlook. Finance users have the same baseline sign-in but get an additional authentication challenge when they try to approve wire transfers in Dynamics or export detailed financials in Power BI. Behind the scenes, Privileged Identity Management (PIM) is telling Dynamics to grant those finance roles just-in-time elevated permissions for those actions—permissions that expire automatically after use. That way, finance isn’t hindered when they’re doing routine work, but there’s still a hurdle in place for higher-risk operations.
When you layer segmentation through PIM and just-in-time access, you start to remove standing privileges from accounts altogether. Instead of a finance manager always having invoice approval rights, they only have them for the hour they need to process the month’s payments. Even if their credentials were stolen, the attacker would have to time the breach to the exact permission window—and that’s assuming they could pass the contextual checks on device compliance and location.
Mapping this to day-to-day tasks is where the design work happens. A sales user might be in Teams chat all day, hopping into SharePoint for proposals, and occasionally checking CRM data in Dynamics. None of that needs high-friction authentication unless they attempt to modify financial records. A finance user might live inside Power BI dashboards and the Dynamics finance module, but they don’t need elevated permissions just to collaborate in a Teams channel. You define these boundaries in policies so each role’s common workflows stay quick, while the sensitive actions stay locked down tight.
Think of it like having different keys for different rooms in an office building, but all on one smart keycard. You swipe once and move freely where you’re authorised. But when you reach the server room or the records archive, the card prompts for a PIN before the door opens. That extra step only happens in the places where it matters, and you’re not fumbling with a massive key ring for every door along the way.
Segmentation designed this way keeps users moving at full speed for low-risk work, but it still forces a deliberate validation before they touch anything critical. It’s a balance—strong enough to block an attacker who gets in with stolen credentials, but invisible enough in daily use that your team doesn’t notice the guardrails. And even with the right access segments in place, the trust you establish at sign-in can’t be the only check you run. In a truly resilient setup, every active session is reassessed as it unfolds—not just at the point of entry.
The Power of Continuous Verification in Multi-Cloud
In a world where one set of cloud credentials can open doors in multiple platforms, checking them only once is asking for trouble. That was fine in the old on‑premise model, where we trusted a device inside the network perimeter until the user logged out. But in a Microsoft 365 and Dynamics 365 environment that also talks to AWS, Google services, or third‑party SaaS apps, the risk level isn’t fixed the moment someone signs in—it changes continually.
Continuous verification flips the traditional mindset. Instead of a single, up‑front decision at sign‑in, access is assessed over and over during the session. That means the system re‑asks: is the user still who they say they are, is the device still compliant, is the connection location still trusted? These checks can be triggered by specific events, scheduled intervals, or risk signals firing in real time. You’re not just validating entry—you’re monitoring behaviour and context every step of the way.
It’s easy to see the gap when you contrast this with the “login once, stay in” approach. In an on‑premise world, once you parked your laptop on the corporate network and passed the first check, you were assumed safe for the rest of the day. But cloud services don’t have that stable, physical perimeter. Users move between devices, networks, and geographies throughout a single work session. Threat actors can steal active session tokens and reuse them without ever seeing another MFA prompt. A static trust decision made at 9 a.m. may be completely irrelevant by 9:15.
Picture this scenario: a user signs into M365 from a trusted laptop at head office. They open Outlook, Teams, and Dynamics 365 Finance. Mid‑session, their IP address shifts to a location 2,000 miles away—maybe because their home Wi‑Fi dropped and their device auto‑connected to a 4G hotspot routed overseas. Azure AD’s Identity Protection flags the sign‑in risk level from “none” to “high” in seconds. In a continuous verification world, that risk level propagates instantly. Microsoft 365 prompts the user for re‑authentication before they can send that Teams file. At the same moment, Dynamics 365 reacts by pausing the approval workflow the user had open, effectively locking down sensitive actions until the session is validated again.
This kind of coordination is powered by Microsoft Graph and Azure AD Identity Protection. Microsoft Graph provides the plumbing—the real‑time stream of identity, device, and activity data available to every connected application. Identity Protection consumes that data to assign a dynamic risk score, based on known signals like atypical travel, sign‑ins from malware‑linked IPs, or impossible sequences of location changes. Any app integrated into this framework can act on those risk changes mid‑session, not just at the original login.
The payoff is especially big when you operate in a multi‑cloud environment. Imagine a developer moving between Azure DevOps, an AWS console, and Jira in a browser tab set. If the device fails a compliance check in Microsoft Endpoint Manager while in Azure, that signal can cascade outward. Integrated apps in other clouds can pick up the same “untrusted device” flag and prompt for re‑authentication or lock sensitive features—no human needs to push the change, and no attacker can exploit a stale trust state.
It’s a bit like a bouncer walking around inside the party, not just guarding the front door. Someone might get in looking fine, but if their behaviour changes—grabbing bags, starting an argument—they’re escorted out before anything escalates. Continuous verification works the same way: the environment keeps scanning for anomalies and enforces action mid‑session, even if the initial entry seemed legitimate.
In multi‑cloud setups, the cost of not re‑checking is multiplied. One risky session that goes undetected isn’t confined to one app—it can thread its way across multiple services via token reuse or API integration. If you only check identity at the start, you’re betting that no context will change, no credentials will be stolen, and no device will drift into a non‑compliant state over hours of activity. That’s not a bet worth making.
When continuous verification is automated through the right Microsoft services, you stop thinking of it as a separate security layer. It becomes a natural part of how access works—always on, always aware, and always ready to reassess trust before any real damage is done. The end result is that Zero Trust isn’t just a sign‑in event—it’s the constant hum in the background, protecting every action in every connected system.
Zero Trust That Doesn’t Burn Out Users
If your Zero Trust rollout has people hitting “approve sign‑in” twelve times a day, they’re going to figure out a way to dodge it. That’s not laziness—it’s survival. There’s only so many interruptions before someone makes a decision that prioritises getting work done over following the rules. The problem is, the workarounds they choose often undo the security controls you worked so hard to put in place.
This is where authentication fatigue comes in. It’s what happens when users are asked to prove themselves so often that the process becomes background noise. The prompt stops being a meaningful check and starts being another box to tick, or worse, something to game. In a Zero Trust model, repeated challenges are meant to protect high‑value actions. But when those same challenges are peppered into every mundane task, people stop distinguishing between legitimate security events and system noise. That loss of attention is risky.
Well‑intentioned policies can sabotage themselves if they burn through goodwill too quickly. If a policy demands a fresh MFA prompt every time someone switches from Outlook to Teams to SharePoint, you’re conditioning them to mindlessly approve anything just to continue working. And in that state, a malicious prompt—say from an attacker trying to gain session control through MFA fatigue techniques—has a much higher chance of being accepted. You’ve spent budget on strong security tech, but the behavioural layer is now the weakest link.
Here’s a real‑world example. An employee, frustrated with constant sign‑in prompts, configures Outlook on their personal laptop to remember credentials indefinitely. It feels harmless—they’re shaving seconds off their day. But now, that personal device has an always‑on token into the organisation’s email, outside the conditional access rules you set for corporate devices. If the laptop is lost or compromised, the attacker doesn’t even have to attempt MFA—they already have a living, active session.
The smarter approach is to base challenges on context. Adaptive access policies are built around that idea: instead of treating every sign‑in the same, they look at the risk level in real time. The system knows if the device is compliant, if the location is expected, if the session has been behaving normally. When all those checks are green, the need for repetitive re‑authentication gets cut way down. Users still get challenged, but only when something changes in a meaningful way.
This is how you thread the needle between strong controls and usability. You dial up the sensitivity in high‑risk scenarios—like accessing financial records from an unmanaged device—and keep it low‑friction when the user is on a trusted laptop in the office. That’s not leniency; it’s strategic resource allocation. You’re expending user time and attention where it matters, not bleeding it out on inconsequential actions that don’t meaningfully raise the threat level.
Think about airport security. Everyone goes through baseline screening, but full bag searches and secondary scans are reserved for cases that trigger concern—a flagged item, an abnormal pattern, a randomised check. No one’s taking their shoes off at every doorway inside the terminal, because the system is designed to balance throughput with threat detection. In Zero Trust terms, your “randomised checks” come in the form of challenging sessions when context shifts, even if the original sign‑in was clean.
When you strip out the unnecessary friction, you don’t just make life easier for users—you make the controls more effective. The fewer prompts they see, the more seriously they take them. A re‑authentication request in the middle of approving a high‑value transaction in Dynamics 365 isn’t ignored, because it’s rare enough to stand out. That attention is exactly what you need when you’re relying on the human to verify a crucial action.
The end goal of Zero Trust by Design in this context is security that is constantly present but rarely intrusive. The automation running in the background keeps checking device compliance, session integrity, and identity signals without waving a flag for every clean result. When something trips the risk meter, the user feels the control kick in—like an extra step before exporting sensitive Power BI data or approving external sharing in SharePoint. For everything else, they just work.
That’s when Zero Trust stops feeling like a barrier and starts functioning like part of the environment—enforcing all the right rules without derailing the day. Which brings us to the bigger picture: what happens when all these moving parts, from identity alignment to continuous verification, actually operate as one interconnected system.
Conclusion
Zero Trust by Design isn’t just a checklist of MFA prompts, device policies, or conditional access rules. It’s the framework that makes every Microsoft 365 and Dynamics 365 workload act on the same live security signals, in sync, without leaving loopholes between them.
Take a hard look at your setup. Are your M365 and D365 policies making decisions together, or are they acting like separate guards who’ve never met? Security gaps don’t always exist inside a product—they often live in the space between them.
Your environment is already interconnected — will your defense be too?
Share this post