Duo: who is protected by multi-factor, and who is not

Duo is the multi-factor layer in front of your partners' logins. This connector reads three things out of it: who is actually protected, who is not, and what is happening at the sign-in prompt. The number an owner cares about is not how many licences they bought; it is how many of their people can still sign in with a password alone, and what in the account's own settings lets them. Everything hangs off the matching Current company, so it feeds your business reviews and the company alert band. The reporting key reads Duo and can never change anything in it.

Covered means a person whose account is active, who has a second factor enrolled, and who is not in bypass. Coverage is the covered people out of the covered people plus the people at risk; people who cannot sign in at all, and people Duo gave no clear answer for, are left out of both. The company page shows it as MFA covered. The People section, the dashboards and business reviews all use that one definition, so the coverage figure on a company card and the one in a review always agree. The authenticator mix calls a person SMS only when none of their devices can receive a push and at least one can receive SMS codes; a person with Duo Mobile on their phone is never counted as SMS only, even if the phone can also take a text.

A Duo account can be fully enrolled and still let people in without a second factor, because its policies say so. Current reads the account's policies and flags each setting that does it:

• ＋The global policy bypasses the second factor for everyone it covers.
• ＋Some other policy bypasses it, for the applications or groups that policy covers.
• ＋A new user policy lets people Duo has never seen sign in without MFA.
• ＋A list of network addresses where the second factor is not required.
• ＋A list of countries, or a default, that lets people in without the second factor.
• ＋How long a remembered device can skip the second factor, shown as the longest window any policy allows.

When a mapped Duo account has any of the first five, the company alert band raises an entry saying people can sign in without MFA because of a policy, and names the setting. It is critical when the global policy bypasses the second factor or lets unknown new users in without MFA, because those reach everyone, and a warning otherwise. It clears itself once a complete read finds none of them. On the company page, Policy gaps reads as a count of Duo accounts, such as 1/3: the accounts with a policy that lets people skip MFA, out of the accounts whose policies Current read. The policy figures stay blank, never a clean result, when Current could not read the policies, and the stat then says policies not read.

Duo's licensing rule is that every user in the Admin Panel consumes a seat except users in the Trash, which Duo calls pending deletion. Active, bypass, disabled and locked-out users all count, and so does a user who never finished enrolling or has no phone at all. Administrators never consume a seat. Current applies that rule to the users it read and shows the result as billable users beside the account's edition. It writes the number only after reading every user in that account on that run; a run that stopped part way leaves the previous figure in place rather than a smaller one.

Duo retired its separate Accounts API on June 11, 2026, and converted every existing Accounts API integration to an Admin API one with no action needed from you. Subaccounts are now read through the Admin API, so one Admin API application in your main account is all Current needs, however many partners you manage. There is no application to create inside each subaccount.

1. 1
   1 · Sign in to the Duo Admin Panel as an owner

   Only an administrator with the Owner role can create an Admin API application. If you manage partners as subaccounts, sign in to your main (parent) account. The Admin API itself is available on the Essentials, Advantage and Premier plans and on Advantage and Premier trials; a free Duo account has no Admin API at all.
2. 2
   2 · Add the Admin API application

   Go to Applications, then Application Catalog, find Admin API, and add it. Duo creates the application and shows its page.
3. 3
   3 · Tick the three read permissions, and leave every write permission off

   Tick Grant read information (the account summary and the daily sign-in totals), Grant resource - Read (people, devices, groups, endpoints, applications, policies and bypass codes), and Grant administrators - Read (the administrator counts, which Duo also requires Grant resource - Read for). Current reads no Duo log, so there is no log permission to tick. If you manage partners as subaccounts, the application page has a Subaccount permissions section: tick Grant accounts - Read there (it reads the list of subaccounts and their editions) plus the same three read permissions. Leave every write box unticked, including Grant resource - Write, Grant applications, Grant settings, Grant accounts - Write and Grant set Admin API permissions. That way this key has no way to change anything in Duo, which is a stronger guarantee than any promise Current can make about its own code.
4. 4
   4 · Copy the three values

   The application page shows an integration key, a secret key, and an API hostname. The hostname looks like api-XXXXXXXX.duosecurity.com. Copy it exactly as Duo shows it, including for a data-residency account where it may look different. Current takes it as given and never rewrites it.
5. 5
   5 · Paste all three into Current and test

   Integrations → Duo → Connect. Paste the API hostname, the integration key and the secret key, then press Test connection. Current signs a read to confirm the key works, lists how many subaccounts it can see if you manage any, and reports each area it reads as working, not included in the account's Duo edition, or refused for a missing permission. An area your edition does not include does not fail the test. The values are stored server-side only; they are never shown again and never reach your browser. The secret key never travels to Duo at all. Current uses it to sign each request rather than sending it.

If you manage partners as Duo subaccounts, each subaccount is one end-customer and Current lists all of them, plus your own parent account, which holds your own staff and which you can map to your own company or ignore. If your key covers a single Duo account, or Duo reports no subaccounts, Current writes exactly one entry so the mapping panel works the same way. Either way, Current links each account to a Current company by normalized name (lowercased, with punctuation and Inc/LLC/Ltd-style suffixes stripped) when exactly one company matches. When two or more of your companies share that name and the names differ only by a suffix like Inc or LLC, Current links the one that is an active customer, or, if none of them is, the one linked to your PSA. Anything still tied stays unmapped for you to decide.

1. 1
   Let the auto-matcher run first

   Every sync links each Duo account to the one Current company whose normalized name matches or, when several share the name and differ only by a suffix like Inc or LLC, to the active customer among them (else the one linked to your PSA). Most map themselves; only the ambiguous ones need a hand.
2. 2
   Open the mapping panel

   Integrations → Duo → Manage → Customer mapping. It opens on the Unmapped tab, which lists every Duo account the matcher could not place.
3. 3
   Map an account to its company

   On an unmapped row press Map, type a few letters of the Current company, and pick it. That account's people and devices attach to the company right away, rather than waiting for the next six-hour sync.
4. 4
   Ignore internal or test accounts

   For an account that should never map to a partner (your own staff, a lab, a demo) press Ignore. It moves to the Ignored tab and stops counting against the card's unmapped badge.
5. 5
   Fix a wrong match later

   The Mapped tab lists every linked account; Unmap corrects a bad auto-match, and the Ignored tab's Un-ignore brings a dismissed one back. A mapping you set by hand is never overwritten by a later auto-match, and neither is a manual unlink.

Duo syncs every six hours. With a large number of subaccounts, Current reads a share of them on each run and works through the rest over the following runs, and it only removes a person or a device that has gone from Duo after reading that account in full.

• ＋The People section of a company record: how many people are covered out of the people Duo gave a clear answer for, how many are at risk broken out as in bypass (by status or through a group) and not enrolled, how many people cannot sign in at all (disabled, locked out, pending deletion, or in a Duo group whose status is Disabled), and the authenticator mix across push, SMS, hardware tokens and security keys.
• ＋The at-risk list itself, naming the people when there are few enough to do something about today.
• ＋Device hygiene: how many enrolled phones have no screen lock or no encryption, each shown as n of m reported, so a device Duo did not report on never counts as a pass.
• ＋Denied sign-ins, this week against the week before, which is the proof that the control is catching things rather than sitting there. A week Current could read only part of says how many of its 7 days were read, so a short week is never compared as a full one.
• ＋Protected applications: the applications Duo protects for that company's account.
• ＋Administrators: how many hold the Owner role, and how many have not signed in for 90 days.
• ＋Policy gaps in words, and the standing bypass codes that never expire or can be reused without limit.
• ＋The account's edition and its billable users.
• ＋Stale accounts: people who are still enabled and have not signed in for ninety days, which is both a licence being paid for and a way in nobody is watching.
• ＋The Security posture chapter of a Strategic Business Review, beside your other security feeds, including the policy gaps as counts.
• ＋The company AI brief, which names policy gaps, standing bypass codes and administrators who have not signed in for 90 days when there are any.
• ＋The company alert band, which raises an entry when somebody at that company can sign in without a second factor, and a second one when a Duo policy lets people in without it.