Everyone says passkeys are the future. No passwords to leak. No brute-force attacks. No “password123” disasters. For EmDash CMS, Cloudflare’s new WordPress successor, passkeys are the default authentication method — and the tech press has mostly cheered.
But here’s what the praise gets wrong. For a CMS, passkeys introduce problems that passwords actually solved. And for the people who run WordPress sites for a living, those problems are deal-breakers.
Passkeys are not wrong. They're the right direction for authentication. But for a CMS designed to replace WordPress — a platform built around multi-site, multi-user, multi-device workflows — making passkeys the only path is premature.
What EmDash Actually Does With Passkeys
EmDash uses WebAuthn passkey authentication out of the box. When you install the CMS, the setup wizard asks for your email and then prompts you to create a passkey — either stored on your device (phone, laptop, security key) or in a cloud password manager like 1Password or Bitwarden.
No password field. No “create a strong password” prompt. Just biometrics or a PIN tied to a cryptographic key pair.
The architecture is sound. Your private key never leaves your device. The server stores only the public key. A compromised database leak gets attackers nothing useful — they’d need your biometric or your device to authenticate.
In theory, this eliminates phishing, credential stuffing, and password reuse attacks. That’s real.
But theory meets practice when you’re not running a single blog on a single device.
The Multi-Site Nightmare
The most common WordPress workflow that EmDash targets isn’t a hobbyist with one site. It’s an agency running 50 to 100 client installations. One reviewer from the source material put it bluntly:
“I hope this pass key isn’t bound to just this one installation. I’m going to run multiple sites on localhost. I need these pass keys to work.”
blockquoteblockquoteblockquote
That’s the problem. Passkeys are bound to the origin (the site’s domain). Each EmDash installation — whether on localhost, staging, or production — requires a separate passkey registration. For an agency managing dozens of client sites, that means dozens of passkey enrollments, each tied to a specific URL.
Compare this to a master password. One credential, memorized, works across every WordPress admin panel you manage. Yes, it’s less secure. But it’s dramatically more practical for people who touch multiple CMS instances daily.
EmDash offers a magic link fallback for authentication. But one tester reported that the magic link returned a “page not found” error. The passkey-first design assumes a single-site workflow. That assumption doesn’t match how WordPress is actually used.
Device Dependency Masquerading as Security
Passkeys tie authentication to a specific device or password manager. Lose your phone? Lose your laptop? Your passkey goes with it.
The recovery story is weak. EmDash lets administrators invite other users and assign roles. But if you’re the sole admin and your device dies before you set up a second passkey, you’re locked out of your own CMS. There’s no “forgot your passkey?” flow because that would defeat the purpose.
WordPress solves this with the “lost password” email flow. It’s not bulletproof, but it’s a known path. For EmDash, the recovery path requires either a second enrolled device or the magic link — which, as noted, has bugs in the beta.
This isn’t a theoretical edge case. Small publishers and freelancers — the exact audience EmDash claims to target — often run their sites alone. One device, one admin. If that device fails, the site becomes unmanageable until the recovery process works. And in a beta where authentication itself has reported bugs, that’s a real risk.
The Linux Gap
One reviewer testing the EmDash beta on Linux reported that passkey authentication didn’t work at all. The magic link fallback returned an error. They were stuck.
Passkeys rely on platform support — the WebAuthn API, the operating system’s credential management, and browser integration. Linux desktop environments have inconsistent support. Some distributions handle it fine; others don’t. For a CMS that positions itself as open-source and developer-friendly, failing on a developer’s primary OS is a gap the marketing doesn’t mention.
WordPress needs a LAMP stack — PHP and MySQL — which runs everywhere. EmDash needs a specific authentication ecosystem that doesn’t.
When Passkeys Actually Make Sense for a CMS
EmDash’s passkey-first design is excellent for single-site owners who work from one device. If you run one blog, publish from your laptop, and manage everything from that machine, passkeys are strictly better than passwords. No remembering credentials, no password manager needed, no phishing risk.
For enterprise deployments with hardware security keys (YubiKey, etc.), passkeys are also a net win. Centralized identity management with WebAuthn is stronger than shared admin passwords.
But the middle ground — agencies, freelancers with multiple clients, developers managing staging and production environments — is where the model breaks. And that middle ground is the majority of the WordPress economy.
What EmDash Should Do
The article’s source material shows EmDash has user roles — administrators, editors, authors, contributors. That’s standard. What’s missing is a practical multi-device passkey workflow that matches how CMS users actually operate.
Cloudflare could add per-site credential portability — a way to export and import passkey registrations between installations. They could improve the magic link fallback to be reliable enough to serve as a primary recovery path. Or they could offer a traditional password option alongside passkeys, letting users choose based on their workflow.
The second option matters most. EmDash’s security pitch is that plugins can’t access your database. That’s the architectural innovation. The authentication layer doesn’t need to be the most secure possible — it needs to be secure enough that the plugin sandbox carries the weight. A well-configured password with 2FA is still far better than what most WordPress sites have. Passkeys on top of that would be a choice, not a mandate.
The Real Takeaway
Passkeys are not wrong. They’re the right direction for authentication. But for a CMS designed to replace WordPress — a platform built around multi-site, multi-user, multi-device workflows — making passkeys the only path is premature.
The common advice says “passkeys are better than passwords” as if it’s a universal truth. For EmDash, the truth is more specific: passkeys are better for the subset of users who manage one site from one device. For everyone else, they add friction without proportional security gain.
EmDash has a real innovation in plugin sandboxing. That’s the feature that justifies its existence. The authentication model should support the workflows of the people who need that innovation — not force them into a single-device paradigm that doesn’t fit how they work.
- What authentication method does EmDash CMS use by default?EmDash CMS uses WebAuthn passkey authentication out of the box, with no password field during setup.
- Why are passkeys problematic for multi-site agencies?Passkeys are bound to the site's domain, so each EmDash installation requires a separate passkey registration, which is impractical for agencies managing dozens of client sites.
- What happens if you lose your device with a passkey?If you lose your device and haven't set up a second passkey, you can be locked out of your own CMS, as the recovery story is weak.
