2FA Apps Do Not Need Google to Be Trusted

A FLOSS authenticator can work across services because TOTP is a shared-secret standard, not because Google, Microsoft, or Proton approves each code.

2026-06-06 GIGATAP Team #tools
#2FA#F-Droid#TOTP

2FA Apps Do Not Need Google to Be Trusted

A user on the F-Droid forum asked a simple but important question: if a workplace login uses a Google account and a second device to confirm access, how can a free and open-source 2FA app work for Proton or other services without Google, Microsoft, or another large platform sitting in the middle?

The short answer: many 2FA apps are not acting as a trusted company at all. They are just calculating short-lived codes from a secret that the service and the app already share.

That distinction matters. It changes what you are trusting, what can fail, and what you need to back up.

What is known from the source#

The forum post is not a vulnerability report. It is a user trying to understand the trust model behind 2FA, especially in the F-Droid ecosystem.

The user describes a workplace setup where a Google account and another device act as the second factor. Their mental model is that Google verifies the PIN or confirmation and tells the service that the login is valid. That model is accurate for some account-based push or platform-mediated flows.

The user then asks how FLOSS 2FA apps work if they are not associated with Google, Microsoft, or another large provider. They are considering stronger security for a Proton account and mention Proton’s own 2FA app available through F-Droid, while preferring an app that can work across multiple services if possible.

That is the useful hinge: not all 2FA is the same. Some systems involve a remote provider. Some are local code generators. Some use cryptographic hardware or passkeys. They are all called “2FA” in everyday speech, but the trust model is different.

The common case: TOTP is local#

Most general-purpose authenticator apps use TOTP: Time-Based One-Time Passwords. This is the six-digit code model many people know from Google Authenticator, Aegis, FreeOTP, and similar apps.

In a TOTP setup, the service gives you a secret during enrollment. Usually it appears as a QR code. Your authenticator app stores that secret. Later, when you log in, the app combines that secret with the current time and calculates a short code. The service performs the same calculation on its side. If the numbers match within the allowed time window, the login proceeds.

No Google approval is required for that calculation. No Microsoft approval is required. The authenticator app does not phone a central authority to ask whether the code is valid. It does not need to be “trusted” by Proton or another service in the same way a federated identity provider is trusted.

The service trusts the code because the code proves possession of the shared secret.

That also explains why a generic authenticator can work across many services. The app is not integrated with each service in a deep way. It is implementing a standard. The service only needs to support TOTP enrollment and verification.

What the app is still trusted with#

This does not mean the app is irrelevant. It means the trust is local and narrower.

A TOTP app is trusted to store the secret safely, display the correct code, and not leak the secret. If the app is malicious, compromised, or backed up insecurely, the second factor can be weakened. If the phone is lost and there is no backup, the user can be locked out.

That is why app choice still matters.

For F-Droid users, the appeal is clear. F-Droid builds packages from source through its own pipeline, which gives users more confidence that the APK corresponds to auditable code than a random release asset uploaded elsewhere. That does not make every app perfect. It does make the software supply chain more legible.

A good authenticator choice usually comes down to a few properties:

  • local encrypted storage for 2FA secrets
  • clear export and backup controls
  • no unnecessary network dependency
  • active maintenance
  • understandable recovery behavior
  • support for the services you actually use

The best app is not automatically the one made by the service you are logging into. A service-specific app may be convenient. A general authenticator may reduce app sprawl and work across Proton, Git hosting, password managers, cloud accounts, and other services. The tradeoff is that one authenticator can become a high-value vault, so backup and device security matter more.

Push approval and TOTP are different models#

The user’s workplace example sounds closer to a platform-mediated or push-style flow. In that model, a device receives a prompt, a PIN, or an approval request. The provider may be deeply involved in validating the login session. The second factor may be tied to account state, device registration, mobile push infrastructure, or an identity provider.

That can be useful. It can also create a different dependency: if the provider, account, push channel, or managed device flow breaks, the authentication path can break too.

TOTP is more boring. That is part of its value. Once enrolled, it can work offline because the app only needs the stored secret and the current time. The server does not need to contact the app. The app does not need to contact the server. The code is just proof that both sides still know the same secret.

The downside is also clear. TOTP codes can be phished. If a user types a password and a current TOTP code into a fake login page, an attacker may be able to relay them quickly. TOTP is better than password-only login, but it is not the strongest available option against real-time phishing.

What not to overclaim#

It would be wrong to turn this forum question into a claim that one Proton app, one F-Droid app, or one 2FA method is categorically safe or unsafe. The source does not provide an audit, incident report, or comparison table.

It would also be wrong to say that FLOSS automatically solves 2FA trust. Open source helps inspection and reproducibility. It does not remove the need for secure storage, good defaults, maintenance, and careful recovery planning.

The practical claim is smaller and stronger: a FLOSS authenticator can work with many services because TOTP is a standard shared-secret mechanism, not because the app has a special trust relationship with Google, Microsoft, Proton, or anyone else.

What users should check next#

If you are enabling 2FA for Proton or any other important account, start with the account’s own security settings. Confirm which second-factor types it supports. Look for TOTP, security keys, passkeys, recovery codes, and backup options.

Then decide how much risk you want to remove.

For many users, TOTP in a maintained authenticator app is a major improvement over password-only login. Store recovery codes somewhere separate from the phone. Test that you can restore access before you depend on it. Do not keep the only copy of your 2FA secrets on a single device with no backup.

For higher-risk accounts, consider phishing-resistant options where supported, such as hardware security keys or passkeys. These change the trust model again: instead of typing a reusable short code into a page, the authenticator binds the login to the real site. That can reduce the damage from convincing fake login pages.

The clean mental model is this:

  • Password-only login proves you know a password.
  • TOTP proves you know the password and possess a stored secret.
  • Push approval proves access to a registered device or provider-mediated flow.
  • Security keys and passkeys can add phishing resistance when implemented correctly.

For the original question, the key point is that a 2FA app from F-Droid does not need to be blessed by a big platform to generate valid codes. The service and the app share a secret. The app calculates. The service checks. The hard part is not corporate trust. It is protecting the secret, keeping a recovery path, and choosing the right second factor for the risk.