How to Implement Compliance-Driven Conditional Access via Hexnode

1. Overview

This document outlines the configuration of Device Compliance-Driven Conditional Access by integrating Hexnode UEM with your Identity Provider’s (IdP) Conditional Access engine (e.g., Microsoft Entra ID or Okta). This architecture moves beyond static credential checks, ensuring that access decisions dynamically adapt to the real-time “Security Posture” and managed state of the user’s device.

Instead of a numerical score, Hexnode evaluates device telemetry against strict organizational benchmarks. If a device fails any parameter, its state flips to Non-Compliant, triggering the IdP to automatically block access or step-up authentication.

2. Compliance Calculation Components

Hexnode determines a device’s compliance state by evaluating telemetry from the Hexnode UEM agent. Failing any of the critical benchmarks below renders the device non-compliant:

(Note: “Impossible Travel” and heuristic risk calculations are handled natively by the IdP’s Identity Protection engine, working alongside Hexnode’s device telemetry).

3. Implementation Workflow

Step A: Configure Compliance Policies in Hexnode

1. Navigate to Policies in the Hexnode console and create a new compliance policy.
2. Define the exact conditions (e.g., OS version < 14.5, Jailbreak is Enabled, Device encryption is Disabled).
3. Apply the compliance policy to targeted device groups or users.

Step B: The “Signal” Handshake (IdP Integration)

For Microsoft Entra ID:

1. In Entra ID, configure Hexnode UEM as a Compliance Partner.
2. In the Hexnode Console, navigate to Admin > Integrations > Microsoft Entra ID and complete the tenant binding.
3. Hexnode will now push real-time device compliance statuses directly to Entra ID.

For Okta Device Trust:

1. In the Okta Admin Console, configure an API Service Integration for “Hexnode Device Trust”.
2. In Hexnode, navigate to Admin > Integrations > Okta Device Trust, and input the Okta Client ID and Secret.
3. Deploy the Okta Verify app via Hexnode to establish Okta FastPass trust on the endpoints.

Step C: Define Conditional Access Logic in the IdP

Log in to your IdP Admin Console (e.g., Microsoft Entra ID) and create a Conditional Access Policy:

• Target: All Users (with exclusions for Break-Glass accounts).
• Conditions: Device platform matches (macOS, iOS, Android, Windows).
• Require device to be marked as compliant: Grants access only if the device meets the compliance policies defined by Hexnode.
  • Optional IdP layered rule: Require MFA if the IdP detects high sign-in risk (e.g., unfamiliar location).

4. User Remediation & Feedback

To prevent unnecessary IT support tickets, end-users must be informed of why their access was halted.

• Notification Mechanism: Hexnode pushes a custom notification or email alert indicating non-compliance.
• Self-Service: If a login is challenged by Entra ID/Okta, the IdP displays a remediation message. For example: “Access denied. Your device is not compliant. Please open the Hexnode/Company Portal to view missing security updates (e.g., BitLocker is disabled).”

5. Security Guardrails

• Exemptions (Allowlisting): Exempt “Emergency Access” (Break-Glass) admin accounts from compliance-based Conditional Access policies within the IdP to prevent total organizational lockouts during API outages.
• Network Fencing: Pair Hexnode’s device compliance with the IdP’s network logic. Access to highly sensitive apps should require both a Hexnode-compliant device and an origin IP from a trusted corporate network or Global Secure Access gateway.

6. Troubleshooting

• Stale Compliance States: If a user resolves an issue (e.g., turns on the firewall) but is still blocked, the Hexnode agent may not have synced. Technicians can click Scan Device in the Hexnode portal to force an immediate telemetry update.
• IdP Sync Latency: There can be a slight propagation delay for the compliance state to update between Hexnode and Entra ID/Okta. Administrators can review the “Device Configuration Status” under Hexnode’s Okta integration page to verify SSO extension payloads.

7. Audit Logging

All compliance shifts and enforcement actions are heavily audited:

• Hexnode Dashboard: Under the Incidents and Action History tabs, IT can track when a device officially flipped to Non-Compliant and what triggered it (e.g., Device [SN: 9982] marked as Non-Compliant: Blocklisted app detected).
• IdP Sign-in Logs: The IdP logs record the blocked authentication attempt, specifying that the failure was due to the Conditional Access policy requiring a managed, compliant device.