Gerätebasierte Authentifizierung: Funktionsweise, Methoden und Sicherheitsvorteile

Gerätebasierte Authentifizierung prüft die Hardware, die Zugriff anfordert – etwa einen Laptop, ein Smartphone, einen Hardware-Key oder einen IoT-Sensor –, bevor die Verbindung akzeptiert wird. Die Benutzerauthentifizierung belegt, wer anfragt; die Geräteauthentifizierung belegt, was anfragt. Die meisten Architekturen brauchen beides, denn ein gestohlenes Passwort scheitert auf einem unbekannten Rechner nur dann, wenn der Rechner auch geprüft wird.

Der Begriff wird für mehrere unterschiedliche Mechanismen verwendet, deren Sicherheit und Lifecycle-Kosten sich stark unterscheiden. Dieser Leitfaden grenzt sie voneinander ab, erklärt, wie jeder funktioniert, zeigt, wo er passt und wo er versagt, und schließt mit einem Plan für den Rollout. Herausgeber dieses Leitfadens ist Hideez, ein Anbieter von Workforce-Identity-Lösungen; den eigenen Ansatz beschreibt Hideez erst im letzten Abschnitt.

Was ist gerätebasierte Authentifizierung?

Was also ist gerätebasierte Authentifizierung? Sie gewährt Zugriff, indem sie das Gerät prüft, nicht nur die Person. Das Gerät weist seine Identität mit einem kryptografischen Merkmal nach, etwa einem Zertifikat oder einem privaten Schlüssel. Die Benutzerauthentifizierung prüft dagegen ein Passwort, einen Code oder ein biometrisches Merkmal.

Nehmen Sie einen Firmen-Laptop und das VPN. Beim reinen Passwort-Login kann sich jeder Rechner verbinden, der die Credentials kennt – auch der eines Angreifers. Mit Geräteauthentifizierung akzeptiert das Gateway den Laptop nur, wenn er ein registriertes X.509-Zertifikat vorlegt, dessen privater Schlüssel im TPM verbleibt. Ein gestohlenes Passwort allein öffnet die Sitzung nicht mehr. In der Praxis umfasst der Begriff vier Ansätze, und jeder belegt etwas anderes:

Entscheidungsregel: Wählen Sie die Methode, deren schwächsten Punkt Ihr Bedrohungsmodell tolerieren kann, und ergänzen Sie sie um eine zweite.

Wie funktioniert gerätebasierte Authentifizierung?

Die Geräteauthentifizierung belegt, dass eine Anfrage von einem bestimmten Rechner oder Token stammt – nicht nur von einem Benutzer, der ein Passwort kennt. Der Server stellt eine Challenge, und das Gerät antwortet mit etwas, das nur es selbst besitzen sollte. Jede Methode folgt diesem Ablauf:

1. Registrierung: Das Gerät wird registriert und an einen Benutzer gebunden – über ein Cookie, ein Zertifikat oder einen öffentlichen Schlüssel.
2. Challenge: Der Server fordert vom Gerät einen Nachweis an.
3. Antwort: Das Gerät liefert ein Cookie, einen signierten Wert oder einen Posture-Bericht.
4. Entscheidung: Die Zugriffsrichtlinie gewährt, beschränkt oder verweigert die Sitzung.
5. Widerruf: Die Bindung wird aufgehoben, wenn das Gerät verloren geht oder ausgemustert wird.

Die Stärke hängt von der in Schritt 3 verwendeten Kennung ab. Vom schwächsten zum stärksten:

• MAC-Adresse: eine Kennung, kein Geheimnis, und trivial zu fälschen.
• Shared Secret oder Cookie: wird kopiert und auf einem anderen Rechner wiederverwendet.
• Zertifikat mit exportierbarem Schlüssel: nur stark, wenn der private Schlüssel an Ort und Stelle bleibt.
• Schlüssel in einem TPM oder Secure Element: nicht exportierbar, der Schlüssel bleibt also auf dem Chip.
• FIDO2-Credential: an den Origin gebunden, sodass eine Phishing-Website es nicht wiederverwenden kann.

Jeder Stufe entspricht ein Angriff: Spoofing, Replay, Schlüsselextraktion und an der Spitze physischer Diebstahl.

Gerätebasierte Authentifizierung vs. Geräteauthentifizierung

Viele Quellen verwenden beide Begriffe synonym, und kein Normungsgremium definiert einen Unterschied. Dieser Leitfaden arbeitet mit einer praktischen Unterscheidung, die bei der Wahl einer Methode hilft.

Geräteauthentifizierung identifiziert den Endpunkt selbst. Sie beantwortet die Frage „Ist das ein bekannter Rechner?“ und gilt für Laptops, Server und IoT-Sensoren, an deren Tastatur niemand sitzt. Typische Nachweise sind ein X.509-Zertifikat, ein in einem TPM gespeicherter Schlüssel oder ein Shared Secret.

Gerätebasierte Authentifizierung ist weiter gefasst. Sie umfasst jedes Verfahren, bei dem ein Gerät Teil des Zugriffsnachweises ist – auch einen Hardware-Key oder ein Smartphone, das stellvertretend für eine Person steht. Das Gerät fungiert dann als Besitzfaktor.

Die Unterscheidung prägt das Design. Ein Maschinenzertifikat sagt nichts darüber aus, wer am Laptop sitzt, daher muss parallel ein Benutzerfaktor laufen, meist als MFA-Schritt. Ein Hardware-Key belegt den Besitz durch eine Person, sagt aber nichts über den Zustand des Computers aus, an den er angeschlossen ist. Behandeln Sie beides als Schichten.

Gerätebasierte Authentifizierung vs. passwortlose Authentifizierung

Der Vergleich von gerätebasierter und passwortloser Authentifizierung läuft darauf hinaus, was entfernt und was belegt wird. Passwortlose Authentifizierung entfernt das Passwort aus der Anmeldung. Gerätebasierte Authentifizierung fügt dem Nachweis ein Gerät hinzu. Beide überschneiden sich, sind aber nicht dasselbe.

• Beides: ein FIDO2-Passkey auf einem Hardware-Key oder Smartphone. Das Passwort entfällt, und ein Gerät hält das Credential.
• Passwortlos ohne Gerätebindung: ein Code oder Link per E-Mail oder SMS. Das Passwort entfällt, aber nichts bindet die Anmeldung an ein registriertes Gerät, und der Code lässt sich über einen Phishing-Proxy weiterleiten.
• Gerätebasiert ohne Passwordless: ein Maschinenzertifikat für WLAN- oder VPN-Zugang, während der Benutzer in Anwendungen weiterhin ein Passwort eintippt, oder ein Trusted-Device-Cookie, das MFA überspringt, das Passwort aber beibehält.

Wenn Passwort-Wiederverwendung und Phishing das Problem sind, sollten Sie eine passwortlose Anmeldung mit Origin-gebundenen Credentials anstreben. Wenn nicht verwaltete Rechner ins Netzwerk gelangen, ist ein Gerätezertifikat oder ein Posture-Check die bessere Antwort. Die meisten Unternehmen kombinieren beides.

Gängige Methoden der gerätebasierten Authentifizierung

Die vier folgenden Methoden sind die Credentials, die am häufigsten zum Besitznachweis für Personen und Workstations eingesetzt werden. Trusted-Device-Cookies und Posture-Checks, oben beschrieben, bleiben als zusätzliche Signale nützlich; ihre Grenzen behandelt der Abschnitt zu den Risiken. Die Methoden unterscheiden sich darin, was sie vom Benutzer, vom Gerät und vom Administrator verlangen.

Hardware-Sicherheitsschlüssel und FIDO2-Authentifizierung

Hardware-Sicherheitsschlüssel sind kleine Authenticatoren, die per USB, NFC oder Bluetooth verbunden werden, private Schlüssel speichern und Challenges signieren. Bei der FIDO2-Authentifizierung erzeugt der Key für jede Website ein eigenes Schlüsselpaar. Der private Schlüssel verlässt den Key nie, der Server speichert nur den öffentlichen Schlüssel, und die Signatur ist an den Origin der Website gebunden – eine Phishing-Website auf einer anderen Domain erhält daher keine verwertbare Antwort. Die FIDO Alliance beschreibt dies als Public-Key-Kryptografie in einem Challenge-Response-Verfahren, ohne Shared Secret, das ein Angreifer abgreifen könnte.

Der Benutzer entsperrt den Key mit einer PIN oder einer Berührung, ein Angreifer bräuchte also sowohl den physischen Key als auch dessen PIN. Es handelt sich um gerätegebundene Credentials im engeren Sinne: Sie verlassen die Hardware nie.

Die Kosten sind operativer Natur. Keys müssen verteilt werden, und ein verlorener Key braucht einen Wiederherstellungsweg, der keine schwache Hintertür ist: Registrieren Sie pro Benutzer einen zweiten Key oder prüfen Sie die Identität, bevor Sie Ersatz ausgeben, und widerrufen Sie den verlorenen Key sofort. Zertifizierungen gelten pro Modell, prüfen Sie also das genaue Modell; der Hideez Key 5 etwa ist FIDO2-zertifiziert. Hardware-Keys eignen sich für gemeinsam genutzte Workstations, smartphonefreie Arbeitsplätze und privilegierte Konten.

Mobile Geräteauthentifizierung und Passkeys

Ein Smartphone kann den Besitz auf drei Arten belegen: per Push-Bestätigung, per Einmalcode oder per Passkey. Ein OTP ist ein beliebiges Einmalpasswort; TOTP ist die zeitbasierte Variante, die aus einem Shared Secret und der Uhrzeit erzeugt wird. Beide lassen sich auf einer Phishing-Seite eingeben und in Echtzeit an die echte Website weiterleiten. Ein Passkey lässt sich nicht weiterleiten, weil er an den Origin gebunden ist.

Passkeys sind FIDO-Credentials, und die FIDO Alliance unterscheidet zwei Arten. Synchronisierte Passkeys werden über den Cloud-Dienst des Anbieters auf alle Geräte eines Benutzers kopiert, was eine Abhängigkeit vom Sync-Konto und dessen Wiederherstellungsprozess schafft. Gerätegebundene Passkeys verlassen nie ein einzelnes Gerät, und solche auf Hardware-Sicherheitsschlüsseln bieten die höchste Vertrauenswürdigkeit. Im geräteübergreifenden Flow meldet ein Smartphone den Benutzer über einen QR-Code an einem Laptop an, wobei Bluetooth die physische Nähe bestätigt.

Kann jemand auf eine Authenticator-App zugreifen? Nur mit physischem Zugriff auf das Smartphone und dessen Entsperrmethode – erzwingen Sie daher eine Bildschirmsperre und Biometrie. Smartphone-basierte Methoden setzen zudem ein privates Smartphone voraus, das in vielen Reinräumen und Lagerhallen verboten ist.

Proximity-basierte Authentifizierung

Proximity-basierte Authentifizierung nutzt die physische Nähe eines Tokens zur Workstation als Signal. NFC arbeitet auf wenige Zentimeter: Der Benutzer tippt mit einem Key oder Ausweis auf ein Lesegerät – eine bewusste Geste, die kaum versehentlich ausgelöst wird. Bluetooth Low Energy arbeitet auf wenige Meter: Die Workstation schätzt die Entfernung anhand der Signalstärke, was das Entsperren bei Annäherung und das Sperren beim Weggehen ermöglicht.

Die Schätzung ist der Schwachpunkt. Die Signalstärke schwankt durch Wände, Körper und Funkstörungen, sodass ein Schwellenwert, der in einem Raum funktioniert, in einem anderen versagen kann. Auch ein Relay-Angriff, bei dem ein Angreifer das Signal zwischen einem entfernten Token und der Workstation weiterleitet, kann eine reine Proximity-Entsperrung täuschen. Die übliche Antwort: Proximity bei der Anmeldung mit einem zweiten Signal wie einer PIN oder einer Berührung kombinieren und Proximity vor allem zum Sperren nutzen, wo eine Fehlauslösung unbedenklich ist.

Testen Sie den Entfernungsschwellenwert in jedem Raumtyp und legen Sie eine kurze Karenzzeit fest, damit ein kurzes Weggehen die Arbeit nicht unterbricht.

Zertifikatsbasierte Geräteauthentifizierung

Bei der zertifikatsbasierten Geräteauthentifizierung stellt eine Zertifizierungsstelle ein X.509-Zertifikat aus, das einen öffentlichen Schlüssel an eine Geräteidentität bindet. Das Gerät belegt den Besitz des zugehörigen privaten Schlüssels, indem es eine Challenge signiert, meist innerhalb eines TLS-Handshakes. Ein VPN-Gateway, ein WLAN mit 802.1X oder eine interne Anwendung akzeptiert nur Endpunkte, die ein Zertifikat Ihrer Zertifizierungsstelle besitzen.

Lassen sich Zertifikate zur Authentifizierung nutzen? Ja, und sie ersetzen das Passwort für das Gerät. Ein Zertifikat ist allerdings nicht automatisch stark. Ist der private Schlüssel exportierbar, lässt er sich auf einen anderen Rechner kopieren. Speichern Sie ihn in einem TPM oder Secure Element, damit er den Chip nicht verlassen kann, und machen Sie dies bei der Registrierung zur Pflicht.

Der Aufwand liegt im Lifecycle: Ausstellung, Erneuerung, Ablauf und Widerruf. Abgelaufene oder verwaiste Zertifikate verursachen Ausfälle, und ein nie widerrufenes Zertifikat funktioniert weiter, nachdem das Gerät verloren gegangen ist. Erfassen Sie die Ablaufdaten vor dem Rollout und richten Sie frühzeitige Warnungen ein. Eine MAC-Adresse ist dagegen eine im Klartext übertragene Kennung, die sich kopieren lässt – nutzen Sie sie höchstens für die Inventarisierung.

Die wichtigsten Vorteile gerätebasierter Authentifizierung

Die Vorteile hängen von der gewählten Methode ab und davon, wie gut der Lifecycle gesteuert wird. Für Unternehmen, die über reine Passwörter hinausgehen, stechen drei hervor.

Besserer Schutz vor Phishing und Credential-Diebstahl

Origin-gebundene Credentials beseitigen die Hauptschwäche von Passwörtern: Es gibt kein Shared Secret, das sich phishen, wiederverwenden oder leaken ließe. Eine gefälschte Login-Seite auf einer anderen Domain erhält nichts, was die echte Website akzeptieren würde, und ein Breach der Serverdatenbank legt nur öffentliche Schlüssel offen. Credential Stuffing, das auf wiederverwendete Credentials setzt, läuft ins Leere. NIST SP 800-63B-4, seit Juli 2025 final, legt technische Anforderungen für Authenticator Assurance Levels fest; klären Sie mit Ihrem Compliance-Team, auf welches Level sich eine Vorschrift oder ein Vertrag bezieht.

Der Schutz hat Grenzen. Er deckt das Credential ab, nicht das Endgerät. Malware auf einem kompromittierten Computer kann eine bereits authentifizierte Sitzung nutzen, und ein Trusted-Device-Cookie lässt sich stehlen und wiederverwenden. Kombinieren Sie gerätebasierte Methoden mit Endpoint-Schutz und halten Sie Cookie-basiertes Vertrauen von privilegierten Konten fern. Die Phishing-Resistenz hängt außerdem von der Registrierung ab: Ein Credential, das über einen schwachen Wiederherstellungsprozess registriert wurde, erbt dessen Schwäche.

Schnellerer und bequemerer Zugriff für Benutzer

Ein Tippen auf einen Key oder eine Berührung eines Sensors geht schneller, als ein langes Passwort und danach einen Code einzugeben. Weniger Passwörter bedeuten auch weniger Passwort-Reset-Tickets für den Helpdesk – zumindest für die Anwendungen, die die neue Methode abdeckt. Ein Trusted-Device-Cookie reduziert wiederholte MFA-Abfragen bei Anwendungen mit geringem Risiko; das ist sein wichtigster Nutzen für die Bedienbarkeit.

An gemeinsam genutzten Workstations hält ein schneller Benutzerwechsel bei der Schichtübergabe die Warteschlangen kurz. Der Komfort hat Voraussetzungen. Die Registrierung kostet Zeit, ein Benutzer ohne Key braucht einen Wiederherstellungsweg, der nicht Stunden dauert, und ein unzuverlässiges Lesegerät macht den Gewinn schnell zunichte. Messen Sie Anmeldezeit und Helpdesk-Anfragen während eines Pilotprojekts, statt eine Verbesserung vorauszusetzen. Passkeys und Keys funktionieren zudem in den Browser-Flows, die Benutzer bereits kennen – das verkürzt Schulungen und hält die Einführungshürden niedrig. Planen Sie die Support-Last der ersten Woche ein, denn Benutzer vergessen Keys zu Hause und vertippen sich bei der PIN.

Mehr Kontrolle über den Unternehmenszugriff

Gerätebasierte Methoden binden jeden Zugriff an ein registriertes, benanntes Gerät, sodass Administratoren beantworten können, welches Gerät sich wann und unter welcher Richtlinie angemeldet hat. Die Registrierung lässt sich auf ein vertrauenswürdiges Netzwerk oder einen verifizierten Benutzer beschränken. Richtlinien können eine PIN verlangen, den Zugriff auf bestimmte Anwendungen beschränken, unterschiedliche Regeln für Administratoren und normale Benutzer festlegen oder Geräte blockieren, die einen Posture-Check nicht bestehen.

Der Widerruf ist die andere Hälfte der Kontrolle. Geht ein Laptop, Key oder Smartphone verloren, beendet das Aufheben seiner Bindung den Zugriff, ohne dass der Benutzer alle seine Passwörter ändern muss. Testen Sie das: Widerrufen Sie ein Pilotgerät und messen Sie, wie lange es dauert, bis der Widerruf greift. Protokolle über Registrierungen, Anmeldungen und Widerrufe liefern Auditoren zudem Nachweise darüber, wie Credentials verwaltet werden – das unterstützt die Compliance, ohne sie zu garantieren. Prüfen Sie dieselben Protokolle regelmäßig, um Geräte zu erkennen, die sich seit Monaten nicht angemeldet haben und ausgemustert werden sollten. Weisen Sie jeder Richtlinie einen Verantwortlichen zu, damit Ausnahmen überprüft werden, statt sich anzuhäufen.

Anwendungsfälle gerätebasierter Authentifizierung

Dieselben Mechanismen wirken unterschiedlich – je nachdem, wer das Gerät nutzt, wo und unter welchen Einschränkungen. Drei Anwendungsfälle zeigen die Bandbreite.

Passwortloser Zugriff auf Geschäftsanwendungen

Ein Passkey oder Hardware-Key kann den Identity Provider entsperren, der den Benutzer dann per Single Sign-On über SAML oder OpenID Connect (OIDC) bei den dahinterliegenden Geschäftsanwendungen anmeldet. Eine starke Anmeldung ersetzt viele Passwörter, und die Anwendungen selbst müssen nicht geändert werden. Beginnen Sie mit den Anwendungen, die die sensibelsten Daten enthalten, und erweitern Sie den Umfang, sobald die Benutzer mit der Methode vertraut sind.

Planen Sie die Ausnahmen ein. Legacy-Anwendungen, die keines der beiden Protokolle unterstützen, brauchen ein Gateway oder einen Agenten zur Credential-Injektion – oder sie behalten ihre Passwörter. Legen Sie fest, welcher Identity Provider die Richtlinie hostet, etwa Microsoft Entra ID oder Keycloak, und prüfen Sie vor dem Rollout, ob er den gewählten Authenticator akzeptiert. Halten Sie einen dokumentierten Wiederherstellungsweg bereit, denn Passwordless ohne Wiederherstellung macht aus einem verlorenen Key eine Aussperrung. Testen Sie die Anmeldung auf jedem Browser und Betriebssystem, das Ihre Belegschaft nutzt. Verlangen Sie für Administratorkonten zuerst phishing-resistente Authenticatoren und weiten Sie dies dann auf die breite Belegschaft aus.

Gemeinsam genutzte Workstations und Mitarbeitende an der Frontline

Was Sie verifizieren können, hängt davon ab, wer das Gerät kontrolliert. Auf einem verwalteten Endgerät meldet ein Agent den Gerätezustand. Auf einem BYOD- oder Dienstleistergerät gibt es keinen Agenten; das einzige verlässliche Signal ist dann der kryptografische Nachweis, dass der Benutzer ein Credential besitzt.

• Verwalteter Laptop: Posture-Check plus Zertifikat oder FIDO2-Key.
• BYOD: FIDO2-Authenticator oder Passkey; der Zustand ist unbekannt.
• Externer Dienstleister: zeitlich befristetes Credential, das bei Vertragsende widerrufen wird.
• Gemeinsam genutzter Kiosk: ein Hardware-Authenticator pro Benutzer, mit Sitzungssperre beim Weggehen.

Ein Posture-Check beschreibt den Zustand eines Geräts, und ein FIDO2-Authenticator belegt den Besitz, nicht den Zustand. Beim Login an gemeinsam genutzten Workstations ist oft das Smartphone die Einschränkung: In Reinräumen, Sterilbereichen und Lagerhallen fallen Push-Benachrichtigungen und QR-Registrierung weg, sodass eine Tipp- oder Ausweis-basierte Methode zur praktischen Baseline wird. Handschuhe und sterile Kittel machen zudem das Eintippen von Passwörtern unpraktikabel, und eine Schichtübergabe erfordert einen schnellen Benutzerwechsel.

Proximity-Login und automatische Sperrung von Workstations

Im Gesundheitswesen, in der Industrie und in der Logistik findet die Authentifizierung an Workstations viele Male pro Schicht statt, oft mit Handschuhen oder vollen Händen. Jedes Mal ein Passwort einzugeben, ist langsam, und wer das als zu langsam empfindet, lässt Sitzungen offen oder teilt Credentials.

Proximity-Login löst beide Seiten. Ein Tippen oder eine Annäherung startet die Sitzung, und die automatische Sperrung beendet sie, wenn die Mitarbeiterin oder der Mitarbeiter weggeht – ein unbeaufsichtigter Bildschirm bleibt so nicht für die nächste Person offen. Kombinieren Sie einen kurzen Inaktivitäts-Timer mit der Proximity-Sperre, sodass jedes der beiden Ereignisse die Sitzung schließt. Das hilft auch bei Audits: Jede Sitzung hat dann einen klaren Beginn, ein klares Ende und einen namentlich bekannten Benutzer.

Testen Sie vor dem Deployment drei Situationen: den schnellen Benutzerwechsel bei der Schichtübergabe, einen Mitarbeiter, der das Token auf dem Schreibtisch liegen lässt, und ein Token mit leerer Batterie. Für jede braucht es ein definiertes Ergebnis, etwa eine Sperrung, einen Override durch die Schichtleitung oder ein Ersatz-Token.

Sicherheitsrisiken und Grenzen gerätebasierter Authentifizierung

Die Sicherheit gerätebasierter Authentifizierung unterscheidet sich je nach Methode, weil jede an einer anderen Stelle versagt und eigene Kontrollen braucht. Halten Sie zuerst fest, was der Angreifer benötigt, und ordnen Sie dann jedem Risiko eine Kontrolle, einen Verantwortlichen und einen Test zu.

• Trusted-Device-Cookie: Einmal gestohlen, funktioniert das Cookie von jedem Rechner aus.
• Posture-Check: den gemeldeten Zustand fälschen oder den meldenden Agenten kompromittieren.
• Zertifikat: einen exportierbaren privaten Schlüssel extrahieren oder ein nie widerrufenes Zertifikat nutzen.
• OTP: den Code über einen Phishing-Proxy weiterleiten.
• FIDO2-Authenticator: das physische Gerät in die Hände bekommen und dessen PIN überwinden.

Das Playbook zur Risikominderung ordnet jedem Risiko eine Kontrolle, einen Verantwortlichen und einen Test zu:

• Verlorenes Gerät: die Bindung widerrufen (IAM-Team). Ein Pilotgerät widerrufen und messen, wann der Widerruf greift.
• Exportierbarer Schlüssel: TPM-Speicherung vorschreiben (Endpoint-Team). Einen Export versuchen.
• Abgelaufenes Zertifikat: vor dem Ablauf warnen (PKI-Verantwortlicher). In der Staging-Umgebung mit einem kurzlebigen Zertifikat testen.
• Schwache Wiederherstellung: den Benutzer verifizieren, bevor Codes ausgegeben werden (Helpdesk). Als Hochstapler eine Wiederherstellung anfordern.
• Gestohlenes Sitzungs-Cookie: die Sitzungsdauer verkürzen und Sitzungen an das Gerät binden, wo die Plattform es erlaubt (Anwendungsverantwortlicher). In einer Testumgebung ein abgefangenes Cookie von einem anderen Rechner aus wiederverwenden.

Jede Methode bringt zudem einen eigenen Lifecycle mit, der verwaltet werden muss, und ein starkes Credential mit schwachem Wiederherstellungsprozess ist nur so stark wie die Wiederherstellung.

So führen Sie gerätebasierte Authentifizierung im Unternehmen ein

Die Einführung ist überwiegend Lifecycle-Arbeit. Gehen Sie in einer festen Reihenfolge vor und benennen Sie für jeden Schritt einen Verantwortlichen:

1. Bereitstellen: die Methode für jedes Flottensegment wählen und die Credentials vorbereiten.
2. An Benutzer binden: jedes Gerät für eine verifizierte Person registrieren.
3. Richtlinie durchsetzen: festlegen, welche Anwendungen welche Methode erfordern.
4. Überwachen: Registrierungen, Anmeldungen und Richtlinienverstöße protokollieren.
5. Wiederherstellen: festlegen, wie ein Benutzer nach einem Verlust wieder Zugriff erhält.
6. Widerrufen: die Bindung zügig aufheben und testen, wie schnell das greift.
7. Außer Betrieb nehmen: Credentials stilllegen, wenn Geräte aus dem Betrieb ausscheiden.

Ordnen Sie die Kontrollen den Frameworks zu, mit denen Ihre Auditoren arbeiten. Gerätebasierte Methoden unterstützen die Compliance, indem sie prüfbare Nachweise erzeugen; allein machen sie ein Unternehmen nicht compliant.

• NIST SP 800-53: IA-3 (Identifizierung und Authentifizierung von Geräten) entspricht Zertifikaten und hardwaregebundenen Authenticatoren. IA-5 (Authenticator-Management) entspricht Ausstellung, PIN-Richtlinie und Widerruf.
• NIST SP 800-207: Die Grundsätze zum Gerätezustand entsprechen Posture-Checks vor jeder Zugriffsentscheidung.
• ISO/IEC 27001:2022: A.5.15 (Zugangssteuerung), A.5.16 (Identitätsmanagement) und A.8.5 (sichere Authentisierung) entsprechen Registrierung, Widerruf und MFA-Durchsetzung.
• NIS2 und PCI DSS 4.0: Diese Frameworks behandeln MFA und den Lifecycle von Authenticatoren.

Lassen Sie Ihren Datenschutzbeauftragten oder Compliance-Manager den genauen Wortlaut der Klauseln für Ihren Geltungsbereich prüfen, bevor er in eine Audit-Akte aufgenommen wird. Beginnen Sie dann klein: Pilotieren Sie eine Methode mit einem Team auf einem realistischen Mix aus verwalteten und nicht verwalteten Geräten, testen Sie den Widerruf an einem verlorenen Gerät und erweitern Sie danach den Umfang.

So wählen Sie eine Plattform für gerätebasierte Authentifizierung

Eine Plattform für gerätebasierte Authentifizierung sollte nach dem Lifecycle beurteilt werden, den sie abdeckt, nicht allein nach dem Anmeldebildschirm. Vergleichen Sie Anbieter anhand dieser Kriterien:

• Unterstützte Methoden: Hardware-Keys, Passkeys, Zertifikate und Proximity, damit jedes Flottensegment eine passende Methode erhält.
• Registrierung und Widerruf: Wer ein Gerät registrieren darf, wie die Identität vorher nachgewiesen wird und wie schnell ein Widerruf greift.
• Wiederherstellung: ein dokumentierter Weg für einen verlorenen Authenticator, der das Sicherheitsmodell nicht schwächt.
• Bereitstellungsmodell: selbst gehostet, Private Cloud oder mandantenfähige Cloud – je nach Vorgaben zu Daten und Datenresidenz.
• Integration: Standardprotokolle (SAML, OIDC, WS-Federation) und veröffentlichte Konnektoren zu Ihrem Verzeichnisdienst und Identity Provider.
• Offline- und gemeinsame Nutzung: Verhalten bei Netzwerkausfall und schneller Benutzerwechsel an gemeinsam genutzten Stationen.
• Nachweise: Zertifizierungen für die konkreten Authenticator-Modelle und exportierbare Audit-Logs.

Lassen Sie sich von jedem Anbieter Widerruf und Wiederherstellung an einer Pilotgruppe vorführen, nicht nur die Registrierung.

Gerätebasierte Authentifizierung mit Hideez

Hideez Workforce Identity nutzt Smartphones, Passkeys und Hardware-Sicherheitsschlüssel, um Mitarbeitende in Geschäftsanwendungen und an Windows-Workstations zu authentifizieren. Administratoren verwalten Benutzer, registrierte Authenticatoren und Zugriffsrichtlinien über den Hideez Enterprise Server, der in der Cloud, in einer Private Cloud oder On-Premises verfügbar ist. Hideez ist zertifiziertes Mitglied der FIDO Alliance und nach ISO 27001 zertifiziert.

Mitarbeitende können die mobile App Hideez Authenticator oder einen FIDO2-Sicherheitsschlüssel wie den Hideez Key 5 verwenden. Bei der FIDO2-Authentifizierung belegt der Authenticator den Besitz eines kryptografischen Credentials, ohne ein wiederverwendbares Passwort zu übertragen. Über Passwordless SSO verschafft diese Anmeldung per SAML oder OpenID Connect Zugriff auf angebundene Anwendungen. Dank der Integration mit Active Directory und Microsoft Entra ID können Unternehmen ihr bestehendes Mitarbeiterverzeichnis beibehalten.

Auf Windows-Computern ermöglicht Hideez die passwortlose Anmeldung und den Proximity-basierten Zugriff. Ein Smartphone oder Hideez Key kann eine automatische Sitzungssperre auslösen, wenn sich die Person vom Arbeitsplatz entfernt. Das ist an gemeinsam genutzten Workstations hilfreich, an denen Mitarbeitende häufig wechseln und das Sperren des Bildschirms vergessen können. Hardware-Keys bieten eine Option für Umgebungen, in denen private Smartphones eingeschränkt sind.

Der Hideez Key 5 kann zudem einen physischen Zutrittsausweis für kompatible Tür- und Drehkreuzleser aufnehmen, sodass Mitarbeitende dasselbe Gerät für die Authentifizierung an der Workstation und den Gebäudezutritt verwenden können.

Um zu sehen, wie Hideez mit Ihren Geräten und Anwendungen zusammenarbeitet, fordern Sie eine Demo an. Anschließend können Sie in einem kostenlosen Pilotprojekt Anmeldung, automatische Workstation-Sperrung und Authenticator-Verwaltung in Ihrer eigenen Umgebung testen. Bei Fragen zu Kompatibilität oder Bereitstellungsoptionen wenden Sie sich an das Hideez-Vertriebsteam.