What happens when a valid corporate identity is being used from a device the organisation does not control? <\/p>\n\n\n\n
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\u2019s security requirements, the access decision is missing an important piece of context. <\/p>\n\n\n\n
This is not simply a theoretical security concern. Verizon\u2019s 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<\/sup> 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<\/sup><\/p>\n\n\n\n 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\u202fwho\u202fis requesting access, but also\u202fwhat they are accessing it from. <\/p>\n\n\n\n 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<\/sup> <\/p>\n\n\n\n For a broader introduction to how Microsoft Intune supports device management, application management and compliance, read The Ultimate Guide to Microsoft Intune<\/a>.<\/p>\n\n\n\n The distinction between these two capabilities is important.\u202fCompliance assesses the device, while Conditional Access enforces the decision.\u202fIntune 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<\/sup> <\/p>\n\n\n\n The question therefore moves beyond <\/p>\n\n\n\n \u201cWho is accessing this data?\u201d <\/p>\n\n\n\n to\u202f <\/p>\n\n\n\n \u201cWhat device are they using, and can we trust it right now?\u201d\u202f <\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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. <\/p>\n\n\n\n This makes compliance more than an endpoint management control. It becomes a\u202fsecurity 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<\/sup> <\/p>\n\n\n\n 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<\/sup> <\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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 \u201cWhat happens when a device stops meeting those conditions?\u201d, because a compliance model is only useful if the resulting signal leads to an appropriate response.<\/p>\n\n\n\n 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. <\/p>\n\n\n\n 1<\/sup> Verizon,\u202f2025 Data Breach Investigations Report<\/em>, Verizon Business 2<\/sup> Palo Alto Networks,\u202fDevice Security Threat Report<\/em> 3<\/sup> Microsoft,\u202fUse compliance policies to set rules for devices you manage with Intune<\/em>, Microsoft Learn 4<\/sup> Microsoft,\u202fZero Trust deployment approach with Microsoft Intune<\/em>, Microsoft Learn 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. <\/p>\n\n\n\n If your organisation is reviewing device compliance, endpoint management or looking to strengthen data protection by ensuring only trusted devices have access, explore Insentra\u2019s Modern Device Management services.<\/strong><\/a>\u00a0\u00a0<\/p>\n\n\n\n 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<\/strong><\/a> to start the conversation<\/strong>.<\/p>\n\n\n\nIdentity is only part of the decision<\/h2>\n\n\n\n
Compliance becomes an access signal<\/h2>\n\n\n\n
Trust has to be current<\/h2>\n\n\n\n
Key considerations<\/h2>\n\n\n\n
\n
\n\n\n\n
https:\/\/www.verizon.com\/business\/resources\/reports\/dbir\/<\/a> <\/p>\n\n\n\n
https:\/\/www.paloaltonetworks.com\/resources\/infographics\/device-security-threat-2025<\/a> <\/p>\n\n\n\n
https:\/\/learn.microsoft.com\/en-us\/intune\/device-security\/compliance\/overview<\/a> <\/p>\n\n\n\n
https:\/\/learn.microsoft.com\/en-us\/intune\/fundamentals\/zero-trust-deployment<\/a> <\/p>\n\n\n\nWhere to Begin<\/h2>\n\n\n\n