Hey folks! We currently use Microsoft Entra ID for SSO across our cloud apps, which works great, but we have a glaring security gap. Right now, as long as an employee has valid credentials (and MFA), they can log in. The problem is, they can do this from devices that are totally unpatched, have BitLocker disabled, or even have blocklisted apps installed. We need a way to completely block access to our corporate data if the device’s security posture is compromised. Has anyone successfully set up a workflow where the actual health of the device dictates whether they get access to cloud apps?
How can i set access to cloud apps based on health of the device?Solved
Replies (3)
I guess you’re looking for compliance-driven conditional access. What you do is integrate Hexnode directly with Entra ID. Instead of relying on static credential checks, you set up strict compliance policies in Hexnode, like requiring minimum OS versions, ensuring encryption is active, and checking for root/jailbreaks. If a device fails any of these benchmarks, Hexnode instantly flips its state to Non-Compliant. Because of the integration handshake, Entra ID catches that real-time signal and automatically blocks the login or steps up authentication. It acts as a great automated enforcer! One thing to consider though before rolling it out: how do you plan on handling user remediation when they fix an issue but get caught in a sync delay?
That sounds nice. I hadn’t even thought about the sync delay yet. I can already picture the flood of IT tickets: “I turned BitLocker back on like the prompt said, but I still can’t get into my email!” How do you handle that latency between Hexnode and Entra ID so users aren’t left stranded? Also, to clarify the setup, do I configure the actual block/grant rules inside Hexnode, or do I do that in Entra ID? I’m a little fuzzy on how the two platforms divide the labor.
It can be a bit confusing at first! Think of it this way: Hexnode is the “truth-teller” and Entra ID is the “bouncer.” You define your compliance benchmarks (the telemetry checks) inside the Hexnode console. Then, you log into your Entra ID Admin Console to build the actual Conditional Access Policy. In Entra, you just set a condition that says, “Require device to be marked as compliant” to grant access.
As for the sync delay, it’s usually just a slight propagation lag between the two APIs. When a user remediates an issue but is still blocked, we have our helpdesk jump into the Hexnode portal and hit the Scan Device button for that endpoint. It forces an immediate telemetry update, pushing the fresh, compliant state over to Entra ID to unlock their access right away. Oh, and one massive pro-tip: make sure to use Entra ID to exempt a “Break-Glass” emergency admin account from these policies! If there’s ever an API outage between the platforms, you don’t want your entire IT team locked out of your tenant.