Authy is a free mobile authenticator built around a phone-number account, optional encrypted cloud backup, and access from multiple authorized mobile devices. Its supported consumer apps are now Android and Apple’s mobile platforms. The Windows, macOS, Linux, Chrome app, and Chrome extension are no longer supported.
Correction published August 30, 2026: The previous edition still described desktop sync as a current advantage, presented unsupported first-person conclusions, assigned a numerical security score, and used generated images as if they showed the Authy interface and setup screens. This edition removes those claims and images, separates backup encryption, device authorization, account recovery, and local app lock, and links each product statement to Twilio’s current documentation.
Short verdict: Existing Authy users can continue using it on supported mobile devices if they know their backup password, maintain service recovery codes, and understand the account-recovery process. It is a restrictive choice for a new authenticator setup because Authy provides no supported token import or export, has no supported desktop client, and requires a phone number. TOTP codes also remain vulnerable to real-time phishing regardless of how their seeds are backed up.
What Authy officially supports in 2026
Twilio’s current system-requirements guide lists Android phones and tablets plus iPhone, iPad, iPod touch, and supported Apple Watch use. It identifies the Chrome app, Chrome extension, and Linux, macOS, and Windows desktop clients as deprecated.
The dedicated desktop end-of-life notice says the desktop apps reached end of life on March 19, 2024. Existing desktop installations were invalidated and removed from Authy accounts. Keeping an old package installed is not a supported recovery or desktop-access plan.
Authy requires a phone number to create and register an account. Twilio describes the number as the Authy account identifier and does not offer an accountless operating mode. Configured TOTP codes can still be generated without receiving an SMS each time; phone verification is part of registration, adding devices, number changes, and recovery workflows.
This review reports documented behavior. It is not an independent usability evaluation, code audit, penetration test, or cryptographic assessment, and it does not assign a numerical rating.
Local tokens, backups, and sync are separate concepts
By default, ordinary authenticator tokens are stored locally. Twilio’s no-backup guidance warns that losing or resetting the only device can permanently remove those locally stored tokens.
Enabling Backups uploads encrypted copies of supported tokens to Authy’s servers. The backup and sync guide says the user creates a backup password, Authy derives an encryption key on the device, and synchronized tokens must be decrypted with that password on another registered device.
Multi-Device controls whether another Authy installation can join the same account. Backups controls whether supported authenticator tokens are encrypted and available for synchronization. A device can be authorized without making a forgotten backup password recoverable, and an account-recovery process can restore account registration without decrypting backed-up tokens.
This distinction is the core of the Authy recovery model:
| Layer | Purpose | What it cannot do |
|---|---|---|
| Phone-number account | Identifies the Authy account and supports registration | Decrypt backed-up tokens by itself |
| Multi-Device | Authorizes additional Authy installations | Replace the backup password |
| Backups | Stores encrypted copies of supported tokens | Recover a forgotten password |
| Protection PIN or biometrics | Locks one local app installation | Act as a cloud-backup password |
| Service recovery codes | Recover the individual website account | Restore the entire Authy vault |
The backup password cannot be recovered or reset
Twilio’s backup-password documentation says the password is not sent to or stored on Authy servers. It is used on the device to generate the key that encrypts and decrypts backed-up tokens. Twilio identifies PBKDF2 as the key-derivation algorithm but does not make that one algorithm name a guarantee against weak user passwords.
If an active device already has every token decrypted, the user can set a new backup password from that device. Other synchronized installations will then require the new password. If all working devices are gone and the password is forgotten, support cannot bypass or reset it; the encrypted tokens remain inaccessible.
Store the backup password outside Authy, such as in a reputable password manager or an offline recovery record. Make it unique and long enough to resist guessing. Do not place the only copy in an account whose login depends on a code stored only in Authy.
Each protected service’s one-time recovery codes should also be stored separately. They are the fallback when an Authy backup, phone-number recovery, or migration does not restore a usable token.
Multi-Device should be opened only when needed
The Multi-Device guide allows several trusted mobile installations to share one Authy account. Existing linked devices continue working after the setting is disabled; disabling it prevents another installation from being added until a working device enables it again.
Twilio recommends enabling Multi-Device long enough to add a secondary device and then disabling it. The app may automatically disable the option after a second device is added, but users who later enable it should verify the state rather than assume it closed itself.
A secondary installation can protect against one broken phone, but it also adds another endpoint that can display live codes. Secure every linked phone or tablet with current updates, device encryption, a strong screen lock, and Authy’s local Protection PIN or biometrics. Remove devices that are sold, lost, retired, or no longer controlled.
Do not authorize an unexpected device request. A text or call that appears to concern Authy can be part of a phishing or SIM-swap attempt. Open the app directly and inspect device state instead of following unsolicited links.
Account recovery does not equal token recovery
Twilio documents several new-phone scenarios. If another registered device is available, Multi-Device can authorize the replacement. Without another working installation, the user may need the formal account-recovery process.
The restoration guide says the recovery process takes 24 hours and cannot be accelerated. The process is tied to the Authy account and phone-number registration. It does not reset a forgotten backup password, decrypt backed-up tokens, or recreate tokens that were never backed up.
Before replacing, resetting, or uninstalling a device:
- Confirm that Backups is enabled if cloud recovery is intended.
- Confirm the current backup password by decrypting a token on another device.
- Temporarily enable Multi-Device and register the replacement.
- Verify several signed-out logins on the replacement.
- Disable Multi-Device again.
- Remove the old installation only after every critical account works.
If the old phone number and registered email are also unavailable, the process can require support involvement. Service-specific recovery codes remain the more direct route to each protected account.
Authy does not support token import or export
Twilio’s import and export article explicitly says the Authy app does not allow importing or exporting 2FA account tokens. This is more restrictive than an authenticator that offers a documented encrypted export.
There is no supported bulk migration file that can be handed to another authenticator. Third-party scripts that extract data from obsolete clients are outside Twilio’s supported workflow and may expose reusable seeds. This review does not recommend them.
The dependable exit path is service-by-service re-enrollment:
- Sign in to the protected website using the current Authy token.
- Save or refresh that service’s recovery codes.
- Open the service’s security settings and disable or replace its authenticator registration.
- Enroll the replacement authenticator with the newly issued QR code or secret.
- Verify a fresh code from the replacement app.
- Complete a signed-out login before deleting the Authy entry.
Start with low-risk accounts, then move email, password managers, domain registrars, financial services, cloud consoles, and developer accounts. Keep Authy installed until the full inventory is complete.
Protection PIN and biometrics are local app locks
Authy supports a four-digit Protection PIN and platform biometrics on compatible iOS and Android devices. Twilio’s PIN and backup-password guide states that this protection is local to each installation.
The app lock and backup password are not interchangeable. The Protection PIN restricts casual access to one installed app. The backup password decrypts synchronized token data. Forgetting a local PIN may require reinstalling or using device recovery options, while forgetting the backup password can permanently block decryption when no active decrypted installation remains.
Enable the local lock on every linked device and keep the auto-lock interval short enough for the device’s risk. A local PIN does not make a compromised operating system trustworthy and does not prevent someone with an already unlocked session from using a visible code.
The 2024 phone-number exposure
On July 1, 2024, Twilio published an Authy security alert. It said threat actors used an unauthenticated endpoint to identify data associated with Authy accounts, including phone numbers. Twilio said it secured the endpoint and had no evidence that the actors breached Twilio systems or accessed other sensitive internal data.
The incident should be described narrowly. Twilio did not say that Authy token seeds or backup passwords were obtained, and it said Authy accounts were not compromised through that event. It did warn that exposed phone numbers could be used for phishing and smishing.
Keep the Authy mobile app current, treat unexpected Authy-themed messages as suspicious, and never disclose verification codes or approve an unrecognized device. The phone-number account model makes telephone-channel security and recovery hygiene relevant even when TOTP seeds are encrypted.
Authy compared with portable alternatives
Authy remains operationally distinct from the reviewed account-optional and local-first alternatives.
| App | Supported desktop client | Account requirement | Built-in sync | Supported export |
|---|---|---|---|---|
| Authy | No | Phone number required | Encrypted backup plus Multi-Device | No import or export |
| Proton Authenticator | Yes | Optional | Optional Proton E2EE sync or Apple iCloud | Yes |
| Ente Auth | Yes, plus web | Optional offline mode | E2EE Ente account sync | Encrypted and plaintext export |
| Aegis | No, Android only | No | No service-operated sync | Encrypted and plaintext export |
| 2FAS | No native desktop vault | No central account | Platform backup or sync plus phone companion | Password-protected export |
Proton Authenticator and Ente Auth fit users who need supported desktop access and a documented exit path. Aegis is a local Android option. 2FAS keeps the vault on mobile while using a browser companion for desktop logins.
No table proves one app is universally safer. Endpoint security, recovery discipline, platform needs, and the ability to leave without lockout are separate decision factors.
TOTP still has a phishing limit
Authy’s encrypted backups protect stored token data under the documented design. They do not bind a six- or seven-digit code to the legitimate website requesting it.
NIST’s current authenticator guidance says manually entered OTP authenticators are not phishing-resistant. A fraudulent login page can collect a fresh code and relay it to the real service before it expires.
Use TOTP when it is the strongest method a service offers or when it materially improves on password-only access. Prefer passkeys or FIDO2 security keys for high-value accounts when available. Verify the domain before entering a code, and do not approve unexpected recovery, phone-number-change, or device-registration prompts.
Who should keep or leave Authy
An existing Authy user does not need to panic-migrate a working vault. Staying can be reasonable when supported mobile access is sufficient, every important token is backed up, the backup password is known, a secondary device is controlled, and service recovery codes are available.
A planned migration is more appropriate when desktop access is required, a phone number should not be the account identifier, a documented export is a requirement, or the organization needs managed provisioning and administrator-controlled recovery.
Authy is difficult to recommend for a new personal setup when equally practical alternatives provide accountless use or portable exports. That conclusion is based on the documented exit path and platform scope, not on an unsupported security score.
The source-verified 2FA authenticator comparison explains the recovery models behind the current alternatives. Choose the model before enrolling important accounts, because Authy’s lack of export makes changing that decision later more labor-intensive.
Authy recovery and migration checklist
- Update Authy from the official Apple App Store or Google Play listing.
- Confirm which mobile devices are currently linked.
- Enable a local Protection PIN or biometrics on every linked installation.
- Confirm whether Backups is enabled for the intended tokens.
- Verify the backup password on an already registered secondary device.
- Store that password outside Authy.
- Save each important service’s one-time recovery codes separately.
- Keep Multi-Device disabled except while adding a device.
- Remove old or unrecognized installations.
- Before changing phones, complete signed-out logins from the replacement.
- For migration, re-enroll one service at a time with a new secret.
- Keep Authy until email, password-manager, registrar, financial, and cloud accounts all work in the replacement.
- Delete temporary QR images or written secrets after verification.
- Prefer phishing-resistant passkeys or security keys when supported.
Authy verdict
Authy still provides a functional mobile TOTP workflow with encrypted backups, multiple authorized devices, local app locking, and documented account recovery. Existing users who maintain the backup password and independent service recovery codes can operate it responsibly.
The product’s present limitations are substantial: desktop support ended in 2024, a phone number is mandatory, and supported import and export do not exist. Account recovery also cannot decrypt a forgotten backup or restore tokens that were never backed up.
For a new setup, a supported export and a clearer account-optional or local-first recovery model usually provide more control. For an existing setup, the safer transition is deliberate account-by-account re-enrollment, not removing Authy before every replacement login has been verified.
Frequently asked questions
Does Authy still have a desktop app?
No. Twilio says the Linux, macOS, and Windows desktop apps reached end of life on March 19, 2024. The Chrome app and extension are also deprecated.
Does Authy require a phone number?
Yes. Twilio says a phone number is required to create, identify, and register an Authy account.
Can Twilio recover an Authy backup password?
No. Twilio says the password is not sent to or stored on its servers. Without an active decrypted device, a forgotten password cannot be reset or bypassed.
Can Authy export tokens to another authenticator?
No supported import or export feature exists. Twilio directs users to disable and re-enroll 2FA on each protected service.
Does Authy account recovery restore every token?
No. It can restore account registration, but it does not reset the backup password or recreate tokens that were never backed up.
Is Authy phishing-resistant?
No. A manually entered TOTP code can be relayed by a phishing site. Use passkeys or FIDO2 security keys when the protected service supports them.
