FreeOTP+ Review 2026: Local Android 2FA and Backup Limits

FreeOTP+ is a free, open-source Android authenticator for TOTP and HOTP codes. It is a community-maintained fork of Red Hat’s FreeOTP, with search, categories, biometric or PIN access control, and manual export and import through Android document providers.

Correction published August 30, 2026: The previous edition described FreeOTP+ as eliminating all cloud connectivity, made an unsupported absolute privacy claim, called its exports encrypted, assigned a numerical score, and used generated images as if they showed the product interface. This edition removes those claims and images. It distinguishes local code generation from Android network permission, app access control from vault encryption, and portable backup files from protected backups.

Short verdict: FreeOTP+ is a reasonable Android-only choice for users who want an open-source, accountless authenticator and are prepared to manage backups themselves. Its current export paths are portable but expose reusable OTP secrets unless the resulting file is protected separately. F-Droid also carries a restore warning, so a backup is not complete until it has been tested on another device. Users who need a documented encrypted vault, built-in cross-platform sync, or phishing-resistant authentication should choose a different tool or method.

What FreeOTP+ is in 2026

The official project repository describes FreeOTP+ as an enhanced fork of FreeOTP-Android. It implements the standard time-based and counter-based one-time-password workflows used by many websites. There is no FreeOTP+ account and no proprietary server component required to generate codes.

The current public release is version 3.4. F-Droid added its reproducible build on June 2, 2026, while Google Play lists a May 31, 2026 update. The repository remains active, so this page still deserves indexable standalone coverage rather than archival or removal.

FreeOTP+ is Android-only. The current build configuration sets a minimum SDK of 23, which corresponds to Android 6.0, even though the repository README still has a broader Android 5.0+ statement. For the current 3.4 release, Android 6.0 or newer is the safer requirement to use.

This review is based on official listings and source inspection. It is not a penetration test, independent telemetry audit, or hands-on comparison, and it does not assign a numerical rating.

Local code generation does not mean no network capability

Once a TOTP token is enrolled, the app can calculate codes on the phone from the shared secret and current time. HOTP similarly uses a shared secret and counter. That local calculation does not require a FreeOTP+ cloud account or a network request for every code.

It would still be inaccurate to call the app network-incapable. The current Android manifest declares the INTERNET permission, and the F-Droid listing describes full network access. The project also supports choosing Google Drive or another Android document provider as the destination for import and export. A provider can move the selected file through its own service.

Google Play says the developer declares that the app collects no data and shares no data with third parties. That is a developer-supplied Data safety declaration, not an independent traffic analysis. The defensible conclusion is narrower: FreeOTP+ has no required product account and generates OTP codes locally, but it has network permission and can interact with network-backed document providers. Users with strict network policies should verify behavior on their own managed device rather than rely on an absolute marketing claim.

Enrollment and daily token management

FreeOTP+ supports QR-code scanning and manual entry. The official listings identify HOTP under RFC 4226 and TOTP under RFC 6238. The repository also documents issuer and label handling, token search, categories, filtering, dark theme support, and a modernized camera path.

Those management features matter when an authenticator holds dozens of accounts. Categories can separate personal, work, infrastructure, and financial tokens. Search helps locate a code without exposing a long, continuously scrolling inventory. Token details improve interoperability when a service uses an unusual digit count, algorithm, or period.

The shared secret shown in a QR code is the durable credential from which future OTPs are produced. Treat a screenshot, copied URI, manually written seed, and exported token as sensitive authentication material. Delete temporary QR images after enrollment, avoid scanning codes while screen sharing, and verify a signed-out login before discarding the service’s recovery information.

For high-value accounts, store the website’s one-time recovery codes separately from both the phone and any FreeOTP+ backup. Recovery codes solve a different problem: regaining the service account when the authenticator or its backup is unavailable.

App lock is not encrypted vault storage

The project supports requiring biometric or PIN authentication when the app opens. This is useful against casual access to an unlocked phone and should be enabled alongside a strong Android screen lock, current operating-system updates, and device encryption.

The feature should not be described as proof of an encrypted FreeOTP+ vault. In the current token data model, the OTP secret is a string. The project’s encryption-type definition contains only PLAIN_TEXT. Source searches do not show a project-level encrypted database or a user-created vault password protecting stored tokens.

Android’s own device and app-data protections still matter, but they are not the same as an authenticator implementing a separately encrypted vault. The biometric or PIN prompt also controls access through the normal interface; it is not evidence that every secret is cryptographically inaccessible on a compromised, rooted, or forensically extracted device.

Users who specifically require an app-level encrypted Android vault should compare Aegis. FreeOTP+’s strengths are openness, local operation, and portability, not a documented independent vault-encryption layer.

JSON exports are portable but not password-encrypted

FreeOTP+ can write a JSON backup through Android’s document picker. The current import and export implementation loads all tokens, serializes them with Gson, and writes the resulting JSON bytes directly to the selected output stream. There is no password prompt, encryption step, or authenticated cipher in that path.

The repository’s import notes say each JSON token needs a secret represented as a list of integer values. Those values encode the reusable OTP seed. Anyone who can read a valid backup can import or reconstruct the same token and generate matching codes.

Choosing Google Drive does not turn the file into a FreeOTP+-encrypted backup. It asks Android to hand the file to the selected document provider. Transport encryption and account security at the provider are separate from client-side encryption of the backup itself.

Protect a JSON export before long-term storage. Put it inside a well-established encrypted container or password-manager attachment, use a unique strong password, and keep that password outside the backup location. Do not email the raw file, leave it in Downloads, or store it beside a plain-text note containing the decryption password.

URI exports expose the same reusable secrets

The second export path writes one otpauth:// URI per line to a text file. The implementation converts every token to a URI and writes those lines directly. Each URI contains the token secret plus settings such as issuer, algorithm, digit count, period, or HOTP counter.

This format is convenient for interoperability because many authenticator tools understand the standard URI. It is also highly sensitive. Opening the text in an editor, cloud preview, indexing service, or support ticket can reveal enough information to clone every exported token.

Use a URI export only for a controlled migration or as input to an encrypted archival process. Transfer it directly to a trusted destination, import it, verify several accounts, then securely remove temporary copies from source and destination devices. Remember that ordinary deletion may not remove historical cloud versions or backups.

Neither JSON nor URI export revokes the old credential. If an export may have leaked, rotate 2FA at each protected website by disabling the old registration and enrolling a newly issued secret. Simply deleting the file or uninstalling FreeOTP+ does not invalidate seeds already copied elsewhere.

A restore warning changes the backup plan

The current F-Droid release note includes an unusually direct warning: users have reported problems with backup and restore, and should test the function when installing on a new device. That warning should be treated as operational guidance, not dismissed because an export command reports success.

A sound migration sequence is:

1. Export from the old device to a controlled location.
2. Protect the export separately before placing it in long-term storage.
3. Import it on the replacement device while the old phone still works.
4. Compare the issuer and account labels and verify codes for several services.
5. Complete signed-out logins for email, password managers, domain registrars, financial accounts, and cloud consoles.
6. Confirm HOTP counters if any HOTP tokens are used.
7. Keep the old device and recovery codes until every critical account is proven.

Repeat the exercise after major app, Android, or storage-provider changes. A file that existed six months ago is not automatically a viable recovery system today.

Android system backup is a separate recovery path

The manifest enables Android application backup, and Google Play says Android backup can restore saved authenticators after reinstallation. This is a platform-managed path, distinct from FreeOTP+’s manual JSON and URI exports.

Platform backup availability varies with Android version, device vendor, account settings, transfer method, and whether the operating system included the app data. It also gives less visible control than a manually inspected export. Do not assume a new phone will recover tokens merely because both devices use the same Google account.

Use Android backup as an additional convenience, not the only recovery plan. Keep a separately protected manual export, retain website recovery codes, and test the replacement before wiping the original phone. If the platform restore works, verify the resulting tokens anyway; successful app installation does not prove that every secret and HOTP counter arrived correctly.

For an organization, document who owns the backup account, where protected exports are held, how access is audited, and how credentials are rotated when someone leaves. FreeOTP+ is primarily a personal authenticator and does not provide a central administrative recovery console.

How FreeOTP+ compares with other recovery models

Authenticator choice is mostly a choice about platforms, backup custody, and exit options.

2FAS is easier when a password-protected portable export is wanted. Ente Auth and Proton Authenticator suit users needing supported desktop access and optional encrypted sync. FreeOTP+ is most compelling when Android-only, accountless operation and open source are the priorities, and the user is comfortable wrapping backups in a separate protection layer.

TOTP remains vulnerable to real-time phishing

FreeOTP+ generates standard OTPs. Local storage, open source, and careful backups can reduce some custody and recovery risks, but they do not bind a manually entered code to the legitimate website.

NIST’s current authenticator guidance says manually entered OTP authenticators are not phishing-resistant. A fake login page can collect the password and a fresh code, relay both to the real service before the code expires, and establish its own session.

Use TOTP when it is the strongest option a service supports or when it materially improves on password-only access. For email, password managers, administrative consoles, financial accounts, and domain registrars, prefer passkeys or FIDO2/WebAuthn security keys when available. Those methods can verify the requesting website rather than relying on the user to inspect a domain and transcribe a code.

Never provide a current OTP to a caller or support agent. Open the service directly, verify the domain, and treat unexpected login, recovery, or new-device prompts as a reason to change the password and review active sessions.

Who should use FreeOTP+

FreeOTP+ fits an Android user who wants no authenticator account, values inspectable open-source code, needs standard TOTP and HOTP, and is willing to own backup encryption and restore testing. Search, categories, and app-entry authentication make it more usable than a minimal token list.

It is a weaker fit when iPhone, desktop, or web access is required; when automatic encrypted synchronization is a requirement; when a separately encrypted application vault is mandatory; or when backup operations must be centrally managed and audited. It is also not the right answer to phishing resistance because the underlying OTP workflow remains manually transferable.

Existing users do not need to abandon a working setup solely because its recovery model is manual. The immediate priority is to create a current export, protect it, test it on another Android device, and preserve service recovery codes. New users should decide whether that ongoing discipline is realistic before enrolling high-value accounts.

The source-verified 2FA authenticator comparison places FreeOTP+ beside accountless, sync-enabled, cross-platform, and phishing-resistant options without reducing the decision to one score.

FreeOTP+ setup and recovery checklist

1. Install FreeOTP+ from Google Play, F-Droid, or another source you can verify.
2. Confirm the installed package and current version before importing secrets.
3. Enable a strong Android screen lock and keep device encryption active.
4. Enable FreeOTP+’s biometric or PIN launch requirement.
5. Enroll one low-risk account and complete a signed-out login.
6. Save that service’s recovery codes outside the phone.
7. Organize tokens with clear issuer, account, and category labels.
8. Create both a controlled migration export and a separately protected archival copy.
9. Encrypt the export before cloud upload or long-term storage.
10. Test import on another device while the original still works.
11. Verify several TOTP codes and any HOTP counters.
12. Remove unprotected temporary JSON, URI, QR, and text files.
13. Repeat the restore test after major app or Android changes.
14. Rotate every affected service if an export may have been exposed.
15. Prefer passkeys or hardware security keys where phishing resistance matters.

FreeOTP+ verdict

FreeOTP+ is actively maintained, open source, accountless, and capable of handling standard Android TOTP and HOTP workflows. Its search, categories, dark theme, and biometric or PIN entry control make it practical for a sizeable local token list.

Its backup story needs more care than the old review suggested. Current JSON and URI exports contain reusable secrets without a project-level password-encryption step. F-Droid warns users to test backup and restore, and the app’s source does not document a separately encrypted local vault. Network permission also makes an absolute offline-only or no-network claim inappropriate.

The app remains a defensible choice for an Android user who accepts those boundaries and builds a tested, externally encrypted recovery process. Users who want native encrypted exports, built-in cross-platform sync, or an encrypted application vault have clearer alternatives. For the most sensitive accounts, move beyond TOTP to passkeys or FIDO2 security keys whenever the service supports them.

Frequently asked questions

Is FreeOTP+ still maintained?

Yes. Version 3.4 reached Google Play and F-Droid in 2026, and the official repository continues to receive changes.

Does FreeOTP+ require an account?

No FreeOTP+ product account is required to enroll tokens or generate codes. A chosen document provider may require its own account when storing exports.

Are FreeOTP+ backups encrypted?

The current manual JSON and URI export implementations do not add password encryption. Protect exported files separately before storing or transferring them.

Does FreeOTP+ work without internet access?

Enrolled TOTP and HOTP codes are generated locally, but the Android app declares network permission and can use network-backed document providers. It should not be described as network-incapable.

Is the biometric or PIN lock an encrypted vault?

No. It restricts normal app access, but the current source does not document a separately encrypted token vault.

Is FreeOTP+ phishing-resistant?

No. Standard manually entered OTPs can be relayed by a phishing site. Prefer passkeys or FIDO2 security keys when available.