物联网电子健康系统可能长期保存敏感数据，因此需要同时考虑当前安全与未来密码迁移。后量子密码学（PQC）关注抵抗未来量子计算攻击的算法；TLS 1.3是安全传输协议版本，两者不能直接画等号。本文说明身份认证与传输方案需要核对的工程边界，不提供未经验证的部署效果或认证通过承诺。
TLS 1.3不自动等于抗量子安全
TLS 1.3可以使用传统公钥算法。系统是否具有相应后量子能力，取决于实际采用的密钥建立、签名算法、协议组合、库版本和端点支持，不能只检查协议版本号。
传输加密、设备身份和应用权限也不是同一件事。安全连接不能证明设备数据正确，更不能替代业务层访问控制。
区分密钥建立与数字签名
NIST于2024年批准的FIPS 203定义ML-KEM密钥封装机制，FIPS 204与205分别定义数字签名方案。它们承担不同功能，选择时应明确系统究竟需要建立会话密钥，还是验证签名和身份。
不能把使用某种格算法直接表述为全部认证过程已经抗量子。还应说明证书、信任根、参数、密钥生命周期和实际实现。
设备、网关和服务端要共同验证
终端资源、通信带宽和已有协议会限制密码方案选择。应核对双方支持的算法与参数，并验证协商失败、版本不兼容和更新失败时的行为。
性能测试应覆盖目标硬件上的运算时间、内存、消息大小、能耗和异常情况。论文或其他系统的结果不能直接代替当前产品的测试。
健康数据系统还需要哪些基础措施
设备与人员应采用合适的身份认证和最小权限，保护密钥和敏感日志，记录关键操作。数据传输、存储、备份和导出都需要明确访问边界。
适用的数据保护、医疗设备和研究要求，应根据实际部署地区、数据类型与系统用途确认，不能把某个海外规则写成所有项目的统一要求。
迁移与验收需要明确退出条件
先记录系统中的算法、证书、依赖库和端点能力，形成迁移清单，再开展兼容性与风险评估。涉及高风险健康业务时，应由相应专业人员确认方案和验收要求。
验收应能说明所用算法和版本、协议实际协商结果、密钥管理、性能数据与失败处置；没有这些证据时，不宣称已经完成安全验证。
技术依据可参阅TLS 1.3标准RFC 8446与NIST后量子密码标准说明。具体产品方案仍需结合目标硬件、协议和数据风险验证。
