Okta Device Trust: Verify Managed Devices Before Auth (2026)

Okta Device Trust allows you to confirm that a user’s device meets your security requirements before granting them access to applications.

Let’s see it in action. Imagine a user, Alice, trying to log into Salesforce from her laptop.

sequenceDiagram
    participant User
    participant Okta
    participant DeviceTrustAgent
    participant Salesforce

    User->>Okta: Initiates login to Salesforce
    Okta->>DeviceTrustAgent: Requests device verification
    DeviceTrustAgent-->>Okta: Device is managed and compliant (e.g., OS version, encryption)
    Okta-->>User: Presents Salesforce login prompt
    User->>Okta: Enters Salesforce credentials
    Okta->>Salesforce: Grants access based on successful auth and device trust
    Salesforce-->>User: Provides access to application

This flow hinges on the Okta Device Trust agent, installed on the user’s device. When a login attempt occurs, Okta signals the agent. The agent then checks the device against a pre-defined policy (e.g., is the OS up-to-date? Is disk encryption enabled? Is the device managed by Intune or Jamf?). If the device passes, the agent sends a signed assertion back to Okta. Okta then uses this assertion, along with the user’s credentials, to decide whether to grant access.

The core problem Device Trust solves is the "trusted network" fallacy. Historically, organizations assumed that if a login came from within their network, it was safe. With remote work and BYOD (Bring Your Own Device), this assumption is broken. Device Trust shifts the security focus from where the login originates to from what it originates. Is the device itself secure and compliant?

Here are the key components you’ll configure:

• Device Trust Policy: This is where you define the rules. You’ll specify attributes like operating system version, whether disk encryption is enabled, whether the device is managed by a specific MDM (Mobile Device Management) solution like Microsoft Intune or Jamf Pro, and even if certain security software is running. You can set these policies for different operating systems (Windows, macOS, iOS, Android).
• Okta Agent Configuration: The Device Trust agent needs to be deployed to your managed devices. For Windows and macOS, this is typically a lightweight agent. For mobile devices, it often leverages the MDM’s built-in capabilities or a dedicated app.
• Application Integration: Within your Okta application settings (e.g., Salesforce, Microsoft 365), you’ll enable Device Trust and link it to your specific Device Trust Policy. This tells Okta to enforce the policy for logins to that application.

Let’s say you want to ensure all macOS devices accessing your G Suite are running at least macOS Ventura (13.0) and have FileVault enabled.

1. Create a Device Trust Policy:

   • Navigate to Security > Device Trust > Device Trust Policies.
   • Click "Add policy."
   • Name it "macOS Ventura+ Encrypted Policy."
   • Under "macOS," set "Minimum OS version" to 13.0.
   • Under "macOS," toggle "Disk encryption" to "Enabled."
   • Save the policy.

2. Integrate with G Suite:

   • Navigate to Applications > Applications.
   • Find your G Suite application and click "Edit."
   • Go to the "Sign On" tab.
   • In the "Device Trust" section, check "Enable Device Trust."
   • Select your "macOS Ventura+ Encrypted Policy" from the dropdown.
   • Save the changes.

Now, any user attempting to log into G Suite from a macOS device will have their device checked. If the device doesn’t meet the OS version or FileVault requirements, Okta will block the login, even if the user enters their credentials correctly.

A critical aspect often overlooked is how Okta verifies the authenticity of the device assertion itself. The Device Trust agent doesn’t just send a simple "yes/no." It sends a cryptographically signed assertion. This signature is generated using a private key held by the agent and is verifiable by Okta using a corresponding public key. This prevents attackers from simply spoofing a compliant device response. The management of these keys, often tied to your MDM’s identity, is paramount.

The next step after establishing device compliance is often exploring conditional access based on network location or user risk.