Passkeys Explained: How They Work, Why They Stay on Your Device, and How UIID 2.12 Uses Them to Create Your Identity

A long read on the technology that is replacing passwords, what it can and cannot do, and how it fits into LINKSPREED’s UIID

Estimated reading time: 45 to 55 minutes

Key takeaways

A passkey is a pair of cryptographic keys, not a secret you remember. Your device creates a private key and a public key. The service only receives the public key. The private key stays with you.
Passkeys rest on open standards. They are built on FIDO2, which combines WebAuthn (the web standard) and CTAP2 (the protocol between your browser and the authenticator).
They are phishing-resistant by design. A passkey is bound to the real domain of the service. A fake website on another domain cannot use it.
They live on your device. The private key sits in secure hardware, and your fingerprint or face scan is checked locally and never sent to the service.
Passkeys are no longer a niche idea. The FIDO Alliance’s Passkey Index 2026 reports that 36% of successful sign-ins now use a passkey, up from about 26% a year earlier.
Passkeys prove that you hold a key. They do not prove who you are. That is the gap an identity layer has to fill.
UIID will support passkeys fully from version 2.12. You will be able to create your UIID with a passkey and never need a passphrase or a password.
UIID is an identity you own. It splits your identity into a protected Core ID and many context-specific aliases, and it uses on-device biometrics and zero-knowledge proofs.

Why passwords failed
What a passkey is, in plain language
A short cryptography primer
The standards: FIDO2, WebAuthn and CTAP2
The four roles in every passkey interaction
What is actually inside a passkey
Creating a passkey, step by step
Signing in with a passkey, step by step
User presence and user verification
Why passkeys resist phishing
On-device: where the key lives and what stays private
Platform authenticators and security keys
Device-bound and synced passkeys
What the security guidelines say
Signing in on a device that does not have your passkey
Attestation: can a service trust your authenticator?
Recovery: the hardest part
Moving passkeys between providers
Adoption: what the numbers say in 2026
Common myths
What passkeys do not solve
UIID in depth
UIID 2.12: full passkey support
Creating your UIID with a passkey
What the passkey protects inside UIID
How passkeys and UIID work together
Who benefits and how
How to prepare
FAQ
Glossary
Conclusion

1. Why passwords failed

Passwords were a good idea for a small, closed computer system. They were never a good idea for the open internet.

The basic problem is simple. A password is a secret that two sides know: you and the service. For it to work, you must remember it, type it, and trust that the service stores it safely. Each of these steps goes wrong in practice.

People cannot remember hundreds of strong, unique passwords. So they reuse them, make them short, or add a number at the end. An attacker who gets one password from one leak can try it on many other services. This is called credential stuffing.

Services store something derived from the password. Even when they do it well, every service becomes a database worth attacking. When one is breached, the damage reaches far beyond that service.

Humans can be tricked. A fake page that looks like the real one is enough. You type the password, and the attacker has it. No technical weakness is needed, only a convincing page and a moment of inattention.

The fixes we added on top created new problems. SMS codes can be intercepted or redirected through SIM swapping. Push approvals can be spammed until someone taps “approve” just to make the notifications stop. Authenticator app codes can be typed into a phishing page just like a password.

Here is the whole picture in one table:

Weakness	What attackers do
Reused passwords	Try stolen logins on many other services
Weak passwords	Guess or brute-force them
Phishing	A fake page collects the password, then the attacker logs in
Shared secrets on servers	One database breach exposes many accounts
SMS codes	SIM swapping and interception
Push approvals	Users are spammed until they approve
One-time codes from apps	Typed into a fake page, then relayed to the real one

All of these attacks work for the same reason: the secret can be typed, copied, guessed or handed over. If the secret cannot be typed or handed over, the whole group of attacks loses its basis. That is the idea behind passkeys.

2. What a passkey is, in plain language

A passkey is a login credential that replaces your password. You do not choose it. You do not remember it. You never type it. Your device creates it for you when you sign up with a service or add a passkey to an existing account.

A simple picture helps. Imagine a lock and a key. When you register, your device builds a matching pair. The lock goes to the service. The key stays inside your device and never leaves it. When you want to sign in, the service shows your device a random number and asks, “Can you prove that you hold the key that fits my lock?” Your device answers by creating a signature over that number. The service checks the signature with the lock. If it fits, you are in.

Three things follow from this picture.

First, the service holds nothing worth stealing. The lock (the public key) is not a secret. If a database leaks, attackers get locks. Locks cannot be turned into keys.

Second, there is nothing for you to remember, reuse or leak. Each passkey is created for exactly one service. A leak at one service has no effect on another.

Third, you unlock the key locally. Before your device uses the key, it asks for your fingerprint, your face or your device PIN. The passkey therefore combines “something you have” (the device that holds the key) with “something you are” or “something you know” (your biometrics or PIN) in a single step.

In technical terms, a passkey is a WebAuthn credential that is “discoverable.” That means the authenticator stores the account information together with the key, so you do not have to type a username. You pick your account from a list, confirm, and you are in.

3. A short cryptography primer

You do not need to be a mathematician to understand passkeys, but one idea is worth having: asymmetric cryptography, also called public-key cryptography.

In the old model (symmetric), both sides share the same secret. If either side loses it, it is gone for both. A password is this kind of secret.

In asymmetric cryptography, you create two keys that belong together:

The private key is kept secret. It can create signatures.
The public key can be shared with anyone. It can only check signatures.

The relationship is one-way. Knowing the public key does not let you work out the private key in any practical way. And a signature made with the private key can be checked by anyone with the public key, but cannot be forged without the private key.

A challenge is a random value that the service creates for each sign-in. Your device signs the challenge, and the service checks the signature. Because the challenge is new every time, an old signature is worthless. An attacker who records a login cannot replay it later.

This is the full security model in two sentences: the server stores only the public key, and the user’s device stores the private key. The server never receives the private key, and even if the server database is breached, attackers only get public keys, which cannot be used to log in.

4. The standards: FIDO2, WebAuthn and CTAP2

A passkey is not a product of one company. It is the user-friendly name for credentials built on open standards from the FIDO Alliance and the World Wide Web Consortium (W3C). It helps to know the three names you will keep seeing.

FIDO2 is the overall framework for passwordless authentication. It defines the architecture, the security model and the requirements for the whole ecosystem. It combines two standards:

WebAuthn (Web Authentication) is the W3C web standard. It defines how a website or app communicates with the browser to create and use credentials. It is an official web standard implemented by all major browsers.
CTAP2 (Client to Authenticator Protocol) defines how the browser or operating system talks to an authenticator over transports such as USB, NFC or Bluetooth Low Energy.

Passkey is the non-technical, user-facing word for a WebAuthn credential. It can be bound to one device, or synced across devices.

One important limit is also worth stating at this point. FIDO2 gives phishing-resistant and replay-resistant authentication when it is implemented and validated correctly. It does not prove a person’s legal identity, decide who should be allowed to enrol, protect a compromised server session or repair a weak account recovery process. We will come back to these limits in Section 21.

5. The four roles in every passkey interaction

Every passkey sign-in or registration involves four parties. Knowing them makes everything else easier to follow.

Role	What it is	Example
User	The person who agrees to the action	You
Authenticator	The component that creates and uses the key	The secure hardware in your phone, a chip in your laptop, a security key
Client	The software that connects the service and the authenticator	Your browser or operating system
Relying party	The service that wants to know the user controls the key	A website, an app, or UIID itself

A few details matter here.

The authenticator can be hardware, software, or a combination of both. On a modern phone, it is usually a mix: dedicated secure hardware that holds the key, and software that decides when to use it.

The client is what keeps the system honest. It tells the authenticator which website is asking. The authenticator uses this information to decide whether it holds a matching credential, which is the basis of phishing resistance (Section 10).

The relying party is the service. It “relies” on the passkey to know who is signing in. In this article, UIID is a relying party when you sign in to it. It also acts as an identity provider for other services, which is a separate role that we describe in Section 22.

6. What is actually inside a passkey

When a passkey is created, several pieces of data are involved. A good simple summary is this:

Piece	What it is	Who holds it
Private key	The secret that creates signatures	Only the authenticator
Public key	The part that checks signatures	The service
Credential ID	A label that lets the authenticator find the right key	Both
Relying party ID	The domain the passkey belongs to	Both
User handle	An internal identifier for the account	Stored with the passkey, so the service can recognise the account

The relying party ID deserves attention. It is the domain name of the service, such as example.com. The authenticator records it with the key. Later, when a website asks for a sign-in, the browser tells the authenticator which domain is asking. If the domain does not match, the authenticator behaves as if it has no passkey for that site. This one check is the reason passkeys resist phishing so well.

Because the passkey is discoverable and stores the user handle, the authenticator can show a list of your accounts for a service. You do not need to type a username. From your side, the sign-in becomes: open the service, pick your account, confirm with your fingerprint.

7. Creating a passkey, step by step

Creating a passkey is called registration. The user sees a short confirmation. Behind the scenes, this is what happens.

You choose to sign up or add a passkey.
The service asks your browser to start a registration.
The service sends a challenge. This is a random, single-use value. It comes with the service’s own identifier, which is its domain.
Your browser passes the request to the authenticator. It also tells the authenticator which domain the request comes from. The authenticator checks that this is consistent.
You confirm. Your device asks for your fingerprint, your face or your device PIN. This is the only step you notice.
The authenticator creates a new key pair. The private key is stored in protected hardware or in a protected credential store. The public key and some metadata are prepared for the service.
The service stores the public key. It checks the response, links the key to your account and finishes the registration.

Three points are worth repeating.

The private key never travels. It is created on the device and stays there, or stays within the protected sync system described in Section 13.
The service never sees your fingerprint or face. The biometric check is local. The result is only “yes, the owner is present”, which unlocks the key.
The service does not need a secret from you. There is no password field, no password policy and no password reset flow, at least for this credential.

8. Signing in with a passkey, step by step

Signing in is called authentication. It is shorter than registration.

You go to the service and choose to sign in.
The service sends a fresh challenge. Because it is new every time, an old login cannot be replayed.
Your device asks you to confirm. You use your fingerprint, your face or your PIN.
The authenticator signs the challenge with the private key. The signed data includes the domain the request came from.
The service verifies the signature using the stored public key. If it matches, you are signed in.

From your side, this feels like a one-tap login. From a security side, it is a cryptographic proof that does not reveal any secret, cannot be replayed and only works for the right domain.

Many services also support a convenient variant of this flow: when you tap into the username field, the browser or operating system offers your saved passkey right there, so you do not even have to start a separate “sign in with passkey” step. This is a user-interface feature on top of the same mechanism.

9. User presence and user verification

Two terms appear in the specifications and in many security discussions.

User presence (UP) means that a person was physically there. It is proven by a simple action, such as touching a security key or tapping a confirmation on the screen. It answers: “Is somebody actually here?”

User verification (UV) means that the authenticator checked who the person is, using a biometric or a PIN. It answers: “Is it the owner?”

A passkey flow on a phone or laptop normally includes both. When the service requires user verification, the authenticator will not sign until the owner has been verified locally. This is what turns a passkey into a multi-factor login in one step: the device is the “have” factor, and the biometric or PIN is the second factor.

This matters for how people think about security. Many users believe that a passkey is “less secure” than a password plus a code because it feels simpler. In fact, it covers two factors with one gesture, and it is the stronger of the two combinations against the most common attack, phishing.

10. Why passkeys resist phishing

Phishing works because a human has to make a decision. A fake page can look exactly like the real page, and the user types their password into it.

With passkeys, the decision is removed from the human. The authenticator ties each credential to the domain it was created for. If a fake site on a different domain asks for a login, the authenticator will not find a matching credential and will not sign anything. It does not matter how perfect the fake page looks. The check is made by software on your device, using the real domain shown by your browser, not by you looking at a page.

The same mechanism helps against attacks where a proxy sits between you and the real service and passes everything through. Such a proxy is called an adversary-in-the-middle. The signature includes the origin, so a relayed login does not work for the attacker. This is one of the main reasons the NIST guidelines describe authenticators that bind their output to a communication channel or a verifier name as phishing-resistant.

Attack	Password with SMS code	Passkey
Fake login page	Often works	Fails, because the domain does not match
Proxy that relays the login	Often works	Fails, because the origin is part of the signature
Leaked server database	Passwords or hashes can be cracked	Only public keys leak, which cannot be used to log in
Replay of a captured login	Possible in some setups	Fails, because every challenge is new
Credential stuffing	Works if the password was reused	Not possible, because nothing is reused
SIM swap	Can intercept codes	No code to intercept
Push fatigue	Can wear users down	No push approval to spam

The FIDO Alliance’s own data points in the same direction. In its Passkey Index 2026, every participant that measures phishing reported fewer successful attacks since deploying passkeys.

An honest note: “phishing-resistant” does not mean “attack-proof”. Malware on your device, a hijacked session after login or a weak recovery process can still cause harm. Passkeys remove one large class of attacks. They do not remove the need for device security.

11. On-device: where the key lives and what stays private

The most important property of a passkey is that the private key is created on your device and stays under your control. It is not uploaded to the service, and the service cannot ask for it.

Modern phones and computers have dedicated secure hardware for this purpose. Depending on the device, this is a secure enclave, a trusted platform module (TPM) or a trusted execution environment. Google’s engineering team describes the design principle as keeping private keys securely bound to the device, often protected by hardware such as a Secure Enclave or a TPM. The key is stored there, and the hardware is designed so that apps and the operating system cannot simply read it out. When the key is used, the signing happens inside the protected area.

Your biometric data follows the same logic. The fingerprint or face scan is checked locally. The result is a “yes, this is the owner” that unlocks the key. The biometric is not sent to the service and is not part of the passkey.

What this means in practice:

No secret travels over the network. Only a signature does.
No central place holds everyone’s secrets. An attacker would have to attack each device separately and get past its hardware protection.
You unlock it. Without your biometrics or PIN, the key stays locked.
The service sees less about you. It receives a public key and a signature, not your biometric and not a reusable secret.

This “on-device” idea is also the core idea behind UIID, and it is the reason the two fit together so naturally. LINKSPREED describes UIID as a local-first identity protocol that generates cryptographically secure identities directly on the device and uses device biometrics for passwordless authentication.

12. Platform authenticators and security keys

Authenticators come in two main types.

Platform authenticators are built into the device you already use. Examples are Windows Hello, Touch ID and Face ID, or the unlock method of an Android phone. They are convenient because there is nothing extra to buy or carry. The passkey is stored on the device or in the credential manager of the platform.

Roaming authenticators, also called security keys, are separate hardware devices that connect over USB, NFC or Bluetooth. They are popular in companies and for high-risk accounts. A security key typically holds device-bound credentials, which means the key cannot be copied to another device.

There is also a third place where passkeys can live: credential managers and password managers. Many of them can now create, store and sync passkeys. Microsoft’s developer documentation lists the possible storage places as a hardware security module, a platform authenticator such as Windows Hello, Touch ID or Face ID, or a password manager.

The practical consequence is that “where is my passkey?” does not have a single answer. It depends on which authenticator or credential manager created it. This matters for recovery, as we will see in Section 17.

13. Device-bound and synced passkeys

Passkeys come in two forms. The difference is important for security, convenience and recovery.

Device-bound passkeys stay on one authenticator. A hardware security key is the classic example. If you lose it, the passkey is gone. The upside is clear control over where the key is. The downside is that you need a backup plan.

Synced passkeys, also called multi-device credentials, can be copied between your devices by a credential manager, such as the one built into your phone platform or a password manager. In Microsoft’s description, the private key is created by the hardware security module and encrypted on the local device. The encrypted key is then synced and stored in the cloud passkey provider, and other devices signed in to the same provider can use the passkey. Examples of providers are Apple’s iCloud Keychain and Google Password Manager. This makes it easier to sign in on a new phone and removes the risk of losing your only device. The trade-off is that the security of the passkey now also depends on the account and cloud service that does the syncing.

	Device-bound	Synced
Where the key lives	On one authenticator	On several devices through a credential manager
Losing a device	Credential is lost	Credential survives
Convenience	Lower	Higher
Control	Very high	Depends on the sync provider
Attestation	Can be supported	Not supported
Typical use	Security keys, high-assurance accounts	Everyday consumer logins

Microsoft’s own figures for synced passkeys in its consumer accounts illustrate the convenience side: 99% of users registered successfully, a sign-in took about 3 seconds compared with 69 seconds for a password with traditional multi-factor authentication, and sign-ins succeeded 95% of the time compared with 30% for legacy methods. These are results from one large provider, but they show why synced passkeys became the default for everyday use.

Neither form is “right” for everyone. A security team that protects administrators will often prefer device-bound keys. A consumer service with millions of users will usually want synced passkeys, because most people do not want to buy and carry extra hardware or lose access when they replace a phone.

14. What the security guidelines say

Standards bodies have taken a position on this. NIST, the US standards institute, published a supplement in 2024 to its digital identity guidelines on authenticators that can be synced between devices. The guidance states, for the first time, that synced passkeys can meet Authentication Assurance Level 2 (AAL2) if they are properly implemented. Passkeys that are not synced, such as device-bound keys stored in dedicated hardware, can reach the higher AAL3 rating.

NIST’s current guidelines, SP 800-63-4, include an appendix on syncable authenticators. It requires, among other things, that:

keys moved to a sync system are stored only in encrypted form,
all authentication operations happen with private-key operations on the local device,
access to the keys in the sync system is protected by multi-factor authentication equivalent to AAL2, and
the user interface should let people see which services have a syncable key, whether it has been synced, and where.

The same guidance also defines what phishing resistance means: an authenticator is phishing-resistant if it binds its output to a communication channel or a verifier name. FIDO credentials, which are tied to registered web domains, meet this idea.

For organisations, the takeaway is practical. Synced passkeys are a good fit for consumer and citizen use where risk is moderate to low. For administrators and sensitive systems, device-bound credentials remain the stronger choice, because synced passkeys shift much of the responsibility for where the key may be copied to the user.

15. Signing in on a device that does not have your passkey

What if you want to sign in on a computer that does not have your passkey, for example a work laptop, a friend’s PC or a public terminal? FIDO2 has a standard answer, called hybrid transport or cross-device authentication.

Here is how it works in simple terms:

The computer shows a QR code. It contains information for setting up a secure connection.
You scan it with your phone, which holds the passkey.
The phone and the computer check that they are physically close using Bluetooth Low Energy. Bluetooth is only used as a proximity check, not as a data channel.
Your phone asks for your fingerprint, your face or your PIN.
The signing happens on the phone. The data flows over an encrypted internet connection between the two devices, and the private key never leaves the phone.

The proximity check is the clever part. Without it, an attacker who tricks you into scanning a QR code could complete the login from anywhere on the internet. With it, the phone refuses to sign unless it can confirm over Bluetooth that it is near a device matching the QR code’s connection material. The mechanism is specified in the CTAP 2.2 specification.

This is why a phone can act as a passkey for almost any computer without you typing anything. It is also one of the reasons that passkeys stay “yours to keep”: your credential does not get stuck on a single device, but the private key also does not get copied around.

A realistic note: the user experience of cross-device sign-in still varies. One 2026 benchmark found that completion rates on Windows web are 79% to 98% when the user is already known on the device, but drop to 52% to 67% when the login starts with an identifier on a new device. This is an area where products and platforms are still improving.

16. Attestation: can a service trust your authenticator?

Attestation is an optional feature of FIDO2. During registration, the authenticator can provide evidence about what kind of device it is. This allows a service to say, for example, “I accept only certified hardware security keys”.

For most consumer services, attestation is not needed. For high-security environments, it can be important. The trade-off is that attestation depends on a known, fixed device. For this reason, synced passkeys do not support attestation. The service cannot be sure that the credential will be used from the device that created it.

In short: if a service needs to know exactly which hardware holds your key, it should ask for device-bound credentials with attestation. If it simply wants strong, phishing-resistant sign-in for everyday users, synced passkeys without attestation are the practical choice.

17. Recovery: the hardest part

Every article about passkeys eventually reaches this point. A strong login is only as strong as the way back in when you lose it.

A security guide puts it clearly: recovery is part of the security model, because a strong FIDO2 login can be bypassed if email, support or identity-recovery paths can replace the credential with weaker evidence. Another guide calls this the “recovery paradox”: strong login, weaker fallback.

Whether you can recover depends on where your passkey lives.

A synced passkey can reappear on a new device when you sign in to your Apple, Google or password manager account there.
A passkey that exists only locally stays on the old device. If the device is lost, the passkey is lost.
A security key is a third case. It fits in a pocket and not in a cloud, so you need a second key or another recovery option.

Microsoft’s guidance for users is direct: a passkey cannot be “recovered” like a password. It can be used or deleted, but not revealed. If access is lost because a device was reset or a passkey was deleted, you sign in with another method, remove the old passkey and create a new one.

For anyone who uses passkeys, a few habits make a big difference:

Know where each important passkey is stored. Is it in your phone’s credential manager, in a password manager, or on a security key?
Have a second way in. A second device, a second security key, or a recovery code stored safely.
Do not delete your old sign-in method until you have tested the new one. The recommended practice in one recovery guide is to keep the old path until an independent recovery method has passed a test in a fresh browser.
Treat recovery as part of the security design. If recovery can be done by anyone who can read your email, that is your real security level.

For services, the lesson is the same. A good service explains clearly what happens when a user loses a device, and it does not open a back door that undoes the benefit of the passkey.

18. Moving passkeys between providers

Early on, passkeys had a lock-in problem. If your passkeys lived in one provider’s ecosystem, moving to another was awkward, and the common workaround, exporting data as a file, was insecure.

The FIDO Alliance has addressed this with the Credential Exchange Protocol (CXP) and the Credential Exchange Format (CXF). They let users copy their passkeys from one password manager to another in encrypted form, without the unsafe detour through CSV files. The specification can also be used for other credentials, including traditional passwords. A broad group of companies took part in this work, including Apple, Google, Microsoft, 1Password, Bitwarden, Dashlane and others.

Why does this matter? Because ownership is a theme of this article. A credential that you cannot move is a credential that someone else partly controls. Portability is part of what keeps the ecosystem open.

19. Adoption: what the numbers say in 2026

Passkeys are no longer a theory. Several 2026 reports from the FIDO Alliance describe a technology that has reached mass use.

Usage. The FIDO Alliance’s Passkey Index 2026, published on 15 October 2026, reports that more than one in three successful sign-ins now use a passkey: 36%, up from about 26% in 2025. Enrolment grew more slowly. The bigger change is that people who have a passkey use it more often.

Success and speed. In the same index, passkey sign-ins succeed more often than traditional multi-factor sign-ins (93% versus 78%) and are nearly three times faster than signing in without a passkey, saving users an average of 27 seconds per sign-in.

Business effects. Every participant that provided savings data reported lower costs for SMS one-time passwords.

Scale and awareness. The State of Passkeys 2026 report, based on a survey of 11,000 consumers and 1,400 decision-makers in ten countries, reports 5 billion passkeys in active use. 90% of consumers are familiar with passkeys, and 75% have enabled them on at least some accounts. 68% of organisations are deploying, piloting or rolling out passkeys for employee authentication.

The gap between enabling and using. One analysis of the same figures points out that only 49% of consumers use passkeys regularly, a gap of 26 points to the 75% who have enabled one. It also notes that most organisations still run passwords in parallel. So the honest picture is: adoption has arrived, but the full transition has not.

Device readiness. A passkey-readiness tracker reports that 96% of devices were passkey-ready in August 2026.

What does all this mean? The question for services is no longer “will users understand passkeys?” but “how do we make them the normal way to sign in, and how do we handle recovery well?”

20. Common myths

“A passkey is just a password manager feature.” No. A password manager stores secrets that you could type. A passkey is a key pair, and the private key is never typed or shared. Some password managers can store and sync passkeys, but the credential itself is not a password.

“If my phone is stolen, the thief has my accounts.” The thief would still need to get past your biometrics or PIN. Without that, the key stays locked. You should also protect your device with a strong lock screen code, because that code is the second factor.

“Biometrics are uploaded to the service.” No. The biometric check stays on your device and only unlocks the key.

“Passkeys only work with one big tech company.” No. They are built on open standards and work across browsers, operating systems and credential managers. Transfer between providers is being standardised too.

“Passkeys remove the need for recovery planning.” They do not. If anything, recovery planning becomes more important, because the login itself is much stronger than the fallback.

“A passkey proves who I am.” It proves that you control a specific key. It does not prove your name, age or nationality.

21. What passkeys do not solve

Passkeys are a large step forward. A good article should say clearly what they leave open.

They do not prove who you are in the legal sense. A passkey says “the same holder as last time”. It does not say “this is Jane Doe, aged 34, from Germany”.
They do not decide who may sign up. A service still needs its own rules for registration, and its own protection against fake or bulk accounts.
They do not protect a hijacked session or a compromised device. If malware controls your device after you sign in, the passkey cannot help.
They do not fix weak recovery. If an attacker can reset your account through a weak email or support process, the passkey is bypassed.
They are tied to one service. A normal passkey proves you to one website. It is a login for that service, not a portable identity across the web.
They do not stop a service from knowing you. Each service still builds its own profile of you inside its own walls. A passkey gives you a safer door, but it does not decide what the room behind the door knows about you.

That last group of points is exactly where an identity layer starts. Passkeys answer the question “how do I log in safely?” They do not answer “who am I online, how much of myself do I reveal, and who controls that?” This is what UIID is for.

22. UIID in depth

UIID stands for Universal Integrated Identity Decoupled. It is the identity layer of LINKSPREED’s Web4 vision. LINKSPREED LLC is a technology company founded in 2025 and based in New Mexico. It describes UIID as its system for secure, decentralised user identity, alongside products such as TribeMaker.

The idea behind UIID is that your identity should belong to you, not to the platform you happen to sign in to. UIID is a local-first identity protocol. It creates cryptographically secure identities directly on your device and uses device biometrics and zero-knowledge proofs for private, passwordless authentication. By decoupling identity from individual platforms, it makes the individual user the administrative authority over their own data.

22.1 Core ID and aliases

The central design idea is a split into two layers.

The Core ID is the protected master identity. It is strictly controlled by the user and is not meant to be handed out. Aliases are context-specific identities for individual apps and situations, such as gaming or work. They allow interoperability without exposing the Core ID.

This split prevents external platforms from cross-correlating your behaviour across independent services. Two services that each receive a different alias cannot easily tell that both belong to the same person.

22.2 Zero-knowledge proofs

UIID uses zero-knowledge proofs, which are a way to prove a statement without revealing the underlying data. In practice, this allows checks such as age or location without disclosing names or full government IDs. The service receives the answer it needs, for example “over 18: yes”, signed by the user’s device, and nothing more.

22.3 WebAuthn and local biometrics

UIID’s authentication is based on WebAuthn. Identities are secured locally on the device using WebAuthn standards, and the system relies on local biometrics. LINKSPREED’s position is that this makes bulk bot accounts and throwaway deepfake profiles economically and technically unattractive. The v1 documentation describes a passwordless flow built from zero-knowledge proofs and WebAuthn, together with granular scopes (for example core:write and alias:read:private), mandatory multi-factor authentication for critical operations and audit log endpoints.

22.4 More than people: six entity types

Since version 2.8, UIID is not only for humans. It defines six entity types, with tailored enrolment flows. They include human individuals, organisations and AI agents. Agents and machines get their own cryptographically verifiable identities.

Several features support this:

Autonomous agent birth. Using a machine-readable skill.md protocol, AI agents can register their own UIID accounts.
The Agent Factory. A control centre where individuals and organisations issue provisioning tokens, start new machine processes, and monitor fleet activity, resource use and trust scores.
Zero-trust provisioning. Static secrets and long-lived access keys are replaced by dynamic authorisation tokens, so an intercepted token cannot be used to compromise a whole fleet.

This is relevant to the topic of this article because it shows the division of labour. Machines authenticate with scoped tokens. Humans authenticate with something a human can hold: a device, a biometric and, from 2.12, a passkey.

22.5 UIID WRAP

UIID WRAP extends the identity across the wider web, including sites that do not integrate UIID. It detects registration forms, generates isolated aliases and prepares credentials, while you stay in charge of every decision. The point is to let people use a separate alias when they sign up somewhere, instead of handing out their primary identifiers.

Bridging from legacy accounts. Users can convert traditional social and banking logins into decoupled Web4 keys. After verification of human status, the link to the legacy tracking is severed.
Embeddable login button. A snippet that allows shop templates, community platforms and custom sites to offer a UIID sign-in without server-side code, while keeping sensitive credentials off the client side.
UIID Mail. A decentralised, passwordless email service built on UIID infrastructure, which LINKSPREED’s channel describes as being in beta.

22.7 Where to try it

You can see UIID and create a free Core ID at uiid.me.

23. UIID 2.12: full passkey support

From the upcoming version 2.12, we will support passkeys fully in UIID.

This is a natural step. UIID has always been built on the same foundations as passkeys: key pairs, on-device storage, local biometrics and WebAuthn. Version 2.12 puts the passkey at the centre of the experience. The passkey becomes the way you create your identity and the way you prove that it is you.

Why do we think this is the right move?

Passkeys are an open standard. Browsers, operating systems and credential managers already support them. People do not have to learn a new concept. The gesture they use to unlock their phone is the same gesture they use for their identity.
Passkeys match the UIID privacy model. The key stays with the user. The biometric stays local. There is no password database. This is exactly the design that UIID has argued for from the start.
Passkeys remove the last weak spots. A passphrase can be written down, photographed or phished. A password can be reused. A passkey cannot be typed into a fake page and cannot be reused across services.
Passkeys are no longer exotic. With 90% of consumers familiar with them and billions in use, the technology that UIID builds on is now familiar to most people.

24. Creating your UIID with a passkey

With version 2.12, you will be able to create your UIID with a passkey. The principle is as simple as it sounds.

You open UIID and choose to create your identity.
Your device asks you to confirm with your fingerprint, your face or your device PIN.
A passkey is created on your device, and your UIID is created with it.
From then on, you sign in the same way, with one confirmation on your device.

You never need a password. You never need to write down or protect a passphrase. There is nothing to type, nothing to forget and nothing to reuse.

Think about what this removes for an ordinary person:

Before	With a passkey
Invent a strong password	Nothing to invent
Store the password somewhere	Nothing to store
Write down or safeguard a long passphrase	No passphrase
Type credentials on every login	One confirmation on your device
Worry about a fake login page	The passkey will not work on a fake domain
Worry about a leaked password database	There is no password database

This keeps the UIID promise of ownership. The passkey stays with you. It does not stay with LINKSPREED and it does not stay with a third party. UIID does not need to hold a database of passwords, because there are none.

25. What the passkey protects inside UIID

A passkey for your UIID is not just a nicer login screen. It affects everything that sits on top of your identity.

Your Core ID. This is the most valuable part of your identity, and it is the part that should never be exposed. Protecting it with a phishing-resistant credential means that the master identity is guarded by something that cannot be typed into a fake page.
Your aliases. Aliases are meant to be created and used freely. The passkey is the way you authorise their creation and use, without the Core ID being revealed to the service that receives the alias.
Zero-knowledge proofs. When a service asks, “is this person over 18?”, the proof is created on your device. The passkey is the natural way to confirm “yes, I authorise this proof”, so the service receives only a signed yes or no.
UIID WRAP. When UIID prepares credentials for a website that does not know UIID, you review and approve what is submitted. A passkey confirmation is a fitting way to make that approval explicit.
Login on other sites. The embeddable login button and standard sign-in flows can rely on a strong, passwordless way to confirm the user.
UIID Mail and other UIID-based services. Passwordless email and other services built on UIID get the same simple and strong way to unlock.
The human side of the Agent Factory. Machines and agents already use scoped tokens instead of passwords. Passkeys complete the picture on the human side, so that the person who creates and controls a fleet of agents signs in with a phishing-resistant credential.

26. How passkeys and UIID work together

It helps to see the two as layers that solve different problems.

Question	Passkey	UIID
How do I log in without a password?	Yes, this is its core job	Uses it, from 2.12 as the main way
Does the key stay on my device?	Yes	Yes, local-first
Is it phishing-resistant?	Yes, bound to the domain	Inherits this for sign-in
Can I use one identity across many services?	No, one passkey per service	Yes, through Core ID and aliases
Can services link my activity across sites?	Not through the passkey	Prevented by context-specific aliases
Can I prove a fact without revealing data?	No	Yes, through zero-knowledge proofs
Can machines and organisations have identities?	Not the focus	Yes, six entity types
Does it prove who I am legally?	No	Not on its own

The simplest summary: the passkey is the key to your front door. UIID is the identity you carry once you are inside. The passkey makes sure that only you can open it. UIID decides how much of you is shown to each service.

It is also worth being clear about what UIID does not claim. It is not a replacement for legal proof of identity. Where a service needs a government-verified fact, that proof still has to come from a trusted issuer. What UIID adds is the way you hold, reuse and reveal such proofs without giving away more than needed.

27. Who benefits and how

For individuals

You get a way to create and use a digital identity with a single confirmation on your own device. There is no password to remember and no passphrase to protect. You can use different aliases for different parts of your life, and the services you use cannot easily connect them.

For developers

Passkeys already follow open standards, and many frameworks have built-in support. Microsoft’s ASP.NET Core Identity, for example, includes passkey registration and authentication. Offering a UIID sign-in means your users can arrive with a strong, passwordless identity, and you do not have to build your own password storage and reset system. The embeddable login button is designed to remove the need for callback handlers and server-side code for simple cases.

For organisations

There is no password database to leak, and the exposure to phishing drops sharply. The FIDO Alliance’s data shows lower SMS code costs and fewer successful phishing attacks for those who deployed passkeys. Because UIID aliases are context-specific, an organisation can confirm what it needs to know without collecting more personal data than necessary.

For privacy-sensitive services

Some services are used only if people trust that nobody else learns who uses them. For these, a service that receives only a signed yes or no, and a context-specific alias instead of a real identity, is a strong fit.

28. How to prepare

Whether you use UIID or not, these habits will serve you well in a passkey world.

Find out where your important passkeys are stored. Look at your phone’s credential manager, your computer’s settings and any password manager you use.
Make sure you have more than one way back in. A second trusted device, a second security key, or a stored recovery method.
Protect your device first. A strong screen lock is the second factor of your passkey. A weak PIN weakens everything behind it.
Keep your credential manager account secure. If your passkeys sync through a cloud account, that account becomes part of your security. Use strong protection for it.
Test recovery before you need it. Try signing in on a fresh device or browser with your backup method.
Do not delete old sign-in methods too early. Remove them only after the new setup has been tested.
When UIID 2.12 arrives, create your UIID with a passkey, and apply the same habits to it.

29. FAQ

Is a passkey the same as a password manager?

No. A password manager stores secrets you could type. A passkey is a key pair, and the private key is never typed or shared. Some password managers can store and sync passkeys, but the credential itself is different from a password.

What if I lose my phone?

It depends on the type of passkey. A synced passkey is available again when you sign in to your credential manager on a new device. A device-bound passkey is not, so you need a second passkey or another recovery option. Plan this before you need it.

Can someone steal my passkey by phishing me?

Not in the usual way. The passkey works only for the real domain it was created for, so a fake site gets nothing.

Does the service see my fingerprint or face?

No. The biometric check stays on your device and only unlocks the key.

Are synced passkeys less secure than device-bound ones?

They have a different trade-off. They are more convenient and easier to recover, but their security depends on the sync provider and your account protection there. NIST says that, properly implemented, synced passkeys can meet AAL2, while device-bound passkeys in dedicated hardware can reach AAL3.

Can I use a passkey on a computer that does not have it?

Yes. Hybrid transport lets your phone sign in on another device after a QR scan and a Bluetooth proximity check.

Can I move my passkeys to another provider?

The FIDO Alliance has introduced the Credential Exchange Protocol and Format for encrypted transfer between password managers. Availability depends on the providers you use.

Do I still need a passphrase or password for UIID?

No. With full passkey support in UIID 2.12, you will be able to create your UIID with a passkey and never need a passphrase or a password.

Does a passkey replace my UIID?

No. The passkey is how you unlock and create your UIID. Your UIID is the identity itself, with its Core ID and aliases.

Where can I try UIID today?

At uiid.me, where you can get a free Core ID.

30. Glossary

Term	Meaning
Alias (UIID)	A context-specific identity that you give to one service instead of your Core ID
Authenticator	The hardware or software that creates and uses the passkey
Attestation	Optional evidence about what kind of authenticator created a credential
Challenge	A random, single-use value that your device signs to prove it holds the key
Client	The browser or operating system component that connects service and authenticator
Core ID (UIID)	The protected master identity in UIID
CTAP2	The protocol between the client and an authenticator
Device-bound passkey	A passkey that stays on one authenticator
Discoverable credential	A credential that the authenticator can list by itself, so no username has to be typed
FIDO2	The open standard that combines WebAuthn and CTAP2
Hybrid transport	Cross-device sign-in using a QR code and a Bluetooth proximity check
Passkey	The user-facing name for a WebAuthn credential, device-bound or synced
Relying party	The service that verifies the credential
Synced passkey	A passkey that a credential manager keeps available across your devices
User presence	Proof that a person is physically there
User verification	Proof that the authenticator checked who the person is, by biometrics or PIN
WebAuthn	The W3C web standard for creating and using public-key credentials
Zero-knowledge proof	A way to prove a statement without revealing the data behind it

31. Conclusion

Passwords were never a good idea. They were the only idea we had. Passkeys replace a secret that you must remember with a key that your device holds for you. They resist phishing, they leave nothing useful on the server, and they keep your biometrics where they belong: on your own device. The 2026 numbers show that this is no longer an experiment. More than a third of successful sign-ins in the FIDO Alliance’s index now use a passkey, and they work more often and faster than the methods they replace.

But a passkey is a login method, not an identity. It tells a service that the same holder is back. It does not decide how many services can link your activity, what they learn about you, or who owns the identity behind the key.

That is the gap UIID is built for. UIID was designed on the same principles as passkeys: local-first, on-device, biometric and passwordless. On top of that, it adds the Core ID and aliases, zero-knowledge proofs, and identities for people, organisations and AI agents. With version 2.12, these principles come together. You will be able to create your UIID with a passkey, and you will never need a password or a passphrase.

If you want to see where this is heading, start at uiid.me.