---
title: "Can an automated browser sign in with a passkey?"
description: "How an automated browser signs in with a passkey: what real machines answer, what Chrome's virtual authenticator gives away, and why the time has to vary."
canonical: "https://scalebrowser.net/blog/passkeys-automation"
last_modified: "2026-10-12"
published: "2026-10-12"
author: "davide"
category: "sign-in"
---
> ## Documentation Index
> Fetch the complete documentation index at: https://scalebrowser.net/llms.txt
> Use this file to discover all available pages before exploring further.
# Can an automated browser sign in with a passkey?
> How an automated browser signs in with a passkey: what real machines answer, what Chrome's virtual authenticator gives away, and why the time has to vary.
More sign-ups now end at a passkey prompt, and an account created with a passkey cannot be reached without it. Automation tools meet that prompt with a virtual authenticator made for tests, or with advice to switch passkeys off. Both leave traces a site can read in the ordinary ceremony. We set what Chrome's test authenticator hands a site next to what a Windows machine hands it, and report the one timing error our own bench found in September 2026.
## What is a passkey for an automated browser?
A passkey is a WebAuthn credential: a private key that stays with the authenticator and a public key the site stores in place of a password. Three parts decide whether an automated browser can use one.
- **The platform authenticator.** The W3C's [WebAuthn Level 3 specification](https://www.w3.org/TR/webauthn-3/) calls the authenticators "that are part of the client device" platform authenticators. On Windows that is Windows Hello.
- **The credential.** A key pair scoped to one site, carrying a model id for the authenticator and a signature counter the site can watch.
- **The ceremony.** Registration creates the credential and sign-in proves it; both wait for a person to confirm at the sensor.
An automated browser has no person at the sensor. It still has to answer each of these parts the way a machine with a person in front of it would, and it has to keep the private key after the browser closes. Other prompts a browser draws next to the page are covered in permission prompts in automation.
## Which answer do real machines give?
Real Windows machines mostly answer that they have a platform authenticator: Microsoft reported on 1 May 2025 that ["more than 99% of people who sign into their Windows devices with their Microsoft account do so using Windows Hello"](https://www.microsoft.com/en-us/security/blog/2025/05/01/pushing-passkeys-forward-microsofts-latest-updates-for-simpler-safer-sign-ins/). A page asks with `isUserVerifyingPlatformAuthenticatorAvailable()`, which under the specification resolves "with the value of true" when the client discovers any user-verifying platform authenticator.
| Machine | What the method returns | Why |
| --- | --- | --- |
| Windows 11 with Windows Hello set up | true | Hello is the operating system's own authenticator; Windows 11 requires TPM 2.0 |
| A machine whose operating system offers no user-verifying authenticator | false | nothing on the device can verify the user |
No primary source publishes the share of all machines that answer true. Microsoft's figure covers people with a Microsoft account on Windows, and it is the closest public number. It is enough to show which answer is ordinary for a Windows desktop: a profile that claims Windows and answers false sits in the smaller group, and a site can read that before any ceremony starts.
## Why does a virtual authenticator give automation away?
A virtual authenticator gives automation away because it was built to test WebAuthn, and several fields it hands the site say so. Chrome's DevTools Protocol has an experimental [WebAuthn domain](https://chromedevtools.github.io/devtools-protocol/tot/WebAuthn/) that "allows configuring virtual authenticators to test the WebAuthn API". Its `enable` command starts "intercepting credential storage and retrieval with a virtual authenticator", and the options of `addVirtualAuthenticator` decide what the page then sees.
| What the site reads | Chrome's virtual authenticator by default | Where it is written |
| --- | --- | --- |
| Model id (AAGUID) | 01020304-0506-0708-0102-030405060708 | Chromium source |
| Is that id a known authenticator | no, absent from all 59 entries of the list on 29 September 2026, which names 3 for Windows Hello | [passkey AAGUID list](https://github.com/passkeydeveloper/passkey-authenticator-aaguids) |
| Signature counter at registration | 1 | Chromium source |
| User presence | "tests of user presence will succeed immediately" | DevTools Protocol |
| User verification | fails unless set, default false | DevTools Protocol |
Each of these values arrives with the ordinary ceremony, so a site pays nothing extra to read them. In our own measurement on stock Chromium, the authenticator also disappeared with the DevTools session that created it, which means a tool that opens a new session per action loses its sensor between two actions. Browserbase's [authentication guide](https://docs.browserbase.com/platform/identity/authentication) takes the opposite route and, as of September 2026, recommends disabling passkeys in automated sessions, which leaves the account with whatever factor remains. Where the passkey sits among the other walls of a sign-in is laid out in [agent sign-in](/blog/ai-agent-login).
## What does an automated passkey have to get right?
An automated passkey has to get three things right beyond the model id: the time a person takes, the counter over many sign-ins, and the key's survival when the browser ends badly.
- **The time.** A person needs seconds to reach a sensor and never takes the same number of milliseconds twice.
- **The counter.** Every use raises the signature counter; a counter frozen at zero reads as a synced passkey rather than one bound to a device.
- **The survival.** A browser that crashes or is closed by hand must not take the private key with it.
The timing result went against us. On 14 September 2026 our engine bench found that the first passkey registration of one profile took almost the same time in two separate starts, about 10 milliseconds apart, and a person does not repeat a deliberation that closely. The delay was tied to the profile's identity instead of being drawn fresh for each ceremony. The corrected build, measured on 16 September 2026, is the one that shipped.
| Build | First registration, start 1 | First registration, start 2 | Ceremonies repeating within 32 ms across starts |
| --- | --- | --- | --- |
| 14 September 2026 | 5508 ms | 5519 ms | 5 of 5 |
| 16 September 2026 | 5500 ms | 4841 ms | 0 of 10 |
Survival is tested on a public page. The passkey acceptance bench registers a key on webauthn.io with the Windows engine, kills the engine, starts it again, signs in and then retires the key through the agent; it passed 8 of 8 checks on 14 and 18 August 2026. The [passkeys page of the documentation](/docs/passkeys) describes where the key lives between runs and why a missing key is recorded with a reason instead of deleted.
### How is a second factor handled without passkeys?
Without a passkey the second factor is usually a six-digit code, and that code can be computed inside the profile. Under RFC 6238 it changes every 30 seconds, so it is derived from the stored setup key at the moment the code field needs it, and the agent never reads the digits. The steps are in [TOTP for agents](/blog/automate-2fa-totp).