Requiring Passkeys

Why It Matters

Passwords and authenticator codes can both be handed to a convincing fake login page. Passkeys cannot: the browser binds them to Kit’s domain, so the credential is never offered to an attacker’s site at all. Requiring one across your account closes the single largest hole in most teams’ security — the member who reuses a password, or types a code into the wrong window.

Turn it on at Settings → Security. The page needs the manage security permission, which both the Admin and Security Analyst roles hold — see Team Roles.

What the Policy Actually Does

Requiring passkeys doesn’t change how you sign in to Kit. It changes what your session can open: this account stays closed until the session you’re using was verified with a passkey. Your other accounts are unaffected.

That distinction is deliberate. A Kit user can belong to many accounts, and passkeys belong to the person, not the workspace. A sign-in mandate would let your account dictate how someone signs in to a client’s workspace or their own personal one. An access gate doesn’t: members sign in however they like and are stopped at your door until they prove a passkey.

It also means losing a passkey costs a member one account, not their Kit identity. They still sign in, still reach their profile, still work in every other workspace.

Before You Turn It On

You must hold a passkey yourself. The Require passkeys button does nothing until you do — Kit answers “Enroll a passkey on your own account first — nobody is exempt from this requirement, you included.”

There is no owner exemption from the gate, ever. Kit’s SSO enforcement exempts the owner because an identity provider can break server-side and strand everyone; a passkey cannot fail that way. An exempt owner would simply be the account’s weakest credential — the one worth phishing.

Add yours at Account Settings → Passkeys first, then come back. The Security page warns you until you do.

Turning It On

The Security page carries a live compliance table for every member:

Status	Meaning
Passkey enrolled	Holds at least one passkey. Nothing is asked of them.
No passkey	Will be blocked at the door until they enroll.
Governed by SSO	Exempt — see below. Nothing is asked of them either.

Click Require passkeys. The confirmation names the cost in plain numbers — “Require passkeys? 4 members cannot open this account until they enroll one.” — so nobody enables this without knowing who it stops. If everyone already holds one, it says so.

Who Is Exempt

Exactly one group: members who sign in through SAML SSO on a connection where you’ve turned on “Require SSO”. For those people Kit already refuses every credential but your identity provider’s, so the mandate has nothing left to add.

Nothing else is exempt:

Not exempt	Why
Owners and admins	No role exemption exists. The person with the most access proves the most.
SSO without “Require SSO”	If passwords still work for that domain, the delegation isn’t real. Only enforcement counts.
Sign in with Google or GitHub	You control neither that provider nor the MFA on it, and Kit’s OAuth signup leaves a usable password behind.
Google One Tap	Same reasoning — consumer OAuth, not your identity provider.
Two-factor codes	Phishable. A code is not a passkey.
Trusted browsers	Trusting a browser skips a two-factor prompt. It proves nothing about passkeys.

Exemption is evaluated live, not frozen at sign-in. Relax SSO enforcement and previously exempt members become subject to the passkey requirement on their next request.

What Happens Immediately

The requirement applies from the moment you save it. There is no grace period and no staged rollout — a member who is mid-session hits the gate on their next page load.

Effect	Detail
Blocked members	See a page headed ”[Account] requires a passkey”, with inline enrollment, a Switch account link, and a return to wherever they were going.
Membership	Untouched. Nobody is removed, and no seat, role, or invitation changes.
Other accounts	Untouched. The block applies to this account only.
New joiners	Your invitation email gains a line telling them a passkey is needed, so they learn before they arrive rather than at the door.

Only members who must act are emailed. They get “Add a passkey to keep using [Account]” — what changed, who changed it, that one passkey is enough and their existing device unlock will do, and a direct link to enrollment. Members who already hold a passkey and members who are SSO-exempt get nothing, because nothing is being asked of them.

You get a separate receipt with the counts: how many were emailed, how many already had a passkey, how many are governed by your identity provider.

API Tokens and AI Assistants

Nothing was revoked. An API token or AI-assistant connection acts on your behalf but cannot present a passkey, so Kit asks a simpler question of it: does the person who created it have a passkey enrolled?

While the answer is no, that member’s API tokens answer 403 and their MCP connections are refused. The moment they enroll, both resume on the same credentials — no token re-issued, no assistant re-authorized, no data touched.

When Someone Loses Every Passkey

Their devices are gone, so they can no longer confirm a passkey — which also means they can’t enroll a replacement on their own, since changing passkeys requires one. Issue them a re-enrollment pass from their row in the compliance table.

You never see the pass. Kit mails it directly to that member, in their language; it appears in no screen, no flash message, and no log, so it cannot be forwarded, screenshotted, or read over your shoulder. Your confirmation says only that a pass was issued. The issuance itself is recorded in the audit trail, naming who issued one to whom.

What the member does with it:

They do	What it costs them
Open the emailed link	Nothing — it only shows a confirmation page. A link scanner or mail preview that fetches the URL can’t burn the pass.
Confirm on that page	The pass is spent, and a 15-minute window opens in which Kit offers enrollment instead of demanding the passkey they can’t produce.
Enroll a new passkey	The window closes and they’re through.

The pass is good for one use within 24 hours, and issuing a new one immediately cancels any outstanding pass for that member. Expired, spent, superseded, or opened by the wrong person all show the same neutral page, which never says which — so a member who reports the link “no longer good” simply needs a fresh one.

Turning It Off

Click Stop requiring passkeys. Members without one can open the account again on their next request, refused API tokens and MCP connections start working immediately, and passkeys members already enrolled simply stay where they are. Nothing needs re-issuing in either direction.

Quick Checklist

• Enroll a passkey on your own account first — the button won’t work until you do
• Review the compliance table and note who shows No passkey
• Confirm your SSO connection actually has Require SSO on if you’re counting on the exemption
• Turn it on and read the count in the confirmation before accepting
• Expect blocked members to enroll inline within minutes — they were emailed a direct link
• Verify anyone requesting a re-enrollment pass by phone, never by email alone
• Remember that API tokens and MCP connections resume by themselves once their owner enrolls

See Also

• Passkeys
• Sign-in Security
• SSO & Directory Provisioning
• Team Roles
• Connecting AI Assistants