Notifications
Clear all
Topic starter
16/08/2026 1:12 pm
TL;DR: Role-based MFA can strengthen Zendesk SSO so billing agents face stronger authentication before accessing sensitive ticket data, while customers and other users keep a simpler login path, according to Descope. The governance lesson is that SSO unifies access, but privilege-sensitive step-up controls still determine who can touch high-risk information.
NHIMG editorial — based on content published by Descope: Adding Zendesk SSO With Descope [Step-by-Step Guide]
Questions worth separating out
Q: How should organisations use MFA and SSO together for enterprise access?
A: Use SSO to centralise sign-in and reduce password sprawl, then apply MFA wherever the account, session, or action carries real business risk.
Q: Why do support platforms need role-based authentication policies?
A: Support environments often mix customers, standard agents, and privileged agents in the same application.
Q: How do access groups affect authentication decisions in SaaS applications?
A: Access groups can become policy inputs when the application or identity provider checks them during login.
Practitioner guidance
- Map sensitive support workflows to assurance tiers Identify which Zendesk actions expose billing, customer records, or account recovery data, then require step-up authentication only for those paths.
- Treat group membership as a governed entitlement source Review how Zendesk groups are created, updated, and revoked, and define ownership for the Billing group or any equivalent privileged support group.
- Harden API-backed policy checks Protect the Zendesk API token as a secret, limit its scope, and monitor the connector path that retrieves user IDs and group membership.
What's in the full article
Descope's full guide covers the implementation detail this post intentionally leaves at a higher level:
- Exact Zendesk Admin Center navigation for SAML SSO setup and configuration fields
- Step-by-step examples of Descope flow configuration, including scriptlets and condition logic
- API request structure for pulling Zendesk user IDs and group memberships into the authentication flow
- Practical examples of mapping role membership to step-up MFA decisions inside the flow
👉 Read Descope's step-by-step guide to Zendesk SSO and role-based MFA →
Zendesk SSO and role-based MFA: what changes for IAM teams?
Explore further
16/08/2026 1:13 pm
Support platform access is not a single identity problem. Zendesk combines ordinary end-user access with higher-risk agent access, and the billing use case makes that split visible. IAM teams should not assume that one SSO session is sufficient to govern every support workflow. The practical conclusion is that the same application can need both convenience controls and high-assurance controls at different points in the workflow.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why entitlement-driven access checks become fragile when they are not continuously governed.
A question worth separating out:
Q: What should teams verify before enforcing MFA for privileged support users?
A: Verify that the identity mapping is correct, the API or directory source is current, and the policy fails safely when entitlement data is missing. You should also test whether the privileged path is limited to the intended functions, so MFA is tied to real exposure rather than a symbolic role label.
👉 Read our full editorial: Zendesk SSO with step-up MFA for billing agents
