定义
2FA（Two-Factor Authentication，双因素认证）是在密码之外增加第二验证因素的认证方式，通常结合「所知」（密码）与「所有」（手机、硬件密钥）或「所是」（指纹、面部）两类因素。在国际物联网云平台（ICMP）中，2FA 与 OTP、IAM 配合，增强 Global Dashboard、Partner Portal、敏感 API 访问的安全，满足企业客户与合规要求。
工作原理
2FA 流程：用户输入账号密码（第一因素）后，系统要求第二因素验证。常见方式包括：OTP（一次性密码）通过 SMS Gateway 短信或 TOTP 应用下发；硬件密钥（如 FIDO2）；生物识别。验证通过后，用户获得会话或 Token，可访问受保护资源。ICMP 平台可在登录、支付、敏感配置变更等场景强制 2FA，与 IAM 角色权限、Audit Trail 配合，形成完整的安全与审计链条。
应用场景
典型场景包括：Portal 登录——Global Dashboard、Partner Portal 管理员、Reseller 登录时强制 2FA；支付与敏感操作——Payment Gateway 集成、批量退款、Suspension 大批量设备等操作前验证；API 高权限调用——部分敏感 RESTful API 可要求 2FA 验证后获取临时 Token；合规要求——满足 PCI DSS、GDPR 等对强认证的要求。
在 ICMP 中的实践
达希物联 ICMP 支持 2FA 可选或强制启用。支持 OTP 短信（经 SMS Gateway）与 TOTP 应用（如 Google Authenticator）两种方式。与 IAM 集成，可针对不同角色、不同操作配置 2FA 策略。敏感操作（如支付、批量 Suspension）可强制二次验证。结合 Audit Trail，2FA 验证事件可记录，支撑安全审计与合规证明。
第二因素保护哪些入口
双因素认证要求同一次确认里出现两类不同的证据。常见组合是只有本人才知道的密码，加上只有本人才持有的动态口令、短信验证码或硬件密钥。它加强的是人在进入管理能力时的确认，不是设备入网时的运营商鉴权。连接管理平台至少有两个入口要考虑：登录门户或接口，以及登录之后的敏感动作。敏感动作包括批量暂停、导出带有设备或联系人信息的文件、修改资费和确认付款。只在登录时验证一次，长会话里的后续动作就不再受第二因素保护。
启用的条件，是每个需要保护的角色都有可用的第二因素，并且丢失时有单独的恢复流程。恢复流程不能比日常登录更弱，例如只凭客服通话就把因素关掉。无人值守的系统调用不应假扮成已经通过双因素的用户，而应使用可吊销的服务凭证，并在授权协议里限制范围。人员会话则应在执行高风险动作前再次确认。因素材料在传输和保存时要受传输加密和访问控制保护，动态口令的共享密钥不能明文出现在工单里。
只守登录却放过敏感动作
容易出错的是全员打开登录双因素后，就认为导出、停机和支付已经安全。攻击者或误操作者只要拿到一个已经登录的会话，这些动作仍会执行。另一个错误是允许用户自己选择“记住这台设备”并且永不过期，第二因素实际上只在第一次出现。共享账号再叠加双因素也没有意义，因为口令生成器同样被多人持有，审计无法对应到个人。
短信因素在国际漫游或短信延迟较高时会让管理员无法登录，所以要事先准备另一种因素，而不是临时关闭策略。关闭双因素本身应被当成敏感动作，需要现有因素确认并留下记录。双因素策略要按入口列出：哪些角色登录时需要、哪些动作需要再次确认、会话多久后必须重做、丢失因素时谁可以恢复。列出之后才算覆盖了连接管理里真正有风险的操作。
再次确认应发生在动作执行之前，而不是执行之后补一次记录。批量停机、导出和支付确认若已经提交到后台，再要求输入动态口令，口令失败也来不及撤回。确认窗口要短，通过后只允许完成这一次已经展示给用户的动作；用户若改了停机范围或金额，应重新确认。把一次确认套用到随后任意操作，等于确认之后又回到了单因素。
恢复手段不能比日常因素更容易被他人完成。备用码若发放，应限制数量、使用后作废，并在生成时提醒用户妥善保存；备用码被用掉时通知账号所有者。客服不能在只核对姓名或邮箱的情况下关闭双因素。关闭本身需要现有因素，因素全部丢失时走事先约定的人工核验，并留下工单。恢复完成后，旧的动态口令绑定失效，避免丢失的手机继续能通过验证。
记住设备的期限要有上限，而且不适用于敏感动作。登录可以在约定期限内少问一次，导出、停机和付款仍要重新确认。期限到期或用户主动取消后，下次登录恢复双因素。公共或共用的浏览器不应被记住。策略页面要能看出某个角色当前是登录需要、敏感动作需要，还是两者都需要，避免只打开了登录开关就认为策略已经完整。