Ente Auth is a free, open-source authenticator with two distinct operating models. Account mode synchronizes encrypted codes across Android, iOS, web, Windows, macOS, and Linux. Offline mode works without an Ente account and keeps codes on one device, with encrypted exports or local backups providing the recovery path.
Correction published August 30, 2026: The previous edition presented unsupported first-person testing conclusions, used generated product-interface images, incorrectly required continuous connectivity, and showed an invented recovery screen with the wrong key length. It also blurred account sync, offline storage, local backup, app lock, and encrypted export into one security claim. This edition removes those claims and images, documents the two operating modes separately, and links platform, encryption, export, backup, and recovery statements to Ente’s current documentation.
Short verdict: Ente Auth is a strong fit when codes are needed across mobile and desktop with end-to-end encrypted synchronization and a documented encrypted export. It also offers a genuine accountless mode, but offline users must maintain their own recovery files. Neither mode makes OTP phishing-resistant, and account users must protect a 24-word Ente recovery key and avoid creating a circular dependency around the Ente account’s own second factor.
What Ente Auth officially supports
The official Ente Auth page lists Android, iOS, F-Droid, web, macOS, Linux, and Windows. Ente’s public monorepo contains client and server code under AGPLv3, and the project says Auth is free.
Ente Auth supports scanning an enrollment QR code on mobile, importing a QR image, entering a secret manually, and bulk importing from other authenticators. Current organization features include search, tags, pinning, notes, custom sorting, multi-select actions, trash, and icons. It can also display the next code before the current TOTP expires.
The platform list does not imply that every control is identical everywhere. Camera enrollment is explicitly documented for Android and iOS, while desktop and web are useful for viewing synchronized codes and managing supported workflows. Verify the current client before planning a large migration around one platform-specific feature.
Open source makes the implementation inspectable but does not prove that every build is bug-free. Likewise, a published audit covers the scope and version assessed, not all future Auth releases. This review reports the current documented behavior and does not assign a security or usability score.
Account mode: end-to-end encrypted cross-platform sync
In account mode, Ente Auth synchronizes codes through an Ente account. Ente says codes are end-to-end encrypted before they leave the device, so the server stores encrypted data rather than readable OTP secrets. The Ente architecture overview explains that a client creates a master key, encrypts it using a key derived from the user’s password, and stores the encrypted master key on the server for other authorized devices.
This model reduces the risk that losing one phone means losing every authenticator seed. Signing in on another supported client can restore the synchronized vault after email verification and successful key derivation. Existing signed-in clients can continue generating TOTP codes locally when temporarily offline; connectivity is needed for account sign-in and synchronization.
End-to-end encryption changes what the service can read, but it does not remove account risks. A weak password, stolen recovery material, compromised endpoint, malicious browser extension, or unlocked desktop can expose codes after legitimate client-side decryption. Every signed-in device becomes part of the authenticator’s security boundary.
Use a unique Ente password, enable app lock on each client, remove old devices, and keep a separate encrypted export. Cloud synchronization is a recovery aid, not a replacement for the recovery codes issued by the individual websites protected by Auth.
Account recovery and the Ente-in-Ente trap
Ente’s shared account system uses a 24-word recovery key. The key can reset the account password when the user is logged out everywhere, and Ente says support cannot regenerate it. Store it somewhere outside Ente Auth and outside the Ente account itself.
The official Enteception guidance describes a circular lockout risk. Enabling TOTP on an Ente account and storing that account’s only TOTP entry inside the same synchronized Ente Auth account can create a situation where the code required to sign in is trapped behind that sign-in.
Ente suggests keeping the recovery key safe, using a separate account for Auth, retaining an encrypted export, or adding other account-recovery options such as passkeys or Legacy contacts. The recovery key can bypass Ente account 2FA during recovery, so possession of it is both a lifeline and a high-value secret.
The previous article’s generated recovery screen used the wrong key length. The current account documentation describes a 24-word Ente account recovery key. Offline mode has a different recovery model and does not become recoverable from Ente’s servers merely because a recovery key exists for another Ente account.
Offline mode: no account, no server recovery
Ente Auth can be used without an account by selecting Use without backups. The offline-mode guide says codes remain on that device and are not uploaded or recoverable from Ente’s servers.
The offline vault is encrypted using a key protected by the operating system’s secure storage, such as a keychain, keyring, credential store, or equivalent service. This is not the same as encrypting the vault with an independently portable user password. If the secure-storage key is lost or becomes unusable, copying the local database alone may not recover the codes.
Ente explicitly warns that device transfers and operating-system backups are not supported recovery methods for offline codes. Before reinstalling the app, resetting credentials, replacing a device, or changing an operating system, create an encrypted export or local backup and verify its password.
Offline mode corrects the old article’s continuous-connectivity claim. Code generation and local use do not require an Ente account or a live connection. The trade-off is that synchronization and server-side recovery disappear; recovery discipline moves entirely to the user.
Encrypted export and automatic local backup
Ente documents plain-text export, encrypted export, automatic CLI export, and on-device local backup. These paths should not be treated as interchangeable.
The encrypted export specification uses Argon2id to derive a key from the export password and XChaCha20-Poly1305 to encrypt the data. After decryption, entries are represented as newline-separated otpauth://totp/... URIs. The file can be re-imported into Ente Auth or decrypted with the official Ente CLI.
Plain-text export removes that protection and exposes reusable OTP seeds. Use it only for a controlled migration, protect the working directory, and delete temporary copies after destination logins are verified.
Ente’s local-backup documentation says the app can create one password-protected backup per day when opened, retain up to five recent backups, and write them to a chosen location. Users can also trigger a manual backup. A backup stored only on the same device is not protection against theft or hardware failure, so copy an encrypted version off the device.
The CLI can automate account-mode exports to a selected directory. Automation improves freshness but does not prove restorability. Periodically import a backup in a controlled environment and confirm that the expected entries are present before depending on it.
App lock, organization, and temporary sharing
Ente Auth offers device lock, a four-digit PIN, or a password as app-lock methods, plus automatic locking intervals from immediately through 30 minutes. The feature documentation is explicit that app lock protects access to the interface; it is not a recovery password and does not re-encrypt stored Auth data.
Tags, search, pins, notes, custom sorting, and multi-select make a large token list easier to manage. Notes and labels are synchronized as encrypted Auth data in account mode. Organization reduces login mistakes, but it is not an additional authentication factor.
Ente also supports temporary sharing links for TOTP codes. The documentation says recipients can view fresh codes for 2, 5, or 10 minutes without receiving the underlying secret key. This is still delegation of active second-factor access during the sharing window. Use it only for an intentional, time-bounded workflow and revoke or wait for expiry before assuming access has ended.
Never share an enrollment QR code or display an entry as a QR code unless the recipient is meant to receive the reusable secret. A TOTP seed grants the ability to generate future codes, which is much more persistent than sharing one expiring code.
Privacy and audit claims: what they do and do not prove
Ente’s Apple privacy-disclosure explanation says Auth collects no data by default. If an account is created for backups, Ente receives an email address, a server-generated user ID, and end-to-end encrypted Auth content. Anonymous diagnostics are collected only when crash reporting is enabled.
The product page says Ente’s cryptography has been externally audited, and the monorepo links audits by Cure53, Symbolic Software, and Fallible. That is meaningful evidence about assessed code and architecture. It is not accurate to call every current Auth client independently penetration-tested unless a report explicitly includes that client, version, and scope.
This distinction matters for GEO-quality claims. “Externally audited cryptography” is supported by Ente’s published material; “independently proven secure” would be broader than the evidence. Endpoint security, account recovery, implementation changes, and operational mistakes remain outside any blanket guarantee.
Users who opt into diagnostics should inspect what will be sent when possible. Open-source availability, E2EE, and audit reports reduce opacity, but they do not eliminate the need for updates, device encryption, a strong operating-system login, and a tested recovery plan.
Migration into and out of Ente Auth
Ente supports QR enrollment, manual entry, bulk imports, encrypted export, and plain-text export. The official help center includes migration guides for Authy, Microsoft Authenticator, Steam, and other formats, but individual imports can still fail when a source app emits unusual or proprietary data.
Ente’s FAQ notes that some Google Authenticator entries may fail to import. The safe fallback is to open the original service’s security settings, register a new authenticator secret, verify a code from Ente Auth, save new service recovery codes, and only then remove the old registration.
Keep the old authenticator until a signed-out login succeeds for every important account. Test email, password manager, registrar, cloud console, financial, and developer accounts individually. Seeing an entry in the destination does not prove its secret, digits, period, or algorithm match what the service expects.
Before leaving Ente Auth, create an encrypted export and verify that the destination accepts the resulting data. Portability is one of Ente’s strongest documented advantages, but a documented format still requires a tested migration procedure.
OTP security limits still apply
Ente Auth can protect stored seeds with E2EE or local secure storage, but it cannot determine whether a login page requesting a code is genuine.
NIST’s current authenticator guidance states that manually entered OTP is not phishing-resistant. A fraudulent site can collect a fresh code and relay it to the legitimate service before expiry. Synchronization, encryption, and open source do not change that protocol limitation.
Use Ente Auth where TOTP is the strongest method offered or where a synchronized, exportable authenticator is operationally useful. Prefer passkeys or FIDO2 security keys when a service supports phishing-resistant authentication. Keep service recovery codes outside the Auth vault so loss of the authenticator does not become loss of the account.
Who should choose Ente Auth
Ente Auth fits users who need codes across Android, iOS, desktop, and web; want open-source clients and E2EE synchronization; and value a documented encrypted export. It also fits users who want an accountless local mode but are prepared to maintain their own backups.
It is a weaker fit when no cloud account is acceptable but manual backup discipline is unrealistic, or when an organization requires centralized provisioning, policy enforcement, access logs, and administrator-controlled recovery. Temporary code sharing is not a replacement for an enterprise identity platform.
Our source-verified 2FA authenticator comparison covers local-first and account-optional alternatives. Choose based on the recovery model, supported platforms, and export path rather than a numerical score.
Ente Auth setup and recovery checklist
- Decide between E2EE account sync and Use without backups before adding critical codes.
- If using an account, create a unique password and store the 24-word recovery key outside Ente.
- Avoid storing the Ente account’s only TOTP entry solely inside that same account.
- Enable app lock on every signed-in mobile, desktop, and browser environment.
- Add one noncritical service and complete a signed-out login.
- Save that service’s own recovery codes separately.
- Create a password-protected encrypted export.
- Enable automatic local backup and move an encrypted copy off the device.
- Test an import before migrating email, registrar, financial, or password-manager accounts.
- Review signed-in devices and remove systems no longer controlled.
- Keep crash reporting off unless its diagnostic value is wanted.
- Treat temporary sharing links as live access during their validity window.
- Keep the old authenticator until every migrated login and recovery method works.
- Prefer passkeys or security keys whenever the protected service supports them.
Ente Auth verdict
Ente Auth combines broad platform support, E2EE account synchronization, a genuine no-account mode, and a technically documented export format. That makes it unusually portable for users who need OTP codes on both phones and computers.
The main complexity is choosing and operating the correct recovery model. Account users must protect a password, 24-word recovery key, and every signed-in endpoint. Offline users must preserve encrypted backups because Ente cannot restore codes that were never uploaded.
Used with an encrypted export, separate service recovery codes, app locks, and phishing-resistant factors where available, Ente Auth is a defensible cross-platform authenticator. The evidence supports that conclusion without the invented testing narrative, generated interface images, or blanket security claims in the earlier edition.
Frequently asked questions
Does Ente Auth require an account?
No. Use without backups stores codes locally without an account. Those codes are not synchronized or recoverable from Ente’s servers.
Can Ente Auth work without internet?
Yes. Configured clients generate TOTP codes locally. Connectivity is required for account sign-in, synchronization, and web access to data not already available locally.
Which platforms does Ente Auth support?
Ente lists Android, iOS, F-Droid, web, Windows, macOS, and Linux clients.
How is an encrypted Ente Auth export protected?
The current export specification uses Argon2id for password-based key derivation and XChaCha20-Poly1305 for encryption.
How long is the Ente account recovery key?
No. Current Ente account documentation describes a 24-word recovery key. Offline-mode recovery instead depends on encrypted exports or local backups and their passwords.
Is app lock the same as backup encryption?
No. App lock restricts the interface. Ente says it is not a recovery password and does not re-encrypt stored Auth data.
Is Ente Auth phishing-resistant?
No. TOTP codes can be relayed by a phishing site. Use passkeys or FIDO2 security keys when the service supports them.
