FIDO UAF: The Original Passwordless Protocol and Its Migration Path

Many banking and payment apps still run FIDO UAF, the FIDO Alliance's first passwordless protocol, while the rest of the industry has moved to FIDO2, WebAuthn and passkeys. UAF works: it binds a key pair to a device, unlocks it with a fingerprint or PIN and supports signed transaction confirmation. But it depends on vendor SDKs, a dedicated UAF server and authenticator metadata that fewer teams know how to run, and WebAuthn defines no route for bringing existing UAF credentials across. This guide explains what UAF is, where it stands officially (it has not been formally deprecated), who is affected by the shift to FIDO2, how to find UAF in your estate, and how to plan and test a migration. It is for identity architects, mobile app owners and fraud teams in banks and fintechs. Protocol internals of FIDO2 itself are in the FIDO2 and WebAuthn Internals Guide; this page does not repeat them.

Key takeaways

• UAF is not deprecated, but it is no longer where development happens. As checked on 8 November 2026 the FIDO Alliance download page lists UAF 1.2 (Proposed Standard, 20 October 2020) and UAF 1.1 without any deprecation label, while CTAP has moved through 2.1, 2.2 and 2.3 since 2021.
• Migration is a re-registration, not a conversion. WebAuthn's appid extension lets relying parties keep using legacy FIDO U2F credentials; the WebAuthn specification describes no equivalent for UAF keys, so plan for every user to enrol a new passkey.
• Transaction confirmation is the feature to plan around. UAF can show text (up to 200 characters for text/plain) or an image to the user and sign it. Payment flows built on that need a replacement design, not just a new login button.
• Run both protocols side by side. A phased migration keeps UAF accepted while users enrol passkeys at their next login, then narrows UAF to a fallback and finally deregisters the keys.
• Metadata hygiene matters now, not just after migration. A UAF server is only as good as its authenticator policy and metadata; stale metadata and permissive surrogate attestation are the areas to watch.

What is changing and why

FIDO UAF (Universal Authentication Framework) defines a client, an authenticator abstraction layer (the ASM), authenticators and a UAF server. The UAF architectural overview describes four operations: registration, where the authenticator creates a key pair scoped to the relying party; authentication, a challenge and response unlocked by local user verification such as a fingerprint or PIN; transaction confirmation, available on authenticators with a display and supporting a "what you see is what you sign" mode; and deregistration, where the relying party asks the authenticator to delete a credential. The protocol identifies each authenticator model with an AAID in the form V#M (four hex digits of vendor code, four of model code), and each registration with the pair (AAID, KeyID).

What has changed is the platform around it. FIDO2 splits the same idea into W3C Web Authentication (the API browsers and operating systems expose) and CTAP (how external authenticators talk to clients). Operating systems now ship passkey support natively: Android's Credential Manager lists passkeys alongside passwords, federated sign-in and digital credentials, and WebAuthn Level 3 defines backup-eligible "multi-device credentials" that can sync between a user's devices. For an app owner this means passkeys need no third-party authenticator SDK, while UAF usually does.

Official timeline and current status

There is no published end-of-life date for UAF. The table records what the FIDO Alliance's own specification page showed when checked on 8 November 2026; dates are taken from the published document identifiers.

The W3C Web Authentication Level 3 source document is marked as a Recommendation (REC) at the time of checking. Read the pattern cautiously: no new UAF version in six years is a signal, not an announcement. If the FIDO Alliance publishes a retirement notice for UAF or for UAF certification, it will change the urgency of everything below, so check the specifications page and the certification programme before setting dates in a business case.

Who and what is affected

• Retail and business banking apps: UAF was adopted for biometric login and payment confirmation in mobile banking. Apps that use UAF transaction confirmation for payment approval are the most affected, because that flow carries strong customer authentication evidence. See the PSD2/PSD3 Strong Customer Authentication Guide before changing it.
• Relying parties running a UAF server: on-premises or outsourced, the server validates attestation against metadata, applies the accepted and disallowed authenticator policy, and links authenticators to accounts. It needs patching, metadata updates and skills that FIDO2-only teams may need to build.
• Users on older or unusual devices: UAF authenticators were often implemented per device model through vendor SDKs. Device churn retires them naturally; the question is whether their replacement is a passkey or a password reset.
• Fraud and risk teams: risk rules keyed on AAID, KeyID or SDK device signals will need equivalents based on AAGUID, attestation and backup state.
• Back-office integrations: payment approval, audit trails and dispute evidence that store UAF signed transaction text need to keep that evidence readable after migration.

Finding affected systems and identities

Build an inventory before deciding anything. These are discovery steps, not changes.

1. App and SDK inventory: list every mobile app and its authentication SDKs. Look for UAF client or ASM components and for AppID URLs and trusted facet list files referenced by the app.
2. Server side: identify UAF server instances, their versions and who operates them. Export the authenticator policy (the accepted and disallowed lists) and the metadata source.
3. Registrations: from the server database, count active registrations by AAID and by last-used date. Accounts with no use for many months are candidates for deregistration rather than migration.
4. Attestation profile: count registrations by attestation type. ATTESTATION_BASIC_SURROGATE means no real attestation (the server checks the signature against the key itself), so those registrations prove less about the authenticator model.
5. Transaction flows: find every flow that sends a UAF Transaction object (contentType and content) and what downstream systems consume the signed result.
6. Recovery paths: document what happens when a user loses the device. Give recovery the same care as enrolment in either protocol. See Passkey account recovery.

Migration options

Choosing between them: the deciding factors are transaction confirmation, device-bound versus synced credentials and regulator expectations. Synced passkeys (backup eligible) improve recovery but mean the key may leave the original device; WebAuthn signals this with the backup eligibility and backup state flags, so a relying party can apply different policy to single-device and multi-device credentials. Banks that require device binding for high-value payments often accept synced passkeys for login and add device or app checks for payment approval. Smaller fintechs usually gain most from removing the third-party SDK entirely.

Domain association: passkeys are scoped to an RP ID, a domain, so native apps must be associated with that domain through each platform's app-to-domain mechanism. Plan the RP ID once; changing it later strands every credential.

Testing and rollback

1. Pilot ring: enable passkey enrolment for staff and a small opt-in group while UAF stays the default. Track enrolment success and login failure by device model and operating system version.
2. Parallel acceptance: accept both a UAF assertion and a passkey assertion for the same account during the overlap, and log which protocol each login used.
3. Payment flow tests: confirm that whatever replaces UAF transaction confirmation shows the amount and payee to the user and binds them to the authentication, and that audit evidence is stored in a format your disputes team can read.
4. Rollback: keep UAF registrations and the server live until passkey adoption meets your target. Rollback is then a feature flag that hides passkey prompts; do not deregister UAF keys until the rollback window closes.
5. Decommission: use the UAF Dereg operation for remaining keys, remove the SDK in an app release, revoke the AppID facet list and retire the server and its metadata feed.

Risks of doing nothing

• Stale authenticator trust: the UAF protocol assumes the server holds metadata for every authenticator it accepts and places authenticators with unacceptable status in disallowed. If nobody maintains this, compromised or uncertified models stay trusted. The FIDO Metadata Service exists to support rapid revocation of trust and should be refreshed and signature-checked.
• Vendor and skills concentration: fewer engineers and vendors work on UAF each year, so incidents and app platform changes take longer to fix.
• User experience gap: customers who use passkeys elsewhere expect the same in their banking app; falling back to passwords and SMS codes when a UAF device is replaced reintroduces phishable factors.
• Deprecated binding options: the UAF 1.2 protocol notes that the tlsUnique channel binding is deprecated; older deployments may still depend on it.

Common failure patterns

• Treating migration as a key conversion: WebAuthn offers no documented way to reuse a UAF key; plan enrolment campaigns.
• Accepting surrogate attestation for everything: it proves possession of a key, not the authenticator model, which undermines model-based risk policy.
• Low-assurance recovery after device loss: a strong authenticator with an SMS reset path is only as strong as the SMS.
• Losing transaction evidence: moving payment approval to passkeys without redesigning what the user sees and what is signed.
• Never deregistering: leaving UAF registrations and the server running for years after the app no longer uses them.

Framework mapping

Practitioner checklist

• Record the current UAF and CTAP status from the FIDO Alliance specifications page, with the date checked, in your business case.
• Inventory apps, SDKs, AppIDs, facet lists, UAF servers and registrations by AAID, attestation type and last use.
• Refresh authenticator metadata from the FIDO Metadata Service, verify the BLOB signature and review the disallowed list.
• Decide the RP ID and app-to-domain association for passkeys before any user enrols.
• Design the replacement for UAF transaction confirmation with your payments, fraud and compliance teams.
• Run a pilot ring with dual-protocol acceptance and per-protocol login logging.
• Set policy for single-device versus multi-device passkeys using the backup eligibility and backup state flags.
• Deregister dormant UAF keys, then retire the SDK, facet list and server after the rollback window.

Standards and references

• FIDO Alliance: Download Specifications
• FIDO Alliance: FIDO UAF Architectural Overview v1.2
• FIDO Alliance: FIDO UAF Protocol Specification v1.2
• FIDO Alliance: FIDO Metadata Service
• W3C: Web Authentication Level 3
• Android Developers: Credential Manager

Related NHI Mgmt Group resources: FIDO2 and WebAuthn Internals Guide · Passkey Rollout Guide · Online Banking Security Guide · Passwordless and Passkeys Guide