Don't use passkeys for encrypting user data

Passkeys are the most exciting authentication development in years. They eliminate phishing, remove the burden of passwords, and deliver a seamless login experience backed by public-key cryptography. But a dangerous misconception is spreading through developer communities: if passkeys are cryptographic, surely they can encrypt user data too. They cannot — and attempting to use them that way will create brittle, unreliable systems that could lock your users out of their own information permanently. Understanding why requires a clear look at what passkeys actually are, what encryption demands, and where the two diverge in ways that matter enormously for any platform handling sensitive business data.

Authentication and Encryption Are Fundamentally Different Jobs

Authentication answers one question: "Are you who you claim to be?" Encryption answers a completely different one: "Can this data remain unreadable to everyone except authorized parties?" These two problems share cryptographic primitives, but the engineering requirements diverge sharply. Authentication needs to happen once per session, can tolerate occasional failure with graceful fallbacks, and doesn't need to produce the same output every time. Encryption demands deterministic, reproducible key access over the entire lifetime of the data — which could be years or decades.

When you authenticate with a passkey, your device generates a cryptographic signature proving you hold the private key associated with your account. The server verifies this signature and grants access. At no point does the server — or even your application — gain access to the private key material itself. This is a feature, not a limitation. The entire security model of passkeys depends on the private key never leaving the secure enclave of your device. But encryption requires that you use a key to transform data, and later use that same key (or its counterpart) to reverse the transformation. If you cannot reliably access the key, you cannot reliably decrypt.

Platforms like Mewayz that manage sensitive business information — invoices, payroll records, CRM contacts, HR documents across 207 modules — need encryption strategies built on keys that are durable, recoverable, and consistently accessible. Building that on a foundation designed specifically to prevent key access is an architectural contradiction.

Why Passkeys Resist Being Used as Encryption Keys

The WebAuthn specification, which underpins passkeys, was deliberately designed with constraints that make encryption use impractical. Understanding these constraints reveals why this isn't a gap that clever engineering can bridge — it's a fundamental design boundary.

• No key export: Private keys generated during passkey registration are stored in hardware-backed secure enclaves (TPM, Secure Enclave, or equivalent). The operating system and browser APIs provide no mechanism to extract raw key material. You can ask the key to sign something, but you cannot read the key itself.
• Non-deterministic key generation: Creating a passkey for the same user on a different device produces a completely different key pair. There is no seed phrase, no derivation path, no way to reconstruct the same key on another device. Each registration is cryptographically independent.
• Device-bound availability: Even with passkey syncing (iCloud Keychain, Google Password Manager), availability depends on ecosystem participation. A user who registers on an iPhone and later switches to Android may lose access. A user whose device is lost, stolen, or factory-reset faces the same problem.
• Challenge-response only: The WebAuthn API exposes navigator.credentials.get() which returns a signed assertion, not raw key material. You receive a signature over a server-provided challenge — useful for proving identity, useless for deriving an encryption key.
• No algorithm flexibility: Passkeys typically use ECDSA with the P-256 curve. Even if you could access the key, ECDSA is a signing algorithm, not an encryption algorithm. You'd need additional transformations (ECDH key agreement, KDF derivation) that the API doesn't support in this context.

Some developers have proposed workarounds — using the PRF (Pseudo-Random Function) extension to WebAuthn, for instance, to derive symmetric keys during authentication. While this extension exists in the spec, browser support remains inconsistent, it's unavailable on many mobile platforms, and it still inherits the device-binding problem. A key derived via PRF on one device cannot be reproduced on another device with a different passkey, even for the same user account.

The Data Loss Scenario No One Wants to Ship

Consider what happens when you encrypt a user's data with a key derived from their passkey. Everything works beautifully on day one. The user logs in, the key is derived, data is encrypted and decrypted seamlessly. Then three months later, their phone falls into a lake.

With traditional authentication, losing a device is an inconvenience. The user recovers their account via email, sets up new credentials, and continues working. But if their data was encrypted with a key bound to the now-submerged device's secure enclave, that data is gone. Not "hard to recover" gone — cryptographically irreversible gone. No customer support ticket, no account recovery flow, no executive escalation can reverse the math. The data might as well have been deleted.

The cardinal rule of encryption system design: if your key management strategy has any single point of failure that permanently destroys access to user data, you have not built a security feature — you have built a data loss mechanism with extra steps.

For a business running operations through a platform — managing 50 client relationships in a CRM, processing monthly payroll for 30 employees, tracking a fleet of vehicles — permanent data loss from a dropped phone isn't a minor UX issue. It's a business continuity catastrophe. This is precisely why Mewayz's architecture separates authentication mechanisms from data protection layers, ensuring that no single device failure can compromise access to critical business information across any of its integrated modules.

What You Should Use Instead

The good news is that well-established patterns exist for encrypting user data without falling into the passkey trap. These approaches are battle-tested, widely supported, and designed specifically for the encryption use case.

Server-side encryption with managed keys remains the most practical choice for the vast majority of applications. Your platform encrypts data at rest using keys managed through a proper Key Management Service (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault, or equivalent. The user authenticates (with passkeys, if you like!) and the server handles encryption and decryption transparently. This is how most SaaS platforms protect data, and it works because the keys are durable, backed up, rotatable, and independent of any user's device.

Password-derived encryption keys (using Argon2id or scrypt for key derivation) are appropriate when you need true zero-knowledge encryption where even the server cannot read user data. The trade-off is that losing the password means losing the data, but passwords can be memorized, written down, and stored in password managers — they aren't locked inside a hardware enclave. Services like 1Password and Standard Notes use this approach effectively.

1. Use passkeys (or any strong method) for authentication — verifying the user's identity.
2. After authentication, derive or retrieve encryption keys through a separate, purpose-built key management system.
3. Implement key escrow or recovery mechanisms — recovery keys, multi-device key sync, or organizational key custody for business accounts.
4. Encrypt data at rest and in transit using AES-256-GCM or XChaCha20-Poly1305 with keys from your KMS.
5. Rotate keys periodically and maintain encrypted key backups that survive any single point of failure.

This separation of concerns isn't just a best practice — it's the only architecture that lets you upgrade authentication methods independently of your encryption strategy. When passkeys eventually evolve or get replaced by something better, your encrypted data remains perfectly accessible.

The PRF Extension: Promise and Pitfalls

Developers following the WebAuthn specification closely may point to the prf extension as a potential bridge between passkeys and encryption. This extension allows a relying party to request a pseudo-random value derived from the passkey's secret material during an authentication ceremony. In theory, this value could serve as an encryption key or seed.

In practice, the PRF extension faces significant adoption barriers. As of early 2026, support varies dramatically across browsers and platforms. Safari's implementation differs from Chrome's. Many Android devices don't support it at all. Hardware security keys have inconsistent support. For any platform serving a diverse user base — and Mewayz serves 138,000+ users across every major operating system and device type — building encryption on a feature with patchy availability is operationally untenable.

More fundamentally, PRF doesn't solve the multi-device problem. The pseudo-random output is derived from the specific passkey on the specific device. A user who registers passkeys on both their laptop and phone gets two different PRF outputs for the same account. You'd need to encrypt data with one device's derived key and then somehow re-encrypt or share that key with the other device — which brings you right back to building a proper key management system anyway. At that point, the passkey-derived key adds complexity without adding security.

Lessons for Builders: Use the Right Tool for the Right Layer

The temptation to use passkeys for encryption comes from a good instinct — developers want to leverage strong cryptography and reduce the number of secrets users need to manage. But security engineering is fundamentally about using the right primitive at the right layer. A lock and a safe both protect valuables, but you wouldn't install a deadbolt inside a vault or try to carry a safe in your pocket.

Passkeys excel at their designed purpose. They've reduced phishing-related account takeovers by up to 99.9% in Google's internal deployment. They eliminate credential stuffing attacks entirely. They provide a login experience that's simultaneously more secure and more convenient than passwords. That's a remarkable achievement, and it's enough. Asking passkeys to also solve encryption is like asking your firewall to also serve as your backup system — it misunderstands the architecture.

When building platforms that handle sensitive business operations, the architecture should reflect clear boundaries. Authentication verifies identity. Authorization determines access. Encryption protects data at rest and in transit. Key management ensures encryption keys survive device loss, employee turnover, and infrastructure changes. Each layer has purpose-built tools, and mixing them creates fragility that surfaces at the worst possible moments — when a user most needs to access their data and cannot.

Getting Security Right Without Overcomplicating It

For most SaaS applications and business platforms, the practical recommendation is straightforward: adopt passkeys enthusiastically for authentication, and handle encryption entirely server-side with a managed KMS. This gives your users the best login experience available today while protecting their data with infrastructure designed specifically for durability and recovery.

If your threat model genuinely requires end-to-end encryption where the server cannot access plaintext data, invest in a proper client-side encryption architecture with password-derived keys, recovery codes, and organizational key escrow — not passkey-derived shortcuts. The engineering investment is larger, but the alternative is shipping a system that will eventually destroy someone's data irrecoverably.

Security decisions compound over time. A shortcut taken today becomes a migration nightmare in three years when the underlying primitive changes, a device ecosystem shifts its syncing policy, or a browser deprecates an extension. Building on the right abstractions from the start — authentication as authentication, encryption as encryption, each with its own key lifecycle — is the foundation that lets platforms scale to hundreds of thousands of users without a ticking time bomb buried in the cryptographic plumbing.

Frequently Asked Questions

Why can't passkeys be used to encrypt user data?

Passkeys are designed exclusively for authentication, not encryption. They rely on public-key cryptography to verify your identity during login, but the private key never leaves your device and isn't accessible to applications. Encryption requires stable, reproducible keys that can consistently decrypt data over time. Passkeys lack this capability by design, making them fundamentally unsuitable for protecting stored user information.

What happens if you try to encrypt data with passkeys anyway?

You risk building a brittle system where users get permanently locked out of their own data. Passkeys can be revoked, rotated, or replaced across devices without warning. If encrypted data is tied to a specific passkey that gets deleted or updated, there is no recovery path. This creates a catastrophic data-loss scenario that no amount of engineering workaround can reliably prevent.

What should developers use instead of passkeys for data encryption?

Developers should use purpose-built encryption solutions such as AES-256 with proper key management, envelope encryption, or established libraries like libsodium. Keep authentication and encryption as separate concerns. Use passkeys for what they excel at — passwordless login — and dedicated encryption keys managed through secure key derivation and storage systems for protecting sensitive user data.

How does Mewayz handle authentication and data security for businesses?

Mewayz provides a 207-module business OS starting at $19/mo that separates authentication from data protection using industry best practices. Rather than misusing passkeys, the platform at app.mewayz.com implements proper encryption layers alongside secure login flows, ensuring businesses can protect customer data reliably without risking the lockout scenarios that come from conflating authentication with encryption.