fleetlessfleetlessdocs
Concepts/Sign-in and Two-Factor

🔐 Sign-in and Two-Factor

How a Fleetless user — your team, not an app’s own users — gets into the console and the central MCP endpoint. There is no password any more: a sign-in is an emailed code or a passkey, and an organisation can ask for a second factor on top.

Signing in

Give your email address and Fleetless mails a six-digit code, valid ten minutes; a resend is offered after sixty seconds. A wrong code tells you how many attempts are left; after five the code is spent and you ask for a new one, which also replaces any earlier code. Typing or pasting the code with spaces in it (123 456) still works — they are stripped before it is checked.

A passkey signs you in on its own, with no code at all. Sign in with a passkey starts a WebAuthn ceremony for a discoverable credential, with no email needed first. A passkey proves both who you are and that you hold the device (possession and verification together), so it stands in for the email code and any second factor in one step.

If you have added an authenticator app or a passkey (below), signing in by email code asks for it next: a six-digit authenticator code, a passkey, or — failing both — a recovery code. If your organisation requires a second factor and you have none set up yet, you set one up right there, before any session exists.

Server keys and robot bridges are not people and are never asked for any of this — they keep their own tokens.

Passkeys and the authenticator app

Two-factor for developers needs the Plus plan or above. Manage both from Settings › Profile › Security. You may add any number of passkeys and at most one authenticator app; either is enough to satisfy a second-factor check.

  • Add passkey starts the browser’s own WebAuthn prompt. Each passkey shows the name you gave it, when it was added and when it was last used; rename or remove any of them from its row menu.
  • Authenticator app shows Set up (or Replace… once one exists): a QR code and a plain-text key for an app that cannot scan it, then a six-digit code to confirm it works. Remove… takes it off your account.
  • The relying party is fleetless.dev, so one passkey works for both the portal and the console — nothing to register twice.

Recovery codes

Confirming an authenticator app hands you ten recovery codes, each good for one sign-in, shown once. Generate new codes… replaces all ten and voids whichever of the old ones you have not used; copy them or download the .txt before you leave the page; there is no second look. If you ever run out, an owner of your organisation can reset your two-factor from Settings › Team (below) and you set it up again.

Requiring two-factor for your organisation

An owner can ask every member for a second factor from Settings › General › Security: the Require two-factor authentication switch. Turning it on signs nobody out — a member without a passkey or authenticator sets one up at their very next sign-in, before that sign-in produces a session. The page shows how many of the organisation’s members have not set one up yet, with a link into Team.

Requiring it needs the Pro plan or above. Developers see the switch, read-only; only an owner may change it. See Plans and Limits.

Server keys and robot bridges are not affected. The requirement covers the console and the central MCP endpoint — the two places a person signs in — never a non-person credential.

While the policy is on, the last factor on an account cannot be removed: a member who tries is refused, the same way turning off two-factor for an app user whose app requires it is refused.

Resetting a member’s second factor

From Settings › Team, an owner can Reset two-factor… on any other member: it removes their passkeys and authenticator, voids their recovery codes, and ends every session they are signed into. They sign in again by email code, and — if the organisation requires two-factor — set a new factor up on the spot. An owner cannot reset their own second factor this way; that door is Profile, not Team.

Next

  • Create an App — the matching choice for your app’s own users: password, emailed code, or both, and whether a second factor is off, optional or required.
  • Manage Users and Roles — the two identity spaces, and how an app user’s own second factor shows up in the console.