What checks are you using to ensure only healthy devices get access?Solved

We started with compliance rules. Things like minimum OS version, encryption status, and root/jailbreak detection are all enforced through policy. If a device doesn’t meet any of these conditions, it gets flagged right away as non-compliant. 

Rooted or jailbroken devices were a major concern for us. Even if the user is verified, a compromised device shouldn’t be trusted. That’s really where Zero Trust becomes important. 

Encryption was a big one for us too. We made FileVault on macOS and BitLocker on Windows mandatory. If encryption is turned off or not configured, the device is automatically marked non-compliant, so it can’t access corporate resources. 

Once a device is marked non-compliant, what do you usually do? Do you handle that manually or let Hexnode take care of it? 

We’ve automated most of it. Hexnode marks the device as “Non-compliant” and we link that status to access control. So, the moment a device fails a compliance check, access to corporate apps or data is restricted automatically. 

We also enabled periodic scanning. Devices are checked at regular intervals, not just during enrollment. So, if something changes later, like OS downgrade or encryption being turned off, it gets picked up quickly. 

That continuous monitoring part really helps. Without it, devices can drift out of compliance over time. With regular checks, device health is validated continuously instead of relying on a one-time check. 

Makes sense. So, it’s more like ongoing validation instead of a one-time check during enrollment. 

Exactly. Identity alone isn’t enough. In a Zero Trust setup, device health plays an equal role. If either the user identity or the device compliance fails, access shouldn’t be granted. 

We also tied compliance status to app access. Only compliant devices can access managed apps or corporate resources, which adds another layer of control on top of the policies.