What happens when a valid corporate identity is being used from a device the organisation does not control?
The identity may be legitimate and the user may be authorised, but that does not necessarily mean the endpoint can be trusted. If the device can access corporate data without meeting the organisation’s security requirements, the access decision is missing an important piece of context.
This is not simply a theoretical security concern. Verizon’s 2025 Data Breach Investigations Report found that 46% of compromised systems containing corporate logins were non-managed devices, with the analysis indicating that these devices were likely associated with BYOD or enterprise-owned devices being used outside permitted policy.1 Palo Alto Networks similarly found that 33% of devices observed on corporate networks were unmanaged in its analysis of more than 27 million devices, highlighting the gap that can exist between the devices organisations expect to control and the devices actually present in their environments.2
Identity is only part of the decision
Identity alone does not provide enough context to determine whether access is safe. A legitimate account can be used from an unmanaged, compromised or insecure endpoint, potentially giving that device access to the same corporate resources as a trusted and properly secured device. Modern access decisions therefore need to consider not only who is requesting access, but also what they are accessing it from.
This is where device compliance becomes an important part of the security model. Compliance policies provide a way to evaluate whether managed devices meet defined security requirements, including conditions such as operating system versions, encryption, password requirements and device risk. The resulting compliance state can then be provided to Microsoft Entra Conditional Access, allowing the organisation to use the current state of the device as part of its access decision.3
For a broader introduction to how Microsoft Intune supports device management, application management and compliance, read The Ultimate Guide to Microsoft Intune.
Compliance becomes an access signal
The distinction between these two capabilities is important. Compliance assesses the device, while Conditional Access enforces the decision. Intune can determine that a device does not meet the organisation’s requirements, but it is Conditional Access that can use that information to prevent the device from accessing protected resources.3
The question therefore moves beyond
“Who is accessing this data?”
to
“What device are they using, and can we trust it right now?”
The second question becomes increasingly important as users work from anywhere and corporate data is accessed across a growing range of corporate, personal and third-party devices.
A device that met security requirements when it was deployed may not remain compliant indefinitely. Security controls can be disabled, operating systems can become outdated, configurations can change or a device can develop a security risk after deployment. Compliance therefore provides a mechanism for evaluating the current state of the endpoint rather than assuming that a device remains trustworthy simply because it was trusted previously.
Trust has to be current
This makes compliance more than an endpoint management control. It becomes a security signal that can contribute directly to an access decision based on the current state of the device. Microsoft describes device compliance and Conditional Access as part of a Zero Trust approach in which access is explicitly evaluated rather than implicitly trusted, with device health and risk contributing to decisions about access to organisational resources.4
The model can also extend beyond relatively static compliance requirements. Microsoft Defender for Endpoint can provide device risk information that can be integrated with Intune and used alongside compliance and Conditional Access, allowing access decisions to respond to active security threats as well as configuration state. This creates a progression from asking whether a device meets a defined baseline to considering whether the device remains sufficiently trustworthy when access is requested.4
There is, however, a balance to find. Compliance policies that attempt to control every possible risk can create unnecessary disruption, increase support overhead and encourage exceptions that weaken the overall model. A more effective approach is to identify the security conditions that genuinely matter to the organisation and use those conditions to establish a practical definition of a trusted device.
For organisations looking to apply this approach, the starting point is understanding which devices can currently access corporate data and whether those devices are managed, unmanaged or operating outside the organisation’s intended policy. From there, define the minimum security conditions that need to be true for a device to be considered trusted, then align those requirements with Intune compliance and Conditional Access. The final question is “What happens when a device stops meeting those conditions?”, because a compliance model is only useful if the resulting signal leads to an appropriate response.
Key considerations
- Define what a trusted device means for your organisation. Focus on the security conditions that genuinely matter rather than attempting to enforce every possible control.
- Make access conditional on device security. Use compliance as a signal alongside identity and other risk indicators, with Conditional Access enforcing the appropriate response.
- Plan for when trust changes. A device that is compliant today may not be compliant tomorrow, so the model needs to define what happens when a device no longer meets the required conditions.
The goal is not to make every device pass every possible security check. It is to make access conditional on the security of the device being used, with the controls proportionate to the sensitivity of the data and services being accessed. Protecting corporate data is therefore no longer just about knowing who is accessing it, but also what they are accessing it from, whether that device can be trusted, and whether it remains trusted when access occurs.
1 Verizon, 2025 Data Breach Investigations Report, Verizon Business
https://www.verizon.com/business/resources/reports/dbir/
2 Palo Alto Networks, Device Security Threat Report
https://www.paloaltonetworks.com/resources/infographics/device-security-threat-2025
3 Microsoft, Use compliance policies to set rules for devices you manage with Intune, Microsoft Learn
https://learn.microsoft.com/en-us/intune/device-security/compliance/overview
4 Microsoft, Zero Trust deployment approach with Microsoft Intune, Microsoft Learn
https://learn.microsoft.com/en-us/intune/fundamentals/zero-trust-deployment
Where to Begin
Our team works with organisations to understand their current endpoint environment, compliance practices and operational challenges, and identify opportunities to strengthen data protection without creating unnecessary barriers to productivity. This can include reviewing how capabilities such as Microsoft Intune and Microsoft Entra Conditional Access can support a more consistent and controlled approach to device compliance and access. The focus is on understanding the problem first and then determining the approach that best aligns with the organisation’s requirements.
If your organisation is reviewing device compliance, endpoint management or looking to strengthen data protection by ensuring only trusted devices have access, explore Insentra’s Modern Device Management services.
Our team can help you assess your current environment, understand the challenges you are looking to solve and determine an approach that aligns with your security requirements and operational needs. Contact us to start the conversation.
