Passkeys verpflichtend machen
Verlangen Sie von allen Mitgliedern einen Passkey, bevor sie Ihr Konto öffnen können, mit Ausnahmen, Hinweisen für Mitglieder und Wiederherstellung nach einem Verlust.
Warum das zählt
Passwörter und Authenticator-Codes lassen sich beide auf einer überzeugenden gefälschten Anmeldeseite preisgeben. Passkeys nicht: Der Browser bindet sie an die Domain von Kit und bietet das Zugangsmittel einer Angreifer-Website gar nicht erst an. Eine Passkey-Pflicht für Ihr gesamtes Konto begrenzt den Zugriff über Passwörter oder Codes, die per Phishing erbeutet wurden.
Aktivieren Sie sie unter Einstellungen → Sicherheit. Die Seite erfordert die Berechtigung Sicherheit verwalten, über die Administratoren und Security Analysts verfügen, siehe Teamrollen.
Was die Richtlinie tatsächlich bewirkt
Kit setzt die Pflicht als Zugangssperre für das Konto um, nicht als Anmeldepflicht. Dieser Unterschied ist wichtig.
Sie können mehreren Kit-Konten angehören, und Passkeys gehören zur Person, nicht zum Arbeitsbereich. Eine Anmeldepflicht ließe Ihr Konto bestimmen, wie sich jemand beim Arbeitsbereich eines Kunden oder bei einem privaten Konto anmeldet. Eine Zugangssperre tut das nicht: Mitglieder melden sich auf beliebige Weise an und werden erst an Ihrer Tür angehalten, bis sie einen Passkey nachweisen.
Verliert jemand einen Passkey, verliert die Person damit nur den Zugang zu einem Konto, nicht ihre Kit-Identität. Sie kann sich weiter anmelden, ihr Profil öffnen und in Konten ohne Passkey-Pflicht arbeiten.
Bevor Sie die Pflicht einschalten
Sie müssen selbst einen Passkey besitzen. Die Schaltfläche Passkeys verlangen bleibt wirkungslos, bis Sie einen hinterlegt haben. Kit antwortet: „Richten Sie zuerst in Ihrem eigenen Konto einen Passkey ein. Niemand ist von dieser Pflicht ausgenommen, auch Sie nicht.“
Für den Inhaber gibt es keine Ausnahme. Bei erzwungenem SSO bleibt der Inhaber ausgenommen, weil ein serverseitiger Ausfall des Identity Providers sonst alle aussperren könnte. Ein Passkey kann nicht auf diese Weise ausfallen. Ein ausgenommener Inhaber wäre das schwächste Zugangsmittel des Kontos und damit das lohnendste Phishing-Ziel.
Fügen Sie Ihren Passkey zuerst unter Kontoeinstellungen → Passkeys hinzu und kehren Sie danach zurück. Die Sicherheitsseite warnt Sie so lange.
Warning
Würden Sie die Pflicht ohne eigenen Passkey aktivieren, wären Sie schon bei der nächsten Anfrage aus Ihrem Konto ausgesperrt. Deshalb verhindert Kit das.
Die Pflicht einschalten
Die Sicherheitsseite enthält eine aktuelle Compliance-Tabelle für alle Mitglieder:
| Status | Bedeutung |
|---|---|
| Passkey eingerichtet | Die Person besitzt mindestens einen Passkey. Sie muss nichts tun. |
| Kein Passkey | Die Person wird am Zugang gehindert, bis sie einen Passkey einrichtet. |
| Durch SSO verwaltet | Ausgenommen, siehe unten. Auch diese Person muss nichts tun. |
Klicken Sie auf Passkeys verlangen. Die Bestätigung nennt die Auswirkung in klaren Zahlen, etwa: „Passkeys verlangen? 4 Mitglieder können dieses Konto erst wieder öffnen, wenn sie einen Passkey eingerichtet haben.“ So weiß jeder vor dem Einschalten, wen die Pflicht betrifft. Haben bereits alle einen Passkey, steht auch das dort.
Wer ist ausgenommen?
Genau eine Gruppe: Mitglieder, die sich über SAML SSO anmelden und für deren Verbindung „SSO verlangen“ aktiviert ist. Für diese Personen akzeptiert Kit bereits ausschließlich Ihren Identity Provider. Die Passkey-Pflicht würde nichts mehr hinzufügen.
Important
Die Ausnahme richtet sich danach, wer die Authentifizierung steuert, nicht danach, wie stark sie ist. Akzeptiert Ihr Identity Provider ein Passwort, gilt die Ausnahme trotzdem. Konfigurieren Sie diese Richtlinie bei Ihrem IdP.
Sonst ist niemand ausgenommen:
| Nicht ausgenommen | Warum |
|---|---|
| Inhaber und Administratoren | Es gibt keine Ausnahme nach Rolle. Wer den größten Zugriff hat, muss den stärksten Nachweis erbringen. |
| SSO ohne „SSO verlangen“ | Funktionieren für die Domain weiterhin Passwörter, ist die Authentifizierung nicht wirklich delegiert. Nur die erzwungene Nutzung zählt. |
| Mit Google oder GitHub anmelden | Sie kontrollieren weder den Anbieter noch dessen MFA. Außerdem bleibt bei der OAuth-Registrierung über Kit ein nutzbares Passwort bestehen. |
| Google One Tap | Derselbe Grund: OAuth für Endverbraucher statt Ihres Identity Providers. |
| Zwei-Faktor-Codes | Sie können abgegriffen werden. Ein Code ist kein Passkey. |
| Vertrauenswürdige Browser | Das Vertrauen überspringt eine Zwei-Faktor-Abfrage. Es weist keinen Passkey nach. |
Kit bewertet die Ausnahme laufend, nicht nur bei der Anmeldung. Lockern Sie die SSO-Pflicht, unterliegen zuvor ausgenommene Mitglieder ab ihrer nächsten Anfrage der Passkey-Pflicht.
Was sofort passiert
Die Pflicht gilt ab dem Speichern. Es gibt weder Übergangsfrist noch gestaffelte Einführung; ein Mitglied in einer laufenden Sitzung sieht die Sperre beim nächsten Seitenaufruf.
| Auswirkung | Details |
|---|---|
| Gesperrte Mitglieder | Sehen die Seite „[Konto] verlangt einen Passkey“ mit direkter Einrichtung, dem Link Konto wechseln und anschließender Rückkehr zum ursprünglichen Ziel. |
| Mitgliedschaft | Bleibt unverändert. Niemand wird entfernt; Plätze, Rollen und Einladungen ändern sich nicht. |
| Andere Konten | Bleiben unverändert. Die Sperre gilt nur für dieses Konto. |
| Neue Mitglieder | Die Einladung weist darauf hin, dass ein Passkey nötig ist. So erfahren sie es vor dem ersten Zugriff. |
Nur Mitglieder mit Handlungsbedarf erhalten eine E-Mail. Der Betreff lautet „Fügen Sie einen Passkey hinzu, um [Konto] weiter zu verwenden“. Die Nachricht enthält einen direkten Link zur Passkey-Seite. Bereits konforme und über SSO verwaltete Mitglieder erhalten nichts.
Was mit API-Tokens und KI-Assistenten passiert
Ein API-Token oder eine Verbindung zu einem KI-Assistenten handelt im Namen eines Mitglieds, kann aber keinen Passkey vorlegen. Kit prüft daher nur: Besitzt die Person, die das Zugangsmittel erstellt hat, einen Passkey?
Solange die Antwort Nein lautet, antworten die API-Tokens dieses Mitglieds mit 403, und seine MCP-Verbindungen werden abgewiesen. Sobald die Person einen Passkey hinterlegt, funktionieren beide mit denselben Zugangsdaten weiter, ohne neues Token, erneute Autorisierung oder Änderungen an Daten.
Note
Diese Prüfung ist schwächer als die Zugangssperre im Browser: Eine Sitzung muss einen Passkey nachweisen, ein Token muss nur einer Person gehören, die einen Passkey besitzt. Ein Token kann keine WebAuthn-Zeremonie ausführen; näher kommt diese Oberfläche dem Nachweis nicht.
Wenn jemand alle Passkeys verliert
Sind alle Geräte verloren, kann die Person keinen Passkey mehr bestätigen. Sie kann deshalb auch nicht selbst einen Ersatz hinterlegen, denn Änderungen an Passkeys erfordern einen vorhandenen Passkey. Stellen Sie in der Compliance-Tabelle für dieses Mitglied einen Pass zur erneuten Einrichtung aus.
Sie sehen den Pass nie. Kit sendet ihn direkt und in der Sprache des Mitglieds per E-Mail. Er erscheint auf Seiten des Ausstellers weder auf einer Seite noch in einer Meldung oder einem Protokoll. Ihre Bestätigung sagt nur, dass ein Pass ausgestellt wurde. Die Ausstellung selbst landet im Audit-Protokoll, einschließlich Aussteller und Empfänger.
So verwendet das Mitglied den Pass:
| Aktion | Auswirkung |
|---|---|
| Link in der E-Mail öffnen | Keine; es erscheint nur eine Bestätigungsseite. Link-Scanner und Mail-Vorschauen können den Pass nicht verbrauchen. |
| Auf der Seite bestätigen | Der Pass wird verbraucht und ein 15-minütiges Zeitfenster beginnt. Darin bietet Kit die Einrichtung an, statt den verlorenen Passkey zu verlangen. |
| Neuen Passkey einrichten | Das Zeitfenster schließt sich und der Zugang ist wieder frei. |
Der Pass kann einmal innerhalb von 24 Stunden verwendet werden. Ein neuer Pass macht jeden noch offenen Pass für dieses Mitglied sofort ungültig. Abgelaufene, verbrauchte, ersetzte oder von der falschen Person geöffnete Pässe zeigen dieselbe neutrale Seite, ohne den Grund zu nennen. Meldet ein Mitglied, der Link sei „nicht mehr gültig“, stellen Sie einen neuen aus.
Danger
Ein Pass zur erneuten Einrichtung umgeht Ihre stärkste Kontrolle. Prüfen Sie deshalb über einen anderen Kanal, ob Sie mit der richtigen Person sprechen. Nutzen Sie einen unabhängigen Kanal, etwa ein Telefonat. Verlassen Sie sich nicht allein auf eine Antwort per E-Mail.
Die Pflicht ausschalten
Klicken Sie auf Passkeys nicht mehr verlangen. Mitglieder ohne Passkey können das Konto ab ihrer nächsten Anfrage wieder öffnen. Abgewiesene API-Tokens und MCP-Verbindungen funktionieren sofort wieder. Bereits eingerichtete Passkeys bleiben bestehen. In keiner Richtung muss etwas neu ausgestellt werden.
Kurz-Check
- Richten Sie zuerst in Ihrem eigenen Konto einen Passkey ein, sonst funktioniert die Schaltfläche nicht
- Prüfen Sie in der Compliance-Tabelle, wer den Status Kein Passkey hat
- Wenn Sie mit der Ausnahme rechnen, prüfen Sie, ob für die SSO-Verbindung SSO verlangen aktiviert ist
- Schalten Sie die Pflicht ein und lesen Sie vor der Bestätigung die Anzahl der betroffenen Mitglieder
- Prüfen Sie, ob gesperrte Mitglieder ihren Passkey direkt eingerichtet haben; sie haben einen Link per E-Mail erhalten
- Prüfen Sie Personen, die einen Pass zur erneuten Einrichtung anfordern, telefonisch und nie nur per E-Mail
- API-Tokens und MCP-Verbindungen funktionieren von selbst wieder, sobald ihr Inhaber einen Passkey hinterlegt