Category filter
Step-up Authentication: Balancing Security with User Productivity
1. The Zero-Trust Philosophy
The modern security perimeter is no longer the corporate network—it is the user’s identity and their endpoint device. Legacy security models annoy users by prompting for Multi-Factor Authentication (MFA) every single time they log in, regardless of context.
Adaptive MFA (or Step-Up Authentication) changes this by acting as the “Intelligence” layer of a Zero-Trust architecture. In this model, the Unified Endpoint Management (UEM) system acts as a real-time health sensor. It constantly monitors the device’s posture: Is the OS updated? Is the firewall active? Is the device encrypted?
If the device is healthy and compliant, the Identity Provider (IdP) grants seamless Single Sign-On (SSO). If the device “drifts” into an unhealthy state or is completely unmanaged, the IdP dynamically “steps up” the security requirement—forcing an MFA challenge or blocking access entirely until the device is fixed.
2. Supported Architectures
Hexnode UEM currently integrates directly with the industry’s leading IdPs to broker compliance data and enforce Zero-Trust:
- Microsoft Entra ID: Uses “Partner Device Management” to sync Hexnode compliance flags directly into Entra Conditional Access policies.
- Okta: Uses “Okta Device Trust” (via Okta Identity Engine) to verify if a device is actively managed by Hexnode before granting access.
Part A: Configuring Microsoft Entra ID (Conditional Access)
Prerequisites:
- Microsoft Entra ID Premium P1 or P2 license.
- Devices must use the Microsoft Authenticator app (mobile) or be Entra Joined (desktop) to register their identity.
Step 1: Establish the Compliance Partnership
Before Hexnode can send data, Microsoft must be configured to accept it. Log in to the Microsoft Intune Admin Center, navigate to Tenant administration > Partner device management, and add Hexnode for your target platforms. Then, in the Hexnode console, go to Admin > Integrations > Microsoft Entra ID and enable the Conditional Access sync.
Step 2: Define Compliance Rules in Hexnode
You must define exactly what makes a device “Healthy” or “At-Risk.”
- In the Hexnode console, navigate to Policies > Compliance Policies.
- Click New Policy and provide a Policy Name.
- You will be presented with two distinct configuration paths:
- Basic Settings: Select from predefined toggles for common vulnerabilities. For example, you can flag a device as non-compliant if it is Not password compliant, Not encrypted, Jailbroken/Rooted, or if it moves outside a designated Geofence.
- Advanced Settings: Use granular controls to define custom compliance rules based on specific device attributes. You can use AND / OR logical operators here (e.g., Device will be non-compliant if OS Version is below 15.0 OR FileVault is disabled).
- Save and associate this policy with your target devices. Hexnode will now actively evaluate the fleet against these rules.
Step 3: Configure Conditional Access (Entra ID)
Log in to the Microsoft Entra Admin Center and navigate to Security > Conditional Access. Create a new policy targeting your core apps (like Office 365). Under the Grant section, select Require device to be marked as compliant. Healthy devices will pass through; unhealthy devices will be blocked with a remediation prompt.
Part B: Configuring Okta Device Trust (Okta Identity Engine)
Prerequisites:
- Okta Identity Engine (OIE) tenant.
- The Okta Verify app must be deployed to devices via Hexnode.
Step 1: Enable Endpoint Management in Okta
Log in to the Okta Admin Console. Navigate to Security > Device integrations. Click Add endpoint management, select your platform (e.g., iOS, Windows), and choose the specific certificate or management key setup required to prove the device is managed by an MDM.
Step 2: Deploy Okta Verify via Hexnode
For Okta to know a device is managed, the Okta Verify app needs a secret payload. In Hexnode, go to Policies > App Management > App Configurations. Select the Okta Verify app and input the specific management key (ManagementHint) generated by your Okta console. Deploy this to your devices.
Step 3: Build Okta Authentication Policies
In the Okta Admin Console, navigate to Security > Authentication Policies. Select an app (like Salesforce or Google Workspace) and add a rule. Set the Device State condition to Registered and Managed. You can now configure Okta to allow passwordless access for these managed devices, while forcing unmanaged devices to pass a strict MFA challenge.
3. Adaptive Security Logic Matrix
| Device Posture (Hexnode) | Network / Context | Authentication Result (Entra / Okta) |
|---|---|---|
| Managed & Compliant | Trusted Corporate IP | Seamless SSO (Access Granted) |
| Managed & Compliant | Public Wi-Fi / Remote | Standard MFA Challenge |
| Managed, Non-Compliant | Any Location | Access Denied (Device needs remediation) |
| Unmanaged / BYOD | Any Location | Blocked or Step-Up MFA Required |
4. User Experience & Troubleshooting
The End-User Remediation Workflow
When a user is blocked due to an unhealthy posture, they do not need to call the helpdesk immediately. Entra and Okta will display a customized block screen indicating the device is non-compliant. The user simply opens the Hexnode UEM app on their device, identifies the failing metric (e.g., “Firewall is disabled”), fixes it, and waits for Hexnode to sync the updated healthy status to the IdP.
Troubleshooting Sync Delays
There can be a short delay between a user fixing a compliance issue on their device and the IdP receiving the updated status from Hexnode. Users can manually click Scan Device from their Hexnode agent app to expedite the sync.
Troubleshooting Okta Unmanaged Errors
If Okta is treating a Hexnode-enrolled device as “Unmanaged,” the App Configuration payload likely failed to deploy. Verify in the Hexnode console that the Okta Verify app successfully received the ManagementHint key configuration.