Encryption vs Authentication: The Architecture Guardrails You Need After the Passkeys Critique
Somewhere a team is shipping a product that uses passkey credentials as data-encryption keys, and they are genuinely proud of the elegance. They will be less proud the first time a user switches phones and watches their data evaporate. The passkeys critique made this failure mode impossible to ignore — so here are the guardrails I would enforce in any architecture review before that elegant design reaches production.
Why Authentication and Encryption Must Stay Separate
"Authentication proves user identity. Encryption protects data confidentiality. These controls can interact, but they must not be the same key lifecycle."
When a team derives encryption keys directly from passkey credentials, losing the passkey means losing the data. This is not a theoretical risk — it is the default failure mode for normal user behavior: switching devices, resetting accounts, or changing authentication providers. Architecture reviews must reject designs that cannot handle these events without irreversible data loss.
Approved Patterns for User-Data Encryption
- Pattern A: Envelope Encryption
- Pattern B: Split-Key Derivation
- Pattern C: Hardware-Backed Keys
Use per-record or per-tenant Data Encryption Keys (DEKs), wrapped by a Key Encryption Key (KEK) in KMS/HSM.
The data path is: generate a DEK scoped to the object or tenant, encrypt plaintext with AEAD (AES-256-GCM or XChaCha20-Poly1305), wrap the DEK with a KEK in managed KMS/HSM, then store the ciphertext alongside the wrapped DEK and metadata (algorithm, version, AAD context).
| Benefit | Why |
|---|---|
| Clean key rotation | Rewrap DEKs without re-encrypting data |
| Scoped revocation | Revoke one tenant's keys without affecting others |
| Auditable key usage | KMS/HSM provides full audit trail |
When user-controlled secrecy is required, derive a user component from a high-entropy secret using memory-hard KDF (Argon2id), then combine with service-held key material in KMS.
| Requirement | Implementation |
|---|---|
| Explicit recovery path | Trusted recovery secret, escrow, or threshold recovery |
| Brute-force resistance | Argon2id parameters tied to current hardware baseline |
| Key-version metadata | Transparent re-encryption support |
Use platform authenticators/passkeys to gate access and authorize key operations, not to become sole raw encryption key material.
| Acceptable Use | Not Acceptable |
|---|---|
| Passkey-authenticated session obtains server authorization to unwrap DEK | Deriving irreversible data key directly from passkey credentials |
| WebAuthn signatures authorize cryptographic operations | Passkey as sole encryption key with no recovery path |
Architecture Review Decision Flow
Anti-Patterns Worth Blocking on Sight
| Anti-Pattern | Why It Fails |
|---|---|
Auth == Encryption key | Passkey/credential loss = permanent data loss |
No recovery story | "Data gone forever if credential lost" for mainstream products |
Client-only key custody by accident | No backup, no escrow, no explicit user warning |
Nonce misuse | AEAD nonce reuse or deterministic nonce without proven construction |
Homegrown crypto | Custom primitives, unaudited constructions |
Single global DEK | One compromise decrypts entire user population |
Soft-delete only | Keys remain active after deletion request |
Opaque key metadata | No key IDs, algorithm IDs, or version tags |
Silent downgrade | Fallback to weaker crypto without explicit control and alerting |
Control Mapping for Review Boards
| Category | Controls |
|---|---|
| Must-have | Envelope encryption, key hierarchy documented, recovery and rotation runbooks, cryptographic logging and alerting |
| Should-have | Per-tenant key segmentation, periodic key health attestations, break-glass with dual authorization |
| Blockers | Irreversible user-data loss from normal auth lifecycle, missing incident response for key compromise, no test evidence for restore/rotation/deletion flows |
Practical default baseline for most SaaS products
- WebAuthn/passkeys for phishing-resistant authentication
- KMS-backed envelope encryption for user data
- Argon2id-derived user secret only where business requirements need user-side secrecy
- Documented recovery with explicit user communication
This combination gives you strong authentication and durable encryption without tying your product's data survival to a single credential artifact.
Implications for Drupal and WordPress
Drupal and WordPress power a huge share of sites that store user data, PII, and sometimes regulated content. Contrib modules and plugins that add auth (e.g. SSO, passkeys, 2FA) or encryption (e.g. field-level encryption, backup encryption) must keep auth and encryption lifecycles separate: passkeys or OAuth tokens should gate access, not double as the only key for decrypting stored data. When evaluating or building modules/plugins that touch sensitive data, apply the same guardrails: reject designs where losing the auth credential means irreversible data loss, require a documented recovery path, and prefer envelope encryption with a KEK in managed KMS where possible. Hosting and platform teams (Pantheon, Acquia, WP Engine, etc.) that offer encryption-at-rest or key management should align with these patterns so that site builders and maintainers don't inherit anti-patterns.
Takeaways
- The passkeys critique dragged a common architecture mistake into the open: treating auth credentials as encryption keys. It happens more often than anyone wants to admit.
- Authentication and encryption need separate key lifecycles. Full stop, no negotiation.
- Every encryption design should prove — not promise — that recovery works, rotation works, and metadata versioning exists before it gets approved.
- The anti-pattern table above is the most useful thing in this post. Print it, paste it into your review template, and use it as a gate.
Looking for an Architect who doesn't just write code, but builds the AI systems that multiply your team's output? View my enterprise CMS case studies at victorjimenezdev.github.io or connect with me on LinkedIn.