UIID v2.12 Is Live: Passkeys for Everyone, and Passkey Authentication as a Service

ALBUQUERQUE, NM, October 17, 2026. Today LINKSPREED released UIID v2.12. It is the biggest step so far in how people sign in to UIID and how other companies can use UIID to protect their own users.

This release does two main things:

Passkeys for UIID itself. People can now create a UIID account and sign in with a passkey, using Touch ID, Face ID, Windows Hello, Google Password Manager, 1Password, or a YubiKey. No password is needed at any point.
UIID WebAuthn-as-a-Service. Third-party developers can use UIID as the engine that handles passkeys for their own applications. They register an app, receive API credentials, and let UIID do the demanding cryptographic work through a set of REST APIs.

UIID is LINKSPREED’s local-first identity protocol. It creates cryptographically secure identities on the user’s device and uses device biometrics for passwordless sign-in. Passkeys fit this approach well. This article explains what is new, how each feature works, why we built it this way, and what it means for users and developers.

Part 1: The password problem

Before the features, it helps to be clear about the problem.

Passwords were designed for a different era of computing. They depend on people remembering secrets, and that has never worked well. People reuse passwords across sites. They pick short, guessable ones. They type them into fake websites that look real. And when a company is breached, a database full of password data can end up in criminal hands.

These problems add up. Passwords are easy to phish, easy to reuse, easy to leak in breaches, and hard to manage at scale. The usual fixes, such as password managers, one-time codes by text message, and complex password rules, reduce the risk but do not remove the cause. The cause is that a shared secret exists at all. If both the user and the server know a secret, someone else can steal it from either side.

Passkeys remove the shared secret. That is the whole idea, and it is why we put them at the center of UIID v2.12.

Part 2: What a passkey is and how it works

A key pair instead of a password

A passkey is built on public key cryptography. The user’s device creates a pair of keys: a private key and a public key. The private key stays on the device. The public key goes to the service the user wants to sign in to. The server only ever stores the public half.

When the user later signs in, the service sends a random one-time challenge. The device signs the challenge with the private key. The service checks the signature with the stored public key. If it matches, the user is in.

Because the service never holds the private key, a breach of the service does not hand attackers a working credential. There is no password database to steal.

The three parties involved

Every passkey interaction involves three parties.

The Relying Party (RP). This is the server: the website or application that owns the user account and decides which credentials are valid.
The client. This is the browser, the operating system, or an app’s WebAuthn layer. It connects the relying party and the authenticator, enforces the origin, and shows the user the prompts.
The authenticator. This is the thing that holds the private key and checks that the user is really present. It can be a phone, a laptop, a password manager, or a physical security key.

The term “relying party” matters a lot for the second feature in this release, so keep it in mind. It is the party that relies on the passkey to confirm who the user is.

Two ceremonies: registration and authentication

WebAuthn defines two flows, often called ceremonies.

Registration creates the passkey. The server issues a challenge. The browser asks the authenticator to create a new credential. The user confirms with a fingerprint, face scan, or PIN. The server verifies the response and stores the public key.
Authentication uses the passkey. The server sends a fresh challenge. The authenticator signs it. The server verifies the signature against the stored public key.

Several pieces of data move through these flows. A few of them are worth knowing:

Challenge: a random, one-time value. Because it changes every time, an attacker cannot record one valid sign-in and replay it later.
Credential ID: a unique label created with the passkey. The server uses it to find the right stored public key.
User handle: a stable internal reference that links the passkey to the account. It is deliberately not an email address or username, since those can change. This is also why a passkey can sign you in without you typing a username.
Sign counter: a number the authenticator can raise on each use, which servers may track to spot cloned authenticators. For synced passkeys it is often 0 and static, so many services treat it as advisory.

Why passkeys resist phishing

A passkey is tied to the domain it was created for. A passkey made for one site will not respond to a similar-looking address. This is the single most important reason passkeys resist phishing, and the browser enforces it. The user does not have to notice a fake address in the moment.

With a password, the user is the last line of defense. With a passkey, the browser and the cryptography do that work.

Your biometrics stay with you

When someone unlocks a passkey with a fingerprint or face scan, that check happens on the device. The biometric data never leaves the device and is never sent to the website. The website only learns that the check passed.

This matters for privacy and fits UIID’s local-first design.

Discoverable credentials

A passkey is a discoverable FIDO credential. That means it can be found and used automatically. When the user starts signing in, the authenticator does not need to be told the user ID. It uses the relying party ID to find the right passkey for that site. This frees the user from typing a username and is what makes one-tap sign-in possible.

Device-bound and synced passkeys

There are two main types of passkeys.

Device-bound passkeys stay on the specific device where they were created, typically a hardware security key. The private key cannot be copied off the device. This is a high-assurance model, but if the device is lost, the passkey is lost with it.
Synced passkeys are available across a person’s devices through a provider, for example a cloud keychain or password manager. They are more convenient and easier to recover.

Each type has different trade-offs for security, recovery, and portability. Neither is “right” for everyone, which is why UIID v2.12 gives users clear guidance and controls. More on that below.

The standards underneath

WebAuthn is a W3C standard. WebAuthn Level 2 has been a W3C Recommendation since April 8, 2021. FIDO2 is the combination of the W3C WebAuthn specification and the FIDO Alliance’s Client to Authenticator Protocol (CTAP). WebAuthn connects a website or app to the client, and CTAP connects the client platform to a roaming authenticator.

One honest point about limits: FIDO2 gives phishing-resistant and replay-resistant sign-in when it is implemented and verified correctly. It does not prove a person’s legal identity, decide who is allowed to register, protect a compromised server session, or repair a weak account recovery process. Those are neighboring controls that must be designed around the sign-in flow. We keep this in mind throughout v2.12, and it is the reason the release also includes security hardening beyond passkeys.

This is the first of the two headline features.

Supported authenticators

UIID v2.12 supports FIDO2/WebAuthn passkeys across:

Apple Touch ID and Face ID
Google Password Manager
Windows Hello
1Password
YubiKeys

This list is deliberate. It covers the platform authenticators built into phones and laptops, the major password managers that store passkeys, and hardware security keys. A person on an iPhone, an Android phone, a Windows PC, or a hardware key can all use UIID with the unlock method they already trust.

An authenticator can be built into a device, such as Windows Hello or Apple Face ID, or be a physical key you plug in, such as a YubiKey, or be a password manager that supports passkeys. UIID works with all three kinds.

Users can sign in with a passkey in two ways.

One-click discoverable (usernameless) sign-in

The user opens the sign-in page and taps the passkey option. Their device shows the available UIID passkeys, and they confirm with a fingerprint or face scan. There is no username field and nothing to type.

This works because the passkey is discoverable: the device finds the right credential for the site on its own. For the user, it is the shortest path from “I want to sign in” to “I am signed in.”
Identifier-first sign-in

Here the user first enters their identifier. UIID then asks for the passkey that belongs to that account. The flow is a little longer but more familiar. It helps in situations where the user shares a device with others, manages several accounts, or simply prefers to confirm which account they are using before the biometric step.

Both modes finish with the same short biometric confirmation. We built both because people think about sign-in differently, and neither group should be forced into the other’s habit.

Registering without a password

On the /register page, a new user can now create a UIID account directly with biometrics. There is no password to invent, remember, store, or lose. The account starts out as a zero-password account.

We think this is one of the most important parts of the release, for three reasons:

Less friction at sign-up. The “choose a password” step is a well-known place where people give up. Replacing it with a fingerprint or face scan shortens the path.
A stronger starting point. The first credential on the account is already a phishing-resistant one. There is no weak password to upgrade later.
Nothing to leak. An account that never had a password cannot have its password stolen, guessed, or reused somewhere else.

Security preferences you can control

Different people want different trade-offs between speed and caution. In Security Settings at /dashboard/security, v2.12 adds two groups of controls.

Passkey Login Mode. Users choose how passkey sign-in works for their account:

Mode	What it means	Who it suits
Both	Discoverable and identifier-first sign-in are both available	Most users
Discoverable Only	Sign-in works only through the usernameless flow	People who want the fastest path and use their own device
Identifier-First Only	Sign-in requires entering the identifier first	People who prefer an explicit account step, or share devices

Step-up Email OTP. Users can require a one-time code sent by email, in addition to the passkey. The passkey proves that the right device and the right person are present. The email code adds a second, independent check. For someone who wants an extra layer, it is a simple switch.

The point of these options is that security is not one-size-fits-all. A person managing a personal account on a single phone may want the simplest path. Someone with higher-risk accounts may want the extra step. UIID lets each user decide.

Sync, transfer, and recovery guidance

The most common question about passkeys is: “What happens if I lose my phone?” It is a fair question, and a poor answer is a real barrier to adoption. A strong passkey sign-in can be bypassed if the email, support, or recovery path can replace the passkey with weaker proof.

So v2.12 includes clear in-product guidance on how access works and how to move it. The guidance explains:

Hardware enclave binding. How a passkey is tied to the secure hardware of the device where it was created.
OS cloud keychain syncing. How iCloud and Google keychains can sync passkeys between a person’s devices.
Multi-device access transfer. Three ways to bring access to a new device: an encrypted .uiid file export, cross-device QR scanning, or a recovery key.

We believe people make better decisions when they understand the options before something goes wrong. A person who knows that their passkey is device-bound, and has saved a recovery key, is in a much better position than one who finds out after losing a phone.

How this fits UIID’s local-first design

UIID generates identities on the user’s device and relies on device biometrics. LINKSPREED’s own description of UIID also stresses hardware-anchored security: identities are secured locally within physical security modules using WebAuthn standards, and because localized biometrics are required, creating mass bot networks or throwaway fake profiles becomes difficult and expensive.

Passkey sign-in and registration put this principle into everyday use. The private key lives in secure hardware. The biometric check happens locally. The server holds only public information. For UIID, this is a natural way for the product to work.

A few everyday scenarios

The new user on a phone. Anna opens UIID on her iPhone and goes to /register. She confirms with Face ID. Her account exists, and she never created a password. Next time, she opens UIID, taps once, looks at her phone, and she is in.

The person with several devices. Tom uses a Windows laptop at work and an Android phone privately. He uses Windows Hello on the laptop and Google Password Manager on the phone. He exports an encrypted .uiid file to move access between them, and he keeps a recovery key in a safe place.

The security-minded user. Maria wants more control. In /dashboard/security she sets Passkey Login Mode to Identifier-First Only and switches on step-up Email OTP. Signing in takes a few more seconds, and she is comfortable with that.

The hardware key user. Jonas carries a YubiKey. He registers it as a passkey, and the private key never leaves the key.

Part 4: UIID WebAuthn-as-a-Service

This is the second headline feature, and for many organizations it may be the more far-reaching one.

The hidden cost of “just add passkeys”

From the outside, adding passkey sign-in to an application sounds like a small feature. Inside, it is a project. A relying party has to own two full WebAuthn ceremonies, registration and authentication, and also recovery, which is a separate system the spec does not write for you.

The details are demanding. Attestation objects are encoded in CBOR and public keys in COSE, so verification is real cryptographic code, not simple data parsing. Shipping passkeys against the WebAuthn standard takes a relying party at least nine coordinated subsystems, not a single feature flag. Google’s own guidance tells relying parties to use established FIDO2 libraries rather than hand-writing assertion verification.

And the work does not end at launch. The hard parts are recovery, cross-device flows, authenticator metadata upkeep, and browser regression testing that never stops. Even small details need care. For example, Apple and Google synced credentials report a signature counter of 0, so any clone detection built on that counter does nothing for them.

For a large company with a dedicated identity team, this is manageable. For a startup, an agency, a product team with a long backlog, or a company whose core business is something else entirely, it is a heavy load, and a risky one. Small mistakes in signature checking can have serious security effects.

What UIID v2.12 offers

With v2.12, UIID becomes an outsourced WebAuthn Relying Party authentication engine. In plain words: a developer can hand the server-side passkey work to UIID.

Recall what a relying party does. It is the party that issues challenges, registers credentials, stores public keys, and verifies assertions. With the Passkey Provider API, third-party developers can delegate FIDO2 passkey registration and assertion signature verification to UIID.

The short version: your application keeps the user experience, and UIID handles the hard cryptographic part.

The three building blocks

The Passkey Vault (/dashboard/passkeys). This is the place in the UIID dashboard where a developer registers their RP application. It is the control point for the apps that use UIID as their passkey engine.
API credentials. After registering an application, the developer receives API credentials. These identify the application when it talks to UIID.
The Passkey Provider REST APIs (/api/v1/passkey-provider/*). These endpoints are how an application delegates work to UIID. Two jobs are delegated:
- Passkey registration. The creation and registration of a FIDO2 passkey for a user of the developer’s application.
- Assertion signature verification. The check that a sign-in response really was signed by the private key that matches the registered public key.

How an integration looks in practice

The exact calls are described in the developer documentation. In general terms, a flow built on a provider like this works as follows:

Setup (once):

The developer signs in to UIID and opens the Passkey Vault.
They register their application as an RP application.
They receive API credentials and store them safely on their server.

When a user creates a passkey in the developer’s app:

The user chooses to create a passkey in the app.
The app’s backend asks UIID, through the Passkey Provider API, to start the registration.
The user’s browser or device creates the passkey and confirms with a biometric or PIN.
The app passes the result back to UIID, which verifies and registers the credential.

When the user signs in:

The user chooses to sign in with their passkey.
The app’s backend works with UIID to run the authentication.
The user’s device signs the challenge.
UIID verifies the signature and tells the app whether the sign-in is valid.
The app signs the user in, using its own session handling.

The developer never has to write the verification code, never has to decode the low-level data formats, and never has to keep a FIDO2 stack up to date.

Developers should follow the API reference for exact request formats, parameters, and responses. The steps above describe the general shape of a delegated flow.

What stays with the application

Delegating the passkey engine does not mean delegating everything. The developer’s application still owns:

The user experience: screens, wording, branding, and the point in the journey where passkeys are offered.
The user account and session: what happens after UIID confirms the sign-in.
Business rules: who may register, which actions need extra checks, and what to do in unusual cases.
Account recovery policy: how the application treats a user who has lost access. As noted earlier, recovery is part of the security model and has to be designed on purpose.

FIDO2 also does not decide who is allowed to register. That decision remains with the application.

Why this is valuable

Speed to market. Passkey support becomes an API integration. A team can reach passwordless sign-in in a fraction of the time that a custom FIDO2 build requires.
Lower security risk. Signature verification is a place where subtle bugs create serious weaknesses. Using a dedicated, standards-based service reduces the chance of a home-grown mistake.
Less maintenance. The authenticator landscape, browser behaviors, and standards keep moving. With UIID as the engine, the ongoing work of keeping up is not on the application team’s plate.
A consistent standard. UIID builds on FIDO2/WebAuthn, the open standard that browsers and platforms already support. Users get the passkey experience they know from other sites.
One place to manage it. Applications, credentials, and settings are managed in the Passkey Vault, not scattered across code repositories.

Build or buy: an honest comparison

Building in-house is sometimes the right answer. A company that needs full control, has a strong identity team, and has special requirements may choose to build. For many others, the decision looks different:

Question	Build it yourself	Use UIID’s Passkey Provider API
Time to first working passkey	Long: several coordinated subsystems to build	Short: API integration
Verification code	You write, test, and maintain it	Handled by UIID
Standards upkeep	Your team tracks changes	Handled by UIID
User interface	Yours	Yours
Account and session logic	Yours	Yours
Recovery policy	Yours	Yours (with UIID’s guidance on how access moves between devices)
Control over internals	Full	Delegated for the passkey engine

The honest summary is that the real cost of passkeys is rarely in the two ceremonies. It is in recovery, cross-device handling, ongoing metadata upkeep, and constant browser testing. The Passkey Provider API is designed to take a large part of that off the developer’s hands.

Moving step by step

Few organizations switch overnight. Google’s developer guidance recommends keeping existing sign-in methods, such as passwords and two-factor authentication, while moving to passkeys, because of compatibility and user readiness.

An API-based approach fits this. A team can:

Start by offering passkeys as an optional, additional sign-in method.
Let early adopters try it and collect feedback.
Promote passkeys in the interface as confidence grows.
Reduce reliance on passwords over time, as users move across.

Because the heavy part runs through UIID, the first step is small, and each next step is a product decision rather than a large engineering effort.

Who benefits

The service is designed for a wide range of teams. These are examples of where it can help:

Startups that want passwordless sign-in from day one without hiring a specialist.
Product teams with an existing password-based application that want to add passkeys gradually.
Companies with several applications that want one consistent approach to passkeys across them.
Teams building internal tools that want phishing-resistant sign-in without running their own WebAuthn server.
Agencies and software consultancies that build many applications for different clients and want a repeatable way to add strong sign-in.
Services in sensitive areas such as finance, health, or e-commerce, where account takeover is costly and phishing resistance is a priority.

Part 5: How the two passkey features work together

On the surface, the two features look separate. One is for people who use UIID. The other is for developers who build applications. In practice, they support each other.

They prove the same engine. The user-facing features show that UIID can run passkeys well: two sign-in modes, step-up checks, and clear recovery guidance. The provider API offers that same capability to others.
They grow the value of passkeys. The more places a person can use passkeys, the more natural it feels. And the more people who are comfortable with passkeys, the easier it is for developers to adopt them. Each side makes the other more useful.
They share one philosophy. Both rest on the idea that identity should be anchored in the user’s own device and in open standards, not in a shared secret stored on a server.
They match UIID’s wider direction. LINKSPREED describes UIID as a model that separates a master Core ID from context-specific aliases, so that outside platforms cannot link a person’s behavior across services. UIID also now extends beyond human users and supports six specialized entity types, including AI agents and autonomous algorithms. A strong, standards-based passkey layer is a solid foundation for all of this.

Part 6: Security hardening in v2.12

Passkeys are powerful, but sign-in is only one part of account security. FIDO2 does not secure a compromised server session or repair a weak recovery process. For that reason, v2.12 also strengthens the surrounding systems.

The release includes hardening of the core security architecture in four areas:

Account recovery. Recovery is often the weakest link in an otherwise strong system. Hardening it means that an attacker cannot simply bypass a strong passkey by going through a weaker door.
Step-up re-authentication middleware. For sensitive actions, the system can ask the user to prove their identity again, even if they are already signed in.
Dual-control administrative approval queues. Important administrative actions can require approval from a second person, so that no single account can make a high-impact change alone.
Session protection mechanisms. Stronger protections around active sessions help reduce the risk after sign-in has happened.

These changes are less visible than a new login screen, but they are a core part of the release. A strong front door matters only if the rest of the building is also secure.

Part 7: A better mobile experience

Many people will meet passkeys on their phone, so v2.12 also improves the mobile experience.

Reworked pages for small screens. The /login page and the /kyc/digital-id page were overhauled for small mobile viewports, so that the key actions are easy to reach and read on a phone.
A floating navigation bar that gets out of the way. The floating mobile navigation bar now listens to the scroll direction. It hides when the user scrolls down, which gives content more room, and it comes back smoothly when the user scrolls up.

Passkey sign-in is meant to feel quick and natural, and a clean mobile screen is part of that.

Part 8: Frequently asked questions

Do users need a password to use UIID v2.12?

No. On /register, a user can create an account directly with biometrics, which gives a zero-password account.

Which devices and tools work?

Apple Touch ID and Face ID, Google Password Manager, Windows Hello, 1Password, and YubiKeys.

Does UIID see or store my fingerprint or face?

No. The biometric check happens on the device, and the website only learns that the check passed.

Discoverable sign-in needs no username: the device finds the passkey for the site. Identifier-first sign-in asks for the identifier first, then requests the matching passkey.

Yes. In /dashboard/security, choose Both, Discoverable Only, or Identifier-First Only.

Can I add an extra check on top of my passkey?

Yes. You can enforce a step-up Email OTP on passkey sign-in.

What happens if I lose my device?

It depends on the passkey type and what you set up. Device-bound passkeys are lost with the device, while synced passkeys remain available through the provider. UIID explains your options in the product, including .uiid file exports, cross-device QR scanning, and recovery keys. We recommend setting up a recovery option in advance.

What is WebAuthn-as-a-Service?

It is UIID acting as an outsourced WebAuthn Relying Party for your application. You register your app and call the REST APIs, and UIID handles passkey registration and assertion signature verification.

Where do I start as a developer?

Open the Passkey Vault at /dashboard/passkeys, register your application, receive your API credentials, and use the /api/v1/passkey-provider/* APIs.

Do I still need to build user accounts and sessions?

Yes. Your application keeps its own user experience, accounts, sessions, and recovery policy. UIID takes over the passkey engine.

Can I keep passwords while I move to passkeys?

That is a sensible approach. Keeping existing sign-in methods during the transition is common guidance for compatibility and user readiness.

Are passkeys enough on their own?

They are very strong for sign-in, but not a complete answer. Recovery, sessions, and administration must be secured as well, which is why v2.12 includes broader security hardening.

Part 9: What this means going forward

Passkeys are moving from a nice extra to the normal way to sign in. The standards are mature, the major platforms support them, and users increasingly expect that signing in should not require remembering a secret.

With v2.12, UIID supports this change in two ways. For people, it offers sign-in and onboarding without passwords, with choices about how strict they want to be and with clear guidance for when devices change. For developers, it offers a way to add passkeys to their own products through one set of APIs, without building and maintaining a full FIDO2 verification stack.

We see these as one idea, offered at two levels: identity that is anchored in the user’s own device, built on open standards, and available to everyone who needs it.

Get started

For users

Create your UIID at uiid.me and register with your fingerprint or face on /register. Review your passkey options under /dashboard/security. Set up a recovery option, such as an encrypted .uiid export or a recovery key, so that you are prepared when you change devices.

For developers

Open the Passkey Vault at /dashboard/passkeys. Register your RP application and receive your API credentials. Integrate the /api/v1/passkey-provider/* REST APIs for passkey registration and assertion verification. Keep your existing sign-in in place at first, and roll out passkeys step by step.

About LINKSPREED LLC

LINKSPREED builds Web4 infrastructure, including UIID, a local-first identity protocol that uses on-device biometrics and zero-knowledge proofs for private, passwordless authentication. UIID is available at uiid.me.