• Duo SSO is the identity provider for your SaaS applications. The applications you intend to protect are already federated through Duo SSO. See Cisco’s Duo Single Sign-On documentation.
• A CSE Access Tier is deployed (public IP; inbound TCP 80/443 for web, TCP 8443 for infrastructure, UDP 51820 for Service Tunnel) to host the CSE IdP and device-trust endpoints.
• A Service Tunnel is available on end-user devices for the device-registration and Passwordless flow. See Passwordless authentication and managed, registered, and unregistered devices.

1. A user opens a SaaS application that is federated to Duo SSO.
2. Duo SSO consults its Authentication source routing rules and selects the CSE SAML Identity Provider authentication source.
3. Duo SSO, as the SAML Service Provider, redirects the user to CSE’s SAML SSO endpoint.
4. CSE performs device trust (Mutual-Auth TLS against the trusted device certificate) and evaluates the attached Web Policy. With Passwordless enabled, CSE reads the user’s email from the device certificate’s UserPrincipalName SAN extension and issues a TrustToken without a username/password prompt.
5. CSE returns a signed SAML assertion to Duo SSO. Duo SSO completes sign-in (applying its own second-factor or bypass policy — see Avoid Duplicate MFA Prompts) and the user reaches the application.

Organizations can create one IDP-Routed SaaS app for all Duo applications, or create multiple IDP-Routed SaaS apps for groups of applications (for example, High Security vs. Medium Security).

1.1 First create the Web Policy that the app will enforce. Navigate from Private Access > Access Policies > + Create Policy, and then select Web Policy. Set Role to ANY and the required TrustLevel (for example, High or Medium for registered devices).

1.2 Create the SaaS application. Navigate from Internet Access > SaaS Apps > Publish SaaS Application, and select the IDP Routed template.

1.3 Select SAML as the authentication protocol.

Why SAML and not OIDC. Duo SSO supports only Active Directory or an external SAML 2.0 Identity Provider as an upstream authentication source; OIDC is supported by Duo only on the downstream (relying-party) side. You must therefore have CSE present its SAML IdP interface here — the same protocol used on the CSE-to-Entra path — rather than the OIDC interface used on the CSE-to-Okta path.

1.4 Complete the IDP-Routed SaaS app fields:

• Application Name — a descriptive name (for example, Duo SSO via CSE).
• Attach the Web Policy from Step 1.1 and set its enforcement mode (see Step 5.1 for the difference between enforcement and permissive modes).
• Optionally toggle Passwordless Authentication on (see Enable Passwordless Authentication).

1.5 Register / publish the app.

1.6 Retrieve CSE’s SAML IdP metadata. From the published SaaS app, copy the metadata URL and download it as BanyanMetadata.xml. You will provide these values to Duo in Step 2:

• Metadata URL: https://<org>.trust.banyanops.com/api/v1/saml_metadata
• SAML SSO URL and Entity ID / Issuer (both are the same value): https://<org>.trust.banyanops.com/v2/saml/sso/<id>
• X.509 signing certificate: the first <X509Certificate> value in BanyanMetadata.xml (base64; strip PEM header/footer and line breaks if pasting as raw base64).

Note: The CSE SAML endpoint paths and the <org> / <id> segments should be confirmed against your live CSE tenant. CSE SAML endpoints still use the legacy banyanops.com domain.

In this step Duo SSO acts as the SAML Service Provider and CSE is the upstream SAML Identity Provider. Metadata is exchanged in both directions: Duo gives CSE its SP values, and CSE gives Duo its IdP values. The goal is to establish a mutual trust relationship so CSE-signed assertions are accepted by Duo and Duo’s sign-in requests are routed to the correct CSE endpoint.

The values to exchange (all already produced in Step 1.6 and shown by Duo in Step 2.3) are summarized below. Cisco’s Duo SSO documentation is the source of truth for the Duo console field labels.

2.1 In the Duo Admin Panel, navigate from Applications > Single Sign-On > Settings, and open the External Authentication Sources tab. Select Add source.

2.2 For the source type, select SAML Identity Provider. This is the generic/custom SAML source; the named providers (Microsoft Entra ID, Okta, Google) are pre-filled variants of this same source. Use the generic Other variant for CSE.

2.3 Under the section 1. Configure your SAML Identity Provider, Duo displays its own SP metadata. Copy the following Duo values into the CSE IDP-Routed SaaS app from Step 1 as the relying party’s Service Provider details:

• Entity ID — format https://sso-XXXXXXXX.sso.duosecurity.com/saml2/idp/<ID>/metadata
• Assertion Consumer Service URL (ACS URL) — format https://sso-XXXXXXXX.sso.duosecurity.com/saml2/idp/<ID>/acs

2.4 Under the section 2. Configure Duo Single Sign-On, enter the CSE IdP values you obtained in Step 1.6:

• Display Name — CSE Policy Engine (the friendly name for this source).
• Entity ID (Issuer) — https://<org>.trust.banyanops.com/v2/saml/sso/<id>
• Single Sign-On URL — https://<org>.trust.banyanops.com/v2/saml/sso/<id>
• Certificate — the CSE X.509 signing certificate (PEM, including the BEGIN/END CERTIFICATE lines).
• Username normalization — set to None, so the SAML NameID matches Duo usernames exactly.

2.5 Save the authentication source.

Verify the NameID format and attribute mapping. Duo’s generic SAML auth source expects a NameID format of urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified whose value matches the user’s Duo username, plus the attributes Email, Username, FirstName, LastName, and DisplayName. CSE’s SAML assertions, by contrast, use a NameID format of EmailAddress and the attributes Email, Username, and Groups. These do not match out of the box. Before production use, confirm in your CSE tenant that the assertion CSE emits can be shaped to satisfy Duo’s requirements (NameID value equal to the Duo username, and the five required attributes present). If your CSE build does not expose configurable NameID/attribute mapping for this path, this federation will fail at Duo with a username/attribute mismatch. There is no vendor-documented mapping for this specific direction, so the exact field labels should be confirmed live.

Once authentication is federated to CSE, a new user who has not yet registered a device can be trapped in a loop: Duo redirects to CSE, CSE requires a registered device to authenticate, but the device-registration flow itself is being federated. You must keep an enrollment/registration path and an administrative break-glass path that do not route through CSE.

3.1 Keep device registration off the federated path. Ensure that the CSE Device Registration flow is reachable without first passing through the CSE authentication source. In Step 4 / Step 5, scope the CSE routing rule so it never matches the application(s) or group(s) used for first-time device enrollment; route those to Duo’s existing source (Duo-hosted users or Active Directory) instead.

Duo model difference. Okta solves this with a dedicated CSE Fallback Routing rule that sends the CSE Device Registration app back to Okta. Duo SSO has no per-app “fallback” toggle, but Duo routing rules achieve the same outcome: create a higher-priority rule that matches the enrollment group or SSO application and resolves to a non-CSE source. Routing rule conditions are Specific groups, Specific domains, Specific SSO applications, and Specific networks, evaluated in descending priority. See Duo SSO routing rules.

3.2 Preserve the Duo Admin Panel break-glass path. The Duo Admin Panel login is architecturally separate from end-user SSO and is your true emergency path. On the Administrator Login Settings page, Authentication with SAML can be set to Disabled, Optional, or Required. Even when set to Required, administrators holding the Owner role can always sign in with username and password using the Use password instead (or Log in using password) link. See Cisco’s article on signing in to the Admin Panel.

Warning: Maintain at least two Owner-role administrators for redundant break-glass access. The admin-login second factor cannot be removed, and administrators cannot self-issue bypass codes for admin-panel logins, so the Owner password-instead-of-SSO path is the supported emergency route. See administering Duo administrators.

For a phased rollout, leave Duo’s default routing rule pointed at your existing source (Duo-hosted users or Active Directory) and add a higher-priority custom rule that routes only the selected applications to the CSE SAML source.

4.1 Confirm the CSE SAML Identity Provider authentication source from Step 2 is enabled (Applications > Single Sign-On > Authentication Sources).

4.2 Navigate from Applications > Single Sign-On > Settings, and open the Routing rules tab. The current default rule is shown at the top.

4.3 Select + Add routing rule. Give it a descriptive name (for example, CSE Policy Engine Routing) and use the Routing rule status toggle to enable it.

4.4 Under conditions, select Specific SSO applications and choose the applications to migrate first using the SSO Applications field.

Warning: Do not select all applications or change the default rule here until you are ready to route all applications through CSE. Multiple conditions within one rule are combined with AND logic.

4.5 In the Result section, select the CSE Policy Engine authentication source, then Save.

4.6 Optionally set the rule’s Priority so it is evaluated ahead of the default rule. Rules are evaluated in descending priority order, and the highest-priority matching rule wins.

The summary of your routing configuration is then as follows:

To expand the rollout, edit the custom rule’s SSO Applications list to add more applications over time.

Note: Duo supports up to 10 SAML and 10 Active Directory authentication sources, and up to 30 routing rules total. Each rule resolves to exactly one authentication source; you cannot fan a single application out to multiple sources.

5.1 Confirm your CSE Web Policy enforcement mode:

• A policy in enforcement mode will not allow any fallback for devices that do not meet the trust levels in your Web Policy.
• A policy in permissive mode will allow a fallback for users whose devices are not yet registered. Begin in permissive mode and move to enforcement after validation. See setting up policies.

5.2 Make CSE the default. In Applications > Single Sign-On > Settings > Routing rules, change the default routing rule to resolve to the CSE Policy Engine SAML authentication source.

Warning: Editing the default rule’s source affects every application not matched by a higher-priority custom rule at once. Complete this only after validating the phased set from Step 4, and only after confirming the device-registration and Owner break-glass paths from Step 3 are still reachable via higher-priority rules.

The summary of your routing configuration is then as follows:

Now all Duo SSO authentication traffic (except the explicitly excluded enrollment/break-glass path) is routed to CSE for policy enforcement.

Passwordless is recommended to provide an optimal user experience when accessing applications on CSE registered devices. If Passwordless is not enabled, end users will default to credential entry at the upstream step.

Passwordless authentication with CSE leverages the fact that the trusted Device Certificate includes the user’s email address in the UserPrincipalName SAN extension field. When Passwordless is enabled, the device certificate presented during device trust is used to extract the authenticating user, who is then issued a TrustToken without a username/password prompt. CSE then returns the SAML assertion to Duo SSO.

1. Edit the existing CSE IDP-Routed SaaS app from Step 1.

2. Enable Passwordless Authentication.

In the setup above, all users matched by the CSE routing rule are sent to CSE for policy enforcement. To exempt specific types of users, use a higher-priority routing rule rather than a per-application setting. We recommend keying the exemption on group membership (a user’s login attributes), not on source-IP network zones or browser-based device sniffing.

1. Add a routing rule called CSE Exempt Users Routing, set its condition to Specific groups, and choose the group(s) to exempt. In the Result section, select your existing non-CSE source (Duo-hosted users or Active Directory).

2. Give this rule a higher Priority than the CSE Policy Engine Routing rule so it is evaluated first.

The summary of your routing configuration is then as follows:

Note: Duo evaluates routing rules in descending priority order, and the highest-priority matching rule wins; a user matched by the exempt rule never reaches the CSE rule.

The CSE device-registration and Service Tunnel / infrastructure authentication flows should not themselves be federated to CSE, or new and unregistered devices cannot establish trust. Exclude these from the CSE routing rule.

1. Edit the CSE Device Registration / Break-glass Routing rule from Step 3.

2. Add the application(s) used for CSE app authentication (device registration, Service Tunnel, and infrastructure access) to that rule’s SSO Applications condition, and Save.

Now those flows authenticate against your existing source rather than being routed back through CSE.

By default, after Duo SSO delegates primary authentication to the CSE SAML source, Duo SSO still prompts for its own Duo two-factor authentication before permitting access. When the upstream CSE step already enforced strong device-based authentication, this produces a duplicate prompt.

Duo model difference. Okta avoids the double prompt with an IdP-based Sign-On policy that scopes the MFA rule to a chosen IdP. Duo has no SAML assertion attribute or “trust the upstream IdP” toggle that automatically skips its own second factor — Duo always treats the external SAML source as primary auth only. Suppressing the Duo second factor is an explicit administrator choice via a Duo Authentication policy.

To suppress the second prompt, apply a Duo Authentication policy whose option is Bypass 2FA (shown in some Duo editions as Skip MFA) at the per-application level. See Duo policy documentation.

1. Open the specific Duo SSO application’s properties page and scroll to the Application policy block.

2. Select Apply a policy to all users.

3. Select (or create) a custom policy whose Authentication policy is set to Bypass 2FA, then click Apply Policy.

Because an application policy overrides the Global Policy, this suppresses Duo’s second factor for all users of that one application.

Warning: Applying Bypass 2FA at the application level removes Duo’s MFA for all users of that application, not only the users who completed strong upstream authentication at CSE. If only a subset should be exempt, attach the Bypass 2FA policy as a Group policy / custom application-group policy instead. Exact label casing (Bypass 2FA vs. Skip MFA, Enforce MFA vs. Require two-factor authentication) varies across Duo editions; verify the live label in your tenant.

Note: If upstream-authenticated users who do not yet exist in Duo should not be forced into Duo enrollment, set the New User policy option to Allow access without MFA (rather than the default Require enrollment) in the same policy.

If the user’s device is registered and the Service Tunnel is established, the application redirects to Duo SSO, Duo SSO routes the user to the CSE SAML authentication source, CSE completes device trust (and Passwordless authentication, if enabled) and returns a signed assertion, and Duo SSO completes sign-in. The user reaches the application.

If the user does not have the Service Tunnel established, or the device is not registered, CSE’s device-trust check fails before Duo SSO can complete sign-in. With the Web Policy in enforcement mode, the user is blocked at CSE and is denied access to every application routed through the CSE authentication source. With the Web Policy in permissive mode, an unregistered user is allowed to fall back according to your policy configuration.

The Duo Admin Panel remains independently accessible to Owner-role administrators via the username/password break-glass path, even if the end-user federation to CSE is unavailable.