A trusted browser is a convenience with security conditions

Recognize the three layers of access

A signed-in Google account identifies a member and permits the server to authorize certain cloud requests. A Vault unlock then uses the separately protected Data Encryption Key to decrypt local authenticator items. An optional trusted-device key slot is another way to wrap or unlock that Vault key on an explicitly approved browser. These are related controls, but a Google session, a Vault key, and a device key do not serve the same purpose.

Registering a browser with a member session does not automatically mean that the browser possesses a trusted cryptographic unlock slot. A device may be bound to the account while the Vault still requires a passphrase or recovery key. Keep those independent recovery routes until you have tested the intended device behavior.

Browser non-extractable is not a hardware certification

The trusted-device design uses local browser-managed cryptographic material, with a non-extractable Web Crypto key where its approved profile permits. The API property is useful because application code cannot simply export raw key bytes through the normal export method. It does not establish that the key lives in a secure enclave, that malware cannot ask the browser to use it, or that every supported browser preserves it after updates or storage eviction.

The source requires G06 real-browser evidence and related policy checks before offering the trusted key path. For security-critical accounts, avoid depending on unverified persistence or assuming a local key survives reinstalling the browser. Store the separate recovery key and create an encrypted backup before treating a device as your only authenticator access route.

Understand what revoking a device changes

A member security workflow can request the revocation of a device associated with its account. When confirmed, the server can stop authorizing that device's session or key-slot route, and the local client can lock or clear the corresponding application state. The flow may require a newly verified Google authentication event, and it should distinguish a confirmed server acknowledgement from a later failed metadata refresh.

Revoking a trusted device cannot reach backward in time to erase secrets an attacker already copied, screenshots uploaded elsewhere, or encrypted backup files on a disconnected computer. If the physical device was stolen while unlocked, review and rotate sensitive authenticator enrollments at the original websites. Revocation is one containment action among several.

Sessions and devices are not interchangeable

A session represents an authenticated period of account access. A device record represents a bound browser or device identity, and a trusted-device key slot represents local cryptographic access to the Vault key. Ending another session can require that browser to authenticate again without proving that it has lost every locally cached file. Revoking a device can invalidate its server access path but still cannot delete anything that lives outside the application's reach.

When the member security page shows a current session and other sessions, read which action you are confirming. The implementation distinguishes signing out the current browser, signing out other sessions, and revoking an identified device. Sensitive actions can redirect through a recent Google authentication flow; after that event, the user must deliberately retry the protected action rather than assuming it continued automatically.

Respond to a lost or unfamiliar browser

Start by securing the Google account and its recovery methods. If a member Vault session is available from a device you still trust, review sessions and devices, revoke access paths you no longer recognize, and confirm the server-side result. Also inspect the original services using the TOTP seeds for suspicious activity and rotate any seed that may have been exposed. Keep another verified factor available while making those changes.

If you lack a safe logged-in session, use the Google account's official recovery process and your previously saved Vault backup material as applicable. Do not upload a TOTP setup QR, current code, or recovery key to someone offering to revoke a device remotely. The security and lost-device guides explain the differences among identity recovery, key recovery, and revocation.

Does trusting a device mean its key is stored in hardware?

No. A non-extractable browser key is not necessarily hardware-backed. Actual persistence and behavior require validation on the physical browser.

Will revocation erase a downloaded backup?

No. Revocation blocks future server-authorized access routes; separately downloaded encrypted backup files may still exist.

Does signing out remove the original website's TOTP enrollment?

No. Enrollment is managed by the original website. Revoke or rotate its authenticator factor in that site's security settings.