Duo is often deployed as the MFA layer in front of VPNs, SSO and servers, and then left on settings that let attackers walk around it: unenrolled users allowed in, plain push approvals, bypass codes that never expire and Admin API keys with every permission. An MFA platform is only as strong as its weakest policy and its least protected administrator, and attackers who cannot beat the second factor go after the help desk, the bypass process or the API instead. This guide covers Duo policies, authentication methods, Verified Duo Push, admin roles, bypass codes, Admin API and Auth API credentials, lockout settings and logging, using the setting names from Duo's own documentation. It is written for identity engineers and security teams running Duo for a workforce, and it explains options without recommending a vendor.
Key takeaways
- Policy decides more than the factor. The New User Policy, Authentication Policy and authentication methods at global, user-group and application level decide whether MFA is enforced at all, so audit every application-level override.
- Retire plain push. Use Verified Duo Push, risk-based factor selection and passkeys or security keys for admins, and remove SMS and phone callback where users have alternatives.
- Bypass is the back door. Bypass status, bypass codes with "Never" expiry and help desk staff who can create codes on request are what social engineers target.
- Admin API keys are privileged non-human identities. Grant only the permissions an integration needs, restrict "Networks for API Access" and rotate the secret key.
- Turn on the lockout and push-throttling settings that are off by default and send authentication and administrator logs to your SIEM, because the Admin Panel only shows 180 days.
How identity and access work in Duo
Duo sits in front of an application as a second factor (or, with Duo Single Sign-On and Duo Passwordless, as the primary login). Each protected system is an application in the Admin Panel with its own integration key, secret key and API hostname. Users are enrolled with one or more devices: Duo Mobile, passkeys and security keys, hardware tokens or phone numbers.
Access decisions come from policies, applied in this order of precedence, highest first:
- Application-group policy
- Application policy
- User-group policy
- Global Policy (built in, cannot be deleted)
The practical consequence is that a strict Global Policy can be quietly undone by one application policy set to Bypass 2FA or Allow access without MFA. Hardening therefore starts with an inventory of every custom policy and where it is applied.
| Policy setting | Options (default first where documented) | Hardened choice |
|---|---|---|
| New User Policy | Require enrollment (default for new applications), Allow access without MFA, Deny access | Deny access for privileged and remote-access applications; Require enrollment elsewhere. Never Allow access without MFA. |
| Authentication Policy | Enforce MFA (default), Bypass 2FA, Deny access | Enforce MFA. Treat any Bypass 2FA policy as an exception with an owner and expiry. |
| Authentication methods | Duo Push, Verified Duo Push, passkeys and security keys, Duo Mobile passcodes, hardware tokens, SMS passcodes, phone callback, bypass codes | Verified Duo Push or phishing-resistant methods; remove SMS and phone callback where possible; enable bypass codes only if your recovery process needs them. |
| Remembered Devices | Risk-based remembered devices, 30 days by default (Advantage and Premier); maximum 365 days | Risk-based remembering with a short window; no remembering for admin and remote-access applications. |
| User Location | Default: no change to requirements per location | Block or require stronger authentication for countries where you have no staff; leave "Only check access device IP" off. |
| Trusted Endpoints | Allow all endpoints (default, records trust only) | Require endpoints to be trusted for sensitive applications once the endpoint inventory is complete. |
| Duo Desktop and device health | Don't require, Check but don't require, Require Duo Desktop; health checks for firewall, disk encryption, system password | Start with Check but don't require to measure, then Require for sensitive applications. |
| Operating Systems | Major OS families allowed with no warnings | Warn, then block out-of-date OS versions with a grace period. |
Several of these settings depend on the Duo edition (Essentials, Advantage or Premier). For MFA design beyond Duo see the MFA Guide.
Verified Duo Push and risk-based factor selection
Plain push approval is what MFA fatigue attacks exploit (ATT&CK T1621 Multi-Factor Authentication Request Generation): the attacker has the password and keeps sending prompts until the user taps approve. Both the Uber breach and the Cisco breach followed this pattern, and in the Cisco case the attacker then enrolled new MFA devices of their own. Verified Duo Push shows a code on the login screen that the user must type into Duo Mobile, so a user who did not start the login has nothing to enter.
- Code length: three to six digits; Duo documents six as the default for risk-based step-up, and admins can lower it in the policy. Shorter codes trade a little security for usability.
- Risk-based factor selection (Advantage and Premier): detects user marked fraud, push harassment (one user targeted), push spray (many users), unrealistic travel, country code mismatch, novel ASN and device distance. On detection the user must complete a stronger method: Verified Duo Push instead of push, and push without a code, Duo Mobile passcodes, SMS, phone callback and most hardware OTP tokens are refused until one secure authentication succeeds.
- Coverage gap: risk-based factor selection works with the Universal Prompt and Auth API applications but not Windows Logon or Duo Unix, so set Verified Duo Push directly in policy for those.
- Choosing between them: always-on Verified Duo Push gives uniform protection and is the simpler choice for small organisations; risk-based selection keeps plain push for low-risk logins and steps up only on signals, which suits large user populations where friction drives help desk calls. Admins and remote access should be on phishing-resistant passkeys or security keys regardless. See the MFA Fatigue and Bypass Guide and the Phishing-Resistant MFA Guide.
Admin roles and privileged access
A Duo administrator can disable MFA for any user or application, so the Admin Panel is a tier-zero system. Duo's built-in roles, in descending order of privilege:
| Role | Can do | Risk if misused |
|---|---|---|
| Owner | Everything, including managing admins and creating Admin API and Account API applications | Full control; can mint API keys that persist after the person leaves |
| Administrator | Users, devices, policies, applications (not Admin or Account API), SSO and Passwordless settings | Can weaken policy or add a bypass application |
| User Manager | Users, phones, tokens, bypass codes, directory sync; bypass status unless restricted | Can enrol an attacker device or put a user in bypass |
| Help Desk | User attributes, phones, tokens, bypass codes, enrollment emails and activations | Prime social engineering target: a convincing caller gets a bypass code or a new device |
| Security Analyst | Risk events, lock out users, view all logs and reports | Low write risk; good fit for SOC staff |
| Application Manager | Add and update applications, manage SSO authentication sources, assign existing policies | Can attach an application to a weaker existing policy |
| Billing, Read-only, Account Switcher | Billing pages; read-only views; switching to subaccounts | Low |
- Owners: keep at least two, as Duo recommends, and no more than you need. Owners never expire under the Inactive Admins setting, so review them manually.
- Admin authentication methods: in Administrator Login Settings, keep passkeys, Yubikey AES and Verified Duo Push, and leave SMS passcodes, phone callback and Duo Mobile passcodes disabled (their defaults).
- Admin SSO: set Authentication with SAML to Required so non-Owner admins log in through your IdP; Owners can still use a password, which makes them your break-glass accounts. See the Break-Glass Account Guide.
- Sessions and dormancy: shorten the absolute session (default 4 hours, range 15 minutes to 10 hours) and idle timeout (default 30 minutes), enable Inactive Admins (30 to 365 days) and keep the admin password minimum at 12 characters or more.
- Scope: use Administrative Units to limit regional or business-unit admins to their own users and groups, and custom roles where a built-in role grants too much.
Bypass controls
| Mechanism | Default behaviour | Hardening |
|---|---|---|
| Bypass status (user) | User skips Duo MFA on every login; each bypass is logged. Set by Owners, Administrators and User Managers. | Use only with a ticket and an end date. Untick "Allow admins with User Manager role to put users in bypass status" (on by default). Alert on any user in Bypass. |
| Bypass codes | Random code, one use or 60 minutes. Can be set to a custom nine-digit code, "Never" expiry and "Unlimited" uses; up to 100 active codes per user. | Keep single use and short expiry; set endpoint verification to "Always required"; forbid "Never" and "Unlimited" by procedure. |
| Help Desk code creation | Help Desk can create and customise codes | Enable "Do not allow admins with the Help Desk role to customize bypass codes", or "...to create bypass codes" if a second team verifies identity. |
| Bypass Authentication Policy | Application or group set to Bypass 2FA | Inventory, owner and expiry for every instance; replace with Authorized Networks or device trust where the reason is a machine login. |
One subtle point: if remembered devices are enabled, a trusted session created with a bypass code can outlast the code. Disable remembering on applications where bypass codes are used for recovery, and tie code issue to verified identity. See the Account Recovery and Help Desk Security Guide; the MGM Resorts breach shows how attackers say a single help desk call led to administrator access in an identity provider.
Integrations, API tokens and service accounts
Every Duo application has an integration key, a secret key and an API hostname. Duo's own documentation tells you to treat the secret key like a password. These keys are non-human identities, and some of them are very powerful.
| Credential | What it can do | Controls |
|---|---|---|
| Admin API application | Depends on grants: Grant administrators (Read or Write), Grant read information, Grant applications, Grant settings, Grant read log, Grant resource (Read or Write), Grant identity verification, Grant set Admin API permissions | Only Owners can create them. Grant the minimum (a SIEM connector needs Grant read log only). Never grant administrators, settings or set permissions to automation without review. Set "Networks for API Access". |
| Auth API application | Run /preauth and /auth to authenticate users; a /preauth result of allow skips the second factor | Limit User access to selected groups; the key cannot call Admin API endpoints (they return 403). |
| Protected application keys (RDP, VPN, SSH, web SDK) | Let the integration call Duo for that application | Store in a vault or protected config file; rotate on staff change or host compromise. |
| Accounts API (MSPs) | Manage subaccounts | Owner only; restrict as for Admin API. |
- Signing: API requests are signed with HMAC; use v5 signing (SHA-512) in custom code rather than legacy v2 (SHA-1).
- IP restriction as detection: Duo checks the network after verifying the signature, so a correctly signed request from an unexpected network is a strong sign that the secret key has leaked.
- Write permissions are account takeover: an Admin API key with Grant resource - Write can add phones, create bypass codes or change user status. That key deserves the same storage and rotation as an Owner password (ATT&CK T1098 Account Manipulation, T1556.006 Multi-Factor Authentication).
See the Secrets Management Guide and the Service Account Security Guide for lifecycle controls, and the Dropbox Sign breach for what follows when a back-end service account with access to API keys and MFA secrets is compromised.
Logging and detection
Duo keeps logs indefinitely by default, but the Admin Panel, reports and the Admin API can only reach back 180 days, so forward logs to a SIEM with a read-log-only Admin API key. Three logs matter: the Authentication Log (every attempt with result and reason), the Administrator Actions log (admin logins and changes to users, phones, tokens, applications and admins) and the Telephony Log (calls and SMS sent, with credits used).
Trust Monitor was removed from the Admin Panel in July 2026, with Cisco Identity Intelligence as the replacement in Advantage and Premier; the Trust Monitor Admin API endpoint reaches end of support on 31 January 2027, so move any integration that reads it.
| Detection | Source | Why |
|---|---|---|
| Many denied or timed-out pushes for one user, then a success | Authentication Log | MFA fatigue (T1621) |
| User marked a push as fraudulent | Authentication Log, lockout notification email | Password known to an attacker; reset it |
| New phone or token added shortly after a help desk interaction or from a new location | Administrator Actions, Authentication Log | Attacker device enrolment, as in the Cisco breach |
| Bypass code created, user set to Bypass, or policy changed to Bypass 2FA | Administrator Actions | MFA weakening (T1556.006) |
| New Admin API application or permission change | Administrator Actions | Persistence through API keys (T1098) |
| Spike in SMS or calls to unusual country codes | Telephony Log | Toll fraud or SMS pumping |
Metrics: percentage of authentications using Verified Duo Push or phishing-resistant methods; number of users in Bypass status and their average age; bypass codes issued per month and the share with non-default expiry; number of Owners and admins without SAML login; number of Admin API applications with write grants or no network restriction; and percentage of applications on a non-global policy. See the SIEM Guide.
Hardening baseline
| Area | Setting | Default | Hardened |
|---|---|---|---|
| Lockout and Fraud | MFA failed attempts threshold | 10 | Keep or lower; route notifications to the SOC mailbox, not "Notify all admins" only |
| Lockout and Fraud | Password failed attempts threshold (Duo SSO) | 20 | Align with your password policy |
| Lockout and Fraud | Block frequent Duo Push attempts | Off | On (blocks a new push within 15 seconds of an unanswered one) |
| Lockout and Fraud | Unenrolled user lockout | Off | On; Duo suggests 30 days |
| Lockout and Fraud | Revert MFA lockout | Off | Leave off so a person reviews each lockout |
| Enrollment | Enrollment code and email link expiry | 24 hours; 30 days | Shorten the email link so stale invitations cannot be claimed |
| Telephony | Max credits per action | 20 | Lower, and set a low-credit alert |
| Admin login | Authentication with SAML | Disabled | Required |
| Help desk | Bypass code customisation and creation | Allowed | Restricted |
Rollout order
- Inventory: export applications and their policies, users in Bypass or Disabled status, admins and roles, and Admin API applications with their grants and networks.
- Protect the Admin Panel first: require SAML for admins, restrict admin factors to phishing-resistant methods and Verified Push, enable Inactive Admins and remove surplus Owners.
- Fix bypass paths: remove Allow access without MFA and Bypass 2FA policies or give each an owner and expiry; restrict help desk bypass code powers; move users out of Bypass status.
- Pilot Verified Duo Push on a user group through a group policy, measure help desk calls for two weeks, then apply globally. Roll back by removing the group from the pilot policy.
- Move device trust from measure to enforce: "Check but don't require" Duo Desktop and Allow all endpoints first, review the trust data, then require trusted endpoints on sensitive applications.
- Lock down API keys: reduce grants, add network restrictions, rotate the secret keys and store them in a vault.
- Connect logging to the SIEM, build the detections above and review the metrics monthly.
Small vs large organisations: on Duo Free all admins are effectively Owners, so the main controls are few admins, strong admin factors and the policy settings available on that edition. Larger tenants should use Administrative Units, custom roles, risk-based factor selection and a separate identity-verified team for bypass issuance.
Common misconfigurations
- New User Policy left at Allow access without MFA on VPN or remote access, so anyone with a password and no enrolled device gets in. The Change Healthcare breach shows the cost of one remote login without MFA.
- Plain Duo Push with no throttling, leaving users to stop fatigue attacks on their own.
- Permanent bypass: users in Bypass status for years, and reusable bypass codes with "Never" expiry kept in a help desk spreadsheet.
- An all-powerful Admin API key created by an Owner for a one-off script, stored in a repository and never rotated.
- Admin login on SMS or phone callback, or Owners with no hardware-backed factor.
- Logs left in the Admin Panel, so evidence older than 180 days is unreachable during an investigation.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| MFA policy, Verified Push, admin factors | IA-2, IA-2(1), IA-5 | PR.AA-03 | Control 6 | A.8.5 |
| Admin roles, bypass, help desk | AC-2, AC-6 | PR.AA-01, PR.AA-05 | Control 5, Control 6 | A.5.15, A.5.17, A.8.2 |
| Policy configuration and device trust | CM-6 | PR.PS-01 | Control 4 | A.8.9 |
| Logging and detection | AU-2, AU-6 | PR.PS-04, DE.CM-03 | Control 8 | A.8.15, A.8.16 |
Practitioner checklist
- List every application and group policy and remove or time-limit Bypass 2FA and Allow access without MFA settings.
- Enable Verified Duo Push (or risk-based factor selection) and remove SMS and phone callback where users have alternatives.
- Require SAML for admin login, keep at least two and few Owners, and restrict admin factors to passkeys, security keys and Verified Push.
- Enable Inactive Admins, shorten admin sessions and use Administrative Units or custom roles for scoped admins.
- Restrict help desk bypass code creation and customisation, stop User Managers setting bypass status and alert on all bypass events.
- Turn on Block frequent Duo Push attempts and Unenrolled user lockout, and route lockout and fraud emails to the SOC.
- Reduce Admin API grants to the minimum, set Networks for API Access, rotate and vault every secret key.
- Forward Authentication, Administrator Actions and Telephony logs to the SIEM and replace any Trust Monitor API integration before 31 January 2027.
Standards and references
- Duo: Policy and Control
- Duo: Managing Duo Administrators
- Duo: Managing Users (bypass codes and user status)
- Duo: Account Settings
- Duo: Risk-Based Authentication
- Duo: Admin API
- Duo: Reporting and logs
- MITRE ATT&CK: T1621 Multi-Factor Authentication Request Generation
Related NHI Mgmt Group resources: MFA Fatigue and Bypass Guide · Phishing-Resistant MFA Guide · Top 10 MFA Mistakes · Account Recovery and Help Desk Security Guide · Keycloak Hardening Guide