Duo lets you reduce risks by enforcing precise policies and controls. Enable your team to define and enforce rules on who can access what applications — under what conditions. Define access policies by user group and per application to increase security without compromising end-user experience.
Duo Premier, Duo Advantage, and Duo Essentials plans customers gain granular control with the Policy & Control feature.
Policies are centrally-managed and can be applied...
Duo Free plan customers have limited access to Duo policies. Free plans may only control the New User Policy via a global or shared application policy. All other available application settings are configured at the individual application.
Create and manage your policies from the top-level Policies tab in the Duo Admin Panel.
Only admins with the Owner or Administrator roles can create or edit policies. Admins with the Application Manager role may assign existing policies to applications, but may not edit or create policies.
When creating policies that restrict access for users, keep in mind that users with bypass status are not subject to these restrictions, as they bypass Duo authentication entirely.
The Global Policy is built-in and cannot be deleted. It always applies to all applications, so you should edit this policy if there are settings you'd like to control for all users and all applications. A summary of the Global Policy settings is shown on the Policies page. Settings at the Duo defaults are greyed out.
Your Duo subscription level determines which policy options show up in the editor. For example, Duo Essentials receives a subset of the policy settings available to Duo Advantage and Duo Premier customers.
As you review the various policy settings in this document, note the Duo plans listed in the Available in information to determine if a setting applies to your subscription or not.
Role required: Owner or Administrator
To edit the Global Policy from the Policies page:
Click Edit Global Policy in the upper right of the Global Policy summary.
Once in the Global Policy editor, click the policy settings listed on the left side of the editor that you want to modify, then update the setting configuration on the right side of the editor.
Click Save Policy when your edits to the Global Policy are complete.
The Global Policy summary reflects your new policy settings (with your configured settings flagged as "Enabled").
If you'd like to restore the original Global Policy settings, open the Global Policy editor again and click the Revert to default link at the top of the "Edit Policy" window. Click Save Policy to apply the Global Policy defaults.
Changes to existing policy settings take immediate effect.
If certain applications require policy and controls that differ from the Global Policy, you can create a Custom Policy and assign it to those applications. Custom policies for an application can also be limited to specific groups. Custom Policies only need to specify the settings they wish to enforce.
Create custom policies for groups or applications from either the main Policies page or from the properties page of any application. Policies may be shared between multiple groups and applications.
When you view an application, the Global Policy settings are shown because these settings apply to all applications unless they are superseded by a custom application or group policy.
Settings configured and assigned by group policy can override settings assigned by an application policy, which in turn overrides settings in the Global policy. If an application policy or group policy setting supersedes a Global Policy setting, the superseded setting is crossed out in the Global Policy view shown when viewing an application. In the example below, the "HIPAA Policy" application policy settings (New User Policy, User Location, etc.) override those same settings in the Global Policy for that specific application.
Role required: Owner or Administrator
Admins with the Owner and Administrator role can create and assign a new custom policy right from an application's properties page. You can also create a custom policy for the self-service portal. To do this:
Navigate to an application's properties page in the Duo Admin Panel.
Click the Apply a policy to all users link to assign the policy to all users of that application.
Click the Or, create a new Policy link instead of selecting a policy to apply from the drop-down list.
The policy editor launches with an empty policy.
Enter a descriptive Policy Name at the top of the left column, and then click each policy item's name to add it to your new custom policy. Each item you click is added to the policy customization area on the right, where you can adjust the settings. Click the X on the right to remove a setting from the customization area.
When you are done adding and configuring policy settings, click Create Policy to save the settings and return to the "Apply a Policy" prompt.
Click Apply Policy. The application page shows the new policy assignment.
Role required: Owner or Administrator
Admins with the Owner or Administrator role can create a new custom policy and assign it to one or more Duo groups right from an application's properties page. To do this:
Navigate to an application's properties page in the Duo Admin Panel.
Click the Apply a policy to groups of users link to assign the policy to only certain users of that application
Click the Or, create a new Policy link instead of selecting a policy to apply from the drop-down list.
The policy editor launches with an empty policy.
Enter a descriptive Policy Name at the top of the left column, and then click each policy item's name to add it to your new custom policy. Each item you click is added to the policy customization area on the right, where you can adjust the settings. Click the X on the right to remove a setting from the customization area.
When you are done adding and configuring policy settings, click Create Policy to save the settings and return to the "Apply a Policy" prompt, with your newly created policy selected. Start typing in a group's name in the Groups field and select the policy target group(s) from the suggested names.
Click Apply Policy. The application page shows the new group policy assignment.
Role required: Owner or Administrator
To create a custom policy from the main Policies page:
Click New Policy.
The policy editor starts with an empty policy.
Enter a descriptive Policy Name at the top of the left column, and then click each policy item's name to add it to your new custom policy. Each item you click is added to the to the policy customization area on the right, where you can adjust the settings. Click the X on the right to remove a setting from the customization area.
When you are done adding and configuring policy settings, click Create Policy.
The Policies page lists the newly created policy. From the policies page you can edit or delete the custom policy by clicking the appropriate action.
Role required: Owner, Administrator, or Application Manager
To assign an existing custom policy to an application:
Navigate to an application's properties page in the Duo Admin Panel.
Click the Apply a policy to all users link to assign the policy to all users of that application.
Select the policy to apply from the drop-down list.
Note that admins with the Application Manager role do not see the "Or, create a new Policy" link visible to Owner and Administrator roles.
Click Apply Policy. The application page shows the new policy assignment.
Role required: Owner, Administrator, or Application Manager
To assign an existing custom policy to a group:
Navigate to an application's properties page in the Duo Admin Panel.
Click the Apply a policy to groups of users link to assign the policy to a specific group of users who access that application.
Select the policy to apply from the drop-down list. Then start typing in a group's name in the Groups field and select the policy target group(s) from the suggested names.
Note that admins with the Application Manager role do not see the "Or, create a new Policy" link visible to Owner and Administrator roles.
Click Apply Policy. The application page shows the new group policy assignment. Clicking the name of the policy group target displays the properties and members of the group.
Modify an existing custom policy's settings by clicking the Edit link shown to the right of the custom policy name on the main Policies page in the Admin Panel, or from the Policy section of an individual Duo application's details page. Make your desired changes in the policy editor, and then click Save Policy.
Changes to existing policy settings take immediate effect.
The policy framework applies custom group policy settings in the order they are listed in an application's Policy properties. When group policy settings conflict, the first policy listed has the highest precedence.
You can reorder group custom policies on an application by clicking Move to Top in the actions to the right of the group policy's name. This will move that policy one spot up in the list of group policies.
In the example below, the effective policy setting is that a member of both the "CorpHQ_Users" and "ITAdmins" groups may authenticate from a device without a screen lock enabled. Reordering the policies so that the "Require Screen Lock" group policy is listed first enforces that "ITAdmin" group members always need screen lock enabled to authenticate to this application.
Clicking the Replace link next to any of an application's currently assigned custom policies brings up the Apply a Policy window. From this window you can pick a different custom policy to apply, or pick different groups to associate with a group policy.
The Applications page of the Duo Admin Panel lists all of your applications. The Application Policy and Group Policies columns display current policy assignments for each application.
Clicking any policy name shown on the Applications page takes you to the Policy section of the properties page for that application.
To remove a custom policy from an application, click Unassign near that policy's name in the Policy section of an application's properties page.
To delete a custom policy from Duo, navigate to the Policies page and click Delete to the right of that policy's name. Deleting the policy also removes it from any applications. The alert shows how many applications (if any) the policy currently affects.
Duo captures policy related events -- such as custom policy creation and edits to the Global Policy -- in the Administrator Actions log.
Available in: Duo Free, Duo Essentials, Duo Advantage, and Duo Premier
The new user policy controls authentication for unknown users, in other words, users not yet enrolled in Duo. In Duo, an enrolled user is someone who exists in the service and has at least one authentication device attached, which can be a phone, hardware token, etc. The new user policy can be one of the following:
To change the new user policy, click the radio button next to the desired setting.
Available in: Duo Essentials, Duo Advantage, and Duo Premier
Configure this policy to change how both existing Duo users and unenrolled/new users access a Duo-protected application or to change access to selected applications. This overrides less-restrictive authentication policy settings configured at the global, application, or group level. More restrictive policy settings, such as a user location policy denying access to a specific country, still apply.
Changing the authentication policy setting from the default prevents new users from completing inline self-enrollment while authenticating to applications. When set to "Bypass 2FA", users not enrolled in Duo bypass the frame entirely when accessing the application so there is no opportunity for self-enrollment. If authentication to the application is blocked with the "Deny Access" setting, new users cannot self-enroll in that scenario either.
End users who receive enrollment links via email (like those sent by the directory sync process) may complete the Duo enrollment process via the emailed link regardless of the authentication policy setting.
As you deploy Duo throughout your organization you may need to let designated users access a certain application without Duo authentication, while requiring that they complete Duo 2FA when accessing any other protected application.
Accomplish this by first creating a Duo group (manually or via Directory Sync) containing those users.
Next, view the application which you want those group members to bypass Duo authentication in the Admin Panel. Click on Apply a policy to groups of users to create a new policy with the authentication policy set to Bypass 2FA, and then attach that new policy to your bypass group.
When the users in that Duo group access that application, they'll pass through to the application after successful verification of primary credentials. All other users accessing that application are subject to any other access policy settings applied to that application or in the global policy.
You can use the same process with the authentication policy set to Deny access to block users from accessing a selected application while still permitting them access to other Duo applications.
If you apply the authentication policy to an application as an application policy (instead of a group policy), then the configured bypass or deny access setting applies to all users of that application. Again, this overrides any other access policy set at the global level, and access to other Duo applications is unchanged.
Configuring the authentication policy within Duo's global policy affects all Duo application and all users — whether the user is enrolled in Duo or not. If you set the authentication policy to deny in the global policy then no users can access any of your Duo-protected applications (unless another policy setting permits access). Conversely, if you set the authentication policy to allow access in the global policy, then all users can access any application without completing Duo two-factor authentication (unless another policy requires 2FA).
Available in: Duo Advantage and Duo Premier
The user location looks up the geographical origin of a user's access device IP address, and can then enforce policy based on that location. You can deny all access from certain countries, or always require two-factor authentication for access requests from a country.
This policy setting overrides other access policies — like Authentication Policy, Authorized Networks, and Remembered Devices — when the setting applied here is more restrictive than the setting applied by those other policy options.
To change the user location policy, start typing in a country name to select it from the list, then change the drop-down to the desired setting for that country. The available settings are:
No action - Permits Duo authentication from the chosen country. This is the default policy setting for all locations.
This is also the effective setting when an authentication access device has no location (i.e. the IP address of the access device falls within a reserved private IP block or is reported as 0.0.0.0, neither of which can be geolocated).
Allow access without 2FA - Do not require Duo authentication for access requests from the named country.
Require 2FA - Always require two-factor authentication for IP addresses originating from the selected country.
Deny access - Prevents all Duo authentication attempts from IP addresses originating from the specified country.
When you activate Duo Passwordless the user location policy expands to apply to both two-factor authentication and passwordless authentication. The default settings apply no restrictions or allowances.
The available settings are:
Learn more about Duo Passwordless and how to enable passwordless authentication for your users in the Duo Passwordless documentation.
Available in: Duo Essentials, Duo Advantage, and Duo Premier
Partially enforced for passwordless authentication
Duo's trusted endpoints feature determines whether an access device is managed by your organization or is an unmanaged "bring your own" or unknown device. When an application loads the Duo Prompt it checks for the presence of a Duo device certificate or verification information from your MDM software or Duo Mobile app on that endpoint. You can use this policy to gain information about the devices used to access your Duo-protected web applications, and optionally restrict access from unmanaged endpoints.
The primary endpoint policy options are:
It's possible to apply different trusted endpoint policies to mobile devices than to computers. If you'd like to enable this functionality then click on Advanced Options for Mobile Endpoints to expose these additional selections:
Enabling the trusted mobile endpoint option could potentially make your overall trusted endpoints deployment less secure. Learn more about the security implications of enabling mobile endpoint options in your trusted endpoints policy.
See our full Trusted Endpoints guide for more information and step-by-step deployment instructions.
When you activate Duo Passwordless the trusted endpoints policy includes a warning describing the limitations of device trust verification and passwordless authentication. Passwordless support for Trusted Endpoints device trust policy applies only to management system integrations that rely on Duo Device Health app trust verification and Cisco Secure Endpoint verification.
Duo Passwordless does not support trusted device verification using certificates, Duo Mobile managed devices, or Google Verified Access.
When Passwordless has been enabled in your Duo account, then the trusted endpoints policy settings include additional information about compatibility between the two features.
Available in: Duo Essentials, Duo Advantage, and Duo Premier
Not enforced for passwordless authentication
The Duo Device Health application gives organizations more control over which laptop and desktop devices can access corporate applications based on the security posture of the device. The first time users log in to an application protected by the web-based Duo Prompt with the Device Health Application policy enabled, they are prompted to download and install the Duo Device Health application. Once the Device Health application is installed, Duo blocks access if the device is unhealthy based on the Duo policy definition and informs the user of the reason the authentication was denied.
The Device Health Application policy can be configured for either macOS endpoints, Windows endpoints, or both, and has three operating modes:
Don’t require users to have the app: Available in all paid plans.
The policy is not in effect and has no impact on end user access. End users are not prompted to install the Duo Device Health application when accessing a Duo-protected application. Data will be collected from the Duo Device Health application if present and running on the machine. This "Reporting" state is the default.
The Allow users to install the app during enrollment setting, enabled by default in a new policy, prompts your users to install Duo Device Health during their first-time Duo enrollment. If you don't want users seeing the option to install Duo Device Health during enrollment you can uncheck this option.
Require users to have the app only: Available in all paid plans.
With this option selected, but none of the "Block access" options selected, the Device Health application must be installed and reporting information to Duo for access.
End users running devices that can install the app (Windows 10+ and macOS 10.13+) are prompted to download the app from the Duo prompt when attempting to access a Duo-protected application associated with the policy if they do not already have the app installed. Devices that are capable of running the app but do not have it installed and running will be blocked.
The app will collect health information from the device, but Duo will not block the user from getting access if it does not pass the specific firewall, encryption, and password health checks. This means that the device will be able to access the application even if the device would not pass each health check.
Devices that cannot run the app, including older versions of Windows, Linux, etc., will not be prompted to install the app and are effectively allowed to bypass the Device Health Application policy.
Require users to have the app and any blocking options: Available to Advantage and Premier plans.
When selected with one or more of the "Block access" options, users must have the Device Health application installed, running, and reporting information to Duo, and the device must satisfy the specified health requirements for access.
End users running devices that can install the app (Windows 10 and macOS 10.13+) are prompted to download the app from the Duo prompt when attempting to access a Duo-protected application associated with the policy if they do not already have the application installed. Devices that are capable of running the app but do not have it installed and running will be blocked.
The app collects health information from the device, and Duo will allow or block access to the protected application based on the device health options selected.
Devices that cannot run the app, including older versions of Windows, Linux etc. will not be prompted to install the app and are effectively allowed to bypass the Device Health Application policy.
Note that the default "fail-open" Device Health Application policy allows you to enforce health checks for supported macOS and Windows devices, while not blocking users who need to access an application using a non-supported device. You can optionally use Duo's Operating Systems policy to restrict other device types from accessing the application.
Use the "device registration" options in the Device Health application policy settings to register devices using signed payloads with the Device Health application. Information collected during the registration process from a device with the Trusted Platform Module (TPM)/Secure Enclave is formatted and displayed on this table.
Note: To register devices using the Device Health application, select Require users to have the app for either macOS or Windows or both.
The primary device registration policy options are:
Require devices to be registered using Device Health - Select this option to have payloads sent from the Device Health Application and evaluated against the policy controls to determine the device’s trust status.
The first time a payload is sent from the Device Health Application for a given device, it will be unsigned, and the device is sent through the automatic Device Health Application registration.
Block devices presenting an already registered device identifier - Select this option to block devices that attempt to register a new Device Health Application but the device does not match the policy controls. For example, the device will be blocked:
If there is an existing Device Health Application registration for the device.
If the payload is signed, and the stored signature does not match the one sent in the payload.
If the payload is signed, and the stored signature matches the one sent in the payload, but it is not the oldest known registration for that device.
When a device does not meet the security requirements of the device registration policies, the Admin Panel provides more information about why the user’s device was blocked.
To view and manage your registered devices, see the Registered Devices page in the Admin Panel.
Device Health application policy options in Duo Essentials
Device Health application policy options in Duo Advantage
Duo Premier plan customers have additional antivirus and anti-malware agent check and policy options to verify that endpoints have a supported security solution in place before accessing an application.
Device Health application policy options in Duo Premier
See our full Device Health guide for more information and step-by-step deployment instructions.
If you configure operating system version policy settings for Windows and macOS, consider deploying the Device Health app to clients or enabling Device Health installation during Duo enrollment to enhance OS version detection for those systems, even if you don't use the Device Health policy options to verify security posture during authentication. Reliable detection and policy enforcement against Windows 11 requires the Duo Device Health application.
Available in: Duo Essentials, Duo Advantage, and Duo Premier
Duo's remembered devices feature is similar to the "remember my computer" or "keep me logged in" options users familiar to users from primary authentication to websites and applications.
With the remembered devices feature enabled, users of the Duo traditional prompt and Duo Authentication for Windows Logon see a "Remember me" option, and users of Duo Universal Prompt see a "Trust this browser". When users select this option during Duo authentication, they will not be challenged for Duo authentication when they log in again from that device for a set period of time.
Note: Endpoint checks for trust status, security posture, etc. still occur during a trusted browser login session.
You can enable remembered devices separately for web applications or Duo Authentication for Windows Logon, or for both in a single policy with distinct session lengths. If you plan to enable Duo Passwordless be aware that the remembered devices policy options apply to both passwordless and password plus 2FA application logins.
The default setting is no remembered devices.
Duo Essentials policy options:
Duo Advantage and Premier policy options:
The Remember devices for browser-based applications setting works with applications that show the Duo Prompt in a browser. Choose between traditional remembered devices, where the user opts-in during authentication, or Risk-Based Remembered Devices.
Allow users to remember their device for nn: This enables traditional remembered devices. Enter the desired number of days or hours — up to 365 days — for the setting and then choose one of these options:
Users will be asked to confirm for each application, then their device will be remembered for that application only.: When a user opts in to remembering their browser in an application, then it only applies to that individual Duo-protected service or application. Subsequent access of the same application will not require 2FA after a user checks the "Remember me" box on the traditional Duo Prompt or opts to "Trust this browser" on the Universal Prompt, but if a user accesses a different application protected by Duo then the user will have to approve a Duo login request again for those other applications.
After a user has confirmed for any application, their device will be remembered for all applications.: When a user checks the "Remember me" box on the traditional Duo Prompt or opts to "Trust this browser" on the Universal Prompt, it creates a trusted session for that user, client browser, and endpoint after successful Duo authentication. Duo won't prompt for authentication again for the duration specified if a user logs into that or any other web applications assigned the same remembered device policy and the trusted session is still valid.
This is especially helpful for users of Duo Single Sign-On and Duo Access Gateway. In this scenario, you would create a policy with remembered devices for all applications and then apply that same policy to each Duo-protected SAML application for which you don't want additional 2FA prompts. When a user logs into one of the protected SAML apps with that policy, like Google Workspace, and chooses to remember that device, the user isn't prompted for Duo access again when accessing other SAML apps via the Duo Access Gateway or Duo Single Sign-On with the same linked remembered devices policy.
In practice, we recommend configuring your remembered devices policy for browser-based applications at the global policy level, and then creating application and group level policies without remembered devices to override an existing trusted login session for those sensitive or restricted-access web applications where you want your users to perform Duo authentication again.
If a user has started a remembered device session for any browser-based application and you delete or remove any device from that user from the Admin Panel, the session will be revoked and the user will have to perform two-factor authentication again the next time they try to log into a browser-based application with that remembered devices policy.
Remember devices using risk-based authentication for up to nn: (Available in: Duo Advantage and Duo Premier) This setting applies Risk-Based Remembered Devices, which analyzes user authentications for IP and device patterns and either suppresses additional two-factor authentication prompts after the initial login for the duration defined, or prompts for two-factor authentication before the defined duration expires if anomalous access is detected.
See our full Risk-Based Authentication documentation for more information and step-by-step deployment instructions.
The Remember devices for Windows Logon setting works with Duo Authentication for Windows Logon version 4.2.0 and later. When enabling remembered devices for local Windows logons, enter the desired number of days or hours — up to 365 days — for the Allow users to remember their device for setting.
This policy setting only affects "Microsoft RDP" Duo applications. If you configure this setting in your global policy, or assign it to any application types other than Microsoft RDP, it has no effect on those other application types and users will not see the remembered device option during Duo authentication from those other applications.
Additionally, remembered devices settings do not apply to remote access Windows logins over RDP; the "Remember me" option shown for local console logins won't be present at RDP login. If you want to bypass Duo authentication for RDP connections, consider applying an Authorized Networks policy to the application.
When a user logs into Windows at the local workstation or server console and checks the "Remember me" box during Duo authentication, it creates a trusted session for that user on that host with that IP address after successful Duo authentication. Duo won't prompt for authentication again when the user locks and unlocks the workstation, or for credentialed UAC elevation by that user, for the duration specified in the policy setting.
Duo Authentication for Windows Logon invalidates the local trusted session on that Windows system before it expires if the user logs out of Windows or reboots, if the user cancels a remembered authentication in process, if the user authenticates with offline access for Windows logon, or if the network location of the system changes from the network in use at session creation. Administrators may revoke use of trusted Duo sessions by disabling or unassigning a remembered devices policy for Windows Logon from a Microsoft RDP application, or by deleting the registry entry for the user session from the Windows client. Learn more about this in the Windows Logon FAQ.
Available in: Duo Advantage and Duo Premier
Operating systems policies apply to:
Which operating systems and versions are allowed to access your applications when protected by Duo's browser-based authentication prompt, while also encouraging users running older operating systems to update to the latest version.
Which mobile OS platforms and versions may be used with Duo Mobile to approve two-factor authentication requests or generate passcodes for authentication. When you block a given mobile operating system, then that restriction applies to use of Duo Mobile to authenticate to all Duo-protected applications, not just those that use Duo's browser prompt, and prevents enrollment of Duo Mobile for any device with that OS. See Mobile Platforms to learn more about operating system policy for mobile platforms.
You may block access from all versions of any of the OS platforms listed in the policy editor: Android, BlackBerry, Chrome OS, iOS, Linux, macOS, Windows, and Windows Phone.
The default settings do not allow access, authentication, or enrollment from browsers on BlackBerry devices and Windows Phones. All other Duo-supported operating systems and mobile platforms are allowed with no warnings.
Duo offers more granular options for the Android, iOS, macOS, and Windows operating systems, like warning on or blocking access below a certain version, warning the user that they need to update to an approved version instead of blocking access outright, and setting a grace period for warning or blocking a user after a version becomes outdated.
Scroll down in the policy editor to see all OS options.
Enable the Encourage users to update option by picking your minimum allowable OS version from the drop-down selector. You can choose to select a specific version, or let Duo determine the most recent available up-to-date or end-of-life version.
Check the OS Specific Version Data section of this document for additional details about how Duo determines the "up-to-date" or "end-of-life" status for a given operating system.
After choosing the OS version, select a grace period from the When a version becomes out of date or end of life, encourage to update choices. Setting this to "Immediately" means users see the warning as soon as their current version is lower than the version you selected. You can delay the Duo warning for up to 365 days. Look to the right of your selection to see a summary of your new policy setting.
Once configured, Duo shows a notification during authentication or enrollment to your users informing them that they should update when accessing your Duo-protected resource from a device running an operating system version older than your selection.
Universal Prompt Example Scenario
You may choose to encourage macOS users to update "If less than the latest" and to start encouraging them "Immediately".
A user accessing your application from a Windows 8 PC sees a message in the Universal Prompt indicating their operating system is out of date.
Users can click Skip for now to continue to the application, or click See how to update to view instructions for their operating system.
Traditional Prompt Example Scenario
You may choose to encourage Windows users to update versions "below 8.1" and to start encouraging them "Immediately".
A user accessing your application from a Windows 8 PC sees a warning at the bottom of the traditional Duo Prompt. Clicking "Let's update it" provides the user with information on how to update the operating system. Users can proceed past the warning by clicking "Skip".
Restrict application access to only the versions you've allowed by making a selection in the Block versions option for an OS, along with a corresponding grace period for blocking. Blocking any operating system version(s) prevents users from completing authentication or new user enrollment from that disallowed OS (or OS version).
Universal Prompt Example Scenario
You choose to block macOS versions "If less than the latest", which prevents authentication or enrollment for any user trying to access your application from a computer no running the latest version of macOS
Choosing to block an out-of-date macOS version with a warning grace period gives users a countdown in the out-of-date warning letting them know when they will be required to update their endpoint to continue accessing the application.
If the user doesn't update their operating system by the end of the warning period, or if you chose to immediately block access from the user's OS version, the Universal Prompt denies application access with the update instructions available from the prompt.
Traditional Prompt Example Scenario
You choose to block users with Windows versions "below 8.1", which prevents authentication or enrollment for any user trying to access your application from a Windows 8 computer. A user accessing your application from a Windows 8 PC can't proceed past the out-of-date software notification.
Uncheck the "Allow" option for an OS to prevent access entirely, i.e. if you uncheck Allow Windows Devices in the policy editor, then users accessing your application from any version of Windows are blocked. They can click See what is allowed for information about the operating systems you permit or block.
The Android and iOS mobile platforms can also be restricted to a minimum allowed version or blocked entirely. Blocking any version of a mobile OS platform, e.g. iOS or Android, not only restricts use of the mobile device to access Duo-protected resources that feature the browser-based traditional Duo Prompt or Universal Prompt on those OS platforms or versions, but also prevents use of Duo Mobile to approve Duo Push requests or generate usable passcodes to complete two-factor authentication for any Duo-protected application on devices running the restricted OS.
If you were to block iOS versions "below 15.0" then any users with Apple devices running iOS 14.x or lower can no longer access Duo-protected applications from mobile Safari, nor can they approve Duo Push request or use Duo Mobile passcodes from those devices to authenticate to any Duo-protected application, whether it's accessed via browser or not. If a user has other additional activated devices running a different mobile platform, the functionality of the other devices is not affected.
When a mobile device operating system or version is restricted users see a message indicating the mobile version or platform can't be used to complete authentication in the browser-based traditional Duo Prompt. The Universal Prompt will indicate that it sent the Duo Push request to the phone, and then show a "Something went wrong" error.
Duo Mobile notifies the user that the mobile platform or version is not allowed when attempting to approve the Duo Push request as well.
Passcodes from a hardware token or received via SMS are allowed, as are phone call authentications, but entering a passcode generated by Duo Mobile on any device running the restricted platform results in an error stating that platform is not permitted.
As an example scenario, if you disallow Android devices then your iOS users continue to receive and approve Duo Push requests, and can also authenticate with SMS passcodes, application passcodes, hardware tokens, or over the phone. Your Android users can only use SMS passcodes to authenticate, approve a login via phone call, or use a hardware token passcode. If you wanted to completely prevent any use of Android phones to approve authentications, you'd also need to disable the "Phone callback" and "SMS passcodes" options in the Authentication Methods policy setting. Keep in mind that disabling phone and SMS authentication affects authentication for all users, no matter what mobile OS they use.
These operating system sections and tables detail the state of our version data for the four major OS platforms as of June 9th, 2021. This data maps to the operating system policy options as follows:
The current version for an OS platform whose status in the tables below is "Current" satisfies the If less than the latest policy option. All other versions are considered out of date.
The current version for an OS platform whose status in the tables below is "Current" or "Supported" satisfies the If not up to date policy option for macOS and Android, and all other versions are considered out of date.
All versions for an OS platform whose status in the tables below is "End of Life" (EOL) fall in scope for the If end of life policy option. Note that out-of-date versions for "Current" or "Supported" status products pass this policy as they aren't considered end of life.
| Release Name | Base Version | Current Version | Status | Date Marked EOL |
|---|---|---|---|---|
| Ventura | 13 | 13.2.1 | Current | n/a |
| Monterey | 12 | 12.6.3 | Supported | n/a |
| Big Sur | 11 | 11.7.4 | Supported | n/a |
| Catalina | 10.15 | 10.15.7 | End of Life | 2022-12-12 |
| Mojave | 10.14 | 10.14.6 | End of Life | 2021-10-25 |
| High Sierra | 10.13 | 10.13.6 | End of Life | 2020-12-14 |
| Older Mac Releases | < 10.13 | n/a | End of Life | n/a |
As of macOS 11, up-to-date versions of major browsers (Safari, Chrome, Firefox, and Edge) have frozen the OS version reported via the browser user agent string as 10.15.6, 10.15.7, or 10.16, impacting the ability to detect whether macOS 11 and later is truly up to date when relying only on information reported to Duo by the browser.
Duo does not block user access from endpoints that report the frozen 10.15.x macOS version in the browser user agent string, as the macOS software on those endpoints may actually be a later, up-to-date version.
The Duo Device Health app detects and reports the actual macOS version, enabling reliable OS version verification during Duo authentication. Duo recommends using the Device Health app on macOS 11 or newer clients to enable accurate macOS version checking, blocking, and reporting, especially if you choose to apply a Duo operating systems policy with the "If less than the latest" option selected, or pick a static version of 11.0 or greater.
Learn more about how the Device Health app enables granular operating system policy for macOS in the Device Health documentation.
| Build Name | Base Version | Current Version | Status | Date Marked EOL |
|---|---|---|---|---|
| Windows 11 22H2 | 10.0.22621 | 10.0.22621.1413 | Current | n/a |
| Windows 11 21H2 | 10.0.22000 | 10.0.22000.1696 | Current | n/a |
| Windows 10 22H2 | 10.0.19045 | 10.0.19045.2728 | Current | n/a |
| Windows 10 21H2 | 10.0.19044 | 10.0.19044.2728 | Current | n/a |
| Windows 10 21H1 | 10.0.19043 | 10.0.19043.2364 | End of Life | 2022-12-13 |
| Windows 10 20H2 | 10.0.19042 | 10.0.19042.2728 | End of Life | 2022-06-14 |
| Windows 10 2004 | 10.0.19041 | 10.0.19041.1415 | End of Life | 2022-01-11 |
| Windows 10 1909 | 10.0.18363 | 10.0.18363.2274 | End of Life | 2021-06-08 |
| Older Windows 10 Builds | < 10.0.18363 | n/a | End of Life | n/a |
| Windows 8.1 | 6.3.9200 | 6.3.9600 | End of Life | 2023-02-06 |
| Windows 8 | 6.2 | n/a | End of Life | 2016-01-12 |
| Windows 7 | 6.1 | n/a | End of Life | 2020-02-11 |
| Older Windows Releases | < 7 | n/a | End of Life | n/a |
Duo’s end-of-life determination for Windows 10 and Windows 11 builds relies on the date that Microsoft marks that build as end of life for Windows Enterprise and Education editions.
For Windows 10 20H2 and earlier versions of Windows 10, Duo’s end-of-life determination was based the date that Microsoft marked a build as end of life for Windows 10 Home and Professional editions.
For Windows operating systems before Windows 10, the Duo end-of-life determination matches Microsoft's stated "Extended End Date" for that version.
Refer to the Lifecycle FAQ for Windows for more details.
A browser user agent provides a limited amount of information about Windows 10 and 11 versions. As of Windows 11, up-to-date versions of major browsers (Chrome, Firefox, and Edge) have frozen the OS version reported via the browser user agent string as Windows 10, impacting the ability to detect whether Windows 11 and later is truly up to date when relying only on information reported to Duo by the browser.
Duo does not block user access from endpoints that report the frozen Windows 10 version in the browser user agent string, as the Windows software on those endpoints may actually be a later, up-to-date version.
The Duo Device Health app detects and reports the actual Windows build version and the security patch version, enabling reliable OS version verification during Duo authentication. Duo recommends using the Device Health app on Windows 10 and 11 clients to enable accurate Windows version checking, blocking, and reporting for specific Windows versions, especially if you choose to apply a Duo operating systems policy with the "If less than the latest" option selected, or pick a static version of Windows 11 or greater.
Learn more about how the Device Health app enables granular operating system policy for Windows in the Device Health documentation.
| Release Name | Base Version | Current Version | Status | Date Marked EOL |
|---|---|---|---|---|
| Android 13 | 13 | 13.0.0 | Current | n/a |
| Android 12 | 12 | 12.1.0 | Supported | n/a |
| Android 11 | 11 | 11.0.0 | Supported | n/a |
| Android 10 | 10 | 10.0.0 | Supported | n/a |
| Android 9 | 9 | 9.0.0 | End of Life | 2022-05-04 |
| Android 8 | 8 | 8.1.0 | End of Life | 2022-05-04 |
| Android 7 | 7 | 7.1.2 | End of Life | 2020-09-28 |
| < 7 | n/a | n/a | End of Life | n/a |
Duo's end-of-life determination for Android is that versions that still receive security patches are considered supported. However, Duo does not check for the presence of security patches on Android devices.
Versions no longer receiving security patches are considered end of life.
| Release Name | Base Version | Current Version | Status | Date Marked EOL |
|---|---|---|---|---|
| iOS 16 | 16 | 16.3.1 | Current | n/a |
| iOS 15 | 15 | 15.7.3 | Supported | n/a |
| iOS 14 | 14 | 14.8.1 | End of Life | 2022-01-25 |
| iOS 13 | 13 | 13.7 | End of Life | 2020-09-25 |
| Older iOS Releases | < 12 | n/a | End of Life | n/a |
Duo bases the end-of-life determination for iOS on Apple's historical update patterns. Historically, only the most recent iOS version has been considered supported, but has changed since Apple began providing security patches for older releases, starting with iOS 14 and iOS 15.
Available in: Duo Advantage and Duo Premier
Enable this feature to inform your users when their web browser is out of date and optionally block access to your Duo-protected resources from clients with older browser versions or an entire browser family. This policy supports Chrome, Chrome Mobile, Edge, Firefox, Internet Explorer, Mobile Safari, Safari, and other browsers (which includes Firefox Mobile). The default setting allows all versions of all browsers and warns users if their browser is out of date.
When the "Warn users if their browser is out of date" option is enabled, users authenticating via the Duo Prompt see a notification when the web browser version used is older than the current release version. Instructions for updating or a link to the browser vendor's website are provided if applicable. If you have only opted to warn users, they may skip the software update and complete authentication. The out of date notification continues appearing during authentication attempts until the end user updates to the current version.
| Universal Prompt | Traditional Prompt |
 |
 |
You may also choose to block user access when web browsers are out of date and specify a grace period during which users may continue to authenticate with older versions (0 days to one year after the current release).
If you set your policy to block access from out of date browsers, users can skip past the software update warning up until the end of the grace period you specified in the policy. After that, users may not continue to Duo new user enrollment and authentication. Only updating the browser to a current version permits a user to complete Duo authentication or enrollment.
Restrict user access from certain web browsers completely by selecting the browser under "Always block".
See Software Update in the user guide for more information.
Available in: Duo Advantage and Duo Premier
Not enforced for passwordless authentication
Enable this feature to inform your users when selected plugins are out of date or block access to your Duo-protected resources from clients with outdated plugins (or block a plugin entirely). The default setting blocks all versions of Flash plugins and warns users when their Java plugin is out of date.
When the "Warn users" option is enabled, users authenticating via the Duo Prompt see a notification when the selected plugins are older than the current release version. If you have only selected to notify users of the outdated software, they may skip the software update and complete authentication. The software update notification continues appearing during authentication attempts until the end user updates the affected plugin.
You may also choose to block user access when plugins are out of date and specify a grace period during which users may continue to authenticate with older versions (0 days to one year after the current release).
If you set your policy to block access from out of date plugins, users can skip past the software update warning up until the end of the grace period you specified in the policy. After that, users may not continue to Duo new user enrollment and authentication. Only updating the affected plugins permits a user to complete Duo authentication or enrollment.
Restrict user access with certain plugins completely by selecting "Block all versions".
Configure software notifications for either or all of the following plugins:
Flash - Checks whether or not the browser uses the Flash plugin. Adobe ended support for Flash on December 31, 2020, and began blocking Flash content from running in Flash Player on January 12, 2021. With Flash at its end-of-life (EOL), version updates are no longer possible. Therefore, the Duo policy options no longer check for the latest version, and only offer the options to allow or block all versions of Flash.
Customers who configured a Flash plugin policy that checks for out-of-date versions prior to the Flash EOL still see those settings when viewing or editing those existing policies, but should be aware that the end of update availability means that all versions are considered out of date.
Duo recommends that all customers set the Flash plugin policy to Block all versions.
Java - Checks the version of the Java plugin used by the current browser and notifies the user if it is out of date. A link is provided to the Oracle Java download site.
See Software Update in the user guide for more information.
Available in: Duo Essentials, Duo Advantage, and Duo Premier
Not enforced for passwordless authentication
Define global or application 2FA policies for different networks with Duo's authorized networks policy. Essentials customers can minimize Duo prompts for specific networks, while Advantage and Premier customers have additional options to require Duo authentication or block access entirely on a per network basis. The default settings apply no per-network restrictions or allowances.
The authorized policy options are:
Allow access without 2FA from these networks - Users accessing Duo-protected resources from these networks skip Duo secondary authentication. Specify a block of IP addresses, IP ranges, or CIDRs as a comma-separated list. If you have enabled Duo Passwordless for your organization the description of this setting mentions this has no effect on passwordless authentication.
By default, Duo prompts users to enroll when logging in from an authorized network when the new user policy is set to require enrollment. To prevent unenrolled users from receiving the Duo enrollment prompt when connecting from an authorized network, uncheck the Require enrollment from these networks setting.
Require 2FA from these networks - Users accessing Duo-protected resources from these networks must always complete Duo secondary authentication, even when another policy that permits bypassing Duo applies. Specify a block of IP addresses, IP ranges, or CIDRs as a comma-separated list. This overrides remembered device trust.
Deny access from all other networks - Use this option to block user access from any network not configured in the "allow access" or "require 2FA" options. At least one network must be defined for 2FA bypass or enforcement to enable this setting.
Enabling the deny access option blocks access from Duo applications that don't report client IP! This prevents connections for any Duo application that shows the client IP as 0.0.0.0. Before configuring the setting please review your authentication logs in the Admin Panel to verify your Duo-protected applications report the client IP.
If there is any overlap between the network segments or IP addresses defined in the "allow access" and "require 2FA" options, then the more restrictive policy setting applies and access requires Duo authentication.
The Duo Essentials plan authorized networks policy only permits specifying a network to bypass Duo Essentials for regular (not passwordless) authentication, and does not include the require or deny options.
Available in: Duo Advantage and Duo Premier
Duo can help you monitor and optionally prevent authentication attempts originating from known anonymous IP addresses, such as those provided by TOR and I2P, HTTP/HTTPS proxies, or anonymous VPNs.
When you activate Duo Passwordless the anonymous networks policy expands to apply to both two-factor authentication and passwordless. The available settings are:
Learn more about Duo Passwordless and how to enable passwordless authentication for your users in the Duo Passwordless documentation.
Available in: Duo Advantage and Duo Premier
Duo’s Risk-Based Authentication automatically detects and mitigates commonly known attack patterns and high-risk anomalies to provide a higher level of security without compromising end-user experience.
The Risk-based Factor Selection policy setting enables detection and analysis of authentication requests and adaptively enforces the most-secure factors in order to highlight risk as well as adapt its understanding of normal user behavior.
Duo Risk-Based Factor Selection works with existing authentication methods policy for web-based applications that show the Duo Universal Prompt and for the Duo Auth API application (meaning any client app that uses the named "Duo Auth API" application). When we identify a risky logon attempt for a user we restrict the authentication methods allowed for that user until they successfully authenticate with a permitted factor.
See our full Risk-Based Authentication documentation for more information and step-by-step deployment instructions.
Available in: Duo Essentials, Duo Advantage, and Duo Premier
Duo offers a variety of ways that users can receive their second authentication factor: one-tap authentication with a WebAuthn passkey or Duo Push, a passcode sent via SMS, an automated voice call, and so on (see our detailed explanation of all authentication methods). Unless otherwise noted, all authentication methods options are available to paid Duo editions, including those for Duo Passwordless and verified Duo Push.
Phone calls and SMS passcode text messages consume telephony credits. Check the rate card to see how many credits will be consumed for users in different locations.
If you disallow an authentication method in a policy, this also prevents self-enrollment of that method. You can create a custom policy for the self-service portal to allow users to enroll different authentication methods than the ones used to authenticate to the application.
Authentication methods policy options:
If you choose to enable phone calls as an authentication method, consider applying some additional policy controls (such as restricting User Location to your expected countries) or reducing your max credits per action telephony setting to only the credit amount needed for phone calls to your users' expected locations to avoid telephony misuse, especially if you've enabled the self-service portal for any of your applications.
WebAuthn security keys and passkeys can be used with the browser-based Duo Prompt when accessing applications with Chrome 70 and later, Edge 79 and later, or Firefox 60 and later on macOS and Windows, and Safari 13 and later on macOS. WebAuthn Touch ID support is available only in Chrome 70 or later on a Touch ID compatible MacBook.
To restrict or allow authentication methods, just choose from the available options.
For example, when "Phone callback" is deselected then phone call no longer appears as an option in Duo Prompt.
If all methods are deselected, then only bypass codes may be used to authenticate.
Note: If Duo Push is disabled but Duo Mobile passcode is enabled then user will be able to use Duo Mobile to generate a one-time passcode (much as they might with a hardware token). You can prevent users from using the app to generate one-time passcodes by not enabling the Duo Mobile passcodes authentication method.
If you permit use of WebAuthn authentication methods in the traditional Duo Prompt, Duo recommends configuring allowed hostnames for your protected applications before onboarding your end-users.
The Duo Universal Prompt has built-in protection from unauthorized domains so this setting does not apply.
The verification code option for Duo Push provides additional security against push harassment and fatigue attacks by asking the user to enter a verification code while approving a Duo Push authentication request. It also provides improved fraud reporting from end-users by directing them toward the fraud report option in Duo Mobile when they receive unexpected Duo Push login requests.
When a user logs into an application that shows the Duo Universal Prompt and has push verification enabled in its effective policy they will see a numeric code three to six digits in length (based on your preference) in the prompt which must be entered to approve the Duo Push request on their authentication device. This ensures users cannot accidentally approve login requests when they aren't actively logging in to the application.
Enable verification for Duo Push by selecting the Always require a Verified Duo Push with n digits. option shown under the Duo Push authentication method. When enabling this option you may select a verification code length from three to six digits (default: 3).
Verified Duo Push requires:
Verified Duo Push has no effect in the traditional Duo Prompt or for non-browser applications like Duo Authentication for Windows Logon, RADIUS or LDAP applications that use Duo Authentication Proxy, Duo Unix, etc.
In addition, trusted endpoint verification of iOS and Android devices with Duo Mobile uses the standard Duo Push approval process and will not prompt for a Duo Push verification code.
The Authentication Log shows when a verification code was used to approve a Duo push request, when an incorrect code was entered, and when a user denied the push request as a mistake or fraud. If the response indicated the login request was suspicious, Duo sends an email notification to the administrators specified in the Alert email global setting.
When you activate Duo Passwordless the authentication methods policy expands to include settings for passwordless authentication methods. These new passwordless methods aren't enabled in your existing policies, including the Global Policy, until you expressly edit a policy to enable them.
Enabling any of the passwordless methods in a policy permits use of passwordless authentication for any Duo Single Sign-On application subject to that policy. The passwordless authentication methods settings have no effect for non-SSO applications, as those applications do not support passwordless logins today.
The authentication method options for passwordless logins are:
Roaming Authenticators: This enables end-user authentication using FIDO2-compliant WebAuthn security keys, like those from Yubico or Feitian. Enabling roaming authenticators prompts all users to register a passwordless authenticator whenever they log in.
Platform Authenticators: This enables end-user authentication using biometric sensors built into their devices, such as Touch ID or Face ID on Apple devices, Windows Hello on Windows 10 and 11 systems, or Android biometrics. Enabling platform authenticators prompts just those users with compatible access devices to register a passwordless authenticator when they log in.
Duo Push: This enables end-user authentication by approval of a login request pushed to Duo Mobile on a user's Android or iOS device. Duo Push authentication for Duo Passwordless is enabled via a browser cookie for the specific browser used to log in to a protected application from a given access device. When the user approves a Duo Push request for passwordless login, they must perform biometric or PIN/passcode verification while they approve the login request. Users may also need to enter a verification code into Duo mobile to complete the passwordless Duo Push login depending on the known and trusted status of the browser used.
Learn more about Duo Passwordless and how to enable passwordless authentication for your users in the Duo Passwordless documentation.
Available in: Duo Advantage and Duo Premier
The Duo Mobile smartphone app is an essential part of most organizations' two-factor deployment. We may need to issue app updates to address security vulnerabilities should any be discovered. The Require up-to-date security patches for Duo Mobile policy setting allows Android and iOS authentication from devices running Duo Mobile version 3.8.0 (released in April 2015) or later for both iOS and Android, while preventing authentication from Duo Mobile versions prior to that minimum secure version.
Example outcomes with this option enabled:
We recommend that users install the latest available Duo Mobile version for their mobile platform and operating system version, and enable automatic updates to keep Duo Mobile secure and up to date.
The default setting requires iOS and Android devices to be running Duo Mobile 3.8.0 or newer.
Available in: Duo Advantage and Duo Premier
It is possible to gain privileged access to the operating system of a mobile device. This is known as "rooting" on Android, and "jailbreaking" on iOS. Tampered, rooted, and jailbroken devices may be considered a security risk because they are more vulnerable to exploit by malware and malicious apps.
Duo can verify whether a device is rooted or jailbroken and prevent authentication from those devices. Duo performs jailbreak detection on iOS and, in addition to checking for rooted access on Android, also utilizes Google's SafetyNet device attestation to identify tampered-with Android devices.
You can prevent Duo authentication approvals from tampered-with or rooted Android and jailbroken iOS devices by enabling the Don't allow authentication from tampered devices policy setting. This setting has no effect on other mobile platforms.
The default setting does not allow authentications from tampered iOS and Android devices.
Available in: Duo Advantage and Duo Premier
Enabling screen lock with passcode on iOS or with PIN on Android secures devices by requiring input of a numeric code when turning on your device or unlocking the screen. If the screen is locked when a Duo Mobile push authentication request is received, then the screen must be unlocked before approving the authentication request.
Require your users to set a PIN or passcode on their devices by enabling the Don't allow authentication from devices without a screen lock option in the "Screen Lock" policy. With this option enabled, users must have screen lock enabled on their devices to approve Duo Push authentication requests or log in with a passcode generated by the Duo Mobile app. Users may still approve phone call login requests and use SMS passcodes texted to a device without screen lock. If you wanted to completely prevent authentications from phones without screen lock configured, you'd also need to disable the "Phone callback" and "SMS passcodes" options in the Authentication Methods policy setting.
This setting applies to all supported Android versions (2.2 and up). For iOS devices, this setting is only enforced on version 8 and higher. Devices running iOS 7 and lower can still authenticate without enabling screen lock. To ensure that Apple devices used to authenticate comply with the screen lock requirement, you may change the Operating Systems policy for iOS to "Block users if their version is below 8.0".
The default setting requires that screen lock be enabled to approve a Duo authentication request received via push or use a Duo Mobile generated passcode.
Available in: Duo Advantage and Duo Premier
Disk encryption protects device data from unauthorized access. Booting an encrypted device requires entering a passcode or PIN at device boot. Apple devices automatically encrypt the filesystem, but on Android devices encryption is enabled by the end user separately after enabling screen lock.
Prevent Duo authentication from Android devices without disk encryption by enabling the Don't allow authentication from devices without full-disk encryption option in the "Full-Disk Encryption" settings. Note that a PIN is required at startup in order for a device's status to show as encrypted.
The default setting does not require full-disk encryption to approve a Duo authentication request from an Android device. This setting has no effect on iOS.
Available in: Duo Advantage and Duo Premier
Biometric identity verification, like Apple's Touch ID and Face ID or Android Fingerprint, makes two-factor authentication even more secure.
In the policy editor, select the Require additional biometric verification option to require biometric approval for Duo Push from supported devices. Use of Duo Mobile generated or SMS passcodes remains unaffected, as well as authentication via phone call.
Fingerprint and Touch ID authentication requires Duo Mobile app versions 3.7 or above for iOS and version 3.10 or above for Android and minimum OS versions iOS 8 or Android 5.0 Lollipop. Face ID requires iOS 11 and Duo Mobile 3.19. Devices running earlier versions of Duo Mobile, iOS, and Android can not authenticate without biometric verification when you enable this policy setting.
Requiring biometric verification changes the Duo Push workflow. Users may no longer approve an authentication request from the app notification. Tapping the Duo notification opens the Duo Mobile app. After you tap "Approve" on the authentication request, scan your enrolled finger at the Touch ID or Android PIN prompt or perform Face ID verification to confirm the authentication approval. If you are unable to authenticate with a biometric factor you can fall back to your device's passcode.
The default setting does not require any biometric verification to approve a Duo Push authentication request from any device. All Duo Mobile, Android, and iOS versions may authenticate (subject to any other version restriction policy settings you may configure).
Please refer to the Duo Policy Guide for supplemental information about constructing effective custom policies and assigning them to your Duo applications and users.
Need some help? Try searching our Knowledge Base articles or Community discussions. For further assistance, contact Support.
All Duo customers have access to Level Up, our online learning platform offering courses on a variety of Duo administration topics. To access Level Up content, sign in with the same email address you use to sign in to the Duo Admin Panel.