duo sso access_denied user canceled mfa

duo sso access_denied user canceled mfa

TL;DR

This error means the user tapped Deny on the Duo push or let it expire, not that anything is broken. Have the user retry the login and approve the push promptly when it arrives. If pushes never arrive, re-enroll the device in Duo; for automated test logins, use a Duo bypass code instead of fighting the push flow.

duo sso access_denied user canceled mfa

Use this when

• Duo SSO login fails with access_denied right after the MFA step
• The Duo authentication log shows the user denied the push
• Test automation cannot get past the Duo prompt

Not for this skill when

• Duo device enrollment or activation failures (different flow)
• access_denied from an access policy or group rule (check policy first)
• Users who never receive any push (enrollment or connectivity issue)

Steps

Step 1: Have the user retry and approve promptly

Ask the user to start the login again and approve the Duo push within its short lifetime. Expected: the login completes and the app session starts.

Step 2: Check the Duo authentication log

In the Duo Admin Panel, open Authentication Log and find the event. Confirm it shows a denied or timed-out push for that user and timestamp. Expected: the log confirms user action, not a system error.

Step 3: Re-enroll if pushes never arrive

If the user reports never seeing the push, walk them through Duo device re-enrollment or switching to a passcode. Expected: a test push arrives and approves cleanly.

Step 4: Use bypass codes for automation

For service accounts and test logins, generate a Duo bypass code in the Admin Panel and use it instead of the push flow. Expected: automated logins pass MFA without human taps.

Step 5: Reduce prompt fatigue

Enable remembered devices or adjust the new-user policy so legitimate users are not drowning in pushes. Expected: fewer pushes per user per day, fewer accidental denies.

Tool compatibility

Duo (Cisco Duo) with SSO integrations; Duo Admin Panel authentication logs; any SAML/OIDC app fronted by Duo MFA.

Variant phrasings

Variant 1

duo access_denied user cancelled mfa push

Variant 2

duo sso login failed user denied push notification

Variant 3

duo mfa push expired access denied sso

Why it happens

Duo sits between the identity provider and the app: after primary authentication it issues its own MFA challenge, and the result comes back as an allow or a deny. A deny, whether the user tapped it deliberately or the push expired unanswered, surfaces to the app as a plain access_denied, which looks like a system failure in logs. The push lifetime is short by design, so slow phones, notification delays, and verified-push number matching all raise the deny rate. There is no server-side fix for a human tapping Deny; the work is in distinguishing user action from device problems via the Duo log, then fixing enrollment or reducing prompt volume.

Edge cases / pitfalls

• Verified Push (number matching) confuses some users; they stare at the number instead of entering it.
• Offline TOTP passcodes work when pushes cannot arrive; make sure users know the fallback exists.
• A flood of unexpected pushes can mean someone else is trying the user's password; treat unprompted pushes as a security signal, not just noise.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dc6qTY6cOSMxu7uLiEk4mQ