导入后先核对条目数量、名称与分组
在将验证码数据从其他身份验证器迁移至安令码，或通过兼容格式导入备份文件后，第一步并非立即开始使用，而是进行严格的完整性核对。由于不同服务对账户命名的规范不一，导入过程中极易出现同名账户混杂、分组标签丢失或条目遗漏的情况。因此，用户应在导入完成后，首先统计当前列表中的验证码条目总数，并与导出前的原始记录或备份清单进行比对。如果数量不一致，说明导入过程可能存在错误或部分条目因格式不兼容而被跳过，此时不应继续后续操作，而应重新检查源文件或联系原服务提供商。
除了数量核对，还需逐一检查每个条目的名称显示是否正确，特别是那些在不同平台拥有相同邮箱或用户名的账户。例如，个人 Gmail 与工作 Google Workspace 账户可能显示为相同的用户名，若未加区分，后续登录时将难以辨别。同时，检查系统是否自动保留了原有的分组标签。若导入后所有账户均处于“未分组”或默认状态，用户需手动介入，为每个账户重新分配明确的分组标识，这是防止后续混淆的基础步骤。
风险边界在于，若在条目数量不符或分组标签缺失的情况下直接清理旧设备或卸载原应用，一旦新设备上的数据存在隐性错误，用户将面临无法登录关键账户的风险。因此，核对阶段必须保持旧设备或原备份文件的可用性，直到所有条目确认无误且经过真实登录测试。
- 核对导入后的条目总数是否与导出前一致，差异需立即排查。
- 检查每个同名账户的显示名称是否包含足以区分的后缀或前缀。
- 确认分组标签是否完整保留，缺失时需手动补全。
- 在确认无误前，严禁删除旧设备上的验证器应用或备份文件。
用搜索与分组区分工作、个人与开发账户
安令码提供了搜索、分组和排序能力，这是解决同名账户混淆的核心工具。面对多个名称相同但归属不同的账户（如多个名为“Admin”的服务器账户），用户应建立一套标准化的分组命名体系。建议至少设立“工作”、“个人”和“开发”三大基础分组，并在必要时细分出“财务”、“社交”或“测试环境”等子类别。通过为每个同名账户打上明确的分组标签，用户可以在主界面通过点击分组标题快速筛选出特定类别下的所有账户，从而大幅缩小查找范围，避免在长长的列表中盲目滚动。
在实际操作中，搜索功能应与分组配合使用。当需要登录某个特定账户时，先通过分组过滤掉无关类别，再使用搜索框输入账户名的关键词。例如，在“工作”分组下搜索“Admin”，结果将仅显示工作相关的管理员账户，排除了个人博客或测试服务器的干扰。这种组合策略不仅提高了登录效率，还降低了误选账户导致验证码错误的概率。此外，利用排序功能，可以将常用账户置顶或按最近使用时间排序，进一步优化高频账户的访问路径。
需要注意的是，分组标签仅是本地整理的辅助手段，用于提升用户体验和管理效率，它并不改变账户本身的加密属性或安全级别。分组信息存储在本地加密保险库中，不会同步至云端或与账户服务提供商交互。因此，用户不能依赖分组标签作为账户恢复的依据，也不能将其视为账户安全的一部分。真正的安全保障仍依赖于本地加密保险库的强度以及用户对敏感凭据的妥善保管。
- 建立“工作”、“个人”、“开发”等标准化分组标签体系。
- 结合分组过滤与关键词搜索，精准定位同名账户。
- 利用排序功能优化高频账户的访问顺序。
- 明确分组仅为本地管理工具，不具备账户恢复或安全认证功能。
同名账户的 TOTP 时间步长与参数核对
对于基于时间的一次性密码算法（TOTP），RFC 6238 规定生成端与验证端必须使用一致的共享密钥及时间步长，并能获取当前 Unix 时间。虽然大多数互联网服务采用默认的 30 秒时间步长，但并非所有服务都遵循这一标准，部分企业内部系统或特殊应用可能使用 60 秒或其他自定义步长。当存在同名账户时，若其中一个账户的时间步长配置错误，生成的验证码将无法通过服务端验证，导致登录失败。因此，在整理同名账户时，必须逐一核对每个账户的 TOTP 参数，确保其与账户服务提供商的要求完全一致。
核对过程包括确认共享密钥是否正确录入，以及时间步长设置是否符合服务规范。如果在添加账户时是通过扫描二维码完成的，通常参数会自动配置；但若是手动输入密钥，则需格外注意步长设置。若发现验证码持续无效，且排除时间同步问题后，应怀疑参数配置错误。此时，需重新查看服务提供商提供的设置页面或二维码信息，确认正确的时间步长，并在安令码中编辑该账户的参数。
此外，RFC 6238 还规定同一时间步长内生成的 TOTP 值相同，且验证端在一次成功验证后，不得再次接受该时间步长内的同一验证码。这意味着用户在使用同名账户时，若在短时间内多次尝试登录，可能会遇到验证码已失效的提示。理解这一机制有助于用户避免因重复提交同一验证码而产生的困惑，并促使他们在每次登录请求时生成新的验证码。
- 核对每个同名账户的 TOTP 时间步长，确认是否为默认的 30 秒或服务指定的其他值。
- 验证共享密钥与服务端记录一致，特别是手动添加的账户。
- 理解同一时间步长内验证码不可重复使用的规则，避免重复提交。
- 若验证码无效，优先检查时间步长和密钥配置，而非立即重置账户。
HOTP 同名账户的计数器同步检查
与 TOTP 不同，基于计数器的一次性密码算法（HOTP）依赖于递增计数器和共享密钥，RFC 4226 指出计数器必须在生成端与验证端保持同步。对于使用 HOTP 的同名账户，计数器失步是导致验证码无效的常见原因。这种情况通常发生在用户连续生成了多个验证码但未提交给服务端，或者在网络不稳定时多次点击生成按钮。由于计数器是单向递增的，生成端的计数器值若超过服务端预期的窗口范围，生成的验证码将被拒绝。
在整理同名账户时，若发现某个 HOTP 账户的验证码持续无效，应首先检查是否存在计数器失步的可能。安令码作为客户端，会记录当前的计数器状态，但无法直接得知服务端的当前计数值。若怀疑失步，用户可尝试连续生成几个验证码并依次尝试提交，看是否能命中服务端的接收窗口。部分服务端支持有限窗口的重同步机制，即在验证失败时向后扫描一定数量的计数器值以重新对齐。
若自行尝试无法解决，需联系账户服务提供方进行计数器重置或重同步。在此过程中，用户应避免随意删除或重新添加账户，因为这可能导致计数器彻底重置，进一步加剧失步问题。对于重要的 HOTP 账户，建议在添加时记录初始计数器值，并在日常使用中避免无谓地生成验证码，以减少失步风险。
- 检查 HOTP 计数器是否与账户服务端记录一致，警惕连续生成未提交导致的失步。
- 尝试连续提交多个生成的验证码，以匹配服务端的接收窗口。
- 若失步严重，联系服务提供方进行计数器重置，勿自行删除账户。
- 记录初始计数器值，避免无谓生成验证码以维持同步状态。
加密导出与备份的独立密码设置
在完成账户整理和分组后，下一步是确保数据的安全备份。安令码支持加密导出功能，允许用户将验证码条目导出为文件，以便在其他设备上恢复或作为离线备份。为了保障导出文件的安全性，安令码备份说明建议为加密导出设置独立于保险库密码的导出密码。这一措施的目的是实现权限分离：即使保险库密码泄露，攻击者若无导出密码也无法解密备份文件；反之，若导出文件丢失，没有导出密码也无法还原数据。
用户应选择一个高强度且易于记忆的导出密码，并将其与导出文件分开保管。例如，可将导出文件存储在加密的云存储或物理介质中，而将导出密码记录在密码管理器或纸质笔记中，切勿将两者放在同一位置。此外，定期更新导出密码并重新生成备份文件，也是维护长期安全的良好习惯。自动备份功能的具体触发条件及保存方式以正式版本说明为准，用户应关注官方发布的最新指引。
风险在于，若用户将导出密码设置为与保险库密码相同，或将其与导出文件一同存储，一旦存储介质被盗或云账户被入侵，攻击者即可同时获取文件和密码，导致所有验证码条目泄露。因此，严格遵循“文件与密码分离”的原则是备份安全的核心。
- 为加密导出设置独立于保险库密码的专用导出密码。
- 将导出文件与导出密码分开保管，避免单点故障。
- 定期更新导出密码并重新生成备份，确保持续安全。
- 严禁将导出密码与导出文件存储在同一位置或媒介中。
恢复后完成重要账户的真实登录验证
备份的最终目的是恢复，而恢复成功的主要标准是能够正常登录账户。因此，在将备份文件导入新设备或重新安装安令码后，用户不应仅满足于看到条目列表恢复原状，而必须执行真实登录验证。选择几个关键账户（如邮箱、银行、主要社交平台），使用生成的验证码完成一次完整的登录流程。这一步骤不仅能验证验证码生成的正确性，还能确认账户参数（如时间步长、密钥）在迁移过程中未发生损坏或篡改。
只有在确认所有重要账户均能成功登录后，方可考虑清理旧设备或删除原始备份文件。若在验证过程中发现某个账户无法登录，应立即停止清理操作，回溯检查该账户的配置参数或重新从服务提供商处获取新的密钥。真实登录验证是迁移流程中的最后一道防线，它能有效避免因隐性错误导致的账户锁定风险。
此外，CISA 提醒用户，身份验证器生成的一次性验证码虽是多因素验证的常见方式，但并非抗钓鱼验证方式。因此，在登录验证时，务必确认访问的是官方网站，避免在钓鱼网站上输入验证码，导致凭据泄露。
- 对每个重要账户完成一次真实登录验证，确保验证码可用。
- 仅在验证成功后才清理旧设备或删除原始备份文件。
- 若登录失败，立即回溯检查配置，勿贸然重置账户。
- 验证时警惕钓鱼网站，确保在官方域名下输入验证码。
区分账户恢复码与验证器备份
在备份与恢复的语境中，用户常混淆“账户恢复码”与“验证器备份”这两个概念。安令码备份说明明确指出，账户服务提供的恢复码（Recovery Codes）是用于在失去双因素验证能力时恢复账户访问权限的一组一次性代码，通常由服务提供商在启用双因素验证时生成并提供给用户。而验证器备份则是安令码导出的包含所有验证码条目加密数据的文件，用于在更换设备或重装应用时恢复验证器本身的状态。
两者功能截然不同且不能互相替代：若丢失了验证器备份但持有账户恢复码，用户可通过恢复码登录账户并重新绑定新的验证器；但若丢失了账户恢复码且验证器备份损坏，用户可能永久无法登录账户。因此，用户应将账户恢复码妥善保存在安全的地方（如打印并存入保险箱），同时将验证器备份文件按前述方法进行加密存储。
在整理同名账户时，建议为每个重要账户单独存档其恢复码，并与验证器备份文件分开管理。这种双重保障策略能最大程度降低因单一备份失效而导致的账户丢失风险。
- 明确账户恢复码用于恢复账户访问，验证器备份用于恢复验证器条目。
- 两者不可互相替代，需分别妥善保管。
- 为每个重要账户单独存档恢复码，并与验证器备份分离。
- 定期检查恢复码的可用性，确保在紧急情况下可使用。
生物识别解锁与保险库密码的备用方案
安令码支持使用密码或生物识别（如指纹、面部识别）解锁本地加密保险库，提升了日常使用的便捷性。然而，生物识别技术受限于硬件状态、系统更新或用户生理变化，可能出现无法识别的情况。安令码备份说明提醒，即使启用了生物识别，用户仍必须记住保险库密码。这是因为在设备更换、生物传感器故障或系统重置等场景下，密码是主要能解锁保险库并访问验证码条目的凭证。
用户应定期测试密码解锁流程，确保在生物识别不可用时能顺利进入应用。建议将保险库密码记录在安全的离线介质中，或存储在另一台可信设备的密码管理器内，避免遗忘。同时，不要将保险库密码设置为过于简单的组合，以免被暴力破解。
若忘记保险库密码且生物识别不可用，用户将无法访问验证器内的任何数据，即使拥有备份文件，若备份密码也遗忘，则将面临数据永久丢失的风险。因此，牢记保险库密码是保障数据可访问性的底线要求。
- 即使启用生物识别，也必须牢记保险库密码作为备用解锁方式。
- 定期测试密码解锁流程，确保在生物识别失败时能正常进入。
- 将保险库密码安全存储，避免遗忘导致数据永久锁定。
- 生物识别不可用或设备变化时，密码是主要的访问凭证。