Protecting high risk users with Advanced Protection
After two failed attempts to grow enrollment in Google's strongest security program, I proposed removing the security key requirement entirely. The proposal went against the program's founding mission, but I built alignment across PM, engineering, and senior leadership to get it approved. While the full redesign was postponed due to resourcing, the core principles became foundational to Google's approach to account security. Google's 2025 passkey-based enrollment validated the thesis: lower the barrier without compromising protection.
Project outcomes
Proposal approved by cross-functional senior leadership: a groundbreaking accomplishment given that it went against the program's initial mission to provide unphishable protection to users.
One-click enrollment drove a 12x increase in enrollments within 2 weeks of launch, surpassing a long-awaited 50k threshold with 60k enrollments in the first month.
Core principles I championed, including flexible enrollment, recovery requirements, and personalized security recommendations, became foundational to how Google approaches account security. The 2025 launch of passkey-based enrollment validated my thesis: lower the barrier without compromising protection.
Advanced Protection is Google's strongest security program, built to protect users at highest risk of targeted attacks: journalists, politicians, and activists, particularly during critical elections.
How does it work?
When signing in
Users were required to use a physical security key to sign in to their account, the strongest form of authentication and the only one proven to be completely resistant to phishing attacks.
While using your account
Additional layers of protection would be applied on the user's behalf, limiting third-party access to your data and blocking most downloads.
An extremely high barrier to entry
The requirement of 2 security keys to enroll in Advanced Protection resulted in a low number of organically enrolled users. To grow the user base, Advanced Protection relied on partnership programs (e.g. Defending Digital Campaigns) to fund and distribute security keys to specific populations.
A History in Advanced Protection's Enrollment
2019 | "Instant" enrollment
The team's first attempt at lowering the barrier to entry was to offer eligible users a 14-day trial of Advanced Protection without a security key, giving users 2 weeks to purchase and set up a physical key.
Seems simple, right?
Wrong. 97% of users dropped out from the 14-day trial, and a very few percent of them actually re-enrolled later with security keys.
This version was deprecated in early 2020.
January 2020 | "One-click" enrollment
In January of 2020, six months after joining the team, I launched the "one-click" enrollment flow, providing users with the ability to enroll with a new phone-based "built-in" security key we simultaneously launched natively on Android and via the redesigned "Smart Lock" app on iOS.
January 2020 | "One-click" enrollment
Enrollments increased by 12x just 2 weeks post launch and we finally surpassed a long awaited 50k enrollment threshold with 60k enrollments 1-month post launch.
However shortly after launch, we found that 72% of our newly enrolled users were getting locked out of their accounts. The phone-based key was easier to set up, but users didn't understand how it worked or how to recover access when something went wrong. We had lowered the barrier to entry without addressing the underlying trust and comprehension gap.
We paused this enrollment flow 3 months later and ultimately, deprecated it.
A revised goal
After two failed attempts, I proposed a controversial new approach: enrollment without a security key requirement. This meant challenging the program's foundational identity. I built the case over months, grounding it in two cycles of failure data and working closely with engineering and PM to ensure the proposal was technically sound before bringing it to senior leadership.
Lower Advanced Protection's high barrier to entry to sustainably increase enrollment rates, allowing Google to protect more users.
A guided enrollment
Working closely with engineers to maintain a high level of security, I proposed a step-by-step, flexible enrollment journey allowing users to leverage non-security key authentication methods like Google Authenticator. We'd also require adding both a recovery email and phone number to relieve lockout concerns.
A win-win scenario
To streamline the onboarding experience, any existing authentication methods (including their recovery email and phone number) would be automatically filled in for the user, allowing them to skip ahead whenever possible.
This design also improved security incrementally. Each step strengthened the user's account, so even if they dropped off before enrolling, their account would still be safer than when they started.
A final review
The last step before turning on Advanced Protection would be a quick review of additional changes to a user's account once enrolled, such as limiting account access on untrusted apps, and signing users out of some devices that haven't had any recent activity for security purposes.
Clear confirmation and navigation to program settings
Once enrolled, users land on a new Advanced Protection settings page to review the program's benefits and manage their enrollment. A branded progress indicator, inspired by the program's new logo, reinforced a cohesive security narrative throughout the experience.
Leveraging existing security tools to further improve a user's security
Without a security key requirement, we'd personalize the experience by recommending keys to users who didn't enroll with one, and leverage Security Checkup to recommend enrollment to users identified as higher risk.
Meet users where they are when encouraging adoption of powerful but intimidating technology.
The enrollment experience assumed users already understood why they needed it and how to set it up. The security key requirement was the program's strongest feature and its biggest barrier. The lesson: the more powerful the technology, the more the design has to close the gap between what it can do and what users believe they can do with it.
Challenging a program's foundational assumption is a design contribution, not just a proposal.
Proposing that Advanced Protection drop its security key requirement meant arguing the program's core identity needed to evolve to fulfill its mission. Getting alignment required building trust with engineering and PM over months, grounding the argument in two cycles of failure data, and framing the change as an expansion of the mission rather than a retreat.