Proton is telling users to rethink one of the web’s most convenient habits: clicking “Sign in with Google” everywhere.

In a new social-media security advisory, Proton argues that using one Google identity across dozens of websites creates two problems at once: it concentrates authentication risk in one account, and it creates a centralized record of which third-party services are connected to that identity.

Its recommended alternative is straightforward: create accounts with unique email aliases, use separate credentials or passkeys for each service, and regularly review the apps tied to your Google Account.

Proton’s First Point: One Login Can Become a Single Point of Failure

The security logic is real, but it needs one important qualification. If an attacker gains control of a Google Account, that attacker may also be able to authenticate to third-party services that rely on that Google identity—especially services where Google is the only sign-in method and no additional verification is required.

That does not mean every account connected through Google is automatically compromised the instant the Google Account is breached. Individual services can have their own session controls, recovery rules, risk checks, passkeys or additional authentication. But the architecture still concentrates risk: compromise of one identity provider can create access opportunities across many relying services.

This is the same reason security engineers generally prefer compartmentalization. One credential should not unlock everything. BitcoinVersus.Tech recently explained how passkeys reduce phishing risk by using cryptographic credentials tied to individual services rather than reusable passwords.

Proton’s Second Point: Your Google Account Knows Which Services Are Connected

Google maintains a connections page that shows third-party apps and services associated with a Google Account. That includes services using Sign in with Google as well as apps granted access to specific Google data.

Proton frames that centralized connection history as another privacy cost: the identity provider sits between a person and many of the services they use. Google, however, explicitly says that information and activity from Sign in with Google itself are not used for advertising or other Google products. Those two claims are not necessarily contradictory: Google can maintain the connection needed to operate the sign-in service while saying it does not use that sign-in activity for ads.

Google’s own documentation says users are shown what data will be shared with a third-party app, that Google does not share the Google Account password with that app, and that users can revoke the connection at any time through account settings. Google’s Sign in with Google privacy explanation provides the company’s side of that tradeoff.

The Better Security Model: Separate the Email Address From the Identity You Expose Everywhere

Proton’s preferred model is to create a different email alias for each service. The alias forwards mail to a real inbox, but the website never receives the primary email address.

That creates useful compartmentalization. If a shopping site leaks its customer database, the attacker gets the alias used for that store rather than the primary address used everywhere else. If that alias starts receiving spam or phishing attempts, it can be disabled without changing the main mailbox.

Proton’s Hide-my-email documentation says its aliases forward messages to the user’s mailbox while keeping the primary address hidden. Proton Pass can also generate a unique password for the account at the same time.

Aliases Help—but They Are Not Magic

An alias prevents one identifier from being reused everywhere, but it does not make a person anonymous. Websites can still correlate accounts through phone numbers, payment cards, device fingerprints, IP addresses, cookies, browser telemetry and other identifiers.

Aliases also do not replace strong authentication. If every alias account uses the same weak password, the user has simply replaced one repeated email address with many addresses while preserving the credential-reuse problem.

The stronger setup is unique alias + unique password or passkey + multifactor authentication. That reduces the blast radius when one service is breached and makes credential stuffing much harder.

Introducing advanced alias management in Proton Pass
byu/Proton_Team inProtonPass

How to See Every Service Connected to Your Google Account

Proton’s cleanup advice is easy to verify using Google’s own account controls:

1. Open myaccount.google.com/connections.
2. Or open your Google Account and go to Security → Your connections to third-party apps & services → See all connections.
3. Filter for Sign in with Google if you only want to see sites that use Google as the identity provider.
4. Select a service you no longer want linked.
5. Choose Stop using Sign in with Google or the available remove/delete connection option.

Revoking the Google connection does not necessarily delete the account at the third-party service, and it does not retroactively delete data that service already received. If you still want to use the account, make sure you have another login method before disconnecting Google.

Do Not Disconnect First and Ask Questions Later

This is the biggest practical trap in Proton’s advice. Some people created an account entirely through Google SSO and never set a standalone password. If they revoke Google access before adding another sign-in method, they can make account recovery unnecessarily difficult.

A safer migration sequence is: sign into the third-party service, add a password or passkey if the site supports one, verify the recovery email and MFA settings, test the independent login, and then remove the Google connection.

The Best Version of Proton’s Advice

The strongest takeaway is not “Google sign-in is insecure.” Google’s OAuth and Sign in with Google systems are designed specifically to avoid handing third-party sites a user’s Google password, and centralized identity can make phishing-resistant authentication easier to deploy.

The better takeaway is: convenience creates concentration. The more services that depend on one identity provider, the more important that account becomes and the larger the consequences if it is lost, locked, phished or compromised.

People who want maximum compartmentalization should avoid making any single Google, Apple, Microsoft, Facebook or other identity account the universal key to their digital life. Unique aliases and independent credentials trade some convenience for a smaller blast radius.

A Practical Security Checklist

• Review your Google third-party connections at least a few times per year.
• Remove services you no longer use.
• Before removing Google SSO, create and test another login method.
• Use a unique email alias for services where compartmentalization matters.
• Use unique passwords or passkeys rather than recycling credentials.
• Turn on multifactor authentication for your primary email and identity-provider accounts.
• Protect recovery email addresses and recovery phone numbers as carefully as the main account.

Bottom Line

Proton’s warning is deliberately provocative, but the security principle underneath it is sound: do not let one account become an unnecessary master key for your entire online identity.

Sign in with Google can be secure and convenient. Email aliases can provide stronger compartmentalization. For users who care most about minimizing the blast radius of a breach, the best architecture is usually a combination of aliases, independent credentials, passkeys, MFA and regular audits of every connected service.

Editor’s Note

This story distinguishes Proton’s privacy and security recommendations from Google’s documented behavior for Sign in with Google. A connected Google account is not proof that every third-party account is compromised, and revoking a connection does not erase data already held by the third-party service.

BitcoinVersus.Tech is independently maintained. Support options on the site help fund additional security research, verification and open technical publishing.

BitcoinVersus.tech is not a financial advisor. Content is provided for informational purposes.