Passkey终于可以跨平台迁移了——FIDO新标准打破生态锁定，密码管理器无需从头再来

如果你和我一样，已经在大部分账户中切换到了Passkey（通行密钥），你会爱上那种不用输入密码的体验：电脑上刷脸或输入PIN码，登录就完成了。但你也会发现一个让人不安的问题——一旦设定，Passkey就被锁死在了创建它的设备或生态系统中。

换一台新设备？从头来一遍。想从iCloud切换到Bitwarden？对不起，没有导出选项。

这个状况正在改变。2026年8月，FIDO联盟发布了两项关键的凭证交换标准——CXF（凭证交换格式）和CXP（凭证交换协议），让用户第一次可以在不同密码管理器之间安全地迁移Passkey。这不是厂商私有的黑盒方案，而是跨平台的开放标准。

问题本质：Passkey的”生态锁定”困境

Passkey为什么会被锁定在单一平台

要理解这个问题，需要先回顾Passkey的工作机制。Passkey本质上是一对非对称密钥——私钥安全存储在设备的硬件安全模块（如Apple的Secure Enclave或Android的StrongBox）中，公钥则发送给服务端。登录时，设备用私钥对挑战签名，服务端用公钥验证。

这种设计在安全上是完美的——但问题出在：私钥与硬件绑定，且缺乏标准的导出机制。早期，无论是Apple、Google还是各个密码管理器，都将Passkey数据隔离在自己的生态内。这不是恶意的，而是行业在安全性和可移植性之间还没找到平衡点。

对于企业用户来说，这意味着：

• 员工离职移交账户时，需要为每个服务重新注册Passkey
• IT管理员无法批量迁移凭证到新的管理平台
• 审计日志分散在多个不互通的系统中

旧方案的”土办法”有多不安全

在CXF/CXP出现之前，迁移Passkey的唯一方法是导出未加密的CSV文件，然后在目标应用中导入。这会带来两个严重的风险：

1. 中间态暴露：CSV文件在磁盘上明文存储期间，任何有文件访问权限的恶意软件都可以读取其中的私钥材料
2. 无完整性校验：没有机制验证导入的凭证是否被篡改，攻击者可以在传输过程中替换或添加恶意凭证

在企业环境中，用明文CSV传输身份凭证是安全审计中最常见的红线之一。

新标准详解：CXF和CXP如何打破锁定

CXF（Credential Exchange Format）——统一的数据语言

CXF是一种基于JSON的标准化数据结构，定义了Passkey在不同应用之间应该如何表示。它解决的问题是：每个密码管理器内部使用自己的数据格式存储Passkey。就像一个中国人用中文写的文件，没学过中文的人看不懂一样——CXF相当于建立了一种”通用语言”。

具体来说，CXF规范包含：

• 标准化的字段定义（公私钥对、算法标识、关联域名等）
• 元数据映射（创建时间、最后使用时间、来源设备等）
• 版本控制（支持向后兼容）

CXP（Credential Exchange Protocol）——安全的传输管道

CXP处理的是安全传输本身。它使用端到端加密来传输凭证，确保数据在离开源应用到达目标应用的整个过程中都不会以明文形式暴露。

简单理解：CXF保证”双方讲同一门语言”，CXP保证”对话走加密通道，中间没人能偷听”。即使传输经过不信任的网络或不信任的中间服务器，密钥材料也不会泄露。

操作流程

一个典型的迁移流程是这样的：

1. 源应用（如Apple Passwords）先用CXF格式将选定的Passkey封装为标准化JSON
2. CXP协议建立一个加密隧道，将封装的凭证安全传输到目标应用
3. 目标应用（如Bitwarden）接收后用CXF标准解析并导入本地安全存储
4. 迁移完成后，源应用中的凭证自动失效，防止同一个凭证在两地同时存在

整个过程不需要用户接触任何明文密钥材料——这和导出CSV有着本质区别。

各平台支持现状

桌面端为什么慢了一步

Passkey的安全机制深度依赖设备级的硬件安全模块——比如Apple的Secure Enclave和Android的StrongBox。这意味着导入导出功能需要操作系统层面提供API支持，而不能仅靠应用层的更新。

移动端之所以先行，是因为Android和iOS的硬件安全模块生态更成熟、API更标准化。而桌面端（特别是Windows和Mac需要做更深层的OS级更新来支持第三方应用的硬件密钥访问。

未来路线图：不仅仅是Passkey

FIDO联盟对CXF/CXP的愿景远不止Passkey迁移。在更长期的路线图中，这套标准还将扩展到：

• 传统密码：用户可以在密码管理器之间安全迁移密码库
• 信用卡数据：支付凭证的加密迁移，对电商和企业采购系统有直接价值
• 数字驾照和身份凭证：这背后有欧盟数字钱包法规对数据可移植性的直接推动——监管正在要求身份数据不能被困在单一平台上

对于企业安全团队来说，这个方向的意义在于：未来所有类型的数字凭证都将有一个统一的安全迁移协议。这意味着：

• 企业可以自由选择身份管理供应商，不被锁定
• 凭证生命周期管理可以集中化
• 审计和合规流程可以标准化

风险分析：迁移协议本身会引入新的攻击面吗

任何新的安全标准引入时，除了欢呼，也需要冷静审视它是否引入了新的风险。

潜在风险一：中间人攻击窗口

CXP的端到端加密在技术上是安全的——但前提是加密密钥交换的过程不被污染。如果一个恶意应用冒充合法的目标应用参与CXP握手，理论上可能截获迁移中的凭证。FIDO联盟的应对措施是要求CXP传输前进行双向认证——源应用和目标应用需要互相验证身份。

潜在风险二：凭证失效的不一致

规范要求迁移完成后源凭证自动失效，但如果在失效确认之前出现了网络中断或其他异常，可能导致同一个凭证在两地同时存在。这种”分裂状态”在安全审计中会制造混乱。建议企业在批量迁移时保留审计日志并逐个验证。

潜在风险三：钓鱼攻击的新变体

当一个标准化的迁移流程变得广为人知时，攻击者一定会设计出仿冒的迁移引导页面。用户可能收到一封看似来自Bitwarden或Apple的邮件，引导他们”迁移Passkey”——实际上是把凭证迁移给攻击者。这需要所有支持CXF/CXP的应用在产品设计层面做好用户教育。

AISOC视角：凭证迁移的标准化的安全运营价值

在安全运营中心的日常工作中，凭证管理和身份访问管理是最容易出现配置漂移的领域之一。CXF/CXP标准化带来的最大价值不是技术层面的便利，而是运营层面的一致性。

场景一：员工离职

传统流程中，IT管理员需要逐一登录离职员工有权限访问的每个SaaS应用，手动撤销权限或重置密码——这通常需要1-3个工作日。如果Passkey在标准化迁移协议下集中管理，IT团队可以将离职员工的凭证在单一控制台上统一转移或吊销，将时间窗口缩短到分钟级。

场景二：安全事件的响应

当SOC检测到一个账户被异常登录时，经常需要做”凭证轮换”——为该账户在多个关联服务中重新生成凭证。在没有标准迁移协议的情况下，轮换是逐服务手动完成的。CXF/CXP的存在让这个流程可以在控制台自动化——批量导出受影响的凭证，批量生成新的替代，批量部署到受控设备。

场景三：合规审计

等保和GDPR都要求企业在审计中证明”知道谁有权限访问什么”。当Passkey分散在不同的密码管理器和生态系统中时，这个证明变得极其困难。标准化的迁移协议让集中化的凭证清单成为可能——审计员只需审查一个来源，而不是五个。

总结

Passkey终于可以迁移了——这不是一个小更新，而是身份认证基础设施的一次结构性升级。

核心变化：

• CXF（JSON标准化格式）让所有密码管理器使用同一种语言描述凭证
• CXP（端到端加密传输协议）让迁移过程无需暴露明文
• Apple、Bitwarden、Dashlane已首批实现；Google和Microsoft正在跟进

核心风险：

• 迁移协议的标准化可能催生针对性的钓鱼攻击
• 凭证失效的不一致性可能导致”分裂凭证”状态
• 早期阶段的实现可能存在边缘场景的兼容性问题

管理建议：

1. 企业安全团队应关注CXF/CXP的发展节奏，提前规划凭证集中化管理的路线
2. 在内部环境中测试最新的迁移功能，验证跨平台的可靠性和安全性
3. 为员工提供标准化的Passkey使用指南，明确什么能做、什么不能做
4. 将凭证迁移日志接入SIEM，作为身份安全管理事件的一部分纳入审计范围