Zero Trust by Design in Microsoft 365 & Dynamics 365

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?


Get full access to M365 Show - Microsoft 365 Digital Workplace
Daily at m365.show/subscribe