Product
Passwordless from day one: how passkeys work on cmdz
No password, no username, no emailed code, no authenticator app. What that means in practice, what happens when you lose a device, and why we will not add a fallback.
There is no password field anywhere on this platform. Not hidden behind "advanced", not as a fallback, not on request.
That decision has consequences, some of which are inconvenient, and this post is about all of them.
What logging in looks like
You click "log in". Your browser asks your device to prove it holds the key. You touch a fingerprint sensor, look at a camera, or type your device PIN. You are in.
No username. No email address. No password to remember, rotate or reuse. No six-digit code arriving in an SMS that a SIM swap can intercept. No authenticator app with a QR code you photographed once and never thought about again.
Why this is meaningfully more secure, not just more convenient
Passkeys are public-key credentials bound to an origin. Three properties follow from that, and they are the whole argument.
Phishing stops working. A passkey registered for app.cmdz.com will not present itself to app-cmdz.com, no matter how convincing the email was or how carefully the page was cloned. The browser makes that decision, not the person, and the browser is not tired at eleven at night.
There is nothing on our side worth stealing. We store a public key. A breach of our database yields public keys, which are public. Compare that with any password database, where the value of the breach is proportional to how bad your users' password reuse is.
There is nothing to reuse. The credential is unique per site by construction. Your cmdz passkey cannot be replayed anywhere, because it does not exist anywhere else.
The part that is genuinely a trade-off
If you have exactly one passkey and you lose the device holding it, you are locked out. That is real, and pretending otherwise would be the kind of thing this blog is supposed to avoid.
Three answers, in order of how much we recommend them.
Register a second passkey. This is the good answer. Most passkeys now sync through iCloud Keychain, Google Password Manager or 1Password, so "the device" is usually already "the account". Add a second one anyway — a hardware key in a drawer, or a second device — and the problem disappears.
Keep a recovery code. A signed, single-use code you store yourself, offline. Using it lets you register a new passkey. It is a bearer credential, so treat it like one.
For teams: another owner. An organisation with two owners has a recovery path that does not depend on either person's hardware. For anything with revenue attached, do this.
Why there is no password fallback
The obvious objection is: why not offer passwords for people who want them?
Because an account is only as secure as its weakest available method. A password fallback means the phishing attack works again — the attacker simply asks for the fallback. Every property listed above evaporates, and what remains is a passwordless login screen with a password behind it, which is worse than either option chosen honestly.
So no fallback, and no exception on request. If that is disqualifying for you, we would rather you know now.
Step-up confirmation
Some actions ask for your passkey again even though you are already logged in: changing payment details, deleting a project, transferring ownership, authorising an agent with a write profile.
That is not friction for its own sake. A session token can be stolen; a fresh passkey assertion requires the device and the person. Anything that moves money or destroys data is worth one more touch.
The admin interface goes further: an IP allowlist and a fresh passkey confirmation for anything that touches a customer account. Our own staff have a harder login than you do, which is the correct way round.
Two domains, one reason
The platform lives on cmdz.com. Customer applications live on cmdz.app — a different registrable domain, deliberately.
That boundary is doing real work. It is the WebAuthn relying-party boundary and the cookie-scope boundary at the same time, which means an application running on something.cmdz.app can never see a platform session cookie and can never be offered a platform passkey. Even if that application is hostile. Even if it was written by a model at three in the morning and nobody read it.
If those two things shared a domain, every customer app would be a potential credential-harvesting surface for the platform hosting it. Separating them costs us a second certificate and buys a category of attack that cannot happen.
For agents
An agent does not use a passkey — it uses an OAuth token you granted with a passkey, in your browser, at a moment you chose. It cannot bootstrap its own access, cannot register a passkey, and cannot manage members.
Which means the answer to "what can an agent do to my account" starts with "nothing you did not personally authorise with a fingerprint", and that is a good place for the answer to start.
Set your limit and start.
One click with a passkey, then you verify a payment method once to start your 14-day free trial (€ 10 of credit). After that it is prepaid pay-as-you-go — you only ever spend credit you have already bought, and no invoice ever arrives above the amount you set.