What's the difference between FIDO1 and FIDO2?

What's the difference between FIDO1 and FIDO2?#

The question usually comes up in a vendor or partner conversation: someone says "we only support FIDO1" and everyone nods, but nobody is sure what that means for the login. A quick search does not help much, because the FIDO Alliance never published anything called FIDO1. The name is shorthand for two different first-generation standards and the two do different things.

FIDO1 is an informal name for U2F and UAF, the two FIDO standards published in 2014. U2F adds a hardware security key as a second factor after the password. UAF enables passwordless login through a FIDO client, using local verification such as a fingerprint or PIN. FIDO2 is the current standard behind passkeys: it combines WebAuthn, which is built into every major browser and operating system, with CTAP for external security keys. FIDO2 supports both use cases through widely supported browser and platform APIs.

---

What FIDO1 means: U2F and UAF explained#

The FIDO Alliance published U2F and UAF together in December 2014. Both build on the same idea that FIDO2 later kept: the device creates a key pair per service, the private key never leaves the device and the server only stores the public key. They differ in what the user does with it.

U2F: password plus security key#

U2F (Universal 2nd Factor) keeps the password and adds a hardware security key on top. The user enters the password, then touches the key. The key signs a challenge that includes the website's origin, so a phishing site gets a signature it cannot use. A normal key touch proves user presence (UP): someone approved the operation. It does not by itself verify that person with a PIN or fingerprint. U2F was designed as an additional factor alongside a password.

The browser support was not Chrome-only and did not always need an extension. Chrome supported U2F, and Firefox 67 enabled the U2F API by default in 2019. Today, websites use WebAuthn; compatible U2F keys can still act as a second factor through CTAP1. The old website API and the protocol spoken by the key are separate things.

UAF: passwordless through a FIDO client#

UAF (Universal Authentication Framework) removes the password. The user unlocks the credential locally with a face or fingerprint scan or a PIN and the device signs the challenge. Native apps typically integrate a FIDO client SDK that talks to the authenticator. UAF is not limited by its specification to native apps: its application API also defines browser and browser-plugin integration. This requires a compatible UAF client integration rather than the WebAuthn API. UAF also defines transaction confirmation, where the user approves a specific text such as a payment amount, which is why banks and payment providers were the early adopters.

Did FIDO1 already support user verification?#

Yes for UAF. For U2F, it depends on whether you mean what the key checks locally or what the protocol reports back to the website.

• UAF verified the user from the start. UAF already supported local verification with biometrics or a PIN. User verification was not invented with FIDO2.
• U2F only reports presence. A modern key used in U2F mode can impose a local biometric check, for example YubiKey Bio requires a matching fingerprint even in U2F mode. The protocol does not carry that result: in a U2F authentication response only the user-presence flag can be set and the UV flag is zero.
• FIDO2 lets the website ask for it. WebAuthn lets a website require user verification and check a signed UV flag from a capable authenticator, for example a device PIN or fingerprint instead of a website password. FIDO2 can also run as a second factor without UV, so a FIDO2 login does not automatically mean that verification happened.

Compared with UAF, the advance of FIDO2 is broad browser and platform integration, not the invention of biometric or PIN verification.

What FIDO2 changed: WebAuthn and CTAP#

FIDO2 took the two jobs of FIDO1 and put them behind one API that browsers and operating systems implement themselves. It has two parts, explained in more detail in our post on WebAuthn vs. CTAP vs. FIDO2:

• WebAuthn is the API a website or app calls to create and use a credential. Chrome, Safari, Firefox and Edge implement it natively and iOS, Android, Windows and macOS expose the same capability to native apps.
• CTAP is the protocol between the browser or operating system and an external authenticator such as a security key or a phone used for cross-device login. CTAP1 is the old U2F wire protocol, which is why old U2F keys still work with WebAuthn as a second factor.

FIDO2 supports both passwordless login and second factor. The site's policy and the authenticator's capabilities determine the flow. A discoverable credential, as used by a passkey, allows the account to be found without entering a username; user verification provides the local PIN or biometric check. Non-discoverable credentials can also support passwordless login with UV after the user identifies their account. They are not inherently limited to second factor. GitHub's security key login, for example, started on U2F in 2015 and runs on WebAuthn today with the same keys.

FIDO1 vs. FIDO2 comparison#

At a glance#

Where it runs and how the user confirms#

Which apps used U2F and UAF?#

Both standards had real deployments before FIDO2 existed, which is why "FIDO1" still shows up in vendor conversations today.

• U2F started with Google Accounts in October 2014, followed by Dropbox in August 2015, GitHub in October 2015 and Facebook in January 2017. All of them run on WebAuthn now. Chrome disabled its U2F API in version 98 and removed it in 104, both in 2022. Keys registered under U2F still work because WebAuthn can address them through the appid extension.
• UAF started with PayPal and Samsung on the Galaxy S5 in 2014, the first FIDO deployment at all, where users confirmed PayPal payments with the phone's fingerprint sensor. NTT DOCOMO followed in May 2015 as the first mobile operator, with fingerprint and iris login for its customer accounts. These are examples of UAF in native apps, rather than a restriction of the standard to native apps.

What to ask when someone says "we only support FIDO1"#

The version label tells you little. Ask which of the two standards they mean:

• "U2F security keys?" Then the login still has a password, the keys keep working through WebAuthn and the migration is a move from the old API to a WebAuthn call.
• "UAF passwordless in the app?" Then the login is already passwordless through a UAF client integration. Moving to WebAuthn means re-enrolling users with passkeys, because UAF credentials cannot be converted.

Either way, the point of FIDO2 is that both cases end up on the same standard, built into the browser and the operating system. That is also why "passkey" in practice means a FIDO2 credential. The FIDO Alliance does count UAF app credentials among device-bound passkeys in its broader definition, but UAF credentials are not interchangeable with WebAuthn credentials.

How Corbado can help#

Most teams meet FIDO1 in the middle of a migration: U2F keys that have to keep working through WebAuthn, or a UAF app whose users need to be re-enrolled with passkeys. The standard is the easy part. The hard part is seeing which users are still on the old flow and where the new WebAuthn call fails for them. Corbado Observe is the authentication observability layer that shows this on your own traffic, alongside Okta, Auth0, Ping, ForgeRock or Cognito.

See Authenticator Inventory in Corbado Observe →

• See what your users actually bring. The Authenticator Inventory reads the AAGUID off every registration, so you know how much of your credential base is still hardware security keys and how much is platform or synced passkeys.
• Separate a broken key from a cancelled prompt. Passkey errors split user cancels from real WebAuthn failures and device incompatibilities, per OS and browser, so an old key that the browser cannot address shows up as its own problem.
• Watch the mix shift. Login Methods tracks passkey, password and social login with usage share, completion rate and duration over time, so the move off the old second-factor or UAF flow becomes a curve rather than a guess.

For the UAF case, where credentials cannot be converted, Corbado Connect adds managed passkeys next to your existing IDP with rollout rules, so the re-enrollment runs in waves instead of a big bang.

---

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →