How to Integrate Okta and Workspace ONE for Unified Endpoint Management

How Okta and Workspace ONE UEM can work together to connect identity policy with device posture, covering the main integration patterns, rollout steps, testing checks, and governance decisions.

Identity and endpoint management now need to work from the same control model.

Okta gives organisations a central identity layer for authentication, MFA, app sign-in policy and user context.

Workspace ONE UEM gives endpoint teams control over device enrolment, configuration, compliance, certificates and app delivery. The integration becomes valuable when those two views meet: access decisions can consider both the user and the device.

For CISOs, CTOs, Security Directors and IAM leaders, this is where the project becomes more than a technical connection. A strong Okta and Workspace ONE design can reduce unmanaged access, improve the sign-in experience for trusted devices, and create clearer evidence for audit and incident review.

 

A note on Workspace ONE and Omnissa

Many teams still refer to Workspace ONE as VMware Workspace ONE. Current official documentation and technical guides now sit under Omnissa for Workspace ONE content, while Okta’s documentation also refers to “Omnissa Workspace ONE” in its current integration guides.

The product names and admin console labels may vary across tenants, contracts and documentation history, so teams should verify the exact naming in their own environment before configuration.

Okta’s desktop guide states that Workspace ONE Access is the identity component of Workspace ONE and that the Okta and Workspace ONE integration is configured through Workspace ONE Access. (help.okta.com)

 

What the integration should achieve

Users should access business applications from devices that meet the organisation’s security policy.

A good integration design should support 5 outcomes:

  1. Okta remains the primary identity control point for workforce applications.
  2. Workspace ONE UEM manages device enrolment, compliance, certificates and configuration.
  3. Workspace ONE Access can pass device posture into the authentication flow.
  4. Okta policies can distinguish between managed, unmanaged and non-compliant devices.
  5. Security and audit teams can see why access was granted, blocked or challenged.

Okta’s SAML-based desktop documentation states that the Workspace ONE integration evaluates whether devices are managed and compliant before users access sensitive applications. It also notes that the desktop integration is based mainly on SAML trust connections. (

 

Reference architecture

A typical enterprise architecture includes the following components:

Okta
Controls user authentication, app assignments, MFA, routing rules and app sign-in policies.

Okta Identity Engine
Adds newer device patterns such as Okta FastPass, Device Assurance and managed device checks.

Workspace ONE UEM
Manages device enrolment, device profiles, compliance rules, certificates, app deployment and device actions.

Workspace ONE Access
Connects Workspace ONE device context into identity flows. In the Okta integration, it can act as the Workspace ONE identity provider in selected authentication flows.

Okta Verify
Registers the device with Okta and supports Okta FastPass.

Applications
SaaS applications, SAML applications, WS-Fed applications, internal applications and mobile applications that need device-aware access policy.

 

Choose the right integration pattern

The right pattern depends on the tenant type, device platforms, application risk and existing architecture.

Pattern 1: Okta as the identity provider for Workspace ONE Access

Use this when you want users to access Workspace ONE, Workspace ONE Intelligent Hub and the Workspace ONE portal with the same Okta-driven sign-in policy used across the workforce estate.

This pattern gives users a consistent authentication experience. It also reduces policy duplication because Okta remains the main workforce identity layer.

Okta’s guide for configuring Okta as an identity provider for Workspace ONE Access describes creating a SAML 2.0 app in Okta, setting the SSO URL, Audience URI, Name ID format and application username mapping. (help.okta.com)

 

Pattern 2: Workspace ONE Access as an identity provider in Okta

Use this when device posture from Workspace ONE must influence access to Okta-protected applications.

In this model:

  1. The user attempts to access a protected application.
  2. The application redirects the user to Okta.
  3. Okta applies routing logic.
  4. Okta sends the request to Workspace ONE Access.
  5. Workspace ONE checks the device state.
  6. The result is returned to Okta.
  7. Okta completes the application sign-in decision.

For Windows and macOS, Okta’s documentation describes a flow where Okta routes the client to Workspace ONE based on routing rules, Workspace ONE checks compliance status, and Okta later validates the SAML assertion before issuing the SAML assertion to the application. (help.okta.com)

 

Pattern 3: Okta Identity Engine with FastPass and Device Assurance

Use this when the organisation is already on Okta Identity Engine or is planning a migration to it.

Okta FastPass is a phishing-resistant, passwordless authenticator that requires Okta Verify on the device. Okta states that FastPass supports Android, iOS, macOS and Windows. (help.okta.com)

Okta’s managed device documentation says a device can be treated as managed when it is registered through Okta Verify, managed by an endpoint management tool, and configured for device management in Security Device Integrations. It also says

Workspace ONE can deploy the mobile management hint and that desktop management attestation certificates can be deployed through an MDM solution. (help.okta.com)

Device Assurance then lets teams add device security checks into app sign-in policy rules. Okta’s documentation states that Device Assurance policies only take effect after they are included in app sign-in policy rules. (help.okta.com)

 

Pattern 4: Workspace ONE posture with Tunnel, APIs and automation

Use this when posture decisions must affect access beyond the first login.

Omnissa’s Tech Zone guide describes 3 optional integration options for device posture with Okta: Workspace ONE Access as an IdP authenticator, Workspace ONE Tunnel, and event notifications with automation through Okta Workflow. (Tech Zone)

This pattern can support stricter operational models. Example: if a device becomes non-compliant after access has already been granted, an automated workflow can update user or device state and influence the next access decision.

 

Step-by-step implementation plan

 

Step 1: Define the access policy model

Start with policy. Configuration should follow the access model.

Classify applications by risk:

  1. Tier 1: admin consoles, financial systems, HR systems, developer platforms, privileged tooling.
  2. Tier 2: collaboration tools, document repositories, CRM, internal portals.
  3. Tier 3: low-risk applications with limited data exposure.

 

Then define device requirements for each tier:

  1. Managed device required.
  2. Managed and compliant device required.
  3. Unmanaged access allowed with stronger MFA.
  4. BYOD allowed only for selected apps.
  5. Blocked access for rooted, jailbroken or non-compliant devices.
  6. Time-limited exceptions for business continuity.

This policy model should be agreed by IAM, security, endpoint, compliance and service desk teams before build work starts.

 

Step 2: Prepare Workspace ONE UEM

Workspace ONE UEM should have clean device data before it influences Okta access decisions.

Check:

  1. Device enrolment flows for Windows, macOS, iOS and Android.
  2. Device ownership status: corporate, BYOD, contractor, shared device.
  3. Compliance rules by platform.
  4. Certificate profiles and SCEP configuration.
  5. Required device profiles: passcode, encryption, OS version, disk security, mobile threat defence where used.
  6. Workspace ONE Intelligent Hub deployment.
  7. App deployment for Okta Verify.
  8. Reporting for managed, unmanaged and non-compliant devices.

A weak compliance model will create weak access decisions. Device rules should be specific enough to support security goals and practical enough for users to remediate.

 

Step 3: Prepare Workspace ONE Access

Workspace ONE Access sits in the identity path for several Okta and Workspace ONE integration models.

Prepare:

  1. Directory sync.
  2. User attributes and UPN matching.
  3. Workspace ONE Access Connector, where required.
  4. AirWatch Cloud Connector, where required for UEM integration.
  5. Authentication methods for desktop and mobile.
  6. Access policies for Okta-originated requests.
  7. A pilot group with test users and test devices.

Okta’s desktop requirements list a Workspace ONE Access tenant, Workspace ONE UEM tenant, Workspace ONE Access Connector and Workspace ONE Access AirWatch Cloud Connector. The same guide notes that ACC is required only when Workspace ONE UEM is used. (help.okta.com)

 

Step 4: Prepare Okta

Okta configuration depends on whether the organisation uses Classic Engine or Identity Engine.

For Classic Engine patterns, prepare:

  1. Okta org admin access.
  2. Device Trust for Workspace ONE.
  3. Identity Provider Routing Rules.
  4. SAML or WS-Fed app scope.
  5. Workspace ONE Access as an external IdP.
  6. Network zones where required.
  7. Pilot app assignments.

For Identity Engine patterns, prepare:

  1. Okta Verify deployment.
  2. FastPass configuration.
  3. Security Device Integrations.
  4. Managed device checks.
  5. Device Assurance policies.
  6. App sign-in rules.

For desktop Device Trust in the SAML model, Okta’s documentation lists Device Trust for Workspace ONE and Identity Provider Routing Rules as required Okta-side capabilities. (help.okta.com)

 

Step 5: Connect Okta and Workspace ONE Access

The SAML trust needs clean metadata exchange and exact attribute mapping.

At a high level:

  1. Create the Workspace ONE SAML app in Okta.
  2. Add the Workspace ONE Access Assertion Consumer Service URL.
  3. Add the Workspace ONE Access Entity ID.
  4. Set the Name ID format.
  5. Map the Okta username to the correct Workspace ONE user attribute.
  6. Add Okta metadata into Workspace ONE Access.
  7. Process the IdP metadata in Workspace ONE Access.
  8. Confirm the Name ID mapping.

Okta’s configuration guide uses SAML 2.0 and states that the application username can be set to Okta username, mapped to the User Principal Name in Workspace ONE. (help.okta.com)

 

Step 6: Configure Windows and macOS device trust

Desktop flows need careful routing design.

For Windows and macOS:

  1. Configure IdP routing rules in Okta.
  2. Scope the rule by application, platform and user group.
  3. Send selected authentication requests to Workspace ONE Access.
  4. Configure Workspace ONE Access conditional access policies.
  5. Use certificate authentication and device compliance methods where required.
  6. Test SP-initiated application flows.

Okta’s desktop guide states that this integration supports only SP-initiated authentication flows and that IdP-initiated flows, such as selecting SAML apps from the Okta End User Dashboard, are not supported in that model. (help.okta.com)

Okta’s desktop policy documentation also states that, for desktop devices, administrators configure IdP routing rules in Okta and conditional access policies in Workspace ONE Access. It says Device Compliance can be used as the second-factor authentication method in Workspace ONE Access access policies. (help.okta.com)

 

Step 7: Configure iOS and Android device trust

Mobile flows differ from desktop flows.

For iOS and Android:

  1. Configure the Workspace ONE identity provider in Okta.
  2. Configure device trust and routing in Okta.
  3. Use Mobile SSO for iOS or Android in Workspace ONE Access.
  4. Return device trust status to Okta.
  5. Apply Okta access policy decisions based on the device trust result.
  6. Test managed, unmanaged and non-compliant device states.

Okta’s mobile guide states that for iOS and Android, device posture policies are configured in Okta and evaluated when the user logs in to a protected application. The same guide describes Workspace ONE returning device trust status to Okta after Mobile SSO authentication. (help.okta.com)

 

Step 8: Deploy Okta Verify and FastPass through Workspace ONE UEM

For Identity Engine designs, Workspace ONE UEM can distribute Okta Verify as a managed app.

Okta’s FastPass FAQ says admins can deploy Okta Verify to devices as a managed app. When users add an account in Okta Verify, the device is registered in Okta Universal Directory, and Okta Verify detects management certificates to attest that the device is managed or trusted. (help.okta.com)

 

Recommended rollout sequence:

  1. Deploy Okta Verify to the pilot group through Workspace ONE UEM.
  2. Ask users to enroll the device in Okta Verify.
  3. Confirm device registration in Okta.
  4. Confirm managed status.
  5. Enable FastPass for selected apps.
  6. Add Device Assurance checks.
  7. Expand by group and device platform.

 

Step 9: Test every access path

Do not test only the happy path.

Build a test matrix across:

  1. Windows managed and compliant.
  2. Windows managed and non-compliant.
  3. macOS managed and compliant.
  4. macOS without certificate.
  5. iOS managed with Mobile SSO.
  6. Android managed with Mobile SSO.
  7. BYOD device.
  8. Unmanaged browser access.
  9. User with Okta Verify enrolled.
  10. User without Okta Verify enrolled.
  11. App launched from the service provider.
  12. App launched from Okta dashboard.
  13. App launched from Workspace ONE catalog.
  14. Lost device.
  15. Retired device.
  16. User moved to another group.
  17. User removed from app assignment.

Record the result of each test. The useful output is a clear access decision, a clear user message and a clear remediation path.

 

Step 10: Move from pilot to production

A production rollout should happen in controlled waves.

Recommended order:

  1. IT and IAM teams.
  2. Security team.
  3. Low-risk business group.
  4. A group using a high-value app.
  5. Executive users.
  6. Broader workforce.

Keep the first production policy narrow. Start with 1 or 2 applications and a defined user group. Expand only after the team has reviewed logs, helpdesk tickets, user messages and exception requests.

 

Common implementation mistakes

Treating the integration as a simple SSO project
SSO is only one part of the design. The bigger security value comes from adding device state to access decisions.

Applying one policy to every application
Admin consoles, HR systems and collaboration tools carry different risk. They should not share the same device posture rule by default.

Blocking enrolment paths
If users need a trusted device to access the enrolment journey, the rollout will break. Keep enrolment and remediation paths available.

Ignoring platform differences
Windows, macOS, iOS and Android do not behave the same way in the Okta and Workspace ONE integration. The desktop SAML flow and mobile Mobile SSO flow need separate validation.

Skipping certificate lifecycle planning
Certificates expire, rotate, fail deployment and get removed during device rebuilds. The access model must include certificate lifecycle handling.

Forgetting user support
A blocked user needs a clear explanation. “Access denied” creates tickets. “Your device must be enrolled in Workspace ONE. Start here” reduces confusion.

 

Governance model for IAM and endpoint teams

A unified Okta and Workspace ONE design changes ownership boundaries.

Define who owns each decision:

  1. IAM owns authentication policy, app assignments, MFA and routing rules.
  2. Endpoint teams own device enrolment, UEM profiles, compliance and certificate deployment.
  3. Security owns risk rules, exception standards and monitoring.
  4. Compliance owns evidence requirements.
  5. Service desk owns user remediation guidance.
  6. Application owners approve policy changes for high-value apps.

This operating model matters. Without it, access failures become difficult to diagnose because every team sees only part of the decision.

 

KPIs to track after deployment

Track adoption, security impact and operational load.

Recommended KPIs:

  1. Percentage of workforce devices enrolled in Workspace ONE UEM.
  2. Percentage of devices compliant by OS.
  3. Percentage of protected app sign-ins from managed devices.
  4. Blocked sign-ins caused by unmanaged devices.
  5. Blocked sign-ins caused by non-compliant devices.
  6. Okta Verify enrolment rate.
  7. FastPass adoption rate.
  8. Device Assurance policy hit rate.
  9. Number of active exceptions.
  10. Average age of exceptions.
  11. Helpdesk tickets linked to device trust.
  12. Time to remediate non-compliant devices.
  13. Failed certificate deployment rate.

These metrics give leadership a practical view of whether the integration is improving control without adding avoidable friction.

 

How Cloudcomputing supports this integration

Cloudcomputing works with organisations that need identity, device management and security controls to operate together.

For Okta and Workspace ONE programmes, Cloudcomputing can support:

  1. Current-state assessment across Okta, Workspace ONE UEM and Workspace ONE Access.
  2. Architecture design for Classic Engine or Identity Engine.
  3. Device trust and Device Assurance policy design.
  4. Workspace ONE UEM compliance model review.
  5. Okta Verify and FastPass rollout planning.
  6. Pilot build and validation.
  7. Production migration by group, platform and application.
  8. Exception and remediation process design.
  9. Audit evidence model for IAM, EUC and security leadership.

The value is in the operating model as much as the technical configuration. A well-built integration gives security teams a reliable answer to a high-pressure access question: should this user, on this device, under this condition, access this application now?

 

Final thought

Okta and Workspace ONE can give organisations a stronger access model when identity and endpoint posture are designed together.

The priority is to make access decisions more specific. User identity, device management status, compliance, application risk and authentication method should all contribute to the decision.

For enterprise security teams, that creates better control. For users on trusted devices, it can also create a cleaner sign-in experience.

Cloudcomputing Acquires Innovate IT Ltd

Innovate IT Ltd is a UK specialist with 20 years experience in identity, access management and cloud security. This acquisition strengthens our ability to support clients across the full identity lifecycle – and specifically across the Okta ecosystem.

Read our CEO’s point of view