Physischer Zutritt per Badge & Passkeys: Ein technischer Guide

In der modernen Sicherheit lösen sich alte Grenzen auf. Jahrzehntelang unterschieden Unternehmen klar zwischen physischer Sicherheit – Wachpersonal, Schlösser und Zutritts-Badges – und logischer oder Cybersicherheit – Firewalls, Passwörter und Netzwerkprotokolle. Diese beiden Bereiche wurden in getrennten Silos verwaltet, mit unterschiedlichen Teams, Richtlinien und Zielen.

Heute ist diese Trennung nicht mehr tragbar. Die Verbreitung von netzwerkfähigen physischen Systemen, von Überwachungskameras über intelligente Türschlösser bis hin zu HLK-Steuerungen, hat eine tief vernetzte cyber-physische Umgebung geschaffen. Diese Konvergenz bedeutet, dass eine Schwachstelle in einem Bereich zu einem katastrophalen Ausfall im anderen führen kann. Ein Cyberangriff kann physische Türen entriegeln, und eine gestohlene Zugangskarte kann zu einem Einbruch in den Serverraum führen. Folglich ist eine ganzheitliche, konvergente Sicherheitsstrategie kein zukunftsweisender Trend mehr, sondern eine grundlegende Anforderung für eine robuste Sicherheitsarchitektur, die erhebliche Investitionen in einheitliche Plattformen nach sich zieht.

Diese neue Realität stellt eine Herausforderung für die Authentifizierung von Mitarbeitenden dar. Mitarbeitende, ob im Büro, remote oder in hybriden Rollen, benötigen Zugriff auf ein schnell wachsendes Portfolio von Cloud- und SaaS-Anwendungen. Dieses verteilte Zugriffsmodell schafft eine riesige und komplexe Angriffsfläche. Der traditionelle Benutzername mit Passwort bleibt, selbst wenn er durch herkömmliche Multi-Faktor-Authentifizierung (MFA) wie SMS-Codes ergänzt wird, das schwächste Glied – ein primärer Vektor für Phishing, Credential Stuffing und Angriffe zur Kontoübernahme. Als Reaktion darauf vollzieht die Branche einen Wandel hin zur passwortlosen, Phishing-resistenten Authentifizierung. Marktprognosen gehen davon aus, dass der Markt für passwortlose Authentifizierung von über 18 Milliarden US-Dollar im Jahr 2024 auf mehr als 60 Milliarden US-Dollar bis 2032 anwachsen wird, wobei 87 % der Unternehmen bereits Passkeys für ihre Belegschaft einsetzen oder dies planen.

Inmitten dieser technologischen Entwicklung liegt ein leistungsstarkes, oft übersehenes Gut: der physische Mitarbeiter-Badge. Diese einfache Karte, die in fast jedem mittleren bis großen Unternehmen allgegenwärtig ist, ist der Schlüssel zu einer sichereren und reibungsloseren digitalen Zukunft.

Der Hauptzweck dieses Artikels ist eine neutrale, tiefgehende technische Analyse der verfügbaren Architekturmuster zur Integration dieser physischen Badges mit Passkey-basierter Authentifizierung. Insbesondere konzentriert sich diese Analyse auf maßgeschneiderte SaaS-Anwendungen im Unternehmenskontext, bei denen man sich nicht zwangsläufig auf einen traditionellen, on-premise Identity Provider (IdP) des Unternehmens verlassen kann. In den folgenden Abschnitten werden wir drei verschiedene Wege für diese Integration analysieren und ihre technischen Komponenten, Sicherheitsmodelle und die entscheidenden Kompromisse zwischen ihnen bewerten.

Bevor wir ein konvergentes System entwerfen, müssen wir ein detailliertes Verständnis seiner grundlegenden Komponenten entwickeln. Die Fähigkeiten des physischen Tokens und die Mechanik des digitalen Berechtigungsnachweises bestimmen die verfügbaren Integrationspfade. Wer die nuancierten Unterschiede zwischen einem einfachen Identifikator und einem echten kryptografischen Authenticator nicht erkennt, riskiert fehlerhafte Architekturentscheidungen.

Mitarbeiter-Badges sind kein Monolith; ihre zugrunde liegende Technologie umfasst ein breites Spektrum an Komplexität und Sicherheit. Zu verstehen, wo ein bestimmter Badge auf diesem Spektrum einzuordnen ist, ist der erste Schritt, um seine potenzielle Rolle in einem modernen Authentifizierungssystem zu bestimmen. Die folgenden Tabellen geben einen detaillierten Überblick über diese Entwicklung.

Unternehmen, die von UID-basierten Zutrittssystemen auf sichere Authentifizierungs-Token umsteigen, folgen typischerweise diesem Pfad:

1. Einfacher UID-Badge → wird nur für den physischen Zutritt verwendet.
2. Sicherer NFC-Badge → fügt Verschlüsselung für die Zutrittskontrolle hinzu, ist aber immer noch nicht für die digitale Authentifizierung geeignet.
3. PKI-Smartcard (PIV) → fügt digitalen, zertifikatsbasierten Zugriff hinzu (VPNs, signierte E-Mails), erfordert Middleware.
4. FIDO2-Smartcard → ermöglicht passwortloses Login über WebAuthn, kann auch mit physischen Zutrittsfunktionen kombiniert werden.
5. Plattform-Passkeys → Zukunftsvision, bei der physische Token optional werden, aber die Konvergenz am besten funktioniert, wenn ein Gerät sowohl den physischen als auch den logischen Zugriff abwickelt.

Diese detaillierte Aufschlüsselung verdeutlicht den Unterschied zwischen einem einfachen Identifikator und einem kryptografischen Authenticator – das ist das wichtigste Konzept in dieser Analyse. Ein einfacher RFID-Badge kann nur eine UID liefern, die bestenfalls als Hinweis auf den Benutzernamen dienen kann, um einen Authentifizierungs-Flow zu initiieren. Er kann nicht an der kryptografischen Challenge-Response teilnehmen, die das Herzstück von WebAuthn ist. Eine FIDO2-Smartcard hingegen ist genau für diesen Zweck konzipiert. Dieser grundlegende Unterschied führt zu den drei verschiedenen Architekturmustern, die im Folgenden beschrieben werden. Optionen 1 und 2 sind im Wesentlichen Workarounds, die die Einschränkungen von Nur-Identifikator-Badges umgehen sollen, während Option 3 die native Integration eines echten Authenticators darstellt.

Mit einem klaren Verständnis der zugrunde liegenden Technologien können wir nun die drei primären Architekturmodelle zur Integration von physischen Badges mit Passkey-Authentifizierung für eine SaaS-Anwendung im Unternehmen untersuchen. Jeder Weg bringt einzigartige Kompromisse in Bezug auf Sicherheit, Kosten, User Experience und Komplexität mit sich.

Dieses Modell ist konzeptionell am abstraktesten. Der physische Badge speichert keinen Passkey selbst. Stattdessen fungiert er als Token mit geringer Sicherheit, um einen zentralisierten Dienst zu autorisieren, eine hochsichere Authentifizierung im Namen des Users durchzuführen. Der private Schlüssel des Passkeys wird nicht vom User gehalten, sondern in einem Hardware Security Module (HSM) gespeichert und verwaltet, das von einem „Credential Vault“-Anbieter betrieben wird.

1. User-Aktion & Identifikation: Ein Mitarbeitender hält seinen Standard-RFID/NFC-Badge an ein Lesegerät, das mit seiner Workstation verbunden ist. Das Lesegerät erfasst die statische UID des Badges.
2. Anfrage an den Tresor: Eine clientseitige Komponente sendet die UID an einen proprietären API-Endpunkt, der vom Anbieter des Credential-Tresors gehostet wird.
3. Serverseitige WebAuthn-Initiierung: Der Tresor-Dienst empfängt die UID, sucht das zugehörige Benutzerkonto und initiiert dann eine WebAuthn-Authentifizierungszeremonie mit der Ziel-SaaS-Anwendung (der Relying Party) im Namen des Users. Die SaaS-Anwendung gibt eine standardmäßige Authentifizierungs-Challenge zurück.
4. HSM-basiertes Signieren: Der Tresor-Dienst leitet diese Challenge an sein internes HSM weiter. Das HSM speichert sicher die private Schlüsselkomponente des Passkeys des Users für diese spezifische SaaS-Anwendung. Das HSM führt die kryptografische Signaturoperation für die Challenge durch und gibt die resultierende Signatur an den Tresor-Dienst zurück. Der private Schlüssel verlässt niemals die sichere Umgebung des HSM.
5. Abschluss der Authentifizierung & Ausstellung des Tokens: Der Tresor-Dienst schließt den WebAuthn-Flow ab, indem er die signierte Challenge an die SaaS-Anwendung zurücksendet. Die SaaS-Anwendung verifiziert die Signatur mithilfe des öffentlichen Schlüssels des Users (den sie gespeichert hat) und stellt bei Erfolg ein Authentifizierungs-Session-Token (z. B. ein JSON Web Token) aus.
6. Bereitstellung der Session: Der Tresor-Dienst leitet dieses Session-Token an den Browser des Users weiter, der es dann verwenden kann, um eine authentifizierte Sitzung mit der SaaS-Anwendung aufzubauen und den Login abzuschließen.

• Vorteile:
  • Nutzung der bestehenden Infrastruktur: Der Hauptreiz dieses Modells liegt in seiner Fähigkeit, mit den gängigsten und kostengünstigsten RFID/NFC-Badges zu arbeiten, die bereits in einem Unternehmen im Einsatz sind, wodurch eine teure und aufwendige Erneuerung der Hardware vermieden wird.
  • Absolut nahtlose User Experience: Es kann ein echtes „Tap-and-go“-Login ermöglichen. Aus der Sicht des Users meldet ihn ein einziges Tippen auf das Badge-Lesegerät direkt in der Anwendung an, was eine extrem geringe Reibung bedeutet.
  • Zentralisierte Verwaltung: Alle Passkey-Anmeldeinformationen werden innerhalb des Ökosystems des Anbieters erstellt, gespeichert und verwaltet. Dies kann administrative Aufgaben wie den Widerruf und die Durchsetzung von Richtlinien vereinfachen.
• Nachteile:
  • Proprietäres und geschlossenes System: Diese Architektur macht den Badge- und Tresor-Anbieter praktisch zu einem neuen, proprietären Identity Provider (IdP). Das Unternehmen wird für eine kritische Funktion stark von diesem einen Anbieter abhängig. Solche „geschlossenen“ Systeme sind von Natur aus unflexibel und schaffen einen erheblichen Vendor Lock-in, was zukünftige Migrationen schwierig und kostspielig macht.
  • Extrem hoher Vertrauensbedarf: Die Sicherheit des gesamten Systems hängt von der Vertrauenswürdigkeit und Kompetenz des Tresor-Anbieters ab. Da die HSMs des Anbieters die privaten Schlüssel für alle User über alle Anwendungen hinweg speichern, wäre eine Kompromittierung des Anbieters katastrophal.
  • Hohe Kosten und Komplexität: Dies ist keine einfache Lösung. Es erfordert entweder den Aufbau oder das Abonnieren eines hochkomplexen, geschäftskritischen Dienstes, der teure HSM-Infrastruktur, hochentwickelte Software und hochverfügbaren Betrieb umfasst.
  • Abweichung von den WebAuthn-Prinzipien: Dieses Modell bricht grundlegend mit dem Kernprinzip von WebAuthn, nämlich der vom User besessenen, clientseitigen Authentifizierung. Der Authenticator ist serverseitig, was ein Anti-Pattern für die allgemeine Web-Authentifizierung ist. Wie in der ursprünglichen Anfrage erwähnt, wird dieser Ansatz für die Authentifizierung bei einer Standard-Web-SaaS-Anwendung im Allgemeinen nicht empfohlen.

Dieses Modell stellt einen pragmatischen Kompromiss dar. Es verwendet den vorhandenen, einfachen Badge nicht zur Authentifizierung, sondern zur Straffung und Beschleunigung eines standardmäßigen WebAuthn-Flows. Eine auf dem Computer des Users installierte Software fungiert als „Brücke“ zwischen dem physischen Badge-Lesegerät und dem Webbrowser.

1. User-Aktion & lokale Erkennung: Ein Mitarbeitender hält seinen einfachen RFID/NFC-Badge an ein Standard-USB-Lesegerät, das mit seiner Workstation verbunden ist.
2. Lokaler Listener-Agent: Ein leichtgewichtiger Hintergrunddienst oder Daemon, der auf dem Betriebssystem läuft (z. B. unter Verwendung der PC/SC-API), lauscht auf Ereignisse des Smartcard-Lesegeräts. Er erkennt das Tippen des Badges und liest die UID von der Karte.
3. Kommunikation zwischen Agent und Extension: Dieser lokale Agent übermittelt die erfasste UID an eine zugehörige Browser-Erweiterung. Dies wird typischerweise über die Native Messaging Host API des Browsers realisiert, die es einer sandboxed Extension ermöglicht, Nachrichten mit einer vorregistrierten nativen Anwendung auszutauschen.
4. Automatisches Ausfüllen des Benutzernamens und Initiierung des Flows: Die Browser-Erweiterung enthält eine Logik, um die empfangene UID einem bestimmten Benutzernamen zuzuordnen. Nach Erhalt der UID fügt sie den entsprechenden Benutzernamen in das Anmeldeformular der SaaS-Anwendung ein. Moderne Anmeldeformulare können auch das Attribut autocomplete="webauthn" in Eingabefeldern verwenden, um dem Browser zu signalisieren, dass ein Passkey-Flow für den automatisch ausgefüllten User initiiert werden kann. Die Erweiterung kann dann programmgesteuert den Start des Passkey-Authentifizierungsprozesses auslösen.
5. Standard-WebAuthn-Zeremonie: Von diesem Punkt an findet eine vollständig standardmäßige WebAuthn-Authentifizierungszeremonie statt. Der Browser fordert den User auf, seinen registrierten Passkey-Authenticator zu verwenden. Dies könnte der Plattform-Authenticator des Computers sein (z. B. Windows Hello, macOS Touch ID) oder ein separater Roaming Authenticator (wie ein YubiKey oder sogar das Telefon des Users). Der User führt die Authentifizierungsgeste aus (z. B. Fingerabdruck-Scan), und der Login wird gemäß dem Standard-Flow abgeschlossen. Die Rolle des Badges ist nun beendet.

• Vorteile:
  • Standardkonforme Authentifizierung: Der größte Vorteil ist, dass die eigentliche kryptografische Authentifizierung ein reiner, unverfälschter WebAuthn-Flow ist. Das Sicherheitsmodell basiert auf den bewährten Prinzipien von FIDO2, nicht auf einem proprietären Workaround. Das Tippen des Badges ist lediglich eine Verbesserung der User Experience.
  • Nutzung der vorhandenen Hardware: Wie bei Option 1 funktioniert dieser Ansatz mit der vorhandenen Flotte von einfachen RFID/NFC-Badges und kostengünstigen USB-Lesegeräten.
  • Verbesserte User Experience: Obwohl es kein Ein-Tipp-Login ist, reduziert es die Reibung erheblich. Der User muss sich seinen Benutzernamen nicht merken und eingeben, was den Anmeldevorgang verkürzt und das Fehlerpotenzial verringert.
• Nachteile:
  • Software-Bereitstellung und -Wartung: Der Hauptnachteil ist der operative Aufwand. Diese Architektur erfordert die Bereitstellung, Konfiguration und Wartung von zwei separaten Softwarekomponenten – einem nativen Agenten auf Betriebssystemebene und einer Browser-Erweiterung – auf jeder einzelnen Mitarbeiter-Workstation. Dies kann eine erhebliche Belastung für IT-Abteilungen sein, die Updates verwalten, Kompatibilitätsprobleme mit verschiedenen Betriebssystem- und Browserversionen beheben und Sicherheitspatches durchführen müssen.
  • Architektonische Fragilität: Der Kommunikationskanal zwischen dem Hardwaretreiber, dem nativen Agenten und der Browser-Erweiterung ist eine maßgeschneiderte Brücke. Dieser „Klebstoff“ kann spröde sein und anfällig für Brüche, wenn das Betriebssystem oder der Browser Updates veröffentlichen, was zu einer schlechten und unzuverlässigen User Experience führt.
  • Unvollständige Lösung: Dies ist keine „Tap-and-go“-Lösung. Der User muss immer noch eine zweite, separate Aktion ausführen, um die Authentifizierung mit seinem eigentlichen Passkey abzuschließen. Das Tippen des Badges automatisiert nur den ersten Schritt des Anmeldevorgangs.

Dies ist die direkteste, sicherste und standardkonformste Architektur. In diesem Modell ist der Mitarbeiter-Badge selbst eine FIDO2-konforme Smartcard. Er ist ein echter kryptografischer Authenticator, der direkt an der WebAuthn-Zeremonie teilnehmen kann, ohne jegliche Vermittlungssoftware.

1. Navigation des Users: Ein Mitarbeitender navigiert zur Anmeldeseite der SaaS-Anwendung. Die Anwendung ist für die Unterstützung der Passkey-Authentifizierung konfiguriert.
2. WebAuthn-Initiierung: Der User klickt auf einen „Mit einem Passkey anmelden“-Button, oder die Conditional UI (Autofill) des Browsers erkennt automatisch verfügbare Passkeys und präsentiert sie in einer nicht-modalen Aufforderung. Das JavaScript des Browsers ruft

navigator.credentials.get() auf, um die Authentifizierungszeremonie zu starten.

1. Interaktion mit dem Authenticator: Der Browser fordert den User über das Betriebssystem auf, seinen Security Key vorzulegen. Der Mitarbeitende tippt entweder seinen FIDO2-Badge auf ein integriertes NFC-Lesegerät oder steckt ihn in ein angeschlossenes Smartcard-Lesegerät.
2. Kryptografische Signatur auf der Karte: Der Browser sendet die Challenge von der SaaS-Anwendung an den Badge. Das Secure Element im Badge verwendet seinen intern gespeicherten, nicht exportierbaren privaten Schlüssel, um die Challenge zu signieren. Abhängig von der Richtlinie der Relying Party und den Fähigkeiten der Karte kann dieser Schritt auch eine User-Verifizierung erfordern, wie z. B. die Eingabe einer PIN an der Workstation oder das Auflegen eines Fingers auf einen im Badge selbst integrierten biometrischen Sensor.
3. Abschluss der Authentifizierung: Der Badge gibt die signierte Antwort an den Browser zurück, der sie an den SaaS-Server weiterleitet. Der Server verifiziert die Signatur, und der User ist sicher eingeloggt. Der gesamte Prozess wird vom Browser und Betriebssystem unter Verwendung standardisierter FIDO-Protokolle orchestriert.

• Vorteile:
  • Höchste Sicherheit und Standardkonformität: Dies ist der „Goldstandard“ für den konvergenten Zugriff. Er verwendet die FIDO2- und WebAuthn-Standards genau so, wie sie konzipiert wurden, und bietet den stärksten möglichen Schutz vor Phishing- und Man-in-the-Middle-Angriffen. Der User ist im physischen Besitz des Hardware-Tokens, das seinen privaten Schlüssel enthält.
  • Architektonische Einfachheit und Robustheit: Dieses Modell besticht durch seine Einfachheit. Es gibt keine benutzerdefinierten Agenten, Browser-Erweiterungen oder proprietären Brücken, die entwickelt und gewartet werden müssen. Der Authentifizierungs-Flow stützt sich auf die sehr robusten und gut gewarteten APIs und Treiber, die in moderne Betriebssysteme und Browser integriert sind.
  • Echte Sicherheitskonvergenz: Diese Architektur löst das Versprechen eines wirklich konvergenten Berechtigungsnachweises ein. Ein einziges, verwaltbares physisches Token wird verwendet, um den Zugriff auf physische Räume (Türen) und logische Ressourcen (Anwendungen) zu gewähren, was die User Experience und das Sicherheitsmodell vereinfacht.
• Nachteile:
  • Erhebliche Hardwarekosten: Die größte Hürde bei diesem Ansatz sind die Vorabinvestitionen. Er erfordert den Austausch der gesamten Flotte von einfachen RFID/NFC-Badges eines Unternehmens durch teurere FIDO2-konforme Smartcards. Abhängig von der bestehenden Infrastruktur kann es auch notwendig sein, physische Türleser aufzurüsten, um mit den neuen Karten kompatibel zu sein.
  • Komplexes Lifecycle-Management für Anmeldeinformationen: Die Verwaltung des gesamten Lebenszyklus von kryptografischen Anmeldeinformationen für eine große Belegschaft ist aufwendiger als die Verwaltung einer einfachen Liste von UIDs. Prozesse für die sichere Ausstellung, Schlüsselrotation, Zertifikatserneuerung (falls auch PKI verwendet wird) und insbesondere für Widerruf und Wiederherstellung werden kritischer und komplexer.
  • Nuancen bei der User Experience: Obwohl sehr sicher, kann die User Experience andere Reibungspunkte mit sich bringen. Wenn die Karte eine PIN zur User-Verifizierung erfordert, führt dies wieder einen Faktor „etwas, das man weiß“ ein, an den man sich erinnern muss. Die physische Handlung, eine Karte in ein Lesegerät einzuführen, kann je nach der eingesetzten Hardware als weniger flüssig empfunden werden als ein einfaches kontaktloses Tippen.

Die Entscheidung zwischen diesen drei Architekturpfaden ist nicht nur technischer Natur; sie ist strategisch und wägt konkurrierende Prioritäten ab. Option 1 priorisiert eine nahtlose User Experience und die Nutzung vorhandener Hardware, schafft aber dadurch eine kostspielige, risikoreiche proprietäre Abhängigkeit, die von offenen Standards abweicht. Option 2 nutzt ebenfalls vorhandene Hardware und verbessert die User Experience unter Einhaltung von Authentifizierungsstandards, verlagert aber die Kosten und Komplexität auf das schwierige und oft unterschätzte Problem der Softwareverwaltung auf jedem Endgerät. Option 3 priorisiert Sicherheit, Robustheit und die Einhaltung offener Standards über alles andere und akzeptiert höhere anfängliche Hardwarekosten im Austausch für eine einfachere, zukunftssichere Architektur mit geringerem langfristigen Wartungsaufwand. Es gibt keine universell „richtige“ Wahl; der optimale Weg hängt von der spezifischen Risikotoleranz, dem Budget, der vorhandenen Infrastruktur und den IT-Support-Fähigkeiten eines Unternehmens ab.

Die Wahl der richtigen Architektur erfordert einen klaren, direkten Vergleich dieser Kompromisse. Dieser Abschnitt bietet einen Rahmen, um die komplexe Analyse in ein handlungsorientiertes Format für technische Führungskräfte zu destillieren und die praktischen, realen Herausforderungen der Implementierung anzugehen.

Der optimale Weg für ein Unternehmen hängt von seinen primären Geschäftstreibern ab.

• Wenn Ihr Hauptziel darin besteht, die anfänglichen Investitionsausgaben zu minimieren und Ihre bestehende Badge-Flotte zu nutzen, dann ist Option 2 (Desktop-Brücke) die pragmatischste Wahl. Sie bietet eine spürbare Verbesserung der User Experience und nutzt einen standardkonformen Authentifizierungskern, ohne eine große Hardware-Investition zu erfordern. Dieser Weg sollte jedoch nur gewählt werden, wenn das Unternehmen über eine ausgereifte und robuste Endpunktverwaltung verfügt, da der Erfolg dieses Modells von der Fähigkeit abhängt, die erforderliche clientseitige Software zuverlässig bereitzustellen und zu warten.
• Wenn Ihr Hauptziel darin besteht, das höchste Maß an Sicherheit zu erreichen, sich an den Best Practices der Branche auszurichten und eine zukunftssichere, wartungsarme Architektur aufzubauen, dann ist Option 3 (Konvergenter Berechtigungsnachweis) der klare strategische Gewinner. Dieser Ansatz nutzt offene Standards vollständig, eliminiert fragile benutzerdefinierte Software und bietet den stärksten Phishing-resistenten Schutz. Die anfänglichen Hardwarekosten sind eine Investition in langfristige Sicherheit und betriebliche Einfachheit.
• Wenn Ihr Hauptziel darin besteht, eine „magische“, reibungslose Tap-to-Login-Erfahrung über alle anderen Überlegungen zu stellen, dann ist Option 1 (Zentralisierter Tresor) die einzige, die dies wirklich bietet. Dieser Weg muss jedoch mit äußerster Vorsicht beschritten werden. Er birgt erhebliche strategische Risiken durch Vendor Lock-in und erfordert ein außergewöhnlich hohes Maß an Vertrauen in die Sicherheitsarchitektur und den Betrieb des Anbieters. Für die meisten offenen Web- und SaaS-Anwendungen macht die proprietäre, geschlossene Natur dieses Modells es zu einer weniger wünschenswerten Wahl im Vergleich zu standardbasierten Alternativen.

Eine erfolgreiche Passkey-Strategie geht weit über den Anmelde-Flow hinaus; sie muss den gesamten Identitätslebenszyklus umfassen. Die Wahl der Architektur hat tiefgreifende Auswirkungen darauf, wie User onboarded werden, wie der Zugriff widerrufen wird und wie Konten wiederhergestellt werden.

• Ausgabe und Onboarding: Für neue Mitarbeitende unterscheidet sich der Prozess erheblich. Bei den Optionen 1 und 2 umfasst das Onboarding die Ausgabe eines Standard-Badges und die anschließende Erstellung eines Eintrags in einer Datenbank, der die UID des Badges dem Konto des Users zuordnet. Bei Option 3 ist der Prozess eine formelle FIDO2-Registrierungszeremonie, bei der der neue FIDO2-konforme Badge verwendet wird, um einen Passkey zu generieren, der dann bei der SaaS-Anwendung registriert wird. Dieser Prozess ist sicherer, aber auch komplexer in der Verwaltung bei großem Maßstab.
• Widerruf (Beendigung des Arbeitsverhältnisses): Wenn ein Mitarbeitender das Unternehmen verlässt, wird sein physischer Zugriff immer im zentralen PACS widerrufen. Für den logischen Zugriff sind die Schritte:
  • Option 1: Der Tresor-Anbieter muss sofort benachrichtigt werden, um die in seinem HSM gespeicherte Anmeldeinformation zu deaktivieren oder zu löschen.
  • Option 2: Der eigentliche Passkey des Users (z. B. der im TPM seines Laptops über Windows Hello gespeicherte) muss in den Einstellungen der SaaS-Anwendung widerrufen werden. Die Zuordnung der Badge-UID wird irrelevant, sobald der zugrunde liegende Passkey deaktiviert ist.
  • Option 3: Der öffentliche Schlüssel, der mit dem FIDO2-Badge des Mitarbeitenden verknüpft ist, muss aus seinem Benutzerprofil in der SaaS-Anwendung gelöscht werden, wodurch der Badge für das Einloggen unbrauchbar wird.
• Wiederherstellung (verlorener oder gestohlener Badge): Dies ist ein kritischer Fehlerfall, der geplant werden muss. Die Auswirkungen variieren drastisch:
  • Bei den Optionen 1 und 2 ist ein verlorener Badge für den logischen Zugriff weniger kritisch, da er nur ein Identifikator ist. Das Hauptrisiko ist unbefugter physischer Zugriff. Der User kann sich immer noch mit seinem eigentlichen Passkey-Authenticator anmelden.
  • Bei Option 3 kann ein verlorener Badge ein großes Problem sein. Wenn der FIDO2-Badge der einzige für das Benutzerkonto registrierte Passkey ist, ist der User vollständig ausgesperrt. Dies unterstreicht eine entscheidende Best Practice für jede unternehmensweite Passkey-Implementierung: User müssen verpflichtet oder nachdrücklich dazu angehalten werden, mehrere Authenticatoren zu registrieren. Eine robuste Richtlinie würde vorschreiben, dass ein Mitarbeitender sowohl seinen FIDO2-Badge (als primären täglichen Authenticator) als auch eine Sicherung, wie seinen Plattform-Authenticator (Windows Hello/Face ID) oder sein Telefon, registriert, um es für die Kontowiederherstellung zu verwenden.

Letztendlich ist eine erfolgreiche Passkey-Implementierung nicht nur ein Authentifizierungsprojekt; es ist ein Identitäts- und Zugriffsmanagement (IAM)-Projekt. Die technische Architektur für den Anmelde-Flow kann nicht isoliert entworfen werden. Sie muss eng mit einer umfassenden Strategie für die Bereitstellung, Verwaltung und Außerbetriebnahme von Identitäten und ihren zugehörigen Anmeldeinformationen über deren gesamten Lebenszyklus hinweg integriert sein. Diese ganzheitliche Sichtweise ist unerlässlich, um Risiken wie die Kontosperrung zu mindern und den langfristigen Erfolg und die Sicherheit des Systems zu gewährleisten.

Der Weg zur Integration von physischen Zutritts-Badges mit moderner digitaler Authentifizierung ist eine klare Manifestation zweier starker, sich überschneidender Trends: die Konvergenz von physischer und Cybersicherheit und die unaufhaltsame branchenweite Abkehr von Passwörtern. Wie dieser Guide detailliert hat, haben Unternehmen drei verschiedene Architekturpfade zur Auswahl, von denen jeder einen fundamentalen Kompromiss darstellt.

• Der zentralisierte Tresor bietet eine nahtlose User Experience auf Kosten von proprietärem Lock-in und erheblichem strategischem Risiko.
• Die Desktop-Brücke bietet einen pragmatischen, kostengünstigen Weg zu einer besseren UX unter Einhaltung von Sicherheitsstandards, führt aber zu erheblichem Wartungsaufwand für Software.
• Der konvergente Berechtigungsnachweis bietet das höchste Maß an Sicherheit und Robustheit durch strikte Einhaltung offener Standards, erfordert aber eine erhebliche Vorabinvestition in Hardware.

Während jeder Weg einen Schritt in eine sicherere, passwortlose Zukunft darstellt, begünstigt die langfristige Entwicklung der Unternehmenssicherheit Lösungen, die auf offenen, interoperablen Standards basieren. Architekturen, die FIDO2 und WebAuthn nativ unterstützen – wie es das Modell des konvergenten Berechtigungsnachweises und in gewissem Maße die Desktop-Brücke tun – bieten die robusteste und zukunftssicherste Grundlage. Sie ermöglichen es Unternehmen, erstklassige Sicherheitssysteme aufzubauen, die ein wettbewerbsfähiges Ökosystem aus Hardware und Software nutzen, frei von den Zwängen der geschlossenen Plattform eines einzelnen Anbieters. Für jedes Unternehmen, das die nächste Generation von Anwendungen für Mitarbeitende entwickelt, ist die Einführung dieser offenen Standards nicht nur eine technische Entscheidung, sondern eine strategische Verpflichtung zu einer sichereren, flexibleren und interoperablen digitalen Welt.