Google Selfie Video Sign-In Privacy: What Data It Stores

Google confirmed in a blog post yesterday that it encrypts and stores a user's enrolled selfie video on its own servers, not just on the device used to record it (Google Security Blog, yesterday). That server-side storage is intentional. Google says the entire premise of selfie video sign-in is helping people recover accounts after losing the device that holds their passkeys, so the reference video has to be reachable from somewhere other than one phone.

The feature itself isn't new. Google rolled out selfie video sign-in three months ago as an added way to verify identity and recover locked accounts (Google product blog, 3 months ago). What's new is Google spelling out, in far more detail than before, exactly what it keeps, what it deletes automatically, and which settings let someone limit or skip the whole thing. Anyone who has already enrolled, or is weighing whether to, now has a clearer picture of whether the convenience is worth handing Google a reference video of their face.

How Google selfie video sign-in works and what stays on its servers

Google states plainly that once enrollment is verified, it encrypts the reference video and stores it on its servers rather than keeping it solely on the device where it was recorded (Google Security Blog, yesterday). The company frames this as unavoidable given what the feature is supposed to do: if the video lived only on one phone, it couldn't help someone who lost that phone.

Google draws a sharp line between that and the facial recognition used to unlock a device, which it says stays strictly local and never reaches Google's servers at all (Google Security Blog, yesterday). Those are two different systems with two different storage models, even though both involve scanning a face.

Worth remembering: Ars Technica's coverage of the July launch described how enrollment and matching are supposed to work, based on Google's own account of the process (Ars Technica, 3 months ago). Neither that reporting nor yesterday's blog post reflects independent testing of how Google actually stores or matches the video. Everything here, including the newest disclosures, comes from Google describing its own system.

What Google deletes, keeps, and still hasn't clarified

Two videos exist in this system, and they have different fates. The enrolled reference video is retained on Google's servers, while the fresh video recorded during an actual sign-in attempt is transient and gets permanently deleted immediately after face-matching finishes, according to Google (Google Security Blog, yesterday).

Users can delete the stored reference video at any time from account settings without affecting the rest of their Google Account, though Google requires re-authentication first as a safeguard against someone else making that change (Google Security Blog, yesterday). Closing a Google Account entirely also removes the selfie video from Google's servers, the company says. Google does not specify how quickly backup copies or internal logs are purged after either kind of deletion, so treat "deleted" as "no longer accessible to you," not necessarily "gone instantly everywhere."

There's a real gap between what Google says now and what was reported when the feature launched. Google's current position is that an enrolled video is used solely to confirm sign-in identity, unless someone separately opts in to let it improve Google's verification technology (Google Security Blog, yesterday). But Ars Technica reported at launch that selfie videos could also support age verification and AI avatar features (Ars Technica, 3 months ago). Google hasn't addressed that discrepancy directly, and nothing in the available reporting confirms whether those are separate recordings, shelved plans, or the same stored video repurposed for other uses. Until Google clarifies it, treat that broader scope as unresolved.

Google Account selfie video verification: setup, signals, and who's excluded

Setting up selfie video requires an existing trusted, signed-in session. Users complete guided head movements from multiple angles to build the reference recording, and Google confirms this step can't happen without that prior trusted session already in place (Google Security Blog, yesterday).

Matching a face isn't a standalone login event. Google says its sign-in risk-assessment engine weighs the face match alongside other contextual signals and can demand extra verification for sessions that look anomalous (Google Security Blog, yesterday). On the anti-spoofing side, Google describes liveness models that check for subtle physical movement and visual artifacts, synthetic-media detection meant to catch AI-generated video, and hardware-backed integrity checks on supported devices that confirm footage came from a physical camera rather than an injected file (Google Security Blog, yesterday). Those are Google's stated defenses, not independently verified results.

Some accounts can't use this at all. Workspace accounts, child accounts, and anyone enrolled in Google's Advanced Protection Program are excluded from setting up selfie sign-in (Ars Technica, 3 months ago). Availability also isn't universal even among eligible account types. Google says it's still expanding the feature globally and tells users to check their own account rather than assume access, since the rollout is staged (Google Security Blog, yesterday; Google product blog).

Checking eligibility and managing Google selfie video account recovery

Checking whether an account qualifies takes a minute. Open Google Account settings, go to Security & sign-in, and look for the Selfie video option, or go straight to g.co/signin-selfie to see eligibility and start setup (Malwarebytes, 3 months ago; Google product blog).

Enrollment and the data-sharing toggle are two separate decisions. Selfie video sits alongside passkeys, recovery contacts, phones, and email as one sign-in option among several, and a Google spokesperson told Ars Technica that leaving the "improve verification" checkbox unchecked during setup keeps the video limited to sign-in use only (Google Security Blog, yesterday; Ars Technica, 3 months ago). That checkbox is optional and distinct from enrollment itself, though Google hasn't stated what it defaults to.

Google also sends real-time alerts whenever a selfie video is enrolled, used for a new sign-in, or removed (Google Security Blog, yesterday). Anyone who gets one of those alerts unexpectedly should go straight to their Google Account's security activity and recovery settings to check for unauthorized changes.

For readers who'd rather not store biometric video with Google at all, the alternative stack is familiar: passkeys, which Google recommends for all users, two-step verification using a hardware security key instead of SMS codes, a current recovery phone and email, backup codes saved offline, and a unique password managed through a password manager (Google Security Blog, yesterday; Malwarebytes, 3 months ago). None of that requires handing Google a video of your face.

Whether selfie video sign-in is worth enabling comes down to one trade: cross-device account recovery against an encrypted copy of your face sitting on Google's servers. Check eligibility at g.co/signin-selfie before assuming it's an option, since the rollout is still staged. If the recovery benefit doesn't outweigh that storage trade-off, passkeys, two-step verification, up-to-date recovery contacts, and offline backup codes cover the same ground without it.