What passkeys got right

Passkeys replaced the password with a device-bound cryptographic key. The private key never leaves the device. Login is phishing-resistant because the key is bound to a specific domain origin and cannot be replayed elsewhere. That is a meaningful improvement over passwords, and the industry moved quickly to adopt it.

But solving the password problem is not the same as solving the identity problem. And the identity problem is where most breaches now begin.

The identity problem passkeys did not solve

Passkeys still require a username or email address to identify the user. That identifier is stored on the service provider's server. It is a phishing target, a social engineering entry point, and a data point that correlates a person's activity across every service they use. A breach that exposes usernames exposes identity — regardless of whether passwords were also taken.

Passkeys depend on vendor clouds for backup and recovery. iCloud Keychain, Google Password Manager, and Microsoft account sync all hold copies of passkey credentials. Any organization that does not want a third party holding copies of its authentication infrastructure has a problem passkeys cannot solve.

Passkeys are domain-bound: one passkey per domain, tied to a specific device ecosystem. A mixed-device fleet, a contractor workforce, or a kiosk environment all introduce compatibility gaps. The more complex the organization, the more visible these gaps become.

And passkeys are authentication only. They do not underpin encrypted vaults, document security, or digital signatures. Every additional security layer requires a separate infrastructure.

What WWPass solves

Passkeys solve the password problem. WWPass solves the identity problem too.

— No username in the system. WWPass generates a unique opaque identifier per user per service — a Protected User Identifier (PUID) — specific to that user's relationship with that service and useless anywhere else. There is no persistent identity to target, correlate, or steal. Social engineering has no username to start from.

— No vendor cloud dependency. Recovery happens through WWPass's distributed architecture. No iCloud, no Google, no third-party cloud holds a copy of the key. The organization controls its own authentication infrastructure.

— No device requirement. WWPass works on any device and browser. No secure enclave, no compatible operating system required. Hardware tokens, mobile app, any combination.

— One key, every service. Each passkey is domain-bound — one per site. The WWPass Key works across every WWPass-enabled service with unique per-service identifiers generated automatically.

Authentication is only the start. WWPass underpins encrypted vaults, document management, digital signatures, and zero-trust applications. Organizations buy a security architecture, not just a login replacement.

Explore WWPass PUID ∙ Protected user identifier

Side by side

A direct comparison across the dimensions that matter for any organization with real security requirements:

Who needs to go beyond passkeys

Any organization where a breach of user identity — not just user passwords — creates real damage. That is most organizations operating at enterprise scale today.

Username exposure is not a compliance-only problem. It is a business risk for any organization whose users can be targeted through their identity. Social engineering, account recovery attacks, and cross-service correlation all start with a username. Removing it removes the starting point.

Vendor cloud dependency is not a compliance-only problem. Any organization that prefers not to have Apple, Google, or Microsoft holding copies of its authentication credentials has a structural reason to go further.

For organizations under DORA, NIS2, or HIPAA, the compliance case is also direct:

• DORA: passkey cloud sync creates third-party ICT risk exposure under Article 23

• NIS2: essential entities must address the identity layer, not just the password layer

• HIPAA: no username should be tied to a patient record

Explore DORA and NIS2 Authentication Requirements

Explore WWPass for financial services & fintech and healthcare

Frequently asked questions

Q: Why go beyond passkeys if they are already phishing-resistant?

A: Passkeys are phishing-resistant for the password step. They are not phishing-resistant for the identity step. The username is still stored on the service side. Account recovery flows, social engineering attacks, and identity correlation across services all operate through the username — which passkeys leave in place. WWPass removes the username entirely. There is no identity to socially engineer, no account recovery flow to exploit, and no correlation possible across services.

Q: Do passkeys eliminate the need for a username?

A: No. Passkeys replace the password with a device-bound cryptographic key but still require a username or email address to identify the user on the service side. That identifier is stored on the service provider's server and remains a phishing target and social engineering entry point. WWPass generates a unique opaque identifier per user per service, removing the username entirely.

Q: Why does vendor cloud dependency matter beyond compliance?

A: When passkey recovery depends on iCloud Keychain or Google Password Manager, a third-party cloud provider holds a copy of authentication credentials. This is a concentration of trust that any organization — not just regulated ones — may prefer to avoid. WWPass recovery uses its own distributed architecture with no third-party cloud dependency. The organization controls its own authentication infrastructure.

Q: What is the difference between WWPass and FIDO2 passkeys architecturally?

A: Passkeys use FIDO2/WebAuthn with asymmetric key cryptography, where the private key stays on the device in a secure enclave and is bound to a specific domain origin. WWPass uses a different model: a cryptographic key that, combined with the service provider's identifier, opens an encrypted distributed data container. Neither the user's identifier nor the service provider's identifier alone is sufficient — both are required together. This generates a unique opaque identifier per user-service relationship rather than a domain-bound device key, and eliminates the username from the process entirely.

Q: Is WWPass only relevant for regulated industries?

A: No. The identity problems passkeys leave open — username exposure, vendor cloud dependency, domain-bound device requirements — affect any organization operating at enterprise scale. Regulated industries face compliance consequences for these gaps on top of the security risk, which makes the case more urgent. But the underlying security argument applies to any organization where a breach of user identity, not just user passwords, creates real damage.