直接答案：Authy 并没有整体停止服务。个人用户仍可在 iOS、Android 上使用 Authy 移动应用保存和生成 TOTP 动态验证码；但 Windows、macOS、Linux 的 Authy Desktop 已在 2024 年 3 月 19 日结束支持。开发者面对的是另一条产品线：Authy API 已不再接纳新客户，并进入支持终止与未来停用路线，新项目应评估 Twilio Verify v2 或其他符合需求的身份验证方案。
这一区分非常重要。旧稿把移动应用、桌面应用、浏览器扩展、Authy API、短信验证和推送审批混写成一个“全平台认证产品”，还承诺换机后“不会丢失任何数据”。这些说法会让个人用户误判令牌恢复条件，也会让开发团队继续扩大已进入退出路线的 API 依赖。本文按个人用户与开发团队两条路线重新说明，并把无法保证的恢复结果改成可执行的条件判断。
Authy 现在还能不能用？先看你使用的是哪个产品
Twilio 的Authy 与 Verify 官方对照页明确区分了消费级 Authy 应用和开发者 API。个人用户不需要因为 API 迁移公告立即删除手机里的令牌；开发团队也不能因为手机应用仍在运行，就推断旧 Authy API 没有迁移压力。
| 产品或能力 | 当前状态 | 主要用户 | 现在应做什么 |
|---|---|---|---|
| Authy iOS / Android 应用 | 仍可作为消费级 TOTP 应用使用 | 个人用户 | 检查备份密码、多设备设置、恢复码和备用登录方式 |
| Authy Desktop | 2024-03-19 结束生命周期，不再受支持 | 原桌面端用户 | 确认移动端令牌可用，不再把桌面端当作恢复或日常方案 |
| Authy API | 停止接纳新客户，处于支持终止路线 | 存量开发客户 | 冻结新增依赖，盘点流程并制定迁移、灰度和回滚计划 |
| Twilio Verify v2 | Twilio 面向新开发推荐的验证平台 | 开发团队 | 按当前区域、通道、合规、成本和风控需求重新设计 |
桌面版状态可直接核对 Twilio 的Authy Desktop EOL 公告和桌面应用停止支持帮助页。不要从非官方软件下载站寻找“旧版续命包”，因为停止维护的软件不会因能够安装而恢复安全支持。
个人用户：换机之前先完成四项准备
最稳妥的换机不是“新手机装好后再想办法”，而是在旧设备还能正常解密令牌时，把恢复条件逐一验证。Authy 的账户访问、令牌备份和各网站自身的账户恢复是三件不同的事；只恢复 Authy 账户，不一定能解开已经加密的令牌。
| 准备项 | 怎样核对 | 为什么重要 | 不要做什么 |
|---|---|---|---|
| 服务恢复码 | 在每个重要账户中重新生成并离线保存 | Authy 不可用时仍能进入原服务 | 不要只把恢复码存在同一部手机里 |
| 备份密码 | 在仍可解密令牌的设备上确认自己记得；必要时按官方流程更改 | 用于解密云端备份的令牌 | 不要假设 Twilio 能替你找回 |
| 备用设备 | 在旧设备仍可用时添加受信任的第二台设备并完成验证 | 主设备丢失时保留一个已配置入口 | 不要长期无条件开放多设备注册 |
| 手机号与邮箱 | 确认号码可接收验证并检查账户通知邮箱 | 换号、恢复和异常提醒都依赖它们 | 不要在停用旧号码后才更新账户 |
根据 Twilio 当前的备份密码能否恢复说明，备份密码不会发送给 Twilio，也不会由 Twilio 保存，因此官方无法查看、恢复或重置它。如果仍有一台设备已经解密令牌，可以在该设备上更改备份密码；如果没有可用设备又忘记密码，就需要回到每一个受保护的服务，使用恢复码或服务方账户恢复来重新注册 MFA。
多设备功能也不是简单的“开着更安全”。Twilio 的多设备设置说明建议仅在添加设备时启用，完成后再关闭；关闭新增并不会让已经关联的设备自动失效。你仍应定期审查设备列表，移除不再控制的手机。
旧手机丢失、号码更换或忘记密码时怎么走
| 你的情况 | 推荐路径 | 时间或限制 | 恢复后检查 |
|---|---|---|---|
| 旧手机仍可用，号码不变 | 在旧设备确认令牌可解密，添加新设备，验证后再移除旧设备 | 通常最快，风险最低 | 逐个测试重要账户，收紧多设备设置 |
| 旧手机不可用，但号码仍可用 | 按官方“新设备、同号码”恢复流程操作 | 无已配置设备时可能需要 24 小时等待，不能加速 | 确认备份令牌能否解密，审查设备列表 |
| 旧手机和旧号码都不可用 | 提交官方电话号码变更流程 | 官方说明通常需 2–4 个工作日，审核不能保证提前 | 更新各服务的号码与恢复选项 |
| 忘记备份密码且无已解密设备 | 使用各服务的恢复码或账户恢复，逐个解绑并重建 MFA | Authy 账户恢复不会替你解密令牌 | 重新保存恢复码并设置新的备份密码 |
具体路径可核对 Twilio 的新手机和丢失手机恢复说明、电话号码变更流程。官方同时说明：没有已配置设备时的账户恢复通常包含 24 小时等待期，而且访问原账户可能取消正在进行的恢复。任何宣称能够“跳过等待”或“代找备份密码”的第三方都不应获得你的验证码、恢复码或设备控制权。
收到陌生设备提醒时，不要只改一个密码
新设备提醒可能来自你自己的换机，也可能说明有人控制了旧号码、验证码或已登录设备。先从通知中的时间、设备类型和自己的操作记录判断；无法确认时按安全事件处理。Twilio 的新设备提醒说明建议移除陌生设备、关闭多设备新增并更改备份密码；若已经失去访问，应联系官方支持。
| 顺序 | 动作 | 目的 | 证据留存 |
|---|---|---|---|
| 1 | 不要点击来历不明的邮件或短信链接，手动打开 Authy | 避免进入钓鱼页面 | 保存通知时间与设备描述 |
| 2 | 查看设备列表并移除不认识的设备 | 切断可见的陌生会话 | 记录被移除设备与操作时间 |
| 3 | 关闭多设备新增，更改备份密码 | 减少再次关联和令牌解密风险 | 记录配置变更 |
| 4 | 检查邮箱、运营商账户和关键服务登录记录 | 排查邮箱劫持、SIM 换卡或密码复用 | 保留异常登录与工单号 |
| 5 | 更换关键账户凭据并重建 MFA | 处理已经泄露的上游账户 | 保存恢复码并验证备用入口 |
如果你在为团队建立统一的事件流程，可以结合本站的AI 安全威胁建模指南和AI 系统安全生命周期清单，把身份验证事件纳入资产、权限、告警、处置与复盘，而不是只依赖个人记忆。
Authy 和 TOTP 能解决什么，不能解决什么
TOTP 在“密码已经泄露”时增加了一个短时凭据，通常比只用密码更好，但它仍可能被实时钓鱼代理窃取，也可能因终端被控制、恢复流程被冒用或用户主动泄露验证码而失效。是否继续使用 Authy，不应只比较界面，而要比较你的威胁模型和恢复能力。
| 能力 | Authy / TOTP 可以提供 | 不能保证 | 补充措施 |
|---|---|---|---|
| 密码泄露后的第二道门槛 | 需要额外的短时验证码 | 无法阻止实时钓鱼转发 | 优先采用服务支持的通行密钥或安全密钥 |
| 多设备使用 | 在配置正确时同步加密备份 | 不保证忘记备份密码后仍可解密 | 保留已验证备用设备和离线恢复码 |
| 丢机恢复 | 在满足号码、设备与备份条件时恢复访问 | 不保证所有令牌都自动回来 | 定期演练关键账户的服务方恢复流程 |
| 账户安全 | 降低一部分凭据复用风险 | 不能替代强密码、终端安全和异常监控 | 密码管理器、设备加密、登录告警和最小权限 |
同理，在涉及 AI 工具账户时，不要把“开启二次验证”等同于已经安全。本站的ChatGPT 账户安全与 MFA 处置指南讨论了会话、第三方应用和恢复链路；生成式 AI 滥用与诈骗识别指南则可用于识别冒充客服、恢复代办和验证码套取。
开发团队：Authy API 迁移不是替换一个域名
Twilio 的Authy 到 Verify 迁移指南把 Verify 描述为后续平台，但迁移仍涉及服务标识、用户标识、验证通道、速率限制、风控、日志和失败处理。Verify v2 的基地址是 https://verify.twilio.com/v2/；具体可用通道和地区限制应以当前 Verify API 文档为准，不能把一张功能列表承诺为每个国家、账户和场景都可用。
| 迁移阶段 | 必须盘点 | 验收标准 | 失败时怎么办 |
|---|---|---|---|
| 发现 | Authy 应用、用户 ID、验证入口、通道、国家、合规与供应商依赖 | 每个生产调用都有负责人和去向 | 冻结新调用，补齐观测 |
| 设计 | Verify Service、身份映射、同意记录、滥用限制、错误码与用户文案 | 正常、超时、重试、拒绝和恢复路径都有规格 | 保留旧路径并设置停止条件 |
| 实现 | 密钥管理、最小权限、服务端调用、幂等、日志脱敏 | 密钥不进入前端或日志，敏感字段有留存边界 | 撤销泄露密钥并回滚版本 |
| 灰度 | 小流量用户、国家和通道分组，成功率、时延、成本与投诉 | 关键指标达到预设阈值且旧路可回退 | 自动停止放量，回到旧路 |
| 收口 | 残余调用、计划任务、旧密钥、仪表盘和应急手册 | 观察期内无未解释旧调用，值班可独立处置 | 延长双运行并修复缺口 |
如果系统会自动发送短信、WhatsApp 或语音验证，还要同时控制欺诈成本和用户骚扰：验证请求应由明确用户动作触发，限制号码、IP、设备和账户维度的频率，异常峰值自动熔断，并把供应商错误与业务拒绝分开统计。可以参考本站的自动化上线门禁与回滚清单，把身份系统迁移纳入变更审批、灰度、可观测和回滚。
选用或替换认证器时的决策表
| 你的主要需求 | 优先核对 | 可能方向 | 上线前测试 |
|---|---|---|---|
| 个人跨设备 TOTP | 加密备份、导出能力、恢复机制、平台覆盖 | 继续使用合规配置的 Authy，或评估其他认证器 | 丢机、换号、忘记密码和恢复码演练 |
| 高价值账户防钓鱼 | 服务是否支持 WebAuthn、通行密钥或硬件安全密钥 | 优先采用抗钓鱼认证 | 备用密钥、设备丢失和管理员恢复 |
| 面向客户发送验证码 | 国家、通道、送达率、成本、同意、反欺诈和数据处理 | Verify v2 或经过评估的同类服务 | 速率限制、号码枚举、短信轰炸、回滚 |
| 企业统一身份 | SSO、条件访问、设备信任、审计和离职回收 | 企业身份提供商与强认证组合 | 权限回收、紧急访问和日志完整性 |
不要把“免费”“云同步”或“支持很多平台”作为唯一标准。真正影响结果的是：令牌是否能安全迁移、恢复是否可验证、服务是否仍受维护、认证是否抗钓鱼，以及团队能否在丢机、换号、供应商故障和账户接管时恢复业务。
个人用户可以做一次不破坏现状的恢复演练
恢复能力不能只靠“我应该记得密码”。在不删除旧设备、不注销现有令牌的前提下，可以先做一次低风险演练：选择一个不涉及资金和主邮箱的测试账户，确认恢复码有效；再检查 Authy 中该令牌是否已经解密、旧手机是否仍能离线生成验证码、新设备是否在预期列表中。演练的目标不是证明 Authy 永不出错，而是确认你在服务中断、手机损坏或号码变更时还有一条独立入口。
关键账户要分别记录恢复责任。例如，邮箱账户的恢复码不能只存放在该邮箱；密码管理器的应急资料不能只存放在密码管理器；运营商账户也需要独立强密码和防换卡措施。若某个服务允许登记两把硬件安全密钥，可以把第二把密钥保存在不同的安全地点。若服务只支持 TOTP，则至少保留离线恢复码，并定期确认服务方没有因安全策略更新而使旧恢复码失效。
迁移认证器时也不宜批量删除旧令牌。应逐个进入原服务的安全设置：验证当前登录会话，新增或重置认证器，使用新认证器完成一次登录，再生成新的恢复码，最后才删除旧认证器绑定。若服务显示多个 MFA 方法，还要确认默认方法和账户恢复方法都符合预期。完成后记录日期即可，不要在记录中保存 TOTP 秘钥、二维码或完整恢复码。
开发团队迁移时要保存什么证据
身份验证属于高影响基础能力。迁移 Authy API 时，产品经理、研发、运维、安全、客服和合规人员应共享同一份变更记录，但各自只访问必要信息。记录至少包含旧调用位置、目标服务、负责人、灰度范围、开始与结束时间、成功率和时延基线、错误码分布、成本上限、用户投诉入口、停止条件、回滚负责人以及旧密钥撤销时间。不要把电话号码、验证码、TOTP 秘钥或完整供应商响应长期复制到工单和聊天群。
上线前要覆盖正常验证之外的滥用场景：同一号码被高频请求、攻击者批量枚举号码、验证码被反复猜测、消息通道延迟后重复发送、供应商返回成功但用户未收到、用户在双运行期间收到两条验证码，以及回滚后新旧系统对验证状态理解不一致。每个场景都需要明确的用户文案、限速层级、可观测指标和客服处置方式。只看“接口返回 200”不能证明迁移成功。
双运行也不等于把每次请求同时发送两条消息。更安全的做法通常是按稳定规则分流一小部分用户或地区，在后台同时记录兼容性指标；如果必须进行影子验证，必须确保影子路径不会向用户发送消息、产生不必要费用或改变账户状态。达到预设指标后再逐步放量；任何关键成功率下降、成本异常或投诉增加都应自动停止放量，而不是等待人工第二天查看报表。
收口阶段要从代码、环境变量、CI/CD、计划任务、告警、运行手册和供应商控制台逐项确认旧 Authy API 依赖已经清除。旧密钥撤销后仍应保留一段观察期，通过网关或日志检测是否还有遗留调用，但日志必须脱敏。观察期还应覆盖至少一个真实业务高峰，并确认告警能到达当班人员；否则“没有报错”可能只是没有监控。最后还要做一次值班交接演练，确保非项目成员也能按手册定位并回滚。只有业务负责人和安全负责人共同确认恢复、回滚和客服流程可用，迁移才算完成。
常见问题
Authy Desktop 还能继续用吗？
已安装版本可能在部分环境中暂时还能启动，但 Twilio 已在 2024 年 3 月 19 日结束支持。它不应继续承担关键账户的日常认证或恢复职责，也不应从第三方站点下载旧安装包。
删除旧手机前要不要开启多设备？
如果要添加新设备，应在旧设备仍可用时短暂启用并完成验证；添加后可按官方建议关闭新增。先确认新设备可以解密并使用关键令牌，再移除旧设备。
账户恢复会重置备份密码吗？
不会。账户恢复解决的是重新访问 Authy 账户，不能替你找回或重置备份密码，也不能解密没有密码的备份令牌。
Authy API 存量客户要立刻停机迁移吗？
不应无计划地立即切断生产流程，也不应继续扩大旧依赖。先依据官方迁移资料盘点，建立 Verify v2 或其他目标方案的双运行、指标、停止条件和回滚，再分批迁移。
来源与复核记录
本文由兰塞 AI 编辑流程于 2026 年 7 月 19 日复核。旧稿混淆 Authy 移动应用、已停用桌面应用、Authy API 与验证通道，包含“全平台支持”和“不会丢失任何数据”等无法保证的表述；本次改写依据 Twilio 官方产品、EOL、备份密码、多设备、换号、恢复和 Verify 迁移资料，增加产品生命周期图、恢复决策图、个人恢复清单、异常设备处置和开发迁移门禁。关于本站如何选择来源、标记更新与处理纠错，见关于本站与编辑规范。
