Steve The Identity Guy

Workspace ONE Access provides a powerful conditional access engine that factors in both user and device information when permitting access to your enterprise resources.  In this blog, I’m going to walk through some of the best practices for setting up access policies to ensure you are getting the proper balance of security and user experience.  Access Policies will determine how users are authenticated and under which conditions there might be alternative forms of authentications, such as multi-factor authentication.  I have spent a lot of time talking to VMware Professional Services, Customer Success, R&D and Product Management to come out with a guideline to help you get started configuring your Access Policies.

Before we get into the recommendations on setting up your access policies, I want to explain some key concepts and definitions, especially around device types.

• Device Types
  • Device Enrollment
  • Windows Enrollment
  • iOS
  • iPad
  • Android
  • Windows 10
  • MacOS
  • Web Browser
  • Workspace ONE App or Hub App
• Fallback Authentication Mechanisms
  • Primary Authentication Failures
  • Allowed Authentication Methods used in 3rd Party IDP
  • Allowed Authentication Methods used to validate a session token
  • Step-up authentication for Device and Login Risk Score.
• Managed Devices vs Unmanaged Devices
• Device Compliance
• Network Ranges
• High-Level Map of Policy Management
• Username Identification
• How Policies are Evaluated
• Recommendation for your Access Policies
  • Default Access Policy Set
  • Workspace ONE UEM
  • High Security Applications
  • Low Security Applications
  • Okta/Ping/ADFS Low Security
  • Okta/Ping/ADFS Medium Security
  • Okta/Ping/ADFS High Security
  • Horizon/Citrix
    

Device Types

In this section, we are going to cover some of the various device types in Workspace ONE Access SAAS Environments.  Please note that on-premises environments may not have all the device types listed in this section.

A device type refers to a grouping or categorization of devices based on common identifiers such as the operating system or based on action, such as enrolling your device into Workspace ONE UEM.  In most cases, you will notice that you can match multiple device types, depending on the context.  We will walk through several illustrations of this and how ordering your policy rules are critical to ensure the integrity of your policy definition.

Device Enrollment

The Device Enrollment type is referring to an authentication request from the Workspace ONE Intelligent Hub Application during enrollment only.   This is something that is available on the default policy (we will discuss default and application-level policies later in this blog). We typically want to perform a high level of assurance when enrolling a device into Workspace ONE UEM.  It is recommended that we configure Multi-Factor Authentication for device enrollment.

After you have successfully enrolled your device and after a configured period of time (we will discuss time-outs later in this blog), you will be prompted to re-authenticate again when launching the Intelligent Hub. When this re-authentication happens, it will NOT match against the Device Enrollment type but will match against your normal device type (e.g., Android, IOS etc.).

What’s included?

• Enrollments originating from the Workspace ONE Intelligent Hub

What’s Not Included?

• Web Enrollment
• DEP Enrollment with Custom Enrollment Enabled and Authentication ON
• DEP Enrollment with Custom Enrollment Disabled and Authentication ON (UEM Authentication)
• DEP Enrollment with Custom Enrollment Disabled and Authentication OFF (Staging)
• AAD Joined Windows 10 Enrollments

Windows Enrollment

This device type refers to a Windows Enrollment using an Azure Active Directory (AAD) joined Windows 10 device. This AAD joined enrollment can originate from an OOBE flow or from Windows 10 Settings.  Please note that Windows Workplace Join will not match this device type.

If you are using a broker architecture, which means you have another IdP before Workspace ONE Access in the authentication flow, this device type may not work depending on the IdP configuration.  This will work with ADFS and Okta (using routing rules).  This will not work with Ping Federate.

What’s included?

• Windows 10 AAD Join – OOBE
• Windows 10 AAD Join – Settings

What’s Not Included?

• Windows 10 Workplace Join (School or Work) -OOBE
• Windows 10 Workplace Join (School or Work) – Settings
• Enrollments originating from the Workspace ONE Intelligent Hub
• Enrollments originating from Dell Out-of-Box Experience Process

iOS

The iOS device type will match iPhones and iPad devices.  In SAAS environments only, this will match iPads (and iPhones) regardless of whether the “Request Desktop Sites” in Safari settings is enabled or not. At the time of writing this blog, this functionality is not available in on-premises environments, you will need to configure a MacOS policy to match iPads (and iPhones) with “Request Desktop Sites” enabled (default setting for iPads).

What’s included?

• iPhones
• iPads (SAAS ONLY)

What’s Not Included?

• Everything else.

iPad

The iPad device type is currently available in SAAS environments and will allow you to identify an iPad regardless of whether the “Request Desktop Sites” in Safari settings is enabled or not.  You should only use this device type if you want to provide a separate policy from iPhones as the IOS policy works for both device types.

NOTE: At the time of writing this blog, this functionality is not available in on-premises environments, you will need to configure a MacOS policy to match iPads with “Request Desktop Sites” enabled (default setting).

What’s included?

• iPads (SAAS ONLY)

What’s Not Included?

• iPhones
• Everything else.

Android

The Android Device type will match all your Android Devices.

What’s included?

• Android Enterprise
• Android Legacy (Device Admin)
• Samsung Knox
• Rugged (e.g., Zebra, Honeywell etc.)

What’s Not Included?

• Everything else.

Windows 10

The Windows 10 device type will allow you to create policies specific to Windows 10.

What’s included?

• Windows 10 Devices

What’s Not Included?

• Windows 8 and below.
• Everything else.

MacOS

The MacOS device type will allow you to create policies specific to MacOS. For on-premises environments, you will need to use the MacOS device type to identity iOS devices with the “Request Desktop Site” in Safari settings enabled.

With the recent updates to support iPads (in SAAS environments), a MacOS policy will NEVER match against an iPad or iPhone (regardless of the request desktop site on).

What’s included?

• MacOS
• iPad (On-Premises ONLY)

What’s Not Included?

• Everything else.

Web Browser

The web browser device type is typically used for web browser scenarios that don’t meet any of the above identified types. This would typically include both Chrome OS and Linux.  This device type can also act as a catch-all if the policy rule is high enough (in the ordering of policy rules).

What’s included?

• Chrome OS / Linux /Windows 10 / MacOS
• iOS/iPad – Only if the policy rule is above an iOS/iPad rule.
• Android – Only if the policy rule is above an Android rule.

What’s Not Included?

• None

Workspace ONE App or Hub App

The Workspace ONE App or Hub App device type is the most misunderstood device type and probably the most incorrectly configured device type as well, which is why I saved this one for last.

Let me start by saying

This device type is NOT used to authenticate users INTO the Workspace ONE Intelligent Hub application.  

The purpose of this device type is to provide a seamless user experience when launching applications from the Workspace ONE Intelligent Hub. This device type is used to validate your existing access token (from the Intelligent Hub) when you click on a Web or SAAS application in the Intelligent Hub Application.  

When you enrolled your device with the Workspace ONE Intelligent Hub, you received an OAuth2 Token from Workspace ONE Access. This access token contains both a timestamp and the method of authentication used at the time of enrollment (or re-authentication).

When you launch an application from the Intelligent Hub, Workspace ONE Access will:

1. First compare the method of authentication last used into the Intelligent Hub (either from Enrollment or Re-Authentication) to see if it matches any authentication methods listed on the Workspace ONE App or Hub App policy.
2. Secondly, it will compare the timestamp last used to authenticate into the Intelligent Hub to see if its within range of the “Re-authenticate After” setting in the Workspace ONE App or Hub App policy.

Let’s take a deeper look at what is happening in this policy evaluation.  When you first enrolled your device, you probably used a Password + MFA or you used a 3^rd Party IDP.   After successful enrollment, a Mobile SSO profile was pushed to your device for future authentication challenges.

The authentication token for the Workspace ONE Intelligent Hub has a default session lifetime of 90 days. This means you can go up to 90 days before re-authenticating into the Intelligent Hub again (using the Mobile SSO profile that was configured).   I should note the default configuration does have a 10-day idle TTL which will require the user to re-authenticate again if they have been idle for 10 days.  Please see my blog on changing these default values. https://theidentityguy.ca/2020/11/10/modifying-the-ws-intelligent-hub-timeouts/

Below is a common Workspace ONE App or Hub App policy rule:

Let’s assume during enrollment, I authenticated using a Password (cloud deployment) + DUO Security.  When a SAAS/Web application is launched from the Intelligent Hub, Workspace ONE Access will match my Password (cloud deployment) authentication method with one of the fallbacks listed and satisfy the first check I mentioned above.  I’ll talk more about fallbacks in the next section. 

The next validation is with the session time. How long ago did I authenticate into the Intelligent Hub? Based on default settings, that could have been up to 90 days (or 2160 hours) ago. The policy rule will never force a re-authentication (and trigger Mobile SSO) if you are within 2160 hours. To further illustrate this example, if you reduced the setting for “Re-authenticate after” to 8 Hours you will be prompted to re-authenticate on every app launch starting from 8 hours after enrollment because your session start time is based on the when you last authenticated into the Intelligent Hub Application and not the last time you authenticated for an application launch.  So, do you really need this policy? We’ll discuss this later in this blog on why this probably good for lower security application and not necessarily for high security applications. Without a Workspace ONE App or Hub policy, the user will be challenged with Mobile SSO on every application launch from the Intelligent Hub. Fortunately Mobile SSO provides a great user experience and this is all transparent to the user.

Fallback Authentication Mechanisms

Workspace ONE Access has a very flexible policy engine that allows you to specify an authentication method that can be used in case a previous authentication method fails.  However, in Workspace ONE Access, fallback authentication mechanisms serve multiple purposes depending on the configuration:

• Primary Authentication Failures
• Allowed Authentication Methods used in 3rd Party IDP
• Allowed Authentication Methods used to validate a session token.
• Step-up authentication for Device and Login Risk Score.

We are going to walk through each of these purposes in further detail:

Primary Authentication Failures

The use of an authentication method if the preceding authentication method fails is the most common use of fallback mechanisms.  In this scenario, when a primary authentication such as Mobile SSO is used (which will tell us if a device is managed) and fails (meaning the device is unmanaged or potentially managed but not compliant) we can configure another option that includes an alternative authentication plus MFA:

By configuring a fallback mechanism for Mobile SSO and Device Compliance, we are allowing unmanaged and non-compliant devices (or managed but not compliant) to access the applicable resources if they can successfully complete the Password + MFA that is defined in the fallback.

Its very important that you are aware that when configuring a fallback mechanism for Mobile SSO or Certificate Authentication that you are potentially allowing unmanaged and non-compliant access to your applications. We will discuss later the option of splitting these applications into different policies where some application will allow for fallbacks and some higher security applications will not.

The following primary authentication methods support using a fallback:

• Mobile SSO (iOS and Android)
• Certificate Authentication
• SAML (only if the SAML IDP supports a failure notification back to Workspace ONE Access)

The following secondary authentication methods support using a fallback:

• Verify (Intelligent Hub)
• Device Compliance (with Workspace ONE UEM)
• Login Risk Score

To illustrate this further, if you had a policy such as Password (Cloud Deployment) with a fallback of a 3^rd Party IDP.   A fallback to the 3^rd Party IDP will never happen as Password (Cloud Deployment) does not support having a fallback. There is one exception to this rule, Password (Local Directory) can be used as a fallback for Password (Cloud Deployment) to authenticate System Domain users.

Allowed Authentication Methods used in 3^rd Party IDP

When Workspace ONE Access receives the SAML Response from a 3^rd Party Identity Provider, it will include an “AuthNContextClassRef” that will tell Workspace ONE Access how the user was authenticated at the 3^rd Party Identity Provider.   Workspace ONE Access needs Authentication methods for each possible AuthNContextClassRef that the IdP sends.

As an example, when integrating with Microsoft Azure AD, its common for Azure to send any of the following:

• urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
• urn:oasis:names:tc:SAML:2.0:ac:classes:Password
• urn:federation:authentication:windows

In the 3^rd Party IDP configuration in Workspace ONE Access, you will need to define each of these SAML Authentication Methods/Context:

Since we don’t necessarily know how the user might be authenticated at the primary IdP, we need to include them as fallbacks in our policy as they provide Workspace ONE Access all the acceptable forms of authentication that should be allowed per our policy definition.

Allowed Authentication Methods used to validate a session token.

I touched on this briefly in the previous section on Workspace ONE App or Hub policy. When authenticating to Workspace ONE Access, a session cookie or OAuth2 Token is generated.  Inside this session cookie/token, you will see the method of authentication that was used at the time of cookie creation (e.g. “urn:vmware:names:ac:classes:CertificateService”).

Workspace ONE Access will compare the previously used authentication method to see if it matches ANY of the allowed authentication methods for the configured application. If it matches, there will be no further authentication (as long as it is within the allowed session time).

Here is example of this use case in action.

1. User logs into Workspace ONE Access using FIDO2 Authentication
2. User clicks on Salesforce Application
   1. Salesforce has a Policy: Primary Authentication=Certificate Authentication
3. Result: User is Prompted for Certificate Authentication
4. Result: User is Granted Access

Example 2:

1. User logs into Workspace ONE Access using FIDO2 Authentication
2. User clicks on Salesforce Application
   1. Salesforce has a Policy: Primary Authentication=Certificate Authentication and Fallback: FIDO2 Authentication
3. Result: User is Granted Access because the previously used authentication method (FIDO2 Authentication) matches one of the fallbacks.

Step-up authentication for Device and Login Risk Score.

If you are using User Risk Score or Login Risk Score, in the configuration of the Authentication Method you will define the appropriate action based on the result of the risk score calculation.

In your Authentication Policy, the fallback mechanism is considered your “Step-Up Authentication”. So, your policy would like something like this:

In the above policy, when Certificate Authentication is Successful, but Login Risk Score is coming back as Medium or High, it will fall back (or in this case Step-Up) to the next policy rule. We still must keep Certificate Authentication as the primary along with my MFA as the secondary.   Just keep in mind with this policy, if Certificate Authentication is not successful, you will return an Access Denied Error.  You might potentially require another fallback if you want to provide a “real” fallback.

Creating policies for User and Login risk score can get quite complicated. I plan on writing another blog dedicated to this configuration.

Managed Devices vs Unmanaged Devices

In Workspace ONE Access, a “Managed” device is determined by a successful Mobile SSO or Certificate- Based Authentication. In scenarios when Workspace ONE Access is sending the Device SSO Response in the SAML Response (i.e., Okta/Ping Integrations), the UDID (aka Device ID) needs to be provisioned by UEM as part of the SAN Attributes on the certificate.

Device Compliance

In order for Workspace ONE Access to check for Device Compliance, a valid certificate with the Device ID (in the SAN attributes) needs to be provisioned to the device. Device Compliance can ONLY be used in conjunction with Mobile SSO or Certificate Based Authentication because this is currently the only way for Workspace ONE Access to know what the Device UUID is in order to validate device compliance.

Network Ranges

Network Ranges in Workspace ONE Access can be used to separate out your policies.  Depending on which network they are coming from, you can define specific policies.  Many Workspace ONE Access tenants are cloud based within one of VMware’s Workspace ONE Access datacenters – and Network Range detection will see the device’s external IP. Workspace ONE Access On-Premises customers may also choose to use private IPs within Network Range detection, however it should be noted any of these packets crossing Internet boundaries – more specifically through Internet routers or proxies – will have the X-Forwarded-For header either stripped and potentially replaced as public routers and proxies will remove all X-Forwarded-For headers containing private IP addresses per Internet Protocols (Per RFC 7239 – https://tools.ietf.org/html/rfc7239).

High-Level Map of Policy Management

When you setup and configure your policies, keep this diagram in mind:

• Authentication Methods on an Access Policy are tied to an IDP Instance (either a built-in IDP, SAML, OIDC or Workspace ONE Access)
  • If you are doing Mobile SSO but Mobile SSO is not selected in your IDP instance, then your authentication will fail.
• IDP Instances are linked to one or more Directory Instances
  • If your directory where the users are created in Access are not selected in the IDP Instance, your authentication methods will fail.
• IDP Instances are linked to one or more Network Ranges
  • If the users are authenticating from a network range which is not selected in the IDP Instance, your authentication methods will fail.

If any link (as noted in the diagram above) is broken your authentication will fail.

Username Identification

When configuring your Access Policies, your users might get prompted to Identify themselves before they authenticate:

There are 2 reasons why this will happen. The most common reason is because you’ve added a group conditon in your Access Policy:

When you add a group condition, Workspace ONE Access will need the user to enter their username/email first to determine if they qualify for the group condition.  

The second reason for this is when you need to select your domain but you’ve hidden the domain chooser.  In Workspace ONE Access preferences, you can hide the domain drop-down and require users to select enter their username first. When you hide the domain chooser, Workspace ONE Access will ask for your username/email for all authentication methods except Mobile SSO and Certificate.  Please keep in mind that if multiple users share the same username/email, you will be prompted with the domain chooser.

How Policies are Evaluated

Workspace ONE Access Policies are evaluated from top to bottom. The policy will stop at the first match. In the below example,  a device type of Web Browser will prevent the policy engine from reaching macOS or Windows10 because it comes ahead in the processing order.

Recommendations for your Access Policies

In this section we are going to walk through the recommended approach to setting up your Access Policies. Your individual authentication methods might be different based on your own use cases and security requirements.

Disclaimer: The recommendations and guidelines posted here are based on feedback provided by customers and other internal/external professionals. They are offered as guidelines for your reference only and are not intended to represent the only approach to any particular use case. The guidelines posted here should not be construed as security advice, and users should seek appropriate security or other professional advice to address specific use cases and circumstances.

Access Policy	Purpose
Default Access Policy Set	• Workspace ONE Hub Enrollment • Workspace ONE Hub Re-Authentication • Workspace ONE Access Portal
Workspace ONE UEM	• Workspace ONE UEM Web Enrollment • Workspace ONE UEM DEP Enrollment
High Security Applications	• Applications that will require higher security (potentially Device Compliance, MFA, Login Risk)
Low Security Applications	• In this access policy, we will allow fallbacks for potentially less secure authentication methods such as Password. 3rd Party IDP can also be used.
Okta/Ping/ADFS Low Security	• In this access policy, we will allow fallbacks for potentially less secure authentication methods such as Password . 3rd Party IDP can also be used.
Okta/Ping/ADFS Medium Security	• In this access policy, we will configure Mobile SSO or Certificate-Based Authentication without any fallbacks. • Original Okta Device Trust
Okta/Ping/ADFS High Security	• In this access policy, we will configure Mobile SSO or Certificate-Based Authentication + Device Compliance without any fallbacks. • Factor-Based Okta Device Trust
Horizon/Citrix	• This is for your Virtual Apps

Default Access Policy Set

Your “Default Access Policy Set” will be used for the following purposes:

• Workspace ONE Hub Enrollment
• Workspace ONE Hub Re-Authentication
• Workspace ONE Access Portal

In Workspace ONE UEM, the configuration that is being used is set in Groups and Settings -> All Settings -> Devices & Users -> General -> Enrollment:

Device Type	Authentication Methods
Device Enrollment	This authentication method should include a Password + MFA. Alternatively, you can use a 3rd Party IDP that includes MFA.
Workspace ONE App or Hub App	As we mentioned previously, this device type is used to transfer your session from the Workspace ONE Hub to seamlessly access your SAAS applications. We recommend using this device type on your Low Security Application Policy. If you are using the External Access Token for the Dell out the box Experience, you will need this device type in the default policy. If you are not using the External Access Token, you don’t need this device type on your default policy. Please see VMware Documentation for more information on the External Access Token.
All Device Types (ANY)	If you are enabling FIDO2 Authentication, you should setup your policy rule here for registering your FIDO2 Authenticators by enabling the Registering FIDO2 Authenticator switch. Select your required authentication method to register your FIDO2 device.
iOS	This authentication policy should use Mobile SSO. If you want to allow a fallback for unmanaged devices, then you can choose a fallback authentication method. This will only get them into the Workspace ONE Access Portal or Hub Application.
Android	This authentication policy should use Mobile SSO. If you want to allow a fallback for unmanaged devices, then you can choose a fallback authentication method. This will only get them into the Workspace ONE Access Portal or Hub Application.
MacOS	Your MacOS Policy would ideally be configured with Certificate Based Authentication. If your MacOS devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Windows 10	Your Windows 10 Policy would ideally be configured with Certificate Based Authentication. If your Windows 10 devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Web Browser	This will be used by Chrome or Linux

Workspace ONE UEM

Your “Workspace ONE UEM” will be used for the following purposes:

• Workspace ONE UEM Web Enrollment
• Workspace ONE UEM DEP Enrollment
  • DEP Enrollment with Custom Enrollment Enabled and Authentication ON
  • DEP Enrollment with Custom Enrollment Disabled and Authentication OFF (Staging)

In Workspace ONE UEM, the configuration that is being used is set in Groups and Settings -> All Settings -> System -> Enterprise Integration -> Directory Services:

This also requires the AirWatch application to be configured in Workspace ONE Access:

Device Type	Authentication Methods
ANY	Given that this policy is used for web enrollment and DEP enrolment flows, you should make this policy rule similar to the Device Enrollment policy rule in the default policy.

High Security Applications

Your “High Security Applications” will be used for the following purposes: Applications that will require higher security (potentially Device Compliance, MFA, Login Risk)

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO and Device Compliance. We don’t recommend any fallbacks for your high security applications.
Android	This authentication should use Mobile SSO and Device Compliance. We don’t recommend any fallbacks for your high security applications.
MacOS	Your MacOS Policy would ideally be configured with Certificate Based Authentication + Device Compliance. We don’t recommend any fallbacks for your high security applications. If you want you use FIDO2 on your high security applications we recommend you also include Certificate Authentication + Device Compliance in your policy rule.
Windows10 Enrollment	If you are doing AAD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy or use a 3rd Party IDP. Note: This is required if O365 is included in this policy.
Windows 10	Your Windows 10 Policy would ideally be configured with Certificate Based Authentication + Device Compliance. We don’t recommend any fallbacks for your high security applications. If you want you use FIDO2 on your high security applications we recommend you also include Certificate Authentication + Device Compliance in your policy rule.
Web Browser	Your Web Browser Policy should be configured for Certificate Authentication for your Chrome OS devices.

Low Security Applications

Your “Low Security Applications” will be used for the following purposes:

• Applications that don’t require management or don’t require a high level of assurance.

Device Type	Authentication Methods
Workspace ONE App or Hub App	As we mentioned earlier in this blog, this device type is used to transfer your session from the Hub Application to Workspace ONE Access. You will need fallbacks for all possibilities: • Mobile SSO (ios) • Mobile SSO (Android) • Certificate Authentication • SAML (3rd Party IDP)) • Password Authentication Session time-out should also be set accordingly. See the section above on Workspace ONE App or Hub.
iOS	This authentication should use Mobile SSO. If you want to allow to allow a fallback for unmanaged devices, you can choose a fallback authentication.
Android	This authentication should use Mobile SSO. If you want to allow to allow a fallback for unmanaged devices, you can choose a fallback authentication.
MacOS	Your MacOS Policy would ideally be configured with Certificate Based Authentication. If your MacOS devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Windows10 Enrollment	If you are doing AAD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy or use a 3rd Party IDP.
Windows 10	Your Windows 10 Policy would ideally be configured with Certificate Based Authentication. If your Windows 10 devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Web Browser	This will be used by Chrome or Linux

Okta/Ping/ADFS Low Security

Your “Okta/Ping/ADFS Low Security” will be used for the following purposes:

• Application when configured with another IDP as a broker.
• Low Security Applications will typically allow for weaker authentication mechanism’s (such as Password Cloud Deployment)  or allow for a fallback mechanism.

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO. If you want to allow to allow a fallback for unmanaged devices, you can choose a fallback authentication. If you are sending the failure notification back to Okta/PING, do not configure a fallback.
Android	This authentication should use Mobile SSO. If you want to allow to allow a fallback for unmanaged devices, you can choose a fallback authentication. If you are sending the failure notification back to Okta/PING, do not configure a fallback.
MacOS	Your MacOS Policy would ideally be configured with Certificate Based Authentication. If you want to allow to allow a fallback for unmanaged devices, you can choose a fallback authentication. If you are sending the failure notification back to Okta/PING, do not configure a fallback. FIDO2 Authentication is also now available.
Windows10 Enrollment	If you are doing AAD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy or use a 3rd Party IDP. Note: This is required if Windows 10 (AAD) enrollments are expected through Okta/ADFS and if O365 is included in this policy. Note: For Okta, this will only work when configured with routing rules.
Windows 10	Your Windows 10 Policy would ideally be configured with Certificate Based Authentication. If you want to allow to allow a fallback for unmanaged devices, you can choose a fallback authentication. FIDO2 Authentication is also now available.
Web Browser	Your Chrome OS Policy should be configured with Certificate-Based Authentication.

Okta/Ping/ADFS Medium Security

Your “Okta/Ping/ADFS Medium Security” will be used for the following purposes:

• Applications when configured with another IDP as a broker.
• These policies will not use weak authentication methods (such as Password) and will also not allow for any fallbacks.
• This policy will be used by the Original Okta Device Trust integration.

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO. Do not configure a fallback authentication mechanism.
Android	This authentication should use Mobile SSO. Do not configure a fallback authentication mechanism.
MacOS	Your MacOS Policy should be configured with Certificate Based Authentication. Do not configure a fallback authentication mechanism.
Windows10 Enrollment	If you are doing AAD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy or use a 3rd Party IDP. Note: This is required if Windows 10 (AAD) enrollments are expected through Okta/ADFS and if O365 is included in this policy. Note: For Okta, this will only work when configured with routing rules.
Windows 10	Your Windows 10 Policy should be configured with Certificate Based Authentication. Do not configure a fallback authentication mechanism.
Web Browser	Your Chrome OS Policy should be configured with Certificate-Based Authentication.

Okta/Ping/ADFS High Security

Your “Okta/Ping/ADFS High Security” will be used for the following purposes:

• Applications when configured with another IDP as a broker.
• These policies will include a Device Compliance policy.
• These policies will not use weak authentication methods (such as Password) and will also not allow for any fallbacks.
• This policy will be used by the Okta Factor-Based Device Trust integration.

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO + Device Compliance. Do not configure a fallback authentication mechanism.
Android	This authentication should use Mobile SSO + Device Compliance. Do not configure a fallback authentication mechanism.
MacOS	Your MacOS Policy should be configured with Certificate Based Authentication + Device Compliance. Do not configure a fallback authentication mechanism. If you want you use FIDO2 on your high security applications we recommend you include Certificate Authentication + Device Compliance in your policy rule.
Windows10 Enrollment	If you are doing AAD Joins, this policy will be used to authenticate users when enrolling their Windows 10 devices. In this scenario, the device is not yet managed so you will have to use either a username + password plus MFA policy or use a 3rd Party IDP. Note: This is required if Windows 10 (AAD) enrollments are expected through Okta/ADFS and if O365 is included in this policy. Note: For Okta, this will only work when configured with routing rules.
Windows 10	Your Windows 10 Policy should be configured with Certificate Based Authentication+ Device Compliance. Do not configure a fallback authentication mechanism. If you want you use FIDO2 on your high security applications we recommend you include Certificate Authentication + Device Compliance in your policy rule.
Web Browser	Your Chrome OS Policy should be configured with Certificate-Based Authentication. Note: Currently Device Compliance is not available for Chrome OS.

Horizon/Citrix

Your “Horizon/Citrix” will be used for the following purposes:

• This is for your Virtual Apps

NOTE: When Horizon/Citrix sync new Applications/Desktops, they will have to be manually assigned this policy. New Applications will automatically get the default policy.

Device Type	Authentication Methods
iOS	This authentication should use Mobile SSO. If you want to allow to allow a fallback for unmanaged devices, you can choose a fallback authentication.
Android	This authentication should use Mobile SSO. If you want to allow to allow a fallback for unmanaged devices, you can choose a fallback authentication.
MacOS	Your MacOS Policy would ideally be configured with Certificate Based Authentication. If your MacOS devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Windows 10	Your Windows 10 Policy would ideally be configured with Certificate Based Authentication. If your Windows 10 devices do not have client certs, configure the appropriate authentication. FIDO2 Authentication is also now available.
Web Browser	This will be used by Chrome or Linux

I want to give a special thank you to the following for contributing to this best practices blog:

• Joe Rainone – PSO, VMware – https://www.virtualjpr.com/
• Dean Flaming – Customer Success, VMware – https://technotes.flaming.ws/
• Sean Hanrahan – Customer Success, VMware
• Matthiew Morin – Product Management, VMware
• Workspace ONE Access Product Management Team