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

6 min read · Updated Sep 5, 2026

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. That number is usually a handful, it is usually a surprise, and it is the reason this connector exists. Everything hangs off the matching Current company, so it feeds your business reviews and the company alert band. Current reads Duo and can never change anything in it.

Note

This connector reads people, and here is exactly what it keeps

Every other read-only feed in Current describes machines. This one describes employees, so it takes the minimum it can and no more. It stores each person's Duo username, their display name, their email address, whether they are enrolled, what kind of authenticators they carry as counts, and when they last signed in. It does not store phone numbers, date of birth, custom attributes, aliases, notes, or anything about a password. Sign-in activity is counted per day and nothing else is kept: not the IP address, not the city or country, not who signed in to what. Partner viewers never see any of it, and that is enforced at the database rather than hidden in the interface.

What Current syncs

Data set	What Current stores	Where it lands
Accounts	Each Duo account this credential reaches — your subaccounts if you manage them, or the single account if you do not — by identifier and name, with Duo's own user, administrator and application counts	The mapping panel on the Duo card, and the People section of a company record
People	Per person: Duo username, display name, email, account status, whether they are enrolled, when they last signed in, and how many phones, hardware tokens and security keys they carry	The People section, the at-risk list on the company card, and the MFA dashboard metrics
Authenticator devices	Per enrolled phone or tablet: platform, model, operating system and app version, when Duo last saw it, and the screen lock, encryption and tamper state Duo reports	The device hygiene numbers on the company card, each shown with its own denominator
Sign-in activity	Per account per day: how many authentications were granted, how many were denied, how many were reported as fraud, and a small count of the reasons Duo gave for denials	The denied-sign-ins trend on the company card and in a business review

Note

The one number to look at first

At risk means a person can reach a sign-in without a working second factor, and it covers four situations that look different in Duo and identical to an attacker: somebody in bypass, somebody disabled, somebody locked out, and somebody who never finished enrolling. Bypass is the one worth pausing on. A person in bypass has a perfectly normal-looking Duo account and authenticates with their password alone, usually because somebody put them there during a phone upgrade eighteen months ago and nobody took them out. Current lists them by name when there are few enough to act on, and counts them when there are not. If a status arrives that Current does not recognise, that person is counted as unknown rather than as fine, so a change on Duo's side can never quietly shrink the number.

Note

What Current does not read

The Duo Admin API can do a great deal more than read. It can create and delete people, issue a working multi-factor bypass code, enrol and remove authenticators, create administrators, rewrite account-wide policy, and on a parent account create and delete entire customer subaccounts. None of those are in this connector's code. It calls five read endpoints and nothing else, so the rest are unreachable rather than merely unused — including one read Current deliberately leaves out because it returns another application's secret key. The connector also does not read Duo Trust Monitor, which Cisco removed from the Duo Admin Panel in July 2026.

Create the Admin API application in Duo

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 do not have that role, this is the point to ask whoever does — no other step below will work without it. 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 · 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 · Tick three permissions, and leave every write permission off
On that application's page, tick Grant read information, Grant resource - Read, and Grant read log. Those three cover the account summary, the people and their devices, and the sign-in activity. If you manage partners as Duo subaccounts, tick the subaccount read permission in the subaccount section as well, or the credential cannot see your partners. Leave every other box unticked, including all four write permissions and Grant set Admin API permissions. That way the credential itself 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 · 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 · 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 makes one read against Duo to confirm the credentials work and can see your directory, then stores them 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.

Note

An over-permissioned key works, which is the problem

If you tick more boxes than the three above, everything below still works and nothing warns you. You have simply handed Current a credential that could change your partners' Duo tenants, and Current's own code is then the only thing stopping it. Ticking exactly three is what makes that impossible rather than merely unlikely. The opposite mistake is quieter: a credential with too few permissions authenticates cleanly and then reads nothing, which shows up as a connected card with no people on it.

Map Duo accounts to your companies

If you manage partners as Duo subaccounts, each subaccount is one end-customer and Current lists all of them. If your credential covers a single Duo account, 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 — and only when exactly one company matches. Two companies that both fit stay unmapped for you to decide.

1
Let the auto-matcher run first
Every sync links each Duo account to the one Current company whose normalized name matches. Most map themselves; only the ambiguous ones need a hand.
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
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
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
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.

Where the data shows up

＋The People section of a company record: how many people are enrolled out of the total, how many are at risk broken out as in bypass, not enrolled and locked out, 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.
＋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 denied sign-ins trend, which is the proof that the control is catching things rather than just sitting there.
＋The Security posture chapter of a Strategic Business Review, beside your other security feeds.
＋The company alert band, which raises an entry when somebody at that company can sign in without a second factor.

Note

Numbers that stay blank on purpose

If Duo does not answer for part of a run, the numbers it would have produced stay blank instead of showing a zero. A blank means Current could not ask; a zero would mean it asked and the answer was none, and those are different things to put in front of a partner. Device hygiene works the same way at the level of a single device: Duo reports a screen lock as present or as an empty value, and it does not say whether an empty value means there is no screen lock or means the platform does not report one. Current counts the ones it can confirm and shows the denominator beside them rather than turning silence into a finding.

When something looks wrong

What you see	What it means
"Duo rejected these credentials"	All three values are signed into every request, so any one of them being wrong reads the same way. Check the integration key, the secret key and the API hostname against the Admin API application page. The most common cause is the hostname: it is the api- address on that page, not the address you sign in at.
"Duo accepted these credentials but refused the user list"	A permissions gap, not a wrong key, and regenerating the key will not help. Go back to the Admin API application and confirm Grant read information, Grant resource - Read and Grant read log are ticked. If they are, check the integration key came from an Admin API application rather than an Auth API one — the two look alike, Duo answers the same way for both, and telling them apart by the key alone is not possible.
"Couldn't reach Duo"	A network or firewall problem between Current and your Duo API hostname, not a credential problem. Current retries on its own at the next scheduled sync.
"Duo is rate-limiting the request"	Duo publishes no read limit for this API, so Current paces itself well under any plausible one and backs off the moment Duo says to. Nothing is wrong with the credentials; wait and press Test again.
Connected, but no people listed	The credential authenticates and then reads nothing, which is the fingerprint of an under-permissioned application. Grant resource - Read is the box that covers people and their devices.
Connected, but no partners listed	If you manage subaccounts, the credential is missing the subaccount read permission, so Current sees the parent account only. Add it in the subaccount permission section of the Admin API application. If you do not manage subaccounts, one entry is correct — that entry is the whole account.
A company shows no Duo data	Its Duo account is not mapped yet. Check the Unmapped tab on the card.
Device hygiene shows fewer devices than you expect	The count only includes devices Duo actually reported a value for. The denominator beside it is the number reported, and the gap between that and the fleet is devices Duo said nothing about.
Somebody shows as at risk who looks fine in Duo	Look at their status. Bypass is the usual answer, and it is easy to miss in Duo because the account otherwise looks healthy. Disabled and locked out also count, as does anyone who never finished enrolling.
The denied sign-ins trend has a gap	Duo's sign-in log reaches back one hundred and eighty days at most and lags a couple of minutes behind live, and Current reads a bounded recent window on each run. A day Current has not covered stays blank rather than showing zero.

Note

Who can do this, and disconnecting

Connecting, testing, mapping, and disconnecting are Tenant Admin actions; sales leadership can run a manual sync and read status. Disconnect stops the sync and skips your workspace on the six-hour sweep — the people, devices and sign-in counts already pulled stay put, and reconnecting resumes from where it left off. Partner (read-only) viewers never see any of this data; it is blocked at the database, not just hidden.

Was this helpful?

← Previous

KnowBe4: phishing results and training progress per partner