UIID Is Getting Passkeys: LINKSPREED and DEV.UNITY Want UIID to Become a Secure Passkey Provider

United States / Germany, October 2026

LINKSPREED has confirmed that its identity system, UIID, is going to support passkeys. The confirmation came from founder and CEO Marc Herdina, who shared it on LINKSPREED’s own Web4 social network and on X. LINKSPREED is also working with its sister company DEV.UNITY on a bigger step: making UIID a secure passkey provider in its own right. In that role, UIID would not only accept passkeys. It would create, store, protect and use them on behalf of its users.

This article is long on purpose. It has three parts:

What UIID is and why passkeys fit it so naturally.
A deep dive into passkeys: what they are, how they work under the hood, and why they matter.
What “UIID as a passkey provider” means for users, developers and organizations.

If you only want the news, read the first two sections. If you want to understand passkeys properly, read on.

1. The announcement in plain words

Three things are happening.

UIID will support passkeys. Passkeys are the new, password-free way to sign in that Apple, Google, Microsoft and many others now back. UIID is built around passwordless sign-in, so it makes sense for it to speak this standard language.

UIID is meant to become a passkey provider. A passkey provider is the place where your passkeys live. It is the app or system service that creates them, guards them and offers them when a website asks you to sign in. Today most people use the provider built into their phone or computer, or a password manager. LINKSPREED wants UIID to be a trustworthy choice on that list.

LINKSPREED and DEV.UNITY are building it together. The two sister companies are working on the engineering and security side so that UIID becomes a secure provider, not just a convenient one.

The goal is simple. You should be able to sign in anywhere with a passkey, while your passkeys stay under your own control instead of sitting inside one big platform’s account.

2. What UIID is (and why it is a natural home for passkeys)

To see why this announcement matters, it helps to know what UIID is.

UIID in one paragraph

UIID stands for Universal Integrated Identity (also written as Universal Integrated Identity Decoupled). It is LINKSPREED’s identity layer for Web4, the company’s vision of an internet where people own their data, accounts and identity instead of renting them from big platforms. LINKSPREED describes UIID as a local-first identity protocol. It creates cryptographically secure identities directly on your device and uses device biometrics and zero-knowledge proofs for passwordless sign-in across web and physical platforms.

The ideas inside UIID

Core ID and Aliases. UIID splits your presence into one master Core ID and many context-specific Aliases. Each website or app gets its own alias, so platforms cannot easily follow you from service to service.
Hardware-anchored security. Identities are secured locally in the device’s security hardware using WebAuthn, the web standard behind passkeys. This also makes mass fake accounts and bot networks very hard to create.
Many kinds of identity. Since version 2.8, UIID supports six entity types. Besides people, these include AI agents, devices and organizations. Each gets its own verifiable digital passport.
Zero-trust provisioning. Instead of long-lived secrets and static keys, UIID uses single-use or multi-use authorization tokens, so an intercepted token cannot compromise a whole fleet of agents.
Bridging to the old web. UIID can convert traditional logins into UIID-based keys. UIID WRAP extends this to websites that do not support UIID yet. It detects registration forms, generates isolated aliases, prepares data-minimized credentials, and leaves every final decision to the user.
Developer-friendly. UIID offers an OpenID Connect-style sign-in flow. LINKSPREED also publishes a UIID Cookbook that shows developers how to give users a decentralized ID with the UIID API.

Why passkeys and UIID belong together

Look at what UIID already tries to do: no passwords, keys created on your device, unlocked with your biometrics, a separate identity per context, and no central database that can leak. Now look at what a passkey is: a key pair created on your device, unlocked with your biometrics, unique per website, with no shared secret stored on a server.

These are two expressions of the same idea. Passkeys are the standard that the rest of the internet is adopting for this model. When UIID supports passkeys, it connects the Web4 identity world to the sign-in flows that billions of people already use. When UIID becomes a passkey provider, it can offer something the big platforms structurally cannot: a passkey home that is not tied to one company’s ecosystem.

3. Deep dive: what passkeys are

The problem with passwords

Passwords have three basic flaws.

They are shared secrets. You know the password and the server knows it (or a version of it). Anyone who steals it from either side can use it.
They can be tricked out of you. A fake website that looks like the real one can collect your password, and you will usually not notice.
They are hard for humans. Good passwords are long, unique and impossible to remember across hundreds of accounts, so people reuse them or pick weak ones.

The numbers show the damage. The FIDO Alliance points to passwords as the cause of most breaches, and cites research that 77% of hacking-related breaches involve stolen credentials. It also reports that 48% of people have abandoned an online purchase because they forgot their password.

What a passkey is

The FIDO Alliance defines a passkey as an authentication credential based on FIDO standards. It can be stored on your phone or computer, or on a hardware security key. You use it to sign in to apps and websites with the same process you use to unlock your device: biometrics, a PIN or a pattern.

In everyday terms, a passkey replaces “something you type” with “something your device proves for you.” You do not type a secret. Your device proves, with cryptography, that it holds a secret, and it never reveals that secret.

The word passkey is a general term, not a feature of one company. It is written in lowercase, like password.

The standards behind passkeys

Passkeys are built from a few open building blocks:

FIDO2 is the umbrella standard from the FIDO Alliance. It combines two parts: WebAuthn and CTAP2.
WebAuthn (Web Authentication) is the W3C web standard. It defines how a website talks to the browser to create and use passkeys. In code, this means navigator.credentials.create() for registration and navigator.credentials.get() for sign-in.
CTAP2 (Client to Authenticator Protocol) defines how the browser or device talks to an external authenticator, such as a USB, NFC or Bluetooth security key.
Passkey is the friendly, user-facing name for a WebAuthn credential that may be device-bound or synced across devices.

The short formula is: FIDO2 is the standard, and passkeys are its everyday implementation.

The vocabulary you need

Term	Plain meaning
Authenticator	The thing that holds your private key and checks that it is really you. It can be built into a device (Windows Hello, Face ID), a physical key (YubiKey), or a password manager that supports passkeys.
Relying party	The website or app you sign in to. It “relies on” the passkey to confirm who you are.
User verification	The quick check that you are present and that it is you, usually a fingerprint, face scan or local PIN. Your biometric data never leaves the device.
Challenge	A random, one-time puzzle sent by the website for your device to sign. Because it is different every time, a recorded login cannot be replayed.
Credential ID	A label created with the passkey, so the website can find the right public key for your account.
Origin binding	A passkey is tied to one specific domain and will not respond to any other address.

4. How passkeys work, step by step

The core idea: a key pair

Everything rests on public-key cryptography. When you create a passkey, your device generates two mathematically linked keys:

A private key, which stays on your device (ideally in secure hardware) and is never shared.
A public key, which is sent to the website and stored with your account.

Think of the public key as a lock you hand to the website, and the private key as the only key that opens it. The website can hold the lock without being able to open anything. Even if the website’s database is stolen, the thieves get only locks, which are useless to them.

Step 1: Registration (creating a passkey)

You choose “create a passkey” on a website.
The website sends a challenge and some information about itself, including its domain.
Your browser passes this to your authenticator.
The authenticator asks you to verify yourself with a fingerprint, face or PIN.
It creates a new key pair just for this website and keeps the private key.
It sends back the public key, a credential ID, and a signed proof of the registration.
The website verifies the response and stores the public key and credential ID with your account.

Here is what that looks like in the browser, simplified:

// Registration (simplified)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,           // random bytes from the server
    rp: { name: "Example", id: "example.com" },
    user: { id: userHandle, name: "marc", displayName: "Marc" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }], // ES256
    authenticatorSelection: {
      residentKey: "required",            // discoverable credential
      userVerification: "required"
    }
  }
});

Step 2: Authentication (signing in)

You visit the website and choose to sign in.
The website sends a new, random challenge.
Your browser checks that the website’s domain matches the domain the passkey was created for. If it does not match, the process stops here.
Your authenticator asks you to verify yourself.
It signs the challenge, together with data about the website and the sign-in, using the private key.
The website checks the signature with the stored public key. If it is valid, you are in.

// Sign-in (simplified)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,
    rpId: "example.com",
    userVerification: "required"
  }
});

Notice what never travels over the network: the private key, your biometrics, and any reusable secret. Only a one-time signature does.

What is inside the signed data

A sign-in response contains more than a bare signature:

Client data, including the challenge and the origin (the website address the browser saw).
Authenticator data, including a hash of the website’s domain, and flags that say whether you were present and whether you were verified.
A signature over both.

The server checks every part: the challenge is the one it issued, the origin is its own, the domain hash matches, the verification flag is set, and the signature is valid. A wrong value in any part means the sign-in is refused.

Discoverable credentials: signing in without a username

A passkey is usually stored as a discoverable credential, sometimes called a resident key. The authenticator keeps enough information to identify the account. This is why many sites can show “Sign in with a passkey” and let you pick your account from a list, without typing a username. A user handle links the passkey to your account in the website’s system. It is deliberately not your email or username, because those can change.

Synced passkeys vs device-bound passkeys

There are two main kinds of passkey.

Synced passkeys are copied between your devices by a passkey provider, for example through your phone maker’s cloud or a password manager. They are convenient: lose a phone, and the passkey still exists on your other devices.
Device-bound passkeys stay on a single device or a hardware security key. They offer a stronger guarantee that the key exists in exactly one place, but they are harder to recover.

One technical detail: the sign counter that helps detect cloned authenticators is often 0 and static for synced passkeys. For that reason many websites treat it as advisory rather than decisive.

Sometimes you want to sign in on a computer that does not hold your passkey. For this, passkeys support a cross-device flow. The computer shows a QR code, your phone scans it, and the two devices set up a nearby, encrypted connection. You then approve the sign-in on your phone with your fingerprint or face. The phone-based flow relies on hardware most people never think about, which is also a proximity check.

Attestation: proving what kind of authenticator you have

During registration, an authenticator can optionally provide attestation, a signed statement about what kind of device it is, for example a certified hardware security key. This matters mostly to organizations that want to require specific, approved hardware. Many consumer websites skip it.

5. Why passkeys are better: the added value

They resist phishing

This is the headline benefit. A passkey is bound to the website’s domain, and the browser enforces that. A passkey created for your real bank simply will not answer a lookalike domain. You are not asked to spot a fake page, because the system does it for you. The same property protects against attacks that sit between you and the website.

This matters more every year. The FIDO Alliance cites a 3,000% increase in AI-powered phishing attacks targeting corporate credentials, and a 47% success rate for AI-powered spear phishing against trained security professionals. When even trained people get fooled, relying on human attention is not a plan.

A server breach leaks nothing reusable

The website stores only public keys. Stealing them does not let anyone sign in. With passwords, a breach at one website can cascade to others where people reused the same password. With passkeys, there is nothing to reuse.

Replay attacks do not work

Each sign-in uses a fresh random challenge, so a recorded login is worthless later.

Nothing to remember, nothing to type

You unlock with a fingerprint, face or PIN, the same action you perform dozens of times a day to open your phone. This also removes a lot of friction, such as password resets and “forgot password” emails.

Privacy by construction

Each passkey is unique to one website, so websites cannot use it to recognize you across services. Your biometrics stay on your device, and the website only learns that the check passed.

Real adoption

Passkeys are no longer an experiment. A 2024 survey commissioned by the FIDO Alliance found that 53% of people had enabled passkeys on at least one account, and 22% had done so on every account they could. A 2026 report from the FIDO Alliance, as summarized by Cyberphinix, counts around 5 billion passkeys in active use worldwide.

Passwords vs passkeys at a glance

	Passwords	Passkeys
What the server stores	A secret (or a derivative of it)	Only a public key
Phishing	Works well for attackers	Blocked by domain binding
Reuse across sites	Common	Impossible, one key per site
Breach impact	Credentials can be reused	Nothing reusable
User effort	Remember, type, reset	Fingerprint, face or PIN
Replay	Possible	Prevented by one-time challenge

6. The honest limits of passkeys

A fair deep dive also covers the weak spots, and the better analyses do exactly that. They name three real challenges: account recovery, ecosystem lock-in and enterprise rollout.

Recovery. If a passkey lives in only one place and that place is lost, you need a safe way back in. Many services fall back to email or SMS recovery, and that fallback can become the weakest link.
Lock-in. Synced passkeys are often tied to a single vendor’s ecosystem. Moving from one provider to another has been awkward, which makes people hesitate to commit.
Mixed worlds. Organizations run old systems, shared devices and a range of operating systems. Rolling out passkeys everywhere takes planning.
Trust in the provider. The provider that stores your passkeys holds the keys to your digital life. Its security model, how it encrypts synced data, who can access it, and how recovery works all matter enormously.

This last point is exactly where the “passkey provider” role gets serious, and it is why LINKSPREED and DEV.UNITY frame their work around being a secure provider.

7. What is a passkey provider, and why does it matter?

A passkey provider is the software or service that stores your passkeys and takes part in the sign-in. When a website asks for a passkey, your device offers a list of providers. Common examples include the one built into your phone or operating system, a password manager, or a hardware security key.

Modern operating systems now let third-party apps register as providers, so that other apps and websites see them in the system’s native sign-in sheet. This is why the “who is my provider?” question has become a real choice instead of a default.

A good provider needs to get several things right:

Key protection. Private keys should be generated and kept in secure hardware wherever possible, and never leave it in readable form.
Strong user verification. Every use of a passkey should require a biometric or PIN check.
Safe syncing. If passkeys sync between devices, the data must be encrypted so that not even the provider can read it.
Recovery that does not undermine security. Getting back into your account after losing a device must not become a loophole.
Portability. You should be able to move to another provider without starting over. The FIDO Alliance is working on standards for exactly this kind of credential exchange.
Transparency. Users and organizations should be able to understand how it works.

8. What UIID as a passkey provider could mean

Marc Herdina’s confirmation, and the joint work with DEV.UNITY, point toward this role. The following describes the direction and the design goals. It is not a feature list with delivery dates.

Why UIID is well positioned

It already creates keys locally and secures them with device biometrics and WebAuthn. Passkey support extends a foundation that exists.
Its Core ID and Alias model matches how passkeys should be used. One anchor identity, with a separate context for each service.
It is built to be independent of one platform’s ecosystem. That addresses the lock-in concern directly.
It already covers more than people. UIID’s entity types include AI agents, devices and organizations. As more software acts on behalf of users, passkey-grade, verifiable identity for those actors becomes more useful.

What this could look like for different groups

For everyday users

Sign in to websites and apps with a passkey held in UIID, unlocked with your fingerprint or face.
One place to see and manage your passkeys, tied to your own identity rather than a vendor account.
No password to type, remember or leak.

For developers

Standard WebAuthn means no special UIID-only code is required to accept a UIID-held passkey.
UIID’s own sign-in can offer passkeys next to its existing options, and the UIID Cookbook already shows the developer path for the UIID API.

For organizations

Phishing-resistant sign-in for employees and customers.
Better fit for environments that want a single, controllable identity layer.
A clearer story for compliance, because no shared secrets are stored.

Design goals for a secure UIID passkey provider

Goal	What it means in practice
Hardware-backed keys	Private keys are created and kept in the device’s secure hardware wherever it is available.
Verification on every use	A biometric or PIN is required each time a passkey signs in.
Local-first	Keys are generated on your device, in line with UIID’s existing local-first approach.
End-to-end encrypted sync	If passkeys move between devices, the data is encrypted so the service cannot read it.
Safe recovery	Recovery paths must be as strong as the passkeys they protect.
Portability	Users can move their passkeys elsewhere and are never trapped.
Alias-aware	Passkeys can be organized by UIID alias, so each context stays separate.

How it connects to UIID WRAP

UIID WRAP already helps users on websites that do not support UIID, by generating isolated aliases and preparing data-minimized credentials while the user reviews everything before submitting. Passkeys fit this naturally. Where a website offers passkey registration, a future flow could create a passkey for that site instead of a password, so the same privacy-preserving idea works with the strongest sign-in method available.

Why partner with DEV.UNITY

Becoming a trustworthy provider is a security engineering effort, not only a product decision. Handling key storage, platform integration across operating systems, and recovery design takes focused work. LINKSPREED and its sister company DEV.UNITY are tackling it together, with the shared aim that UIID becomes a passkey provider people and organizations can rely on.

9. What happens next

LINKSPREED’s announcement establishes the direction: UIID supports passkeys, and UIID is being developed into a secure passkey provider. The work with DEV.UNITY is ongoing. No release date is attached to this announcement. Further details will come through LINKSPREED’s channels as the work progresses.

If you want to follow along:

Watch LINKSPREED’s own Web4 social network and Marc Herdina’s posts on X for updates.
Get a free UIID Core ID at uiid.me and try the existing passwordless flow.
Developers can explore the UIID Cookbook on LINKSPREED’s GitHub.

10. FAQ

Is a passkey the same as a password?

No. A password is a secret you type and share with the website. A passkey is a key pair. The private half never leaves your device, and the website holds only the public half.

What happens if I lose my phone?

It depends on whether your passkeys are synced or device-bound, and on your provider’s recovery design. This is why recovery is a core design goal for any serious provider.

Are passkeys safe against phishing?

Yes, in a very practical sense. The browser binds each passkey to the correct domain, so a lookalike site cannot use it.

Do websites see my fingerprint or face?

No. Biometrics are used locally to unlock the key. The website only learns that the check succeeded.

Do I have to give up passwords everywhere?

Not on day one. Most services will offer both for a while. Passkeys are designed to coexist with passwords during the transition.

Is UIID a passkey provider today?

UIID is moving in that direction. The confirmed news is that UIID will support passkeys and that LINKSPREED is working with DEV.UNITY to make UIID a secure passkey provider.

What is the difference between UIID and a normal password manager?

A password manager stores secrets for you. UIID is an identity layer: one Core ID, separate aliases per context, local-first keys, and support for people, agents, devices and organizations. Passkey support adds a standard way to sign in on top of that.

Final thought

Passwords were built for a smaller, safer internet. Passkeys are the first serious replacement that is also easier to use. The question that remains is who holds your passkeys. For many people the answer will be a big platform. LINKSPREED and DEV.UNITY want UIID to offer another answer: a secure, local-first home for your passkeys, tied to an identity that you own.

About LINKSPREED. LINKSPREED is building Web4, a community-based internet in which users and businesses own their data and control their digital identity. Its products include Web4 social networks as a service and UIID, its identity system.