Beschreibung: Was sich bei Windows-Hello-PIN-Abfragen im Browser automatisieren lässt: Sicherheitsänderungen 2026, Sessions, offizielle APIs und virtuelles WebAuthn.
Ein Roboter für die Nacht, ein Mensch für die PIN
Der Browser klickt auf Anmelden, füllt das Formular aus und erledigt alles allein. Dann erscheint Windows: „PIN eingeben“. Statt eines durchgehend arbeitenden Bots haben Sie einen neuen Job – als menschlicher PIN-Nachtdienst.
Antwort: Ein gewöhnliches Browser-Skript kann die Prüfung eines bereits in Windows Hello gespeicherten Passkeys nicht auf einem standardmäßigen, zuverlässig unterstützten Weg unbeaufsichtigt erledigen. Erlaubte Sitzungen wiederzuverwenden, offizielle APIs einzusetzen oder unter passenden Bedingungen separate virtuelle Zugangsdaten zu registrieren, kann die Handarbeit jedoch reduzieren.[1][2][3]
Eine PIN ist kein Website-Passwort
Windows Hello schützt einen privaten Schlüssel auf dem Gerät. PIN, Gesicht oder Fingerabdruck bestätigen den Benutzer, damit der Schlüssel die Anmeldeanforderung der Website signiert. Die Website erhält die PIN-Ziffern nicht als Passwort.[1][4] Deshalb ist das automatische Ausfüllen einer HTML-Seite etwas anderes als die Bedienung des Windows-Sicherheitsfensters. Der Bot kommt ins Gebäude, doch der Pförtner kontrolliert weiter.
Was seit Januar 2026 anders ist
Microsoft dokumentiert Einschränkungen für nicht vertrauenswürdige automatische oder entfernte Eingaben in Windows-Anmeldedialogen durch Updates ab dem 13. Januar 2026. Lokale physische Tastaturen und bestimmte privilegierte Anwendungen werden anders behandelt als gewöhnliche simulierte Tastendrücke.[5]
Auch für Power Automate Desktop beschrieb Microsoft Probleme mit einigen Anmeldefenstern. Der Vorschlag, statt Edge Chrome oder Firefox zu testen, bezieht sich auf diesen konkreten Fehler, nicht auf eine generelle automatische Windows-Hello-Freigabe.[6]
Fünf Möglichkeiten
Sitzung wiederverwenden: Einmal rechtmäßig anmelden und den vom Dienst erlaubten Zustand behalten. Playwright kann Cookies und weitere Authentifizierungsdaten speichern. Nach Ablauf oder zusätzlicher Prüfung ist erneut eine Person nötig. Solche Zustandsdateien niemals auf GitHub veröffentlichen.[2]
Offizielle API: Bietet ein Dienst einen vorgesehenen Programmzugang, passt dieser meist besser zu unbeaufsichtigten Aufgaben. Die Passkey-Pflicht im Browser muss nicht für jeden API-Aufruf gelten.
Virtuelles WebAuthn: Chrome DevTools und Playwright simulieren Passkey-Registrierung und Anmeldung, besonders für Tests. Der vorhandene Windows-Hello-Schlüssel wird dadurch nicht exportiert. Bei echten Websites sind zusätzliche Registrierung und Nutzungsregeln zu prüfen.[7][3]
Gesicht oder Fingerabdruck: Das Tippen entfällt, nicht die Anwesenheit.[4]
Tasten simulieren: AutoHotkey, PowerShell oder USB-Tastaturemulatoren können an geschützten Fenstern scheitern. Eine unverschlüsselt gespeicherte PIN ist zudem ein Sicherheitsrisiko.[5]
Die sinnvolle Reihenfolge
Für wiederkehrende Aufgaben zuerst die Sitzung prüfen; für dauerhafte Automatisierung nach einer offiziellen API suchen; für eigene Webtests virtuelles WebAuthn verwenden. Fordert ein fremder Dienst jedes Mal eine Person, sollte das Programm pausieren und benachrichtigen. Neustart, Sitzungsablauf und sensible Aktionen getrennt testen.
Fazit
Nicht die vier Ziffern sind das eigentliche Automatisierungsziel, sondern das ständige Nachfragen beim Menschen. Sonst bleibt die einzige unersetzliche Kraft im automatisierten Betrieb: der menschliche PIN-Nachtwächter.
Quellen (7)
- Microsoft Learn: Support for Passkeys in Windows learn.microsoft.com
- Playwright: Authentication and session state playwright.dev
- Playwright: Virtual WebAuthn credentials playwright.dev
- Microsoft Learn: Passkey verification on Windows learn.microsoft.com
- Microsoft Support: Credential autofill restrictions, Windows January 2026 update support.microsoft.com
- Microsoft Learn: Power Automate desktop Windows credential dialog issues learn.microsoft.com
- Chrome for Developers: Emulate WebAuthn authenticators developer.chrome.com
