In the previous posts, we established identity as the primary enforcement point and introduced identity risk as a signal to influence access decisions.
However, focusing on identity alone is not sufficient: a valid authentication, even combined with strong MFA and low identity risk, does not guarantee that the device used to access Microsoft 365 is trustworthy.
Once authentication succeeds, access is granted through an access token. From that point onward, the security of the session also depends on the device used to access Microsoft 365.
If that device is unmanaged or compromised, identity-based controls alone are no longer sufficient.
This is where endpoints become a critical part of the Zero Trust model.
From Identity Trust to Device Trust
Traditional access models focus on the user. If the user can authenticate, access is granted. In a Zero Trust model, this assumption no longer holds. Access decisions must take into account not only who the user is, but also the condition of the device being used.
A legitimate user signing in from a compromised endpoint introduces the same type of risk as token theft or session hijacking. The authentication itself is valid, but the context in which the token is used is not trustworthy.
Device trust therefore becomes a necessary complement to identity trust.
Managed and Unmanaged Devices
The first practical distinction is between managed and unmanaged devices.
Managed devices
Managed devices are enrolled in Intune and can be evaluated against compliance policies. This provides a continuous signal about their configuration and security posture, which can be used in Conditional Access decisions. This includes verification of boot-time security measures such as BitLocker, Secure Boot, and code integrity; device security controls (firewall, antivirus, antispyware, TPM); device risk level; OS version; and other security-relevant attributes.
However, compliance should be seen as a baseline, not a guarantee. A device can be compliant and still be compromised.
In practice, attackers do not need to bypass compliance directly. By stealing session tokens or browser cookies issued to a compliant device, they can reuse an already trusted session without triggering Conditional Access again. This highlights an important limitation: device trust is enforced at session creation, not continuously during its lifetime. We will see how this can be mitigated in the following sections.
In addition, if device enrolment is not properly restricted, attackers may be able to register their own devices and have them marked as compliant, effectively bypassing intended controls. Compliance should therefore not be treated as a standalone security boundary.
Hybrid Azure AD joined devices
In hybrid environments, devices may be Hybrid Azure AD joined. While this provides identity integration with Entra ID, it does not by itself guarantee that the device is compliant or meets security requirements. Without Intune enrolment or another form of device management, these devices still lack a reliable compliance signal.
Unmanaged devices
Unmanaged devices, on the other hand, provide little to no trustworthy information about their state. Their configuration and security posture are unknown, and any access granted to them is effectively based on assumption rather than verification.
Allowing full access from such devices introduces a blind spot in the access model. The goal is not necessarily to block them entirely, but to ensure that access is limited and controlled based on the level of trust that can be established, using mechanisms such as session restrictions and application-level controls.
Device trust and token theft (AiTM)
A common assumption is that once MFA is enforced and identity risk is low, access is sufficiently protected. In practice, this is not always the case.
In multiple incidents we have worked on, attackers used Adversary-in-the-Middle (AiTM) techniques to capture session cookies and, in some cases, tokens after successful authentication. These session artifacts, originating from an already authenticated session, act as bearer credentials and allow attackers to operate as the user without performing authentication again. If no device-based restrictions are used, attackers may be able to refresh their access to maintain access to the compromised account.
This highlights a fundamental limitation: authentication can be valid, while the session itself is compromised.
Device-based controls help reduce this gap. If Conditional Access is configured to require managed and compliant devices, tokens and session cookies are only issued when authentication satisfies device-based conditions. This ensures that access is initially tied to devices that meet defined security requirements.
Token Replay and Token Protection
Even with device compliance and endpoint protection in place, a key limitation remains: access and session tokens can be reused after they are issued. This is the core weakness exploited by AiTM phishing and token theft.
To address this, Microsoft introduced Token Protection. Token Protection binds access tokens (in supported scenarios) to the device they were issued on. If a token is intercepted and replayed from another device, authorization fails, even if authentication was successful.
Without token protection, a stolen token can be reused from anywhere. With token protection, the token is only valid on the original device. It is important to note that AiTM attacks can still capture tokens and initiate sessions. However, token protection makes those tokens significantly less useful outside of the original device context.
Combined with device compliance and endpoint risk signals, this provides a layered approach where access is no longer based solely on a valid token, but also on where and how that token is used.
As shown in the screenshot, Token Protection only works with supported applications, such as Exchange Online, SharePoint Online, and Microsoft Teams. Support for Windows devices is in General Availability, while support for iOS / iPadOS and macOS is currently in preview. Additionally, Token Protection only works on native applications (browser-based apps are not supported).
More information can be found here: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection
Conditional Access and Enforcement
At this stage, access decisions can require not only a trusted identity, but also a compliant and low-risk device.
This significantly reduces the attack surface. Even if credentials are valid and MFA has been satisfied, access from an untrusted or compromised device can still be denied.
However, it is important to understand the enforcement boundaries. Conditional Access evaluates conditions at the moment a token is issued or refreshed. It does not provide full continuous control over an active session.
Token Protection partially addresses this limitation by binding tokens to the device they were issued on, preventing their reuse from another device. However, it does not continuously re-evaluate device compliance or session context during the lifetime of a session.
This means that device trust must be part of a broader design, not treated as a standalone control. We will see in a next blog post of the series how Continuous Access Evaluation can be used to act on active sessions.
Bring Your Own Devices (BYOD)
While enforcing managed devices and Token Protection represents the preferred security posture, many organizations must still accommodate unmanaged devices in Bring Your Own Device (BYOD) scenarios. In these cases, the objective shifts from establishing full trust to limiting exposure.
Instead of granting full access, organizations can enforce restricted access patterns. This can include browser-based access, session restrictions, or mobile application management (MAM) controls.
In Conditional Access, this can be achieved by enabling “Use app enforced restrictions”, which allows supported applications such as SharePoint Online and Exchange Online to apply additional controls based on the device state.
The goal is to maintain usability while ensuring that sensitive data is not exposed to devices that cannot be fully trusted. However, we recommend to always prefer the use of managed devices, BYOD should be avoided or only used when required.
Exchange Online
In Exchange Online, organizations can restrict how users on unmanaged devices interact with email attachments. These restrictions can be applied using mailbox policies and allow organizations to prevent users from downloading attachments, reducing the risk of data leakage or storage on untrusted devices.
The following example shows how to block users from viewing attachments from unmanaged devices:
If the user tries to access an email with an attachment, they will see that they cannot view, download, or print attachments from this device or browser:
SharePoint Online
In SharePoint Online (SPO), restrictions can be configured from: SharePoint Online admin centre → Policies → Access control → Unmanaged devices:
Note that this policy applies tenant-wide. More granular restrictions can be applied at the site level using the SharePoint Online Management Shell. For example, the following command blocks access from unmanaged devices to a specific SharePoint site or OneDrive account:
Set-SPOSite -Identity https://<SharePoint online URL>/sites/<name of site or OneDrive account> -ConditionalAccessPolicy BlockAccess
Additional configuration allow more granular control such as permitting web-only editing, or downloads for files that can't be previewed.
More information can be found here: https://learn.microsoft.com/en-us/sharepoint/control-access-from-unmanaged-devices
Conclusion
While identity remains the absolute foundation of a Zero Trust architecture, relying on it alone is no longer sufficient. The devices connecting to your environment introduce a critical dimension to access decisions; an unmanaged, misconfigured, or actively compromised endpoint poses a severe risk, even if the user’s initial authentication and MFA were perfectly valid.
To reduce blind trust and limit the risk of token misuse from untrusted endpoints, organizations must move beyond static assumptions. By layering device compliance, endpoint risk signals, Conditional Access restrictions, and Token Protection, access to Microsoft 365 can be based on verifiable conditions rather than implicit trust.
In the next post, we will build on this foundation by introducing application context, and how access requirements can be adapted depending on what is being accessed.
Let's Connect
Are you in need of assistance from our Cloud Experts, or want to discuss how these principles apply to your organization? Don't hesitate to fill out the contact form below!