Passkeys

Why It Matters

A passkey is the unlock you already use — your face, your fingerprint, your device PIN — standing in for a password. There is nothing to install and nothing new to memorize. Unlike a password or a six-digit code, a passkey cannot be typed into a convincing fake: it is bound to Kit’s domain by the browser, so a phishing page that looks identical simply never receives it.

Some accounts go further and require every member to hold one. This page covers adding a passkey, what the requirement means for you, and what to do when something goes wrong.

Adding a Passkey

Open Account Settings → Passkeys and click Add passkey. Give it a name you’ll recognize later (“MacBook Touch ID”, “iPhone”), then confirm with your device when it prompts. That’s the whole setup.

Anything your device offers as a passkey works:

What you have	How it’s used
Mac, iPhone, or iPad	Touch ID or Face ID
Windows PC	Windows Hello — face, fingerprint, or PIN
Android phone	Your screen lock
Hardware security key	A YubiKey or similar, tapped when prompted
Your phone, from a computer	Scan the QR code the browser shows and confirm on the phone

One passkey is enough. A second one is worth the thirty seconds it takes: if the first device is lost, stolen, or wiped, the second one keeps you moving without asking anyone for help.

Synced Passkeys Count

Passkeys stored in iCloud Keychain or Google Password Manager sync across your devices, and Kit accepts them exactly like any other. Set one up on your laptop and your phone already has it.

They are still bound to Kit’s domain and still unphishable — what they are not is bound to a single piece of hardware. That’s a deliberate trade. Device-bound-only keys are marginally stronger and dramatically harder to live with, and lockouts are what stop teams adopting passkeys at all.

When an Account Requires a Passkey

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.

So you sign in however you normally do. If you then open an account that requires a passkey and this browser hasn’t proved one, Kit stops you at a page headed ”[Account] requires a passkey”, which offers exactly two ways forward:

• Set up a passkey — if you hold none yet. You enroll right there, inline.
• Use your passkey — if you already hold one. Confirm it, and this browser is verified.

Either way, Kit returns you to the page you were heading for. There is also a Switch account link, because your other workspaces stay open the whole time.

The requirement takes effect the moment an owner turns it on — there is no grace period and no countdown. Nobody is removed from the account, and no seat, role, or invitation changes. If the requirement applies to you, you’ll usually have an email about it first: “Add a passkey to keep using [Account]”.

Adding and Removing Passkeys Later

Your first passkey can be added from any session you’re already signed in to. After that, adding or removing one requires confirming with a passkey you already have.

Your situation	What unlocks passkey management
No passkeys yet	Any session you’re signed in to — the bootstrap
One or more passkeys	A passkey confirmation, every time

The second rung is the point of the whole feature. Without it, someone who stole your password could simply enroll a passkey of their own and walk through the gate — the requirement would add a step for them instead of a wall. Once you hold a passkey, your password no longer opens that page, and neither does signing in through Google or GitHub.

If You Lose Every Passkey

Losing your only device is inconvenient, not catastrophic. You can still sign in, still reach your profile and settings, and still use every other workspace you belong to. Only the account that requires a passkey stays shut.

Ask an owner or admin of that account for a re-enrollment pass. Expect them to check it’s really you by phone or in person first — that verification is the whole point of the pass. They issue it from their end and never see the link themselves: Kit emails it straight to you, in your language, subject “Your pass to set up a new passkey for [Account]”.

Open it while signed in to Kit as yourself. Then:

Step	What happens
Open the link	You get a confirmation page. Nothing is spent yet — a mail scanner, link preview, or security appliance that fetches the URL cannot burn your pass.
Click “Use this pass”	This is the commitment. The pass is spent, and a 15-minute window opens.
Set up your new passkey	Inside that window Kit offers enrollment instead of asking for the passkey you can no longer produce. Enrolling closes the window and lets you in.

A pass works once, expires 24 hours after it was issued, and only works for the person it was issued to. The moment an owner issues you a new one, any earlier pass stops working — so always use the most recent email. If the 15 minutes run out before you finish enrolling, ask for another pass.

You Can’t Delete Your Last Passkey

While any account you belong to requires one, Kit refuses to delete your final passkey:

This is your last passkey, and one of your workspaces requires every member to have one. Add another passkey first, or ask that workspace’s owner to lift the requirement.

This isn’t bureaucracy — deleting it would lock you out of that account in a way only its owner can undo. Add a replacement first, then remove the old one.

Sign-in Methods That Don’t Satisfy It

A passkey requirement asks for a passkey specifically. These get you into Kit, but not into a requiring account:

Method	Why it isn’t enough
Password + authenticator code	Both can be phished or replayed; neither is a passkey.
Sign in with Google or GitHub	Convenient, but the account’s owner controls neither that provider nor the security you have on it.
Google One Tap	Same as above — it’s still consumer OAuth.
A trusted browser	Trusting a browser skips your two-factor code. It has nothing to say about passkeys.
A remembered session	Resuming from a remember-me cookie is not a fresh proof of anything.

In every case the fix is the same and takes seconds: confirm your passkey on the block page. See Sign-in Security for how trusted browsers and sign-in alerts work.

“My API Token or AI Assistant Returns 403”

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?

Until you enroll one, requests from your tokens and your MCP connections to that account are refused — the API answers 403, and your assistant reports an authorization error. The moment you add a passkey at Account Settings → Passkeys, they start working again on the very next call. Your token is still valid, your assistant is still connected, and there is nothing to re-issue or re-authorize.

Quick Checklist

• Add a passkey at Account Settings → Passkeys — use the unlock your device already has
• Add a second one, on a different device, so a lost phone is an inconvenience rather than a support ticket
• Remember that changing your passkeys later needs a passkey, not your password
• If an account blocks you, confirm your passkey on the block page — your other workspaces stay open
• Lost every passkey? Ask that account’s owner for a re-enrollment pass
• Getting a 403 from an API token or AI assistant? Enroll a passkey — nothing was revoked

See Also

• Requiring Passkeys
• Sign-in Security
• SSO & Directory Provisioning
• Connecting AI Assistants
• API Reference