Somewhere this week a 22-year-old is going to rename [email protected] to something professional. Google will let them. The press will write a tutorial. Forty SaaS products that person signed up for with "Sign in with Google" will quietly lose track of who they are.
Google shipped Gmail address renaming on 31 March 2026. Sundar Pichai posted about it on X. The coverage was wall-to-wall how-to guides. Nobody asked the only question that matters. Who pays when this breaks things?
The assumption Google just broke
For twenty years email addresses were permanent. Not by design. By accident. You simply couldn't change them. So everything built on that. CRMs. SSO directories. Audit logs. OAuth logins. Stripe records. E-discovery exports. Identity graphs. All of it quietly assuming the string before the @ would be the same string tomorrow.
That assumption is now wrong. Google provided no safety net. No webhook. No SCIM event. No "this user was formerly known as" token claim. Salesforce won't know. Slack won't know. Your company's Relativity instance definitely won't know. You'll find out eighteen months from now when a litigation hold turns out to have missed half the relevant correspondence.
It's not your employees you should worry about
The natural first reaction: "We use Google Workspace on our own domain. Our people can't rename through this feature. Why should I care?"
You're right. About your employees. The consumer Gmail rename doesn't touch managed @company.com accounts. The bill doesn't land because your employees renamed. It lands because your customers did.
Your OAuth logins. Offer "Sign in with Google"? Your users authenticate with personal @gmail.com accounts. When they rename your user table fractures. Phantom accounts appear. This one you can fix in code.
Shadow SaaS. Employees sign up for Notion, Figma, ChatGPT with personal Gmail. Outside SSO. Rename fragments those accounts. Your org's data is now tied to an identity you can't trace.
Your CRM. Every Salesforce contact and Zendesk ticket keyed on a prospect's email goes stale the moment they rename. No signal. Just silent data rot.
Contractors. Onboarded via personal Gmail into Slack, Jira, shared Drives. Rename forks their permissions and audit trail overnight.
Four problems. One root cause. The first one is a code fix. The rest are reasons you should care about it.
Google told you this would happen
In a developer blog post that almost no working engineer will ever read, Google wrote this:
"If an OAuth grant was revoked by the user, Google will provide the new email address instead on subsequent sign in. This may cause your platform to fail to recognize the user, potentially resulting in duplicate accounts and loss of access to existing data."
Read that again. Google is telling you in their own docs that this feature creates duplicate accounts and loses data. They shipped it anyway. Vanity addresses help them compete with Outlook and iCloud. The phantom-user tickets land on your support queue, not theirs.
That's not an oversight. That's an externality.
The "fix" that doesn't quite work
Google's advice: don't key on email. Key on the immutable sub claim. The OIDC Subject ID. It never changes.
Except it does. In January 2025 Truffle Security's Dylan Ayrey showed that the sub claim drifts in about 0.04% of Google sign-ins. Google closed it as "Won't fix." Then reopened it. Paid a $1,337 bounty. Promised a fix that hasn't visibly shipped.
0.04% sounds tiny. At 1.8 billion Gmail users that's hundreds of thousands of identity drift events daily. Before the rename feature turned a random glitch into something any user can trigger on purpose.
"Use sub" is the right advice. It's just not the complete advice. The whole identity layer leaks at both seams.
"But the old address still works"
Fair point. Google keeps the old email as a permanent alias. Mail delivers. OAuth tokens that haven't been revoked still return the old address. The break only fires on revoke, expiry, fresh sign-in to a new app. Most users won't hit that trigger.
But latent failures are more expensive than immediate ones. The break won't surface on rename day. It'll surface months later in an audit. A deposition. A support ticket. Nobody remembers the rename. Nobody connects the two accounts that used to be the same person. The alias buys time. It doesn't buy safety.
We checked. It's everywhere.
We scanned Sourcegraph's public index. 2M+ open-source repositories. Looking for Google OAuth handlers that use email as an identity key.
124 repositories across Passport.js, NextAuth, Django/Flask, Ruby OmniAuth. Some with tens of thousands of GitHub stars. Well-maintained, widely deployed codebases. This isn't a niche mistake. Keying on email was the correct pattern until Google changed the rules twelve days ago.
The common anti-pattern: look up users by Google ID first, fall back to email when the ID isn't found. After a rename plus token revocation the fallback fires and creates a duplicate. Exactly the cascade Google's own docs warn about. Sitting in production. Waiting for a trigger.
The recursive irony: Sourcegraph themselves match OAuth identities by email. The tool we used to find the pattern has the pattern.
The OAuth vector is a code problem with a code fix. authdrift scans your codebase for OAuth handlers keying on email instead of sub. Open-source. Read-only. Runs in CI:
pip install authdrift && authdrift scan ./Three things breaking in silence
E-discovery holds. Relativity, Logikcull, Disco. They all identify custodians by email. A litigation hold issued before a rename and executed after will silently miss messages to the new address. No major e-discovery vendor has published a Gmail rename advisory. The first time anyone notices will be in a deposition.
GPG commit signatures. Developers who sign commits with keys tied to their old email lose verified status on new commits. In regulated fintech that's a failed audit. Nobody will connect it to a Gmail rename that happened months earlier.
Same person, two accounts. After rename, signing in with the old vs new address can create two separate user records in the same app. Silent identity fan-out. Depends entirely on which sign-in flow the user hits that day.
What to do about it
If you run a SaaS product:
- Check if your user table keys on
suboremail. If email, you have a P1. Runauthdrift scan. - Decide what happens when an OAuth token returns an email you've never seen. Most apps create a new user. That's the bug.
- Subscribe to Google's OpenID Connect changelog. Not the Gmail blog.
If you run IT on Google Workspace:
- Don't assume Vault custodian holds follow the new address. Test it.
- Audit your SaaS estate for email-keyed apps. Document the rename behaviour for each.
- Talk to your e-discovery counsel now. Not after a filing.
If you're Google:
- Ship the immutable user-ID claims Truffle Security asked for in January 2025.
- Publish a rename webhook. Even a polling endpoint. Anything.
- Put the duplicate-account warning in the user-facing rename flow. Not buried in a dev blog.
Jake Moore at ESET put it well: "An email address used to be permanent but now it's finally editable like a username, which is a huge shift in how identity works online."
He's right. The second half of that sentence is the part Google is asking the rest of the internet to absorb without compensation. Google keeps the user. Everyone else gets the cleanup bill. That's what externalised cost looks like in software. Not a memo. A feature launch and twenty-two years of muscle memory quietly snapping across millions of systems at once.
The fix isn't technical. The fix is for someone to call the externality by its name, in public, while there's still time to demand the webhook.