--- url: 'https://www.corbado.com/faq/fido1-vs-fido2' title: 'What''s the difference between FIDO1 and FIDO2?' description: 'FIDO1 vs. FIDO2: how U2F and UAF differ from passkeys, what changed in browser support and user verification and what to ask your vendor.' lang: 'en' keywords: 'fido1 vs fido2, fido1, u2f vs fido2, uaf vs fido2, difference between fido1 and fido2' --- # What's the difference between FIDO1 and FIDO2? ## Key Facts - **FIDO1 is an informal name for two standards from 2014.** [U2F](https://www.corbado.com/glossary/u2f) adds a security key as a second factor after the password. UAF does passwordless login through a FIDO client, usually in a native app. - **FIDO2 is one standard for both jobs.** The same [WebAuthn](https://www.corbado.com/glossary/webauthn) call does passwordless login with a passkey or a second-factor check with a security key. - **The practical change is a common browser and platform API.** FIDO2 is built into every major browser and operating system. - **When a vendor says "we only support FIDO1", ask which one.** U2F keys keep working through WebAuthn. UAF users re-enroll with passkeys. ## 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.mozilla.org/en-US/firefox/67.0/releasenotes/). 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](https://fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fido-uaf-client-api-transport-v1.2-ps-20201020.html). 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](https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html). 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](https://docs.yubico.com/hardware/yubikey/yk-tech-manual/yk5-bio-specifics.html#yubikey-bio-and-fido-u2f). 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](https://www.w3.org/TR/webauthn-2/#fido-u2f-signature-format-compatibility). - **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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/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](https://www.corbado.com/glossary/ctap)** is the protocol between the browser or operating system and an external [authenticator](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/discoverable-credential), as used by a [passkey](https://www.corbado.com/glossary/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: U2F and UAF compared with WebAuthn and CTAP](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/fido1_vs_fido2_comparison_c8fd19f66f.png) ## FIDO1 vs. FIDO2 comparison ### At a glance | | U2F | UAF | FIDO2 | | ------------------ | -------------------------------- | ------------------------------------------ | ---------------------------------------------------------------------- | | **Usually called** | FIDO1 | FIDO1 | FIDO2 | | **Published** | 2014 | 2014 | 2018 to 2019 | | **What it does** | Second factor after the password | Passwordless login through a FIDO client | Passwordless login with a passkey or second factor with a security key | | **Status today** | Keys keep working via WebAuthn | Still in some older banking and telco apps | Current standard, the basis for passkeys | ### Where it runs and how the user confirms | | U2F | UAF | FIDO2 | | -------------------------- | ------------------------------------------------- | ----------------------------------------- | ---------------------------------------------------------------- | | **Private key lives** | On a hardware security key | On the device, managed by the FIDO client | On the device, on a security key or synced by a passkey provider | | **User confirms with** | A touch, some keys also a fingerprint | Face, fingerprint or PIN | Face, fingerprint, PIN or a touch on a security key | | **User verification (UV)** | Not reported to the website | Yes, checked locally | Website can require it and verify the signed result | | **In the browser** | Historically Chrome and Firefox, now via WebAuthn | Only with a UAF client integration | Built into Chrome, Safari, Firefox and Edge | | **In native apps** | Rarely, vendor-specific SDKs | Yes, via a FIDO client SDK | Yes, via the platform APIs of iOS, Android, Windows and macOS | ## 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](https://krebsonsecurity.com/2014/10/google-accounts-now-support-security-keys/), followed by [Dropbox in August 2015](https://blog.dropbox.com/topics/product/u2f-security-keys), [GitHub in October 2015](https://techcrunch.com/2015/10/01/github-launches-support-for-u2f-security-keys) and [Facebook in January 2017](https://www.computerweekly.com/news/450411705/Facebook-ups-security-with-Fido-U2F-two-factor-authentication). All of them run on WebAuthn now. [Chrome disabled its U2F API in version 98 and removed it in 104](https://www.yubico.com/blog/google-chrome-u2f-api-decommission/), 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](https://www.globenewswire.com/news-release/2014/02/24/968133/0/en/The-FIDO-Alliance-Announces-First-FIDO-Authentication-Deployment-PayPal-and-Samsung-Enable-Consumer-Payments-With-Fingerprint-Authentication-on-New-Samsung-Galaxy-S5.html), the first FIDO deployment at all, where users confirmed PayPal payments with the phone's fingerprint sensor. [NTT DOCOMO followed in May 2015](https://www.nfcw.com/technology/fido-fast-identity-online/) 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](https://www.corbado.com/observe) is the authentication observability layer that shows this on your own traffic, alongside Okta, Auth0, Ping, ForgeRock or Cognito. [Video: Authenticator inventory](https://www.corbado.com/videos/features/authenticator-inventory.mp4) ([See Authenticator Inventory in Corbado Observe](https://www.corbado.com/observe/authenticator-inventory)) - **See what your users actually bring.** The Authenticator Inventory reads the [AAGUID](https://www.corbado.com/glossary/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](https://www.corbado.com/observe/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](https://www.corbado.com/connect) adds managed passkeys next to your existing IDP with rollout rules, so the re-enrollment runs in waves instead of a big bang. ---