wif.tax

Cisco

F Duo Admin API

Automating Duo means an Admin API integration key and secret key that sign every request with HMAC. The secret never expires, shows no last use and is not a GitHub secret-scanning partner, though it has granular permissions and can be reset over the API. There is no OIDC or federation path. Directory sync from Entra ID and Google is consent-based, but device-trust integrations want pasted client secrets, API keys or passwords.

Docs: duo.com · Checked 2026-10-22 · source YAML · dispute via PR

Inbound Frequires Duo Essentials, Advantage or Premier (Admin API is not on the free plan)

How a workload running anywhere authenticates to this product.

Admin API application created by an Owner in the Duo Admin Panel: a static integration key (HTTP Basic username) and secret key used as the HMAC-SHA512 (v5) or HMAC-SHA1 (v2, legacy) signing key on every request.

No OIDC, JWT bearer, token exchange, cloud workload identity or mTLS option is documented for the Admin API, so the weakest (and only) path is the static ikey/skey pair. HMAC signing means the secret key itself never crosses the wire and requests carry a Date header, which limits replay, but the key is still a long-lived shared secret that Duo stores in recoverable form (the API's Retrieve Secret Key endpoint returns it in plain text to a sufficiently privileged Admin API app). Optional "Networks for API Access" IP allowlisting is a useful compensating control, not an identity. The "sso-oauth-client-credentials" integration type in the same API is Duo SSO acting as an OAuth server for your own APIs, not a way to authenticate to Duo. With 2 of 5 hygiene checks passing, the grade is F; an enforced expiry plus a last-used timestamp would make it D.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

Entra ID and Google Workspace directory sync use admin consent to Duo's own app (keyless). Trusted Endpoints device-management integrations want a pasted Entra client secret (Intune), Jamf Pro or Ivanti/Sophos user passwords, a CrowdStrike API client secret, a Cisco Secure Endpoint API key or a Meraki API key. AD and OpenLDAP sync run through the customer-hosted Duo Authentication Proxy, which holds the directory bind password locally.

Checked: directory sync for AD, Entra ID, Google, Okta, OpenLDAP and generic SCIM (overview at duo.com/docs/directorysync), and Trusted Endpoints integrations for Intune, Jamf Pro, CrowdStrike Falcon, Cisco Secure Endpoint, Meraki Systems Manager, Workspace ONE, Ivanti Neurons for MDM and Sophos Mobile. Keyless: Entra ID sync (admin consent) and Google sync (OAuth authorization by a Google admin, re-authorized when it lapses). Okta and generic SCIM push into Duo with a Duo-issued bearer token (an inbound credential that expires every 90 days), so Duo never reaches into Okta. AD and OpenLDAP sync never hand Duo a directory credential: the bind password stays in authproxy.cfg on a host you run (optionally encrypted on Windows hosts), though that host also stores a Duo ikey/skey. The device-trust integrations are the static part: Intune wants a client secret on an Entra app you register (customer-managed OAuth secret, C-like), while Jamf, Workspace ONE, Ivanti and Sophos want an API user's password and Meraki, Secure Endpoint and CrowdStrike want API keys or client secrets. Duo does give least-privilege guidance throughout (read-only Graph permission, Jamf Auditor privilege set, read-only Secure Endpoint scope). Keyless on some, static on others is B; Intune via admin consent or a federated credential on Duo's multi-tenant app would be the obvious fix.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
Neither the Admin API integration object nor the Admin Panel docs offer an expiry date or an org policy that forces one; the secret key lives until someone resets it, and Duo frames resetting as a compromise response. Contrast Duo's own bypass codes and SCIM tokens, which do carry expirations.
  • duo.com checked 2026-10-22
    “If you suspect a compromise of the credentials of your Duo application you may want to reset the application's secret.”
  • duo.com checked 2026-10-22
    “Secret used when configuring systems to use this integration. The secret key will be hidden, showing only the last four characters.”
✓ Rotation via API
POST /admin/v3/integrations creates an Admin API app, POST /admin/v3/integrations/[ikey] with reset_secret_key=1 resets a secret and DELETE removes one, all needing "Grant applications". An app cannot reset its own secret, and a reset is an instant cutover with no overlap, so automated rotation needs a second privileged Admin API app or a create-new-then-delete-old pattern.
  • duo.com checked 2026-10-22
    “If set to 1, resets the integration's secret key to a new, randomly generated value. The new secret key is returned in the return value.”
  • duo.com checked 2026-10-22
    “Create a new integration. The new integration key and secret key are randomly generated and returned in the response.”
  • duo.com checked 2026-10-22
    “Attempting to reset the secret key for the same Admin API integration whose integration key and secret key are used to make this call will return an error.”
  • duo.com checked 2026-10-22
    “There is no way to make the previously-used secret key or client secret value valid for use after the reset.”
✓ Scoped keys
Each Admin API application is a purpose-built machine principal, not tied to a human admin, with its own set of permission toggles (read log, read or write resource, settings, applications, administrators, identity verification) plus optional source-IP restriction. Permissions are account-wide per category rather than per object.
  • duo.com checked 2026-10-22
    “Determine the permissions you want to grant to this Admin API application.”
  • duo.com checked 2026-10-22
    “The Admin API application can read authentication, offline access, telephony, and administrator action log information.”
✗ Last-used visible
The integration object returned by GET /admin/v3/integrations has no last-used or last-authenticated field, and the Protecting Applications page shows none for application secrets, even though Duo tracks date_last_used for user WebAuthn credentials. Admin action logs record what an Admin API app changed, not when its key was last presented.
  • duo.com checked 2026-10-22
    “The date the WebAuthn credential was last used.”
  • duo.com checked 2026-10-22
    “Returns a paged list of integrations.”
✗ Leak revocation
Neither Duo nor Cisco appears in GitHub's supported secret-scanning patterns table, so a leaked Duo secret key pushed to a public repo is not reported to Duo. Third-party scanners (for example GitGuardian) detect Duo keys, but that does not trigger revocation.

Notes

Graded on the Admin API, the documented way to automate Duo administration (MSP subaccounts are managed through the same Admin API app via subaccount permissions). The sibling Auth API uses the same ikey/skey HMAC scheme on its own application type and was not graded separately. Two of five hygiene checks pass (rotation API, scoping). Inbound moves to D with an enforceable expiry and a last-used timestamp, plus GitHub partner revocation for good measure, and to B or A only if the Admin API accepts a federated token instead of an HMAC secret.

Badge

wif.tax grade F

[![wif.tax grade](https://wif.tax/badge/cisco-duo-admin-api.svg)](https://wif.tax/p/cisco-duo-admin-api/)