Skip to main content
Identity Authority
Category: FIDO & Passkeys

Universal Authentication Framework

Also known as: UAF, FIDO UAF
Simply put

The Universal Authentication Framework (UAF) is an authentication standard created by the FIDO Alliance that lets people sign in without passwords. Instead of typing a password, the user proves their identity on a personal device using methods like a fingerprint, other biometric, or a PIN. The goal is to replace passwords with stronger, device-based ways of verifying who a user is.

Formal definition

FIDO UAF is a FIDO Alliance authentication protocol designed to supplant passwords by providing a unified and extensible passwordless authentication mechanism for online services. In a typical deployment, the user carries a device with a FIDO UAF client stack installed and registers that device (an authenticator) to the online service; subsequent authentication relies on local user verification via inherence factors (such as biometrics) or knowledge factors (such as a PIN) rather than a shared secret transmitted to the server. Per the specifications, UAF supports passwordless and multi-factor authentication scenarios. The published protocol specification referenced here is FIDO UAF v1.2 (2020-10-20), with earlier v1.1 architectural materials also available; UAF addresses authentication (verifying the user) and is distinct from FIDO U2F, which targets second-factor use. Authorization decisions and downstream access control are out of scope for this term.

Why it matters

Passwords remain one of the weakest links in most authentication systems: they are reused across services, susceptible to phishing, and transmitted as shared secrets that can be intercepted or stolen from server-side stores. FIDO UAF matters because it was designed specifically to supplant passwords, moving user verification onto a personal device where inherence factors such as biometrics or knowledge factors such as a PIN are checked locally rather than sending a reusable secret to the online service. For architects evaluating passwordless strategies, UAF represents an early and influential FIDO Alliance approach to eliminating the shared-secret model at the point of authentication.

For identity teams, UAF's device-based model changes the threat surface. Because the local user verification happens on the authenticator and the service does not receive a transmitted password, several classes of credential-theft attack that target shared secrets are addressed at the authentication layer. It is important to keep scope clear, however: UAF concerns authentication, verifying who the user is, and does not by itself make authorization or downstream access control decisions, which remain the responsibility of the relying service.

UAF should also be understood in relation to the broader FIDO family rather than treated as the whole of passwordless. It is distinct from FIDO U2F, which targets second-factor use, and readers evaluating current deployments should assess which FIDO specifications and versions their target platforms and vendors actually support before committing to an approach.

Who it's relevant to

Security architects
Architects designing passwordless authentication strategies should understand UAF as a FIDO Alliance protocol that replaces the shared-secret model with local, device-based user verification. When evaluating it, distinguish UAF's authentication role from downstream authorization, and consider how it relates to and differs from other FIDO specifications such as U2F before selecting an approach.
IAM engineers
Engineers integrating passwordless flows need to account for the UAF client stack on user devices, the device registration step that binds an authenticator to a service, and the local verification using inherence or knowledge factors. Available capabilities, supported biometrics, PIN handling, and specific UAF versions such as v1.2, typically vary by platform and vendor, so validate what your target environments actually implement.
Compliance officers and identity governance leads
Those assessing authentication controls should note that UAF addresses how a user is verified at sign-in by removing transmitted passwords in favor of device-based factors, and supports both passwordless and multi-factor scenarios per its specifications. UAF does not itself perform authorization or access certification, so governance concerns such as access reviews and provisioning remain separate from what this protocol covers.

Inside UAF

Passwordless authentication model
UAF is a FIDO Alliance specification designed for passwordless authentication, in which a user registers a local authenticator to an online service and subsequently authenticates using an inherence or possession factor (such as a biometric or PIN-protected device) rather than a shared secret transmitted to the server.
Local authenticator and gesture
The user unlocks the authenticator locally through a user verification gesture (typically biometric such as fingerprint or face, or a local PIN). The gesture unlocks the private key on the device; it is verified locally and, in most deployments, is not transmitted to the relying party.
Public/private key credential pair
During registration the authenticator generates an asymmetric key pair per relying party account. The private key remains protected on the authenticator, and the public key is registered with the online service for later verification of signed authentication challenges.
Challenge-response authentication
At authentication time the relying party issues a challenge that the authenticator signs with the corresponding private key after successful local user verification. The service verifies the signature against the registered public key to complete authentication.
Relationship to FIDO2/WebAuthn
UAF is part of the earlier FIDO Universal Authentication Framework family, distinct from the later FIDO2 effort (WebAuthn plus CTAP). UAF, WebAuthn, and passkeys are related but not interchangeable; UAF predates and differs in scope from the FIDO2 specifications.

Common questions

Answers to the questions practitioners most commonly ask about UAF.

Is UAF just another name for FIDO2 or WebAuthn?
No. UAF is a distinct specification from the original FIDO Alliance UAF protocol family and should not be treated as interchangeable with FIDO2 or WebAuthn. FIDO2 refers to the newer body of work comprising the W3C WebAuthn API and the CTAP protocol, whereas UAF is the earlier passwordless framework. They share the FIDO Alliance's lineage and the general goal of eliminating shared-secret passwords, but they are separate specifications with different APIs and integration models. Referring to one by the other's name will cause confusion in design and procurement discussions, so keep the terms separate and confirm which specification a given product or SDK actually implements.
Does UAF handle what a user is allowed to do after they sign in?
No. UAF is concerned with authentication, that is, verifying who a principal is using local device-based factors rather than shared passwords. It does not perform authorization, which is the separate step of determining what an authenticated principal may access. Authorization decisions remain the responsibility of your access control model and enforcement components regardless of how the user authenticated. Treat UAF as one part of the identification and authentication flow, and keep authorization logic distinct from it.
What authentication factors does UAF typically rely on at the device level?
UAF is designed around local user verification on the device before a cryptographic authentication response is produced. Depending on the authenticator and configuration, this local verification commonly uses an inherence factor such as a biometric, or a knowledge factor such as a local PIN, combined with the possession factor represented by the device or authenticator itself. The exact factors available depend on the authenticator hardware, the platform, and how the relying party configures its policy, so verify what a specific authenticator supports rather than assuming a fixed set.
How should we approach integrating UAF with an existing web SSO stack?
In most deployments, UAF operates as the authentication mechanism at the point where a user is verified, and the resulting authenticated session must then be bridged into your broader federation layer. That bridging is typically handled by your identity provider, which can consume the authentication event and issue federation assertions or tokens through separate standards such as SAML 2.0 for web SSO or OpenID Connect for token-based authentication. UAF itself does not define those federation flows, so plan the integration as UAF for the authentication step and your existing IdP for issuing and propagating session artifacts. Confirm which UAF SDKs and server components your IdP or gateway supports before committing to an architecture.
What server-side components are involved in a UAF deployment?
A UAF deployment generally requires a server-side component, often described as a UAF or FIDO server, that manages registration and authentication ceremonies, stores the public keys registered by authenticators, and validates the signed responses returned from client devices. On the client side there is an authenticator and the software that mediates between the application and that authenticator. The precise component names, deployment topology, and clustering or high-availability options vary by vendor, so treat this as a general division of responsibilities and validate specifics against the product documentation you are evaluating.
What should we verify when validating a UAF authentication response?
Server-side validation in a UAF flow typically centers on verifying the cryptographic signature produced by the registered authenticator against the previously registered public key, and confirming that the response corresponds to the expected challenge and relying party context. Note that a signed response establishes integrity and origin of the authentication assertion but is not the same as confidentiality; signing and encryption are distinct properties. The exact validation steps, challenge handling, and any additional metadata or attestation checks depend on the specification profile and server implementation, so follow the authoritative specification and your vendor's guidance rather than assuming a generic procedure.

Common misconceptions

UAF is an authorization framework similar to OAuth 2.0.
UAF addresses authentication (verifying the identity of a principal via a local authenticator and signed challenge), not delegated authorization. Determining what an authenticated principal may do is a separate authorization concern outside UAF's scope.
UAF and FIDO2/WebAuthn are the same thing and can be used interchangeably.
UAF is part of the earlier FIDO framework family, while FIDO2 comprises WebAuthn and CTAP. They share the public-key, passwordless design philosophy but are distinct specifications with different scopes and are not synonyms.
The user's biometric data is sent to the online service during UAF authentication.
In typical UAF deployments the biometric or PIN gesture is verified locally on the authenticator to unlock the private key; the inherence factor itself is generally not transmitted to the relying party, which instead receives a signed challenge response.

Best practices

Treat UAF as an authentication mechanism and pair it with a separate, explicitly defined authorization layer (for example RBAC, ABAC, or PBAC) rather than relying on it to make access decisions.
Confirm which specification your platform actually implements, UAF versus FIDO2/WebAuthn, since they differ in scope, and document the version or profile to avoid integration and support ambiguity.
Keep the user verification gesture and its handling local to the authenticator, and validate that biometric or PIN data is not being transmitted to relying parties in your deployment.
Register and manage per-service public keys carefully, ensuring the relying party stores only public keys and that private keys remain protected on the authenticator.
Consider step-up authentication and account recovery paths, since loss of a local authenticator can otherwise lock users out; define fallback and re-enrollment procedures explicitly.
Validate signed challenge responses against the correct registered public key on the server side, and verify that challenge freshness protections are enforced according to your configuration.
Application Security Isn’t Optional Anymore.