Can an automated browser sign in with a passkey?

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 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". A page asks with isUserVerifyingPlatformAuthenticatorAvailable(), which under the specification resolves "with the value of true" when the client discovers any user-verifying platform authenticator.

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 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.

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 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.

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.

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 describes where the key lives between runs and why a missing key is recorded with a reason instead of deleted.

Scalebrowser gives each agent its own isolated browser with a persistent identity, on your own machine, so a run stays signed in, handles the captcha and finishes without anyone watching it.

See how Scalebrowser does it

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.