2026年2月3日，FDA发布了网络安全上市前指南的最终版本，标题是"Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions"。这份指南替代了2025年6月27日的草案版本，生效时间恰好卡在QMSR（21 CFR Part 820）正式实施的第二天——2026年2月2日。这个时间点不是巧合，FDA等的就是QMSR落地，然后马上把网络安全指南拽到质量体系的轨道上来。
对企业来说，最直接的影响是：FDA在2026年的审查实践中，已经把附录1的八大安全控制类别当成了事实上的检查表。缺一项，审查员就会发缺陷信。这篇文章把指南的核心变化、SPDF与ISO 13485的映射关系、SBOM的法定要求、附录1逐条拆解、FDA今年最高频的五个缺陷模式全部讲清楚，最后给中国器械企业一份可以直接用的提交文件清单。
为什么FDA在QMSR生效次日就更新网络安全指南
FDA选择在QMSR生效的第二天发布终稿指南，信号很明确：网络安全不再是技术附件，而是质量体系的一部分。旧版指南引用的是QSR（21 CFR 820），新版全部替换为QMSR框架，术语、条款号、责任主体都跟着变了。
这个变化的实际意义在于审查逻辑的迁移。过去FDA审查网络安全材料，看的是你有没有做威胁建模、有没有提交SBOM，更多是技术文档审查。现在QMSR把ISO 13485纳入法规体系后，审查员的视角变了——你的威胁模型是否追溯到ISO 13485第7.3节的设计输入？你的安全测试是否锚定在7.3.7的设计确认中？你对已知漏洞的处理是否纳入了8.5节的改进流程？如果你的网络安全活动游离在质量体系之外，即使技术做得再好，FDA也会认为你的流程不完整。
指南的适用范围
这份指南覆盖了几乎所有需要FDA上市前审查的提交类型：
| 提交类型 | 是否适用 | 备注 |
|---|---|---|
| 510(k) | 是 | 包括Traditional、Special和Abbreviated |
| PMA | 是 | 包含PMA补充申请 |
| De Novo | 是 | |
| IDE | 是 | 研究性器械豁免 |
| HDE | 是 | 人道主义器械豁免 |
| BLA / IND | 是 | 含软件的生物制品许可申请 |
| 510(k)豁免器械 | 视情况 | 如果存在网络安全风险，仍建议处理 |
最后一条容易被忽略。FDA对"cyber device"的定义非常宽泛：只要设备包含软件（含固件、可编程逻辑），且具备连接互联网的能力（包括USB、蓝牙、串口、Wi-Fi、NFC，甚至未启用的调试端口），就可能被归入cyber device。即使你的设备在510(k)豁免清单上，如果它有USB接口用来导出数据，FDA很可能认为你需要处理网络安全问题。
指南的核心变化：从QSR到QMSR
对于已经熟悉2025年草案版本的企业来说，终稿在技术要求上没有大的变动，变化集中在框架层面的对齐。
术语和引用的全部替换
FDA把文档中所有对"QSR"的引用改成了"QMSR"，相应地，原来引用21 CFR 820具体条款的地方，改成了ISO 13485:2016的条款号。这不是文字游戏。QSR和ISO 13485虽然在很多地方一致，但在设计和改进流程上的表述和粒度有差异，FDA需要确保网络安全指南与新的法规基础完全对齐。
一个具体的例子：旧版指南提到"design controls under 21 CFR 820.30"，新版改为"design controls under Clause 7.3 of ISO 13485:2016 as incorporated by the QMSR"。看起来只是引用路径变了，但实际上ISO 13485的7.3节比820.30更细——7.3.2设计策划、7.3.3设计输入、7.3.4设计评审、7.3.5设计输出、7.3.6设计验证、7.3.7设计确认、7.3.8设计转换、7.3.9设计变更、7.3.10设计记录——每个子条款都需要网络安全活动的对应映射。
静态SBOM与生命周期模型的冲突
指南中有一个容易忽略但很重要的信号：FDA明确表示，为510(k)准备一份静态SBOM然后提交上去就完事，这种做法与QMSR的生命周期模型不匹配。SBOM应该是设计输出的一部分，随着产品的迭代持续更新。换句话说，FDA希望看到你的SBOM管理流程，而不只是一份快照文件。
这对中国企业的提交策略有直接影响。如果你的510(k)材料里只放了一份SBOM表格，审查员可能会追问你背后的管理机制——什么时候更新？谁来维护？组件EOL了怎么办？这些问题的答案需要追溯到你的质量体系程序。
SPDF框架：如何将网络安全嵌入ISO 13485设计控制
SPDF（Secure Product Development Framework，安全产品开发框架）是这份指南推荐的核心方法论。FDA没有指定某个具体的SPDF标准，但列出了三个认可的框架：
- AAMI TIR45：医疗器械行业特有的安全开发指南
- IEC 81001-5-1：健康软件生命周期过程的网络安全要求
- ANSI/ISA 62443-4.1：工业自动化系统的安全产品开发生命周期要求
不管你选哪个框架，FDA的核心期望是：SPDF的活动必须能追溯到ISO 13485的设计控制条款。下面这张表把SPDF的关键活动与ISO 13485做了映射。
SPDF与ISO 13485设计控制的映射
| SPDF活动 | ISO 13485条款 | 你需要做什么 | 提交证据 |
|---|---|---|---|
| 安全需求定义 | 7.3.3 设计输入 | 将网络安全功能需求（认证、加密、日志等）纳入设计输入文件，与临床需求并列 | 设计输入文档中的网络安全需求章节 |
| 威胁建模 | 7.3.3 设计输入 / 7.3.2 设计策划 | 在设计策划阶段识别威胁来源、攻击面、潜在攻击路径。推荐STRIDE或攻击树方法 | 威胁建模报告（含数据流图、威胁列表、风险缓解措施） |
| 安全架构设计 | 7.3.5 设计输出 | 定义安全架构：分段隔离、最小权限、加密方案、安全通信协议 | 安全架构文档、网络安全设计说明 |
| 安全编码规范 | 7.3.5 设计输出 / 生产控制 | 建立并执行安全编码标准（如MISRA、CERT C/C++），禁止使用不安全函数 | 编码规范文档、静态分析报告 |
| 安全测试（单元级） | 7.3.6 设计验证 | 对安全关键模块进行单元测试，覆盖边界条件和异常输入 | 单元测试报告（含安全相关测试用例） |
| 渗透测试 | 7.3.7 设计确认 | 在生产等效配置上执行渗透测试，模拟真实攻击场景 | 渗透测试报告（含测试范围、发现的漏洞、修复状态） |
| 漏洞管理 | 8.5 改进 / 7.3.9 设计变更 | 建立持续漏洞监控流程，对已知CVE进行分诊和响应 | 漏洞管理程序、SBOM/VEX文档 |
| 安全更新机制 | 7.3.8 设计转换 / 7.3.9 设计变更 | 设计安全的固件/软件更新通道（签名验证、回滚保护） | 更新机制设计文档 |
这张表的核心逻辑是：网络安全活动不能游离在质量体系之外。每一项安全工作都需要在ISO 13485的设计控制流程中找到位置，并且留下可追溯的记录。
威胁建模的具体要求
FDA在指南中明确要求提交威胁建模报告，并且给出了几个推荐的方法论：
- STRIDE（Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege）：微软提出的威胁分类框架，适合系统级分析
- 攻击树（Attack Trees）：从攻击者视角建模，分析达成攻击目标的可能路径
- MITRE方法：基于MITRE ATT&CK框架的威胁建模，适合复杂系统
就实际经验而言，对于大多数中国器械企业来说，STRIDE是最务实的起点。它的六类威胁覆盖面足够广，学习曲线也不陡。关键是要画出数据流图（DFD），标注信任边界，然后对每个数据流和外部实体做STRIDE分析。
很多企业提交的威胁建模报告流于形式——画个系统框图，列几个通用威胁，然后说"通过加密和认证缓解"。FDA在2026年的审查中对此越来越严格。审查员会看你的威胁建模是否针对设备的具体架构和通信场景，而不是模板化的泛泛之谈。
安全风险管理：不是ISO 14971的附属品
这一点值得单独展开讲。FDA在指南中反复强调：网络安全风险管理（Security Risk Management）与ISO 14971的安全风险管理（Safety Risk Management）是两套体系，不能合并。
两套体系的核心区别
| 维度 | ISO 14971安全风险 | FDA网络安全风险 |
|---|---|---|
| 评估对象 | 患者伤害 | 机密性、完整性、可用性 |
| 评估方法 | 概率 x 严重度 | 可利用性（exploitability） |
| 风险接受标准 | 基于临床获益 | 基于残余风险的合理性和补偿控制 |
| 标准依据 | ISO 14971:2019 | IEC 81001-5-1 / AAMI TIR57 |
| 输出文档 | 风险管理报告 | 安全风险管理报告（独立文档） |
概率模型用在网络安全上会失灵。一个CVSS 9.8的远程代码执行漏洞，用ISO 14971的概率矩阵来评，可能得出"发生概率极低、风险可接受"的结论——因为现实中某家医院被攻击的"概率"确实不高。但攻击者不需要一家一家攻击，一个自动化脚本就能扫描全网。FDA要求的是可利用性评估：这个漏洞能不能被利用？利用的难度有多高？需要什么条件？而不是"发生的概率有多大"。
安全风险管理报告应该包含什么
一份合格的网络安全风险管理报告，FDA期望看到以下内容：
- 资产识别：设备中有哪些需要保护的资产（患者数据、配置参数、固件、密钥等）
- 威胁识别：谁可能攻击这个设备？攻击动机是什么？（与威胁建模衔接）
- 漏洞识别：设备存在哪些安全弱点？通过渗透测试、静态分析、SBOM分析来发现
- 可利用性评估：每个漏洞被利用的技术可行性（攻击向量、复杂度、所需权限）
- 影响评估：如果被成功利用，对机密性、完整性、可用性的影响
- 风险缓解：你采取了什么控制措施（对应附录1的八大类别）
- 残余风险评估：缓解后的残余风险是否可接受，理由是什么
- 与ISO 14971的交叉引用：哪些网络安全风险可能转化为患者伤害，追溯到安全风险管理文件
第8点很重要。两套体系独立运行，但需要有接口。如果一个网络安全漏洞被利用后可能导致患者受伤（比如胰岛素泵的剂量被远程篡改），这个场景需要同时出现在网络安全风险报告和ISO 14971的风险管理文件中。
SBOM：从"建议提交"到"法定要求"
Section 524B(b)(3)已经把SBOM变成了法定义务。不提供SBOM属于FD&C Act第301(q)条规定的禁止行为，FDA可以据此拒绝审查或采取执法行动。这不是指南建议，是法律要求。
SBOM必须包含什么
FDA在2026年的审查实践中，对SBOM的检查非常具体：
| SBOM字段 | FDA的期望 | 常见问题 |
|---|---|---|
| 组件清单 | 所有软件组件（含传递依赖） | 遗漏传递依赖，只列了直接集成的库 |
| 版本号 | 精确到补丁级别 | 用"最新版"或模糊版本号 |
| 供应商信息 | 组件来源和供应商名称 | 开源组件未标注维护组织 |
| 依赖关系 | 组件间的调用链和依赖树 | 依赖关系缺失或不完整 |
| 支持级别 | 活跃维护/仅安全补丁/已弃用 | 全部标注为"活跃"，但很多组件已停更 |
| EOL/EOS日期 | 供应商计划终止支持的日期 | 不提供，或提供过期信息 |
| 已知漏洞 | CISA KEV目录中的已知利用漏洞 | 不做KEV交叉比对 |
| 格式 | CycloneDX或SPDX，机器可读 | 提交Excel或PDF（不被接受） |
"过滤过的SBOM"是FDA在2026年特别关注的问题。有些企业提交的SBOM只包含自己认为"重要"的组件，过滤掉了底层库、操作系统组件或传递依赖。FDA明确表示这不合规——SBOM必须是完整的。
SBOM格式选择
FDA接受两种标准格式：
- CycloneDX（OWASP维护）：医疗器械行业采用更广泛，对漏洞管理和VEX支持更好
- SPDX（Linux基金会维护）：软件行业通用，许可证合规功能更强
我们的建议是选CycloneDX。原因不只是行业惯例——CycloneDX的原生支持包括了"支持级别"和"EOL日期"字段，而这些恰好是FDA特别关注的。SPDX虽然也能通过扩展字段实现，但需要额外配置。
附录1：FDA把建议当检查表用的八大控制
附录1列出了八个安全控制类别。指南文本中用了"recommended"这个词，但FDA在2026年的审查实践中已经在按检查表逐项核对了。如果你缺少某项控制且没有提供合理的书面理由（justification），审查员大概率会发缺陷。
八大控制类别详解
| 类别 | 英文名称 | 控制要求 | 典型证据 |
|---|---|---|---|
| 认证 | Authentication | 确保用户和设备的身份可验证。多因素认证（MFA）在适用场景中推荐 | 认证机制设计文档、密码策略、MFA实现说明 |
| 授权 | Authorization | 基于角色的访问控制（RBAC），最小权限原则 | 权限矩阵、角色定义文档、访问控制策略 |
| 密码学 | Cryptography | 数据传输和存储的加密保护。使用经过验证的加密算法和标准库 | 加密方案说明、TLS配置、密钥管理方案 |
| 代码/数据完整性 | Code/Data Integrity | 防止未经授权的代码和数据修改。固件签名验证 | 签名验证机制、哈希校验、启动链安全（Secure Boot） |
| 机密性 | Confidentiality | 保护敏感数据（患者数据、配置参数）不被泄露 | 数据分类方案、加密存储策略、传输加密 |
| 事件检测与日志 | Event Detection & Logging | 记录安全相关事件，支持事后审计和取证 | 日志策略、事件分类、日志存储和保护方案 |
| 弹性 | Resiliency | 在遭受攻击或故障时保持基本功能（安全降级） | 降级模式设计、容错机制、恢复策略 |
| 可更新性 | Updatability | 支持安全补丁的安装，更新过程本身也要安全 | 更新机制设计、签名验证、回滚保护、更新通道说明 |
每项控制需要准备的提交材料
FDA没有要求你对每一项控制都提供独立的文档，但在510(k)或PMA的网络安全材料中，审查员需要能找到每项控制的对应证据。实际操作中，很多企业用一份网络安全控制矩阵（Cybersecurity Controls Matrix）来汇总：
| 控制类别 | 设备中的实现 | 对应设计文档章节 | 测试证据 | 备注 |
|---|---|---|---|---|
| Authentication | 用户登录使用用户名+密码，管理功能需证书认证 | 设计说明3.2节 | 测试报告TC-SEC-001 | N/A |
| Authorization | 三种角色：操作员/技师/管理员，权限矩阵见附件A | 设计说明3.3节 | 测试报告TC-SEC-002 | N/A |
| Cryptography | TLS 1.3用于所有网络通信，AES-256用于数据存储 | 安全架构4.1节 | 渗透测试报告PEN-001 | N/A |
| ... | ... | ... | ... | ... |
对于确实不适用的控制项，你需要提供书面理由（justification）。比如你的设备是单机版、完全没有网络接口，那么"事件检测与日志"中的远程日志传输可能不适用。但即使在这种场景下，本地日志记录大概率仍然是需要的——justification要说得有说服力，不能一句话"不适用"就打发了。
FDA 2026年最高频的五个缺陷模式
根据Medcrypt对2026年FDA网络安全审查反馈的分析，以下五种缺陷出现频率最高。
| 排名 | 缺陷类型 | FDA的关注点 | 为什么会被抓 | 怎么修 |
|---|---|---|---|---|
| 1 | 渗透测试不充分 | 测试范围不完整、发现的漏洞未关闭、测试版本与生产版本不一致 | FDA要求渗透测试在生产等效配置上执行，且所有高危/严重发现必须关闭或提供残余风险接受理由 | 使用生产版本的完整构建做测试；提供漏洞修复追踪表，标注每个发现的修复状态；如果接受残余风险，附上书面理由 |
| 2 | SBOM不完整 | 非机器可读、缺少支持级别和EOL日期、"过滤"后的SBOM | 审查员会用自动化工具解析你的SBOM，格式不对直接拒绝；信息不全的SBOM会被追问 | 使用CycloneDX JSON格式；包含所有组件含传递依赖；标注每个组件的支持级别和EOL日期 |
| 3 | 附录1控制缺失且无理由 | 某些控制类别完全没有提及，或只写了一句话 | FDA已经按检查表逐项核对 | 建立网络安全控制矩阵，逐项对照附录1；不适用的项目提供书面justification |
| 4 | 网络安全标签不充分 | 缺少连接接口披露、没有支持寿命声明、缺少补丁安装说明 | FDA要求设备标签中包含网络安全相关的信息披露 | 在IFU/标签中增加：连接接口列表、支持寿命（support lifetime）、补丁/更新获取方式、用户可采取的安全措施 |
| 5 | 安全风险与安全（ISO 14971）混为一谈 | 用ISO 14971的风险评估方法处理网络安全问题 | 概率模型不适用于网络安全评估，FDA明确要求分开 | 建立独立的网络安全风险管理流程，使用可利用性评估方法；与ISO 14971保持接口但独立运行 |
这五个缺陷覆盖了2026年FDA网络安全审查反馈的大部分案例。排第一的渗透测试问题尤其值得注意——不少企业找了第三方做了渗透测试，报告看起来也很专业，但FDA追问的点是：你的测试环境是不是跟生产环境一致？你发现的那些中高危漏洞关了没有？你的测试版本号跟510(k)申请的版本号对得上吗？这些问题答不好，渗透测试报告再厚也没用。
中国器械企业网络安全提交文件包清单
对于正在准备510(k)或PMA的中国器械企业，我们把需要准备的网络安全相关文件整理成了一份清单。这份清单基于FDA 2026年指南要求和实际审查反馈，按文件类型分组。
文档清单
| 序号 | 文档名称 | 用途 | 参考依据 |
|---|---|---|---|
| 1 | 网络安全风险管理报告 | 独立于ISO 14971的网络安全风险评估 | 指南Section V、IEC 81001-5-1 |
| 2 | 威胁建模报告 | 识别设备面临的威胁、攻击面和攻击路径 | 指南Section V、STRIDE/攻击树 |
| 3 | 网络安全控制矩阵 | 逐项对照附录1的八大控制类别 | 指南Appendix 1 |
| 4 | SBOM（CycloneDX JSON） | 软件物料清单，法定要求 | Section 524B(b)(3) |
| 5 | VEX文档 | 对SBOM中已知漏洞的可利用性判定 | 指南Section VI |
| 6 | 渗透测试报告 | 模拟攻击测试，验证安全控制的有效性 | 指南Section V |
| 7 | 安全架构设计文档 | 设备的安全架构、加密方案、通信安全设计 | 指南Section IV |
| 8 | SPDF流程文档 | 安全产品开发框架的实施说明 | 指南Section IV、ISO 13485 7.3 |
| 9 | 网络安全标签信息 | IFU/标签中的网络安全披露内容 | 指南Section VII |
| 10 | 软件描述文档 | 设备软件功能的概述、架构、第三方组件说明 | 指南Section IV |
提交时的注意事项
文档一致性是很多中国企业的薄弱环节。你的SBOM里的组件版本号，要跟渗透测试报告里测试的版本号一致；你的威胁建模报告里的攻击面，要跟安全架构文档里的设计一致；你的网络安全控制矩阵里引用的测试报告编号，要能在渗透测试报告中找到对应条目。FDA审查员会交叉核对这些材料，一旦发现对不上，信任度会大幅下降。
另一个常见问题是文档语言。FDA接受英文提交，如果你的原始文档是中文的，需要翻译。翻译质量很重要——"安全"（security）和"安全"（safety）在中文里是同一个词，但在FDA的语境中是完全不同的概念。建议在翻译后做一次术语审校，确保security和safety没有混用。
渗透测试的具体要求：不是走过场
渗透测试是FDA审查中关注度最高的证据之一，也是2026年缺陷频率排第一的项目。很多企业低估了FDA对渗透测试的期望，做了但不达标。
FDA对渗透测试的核心期望
FDA不是在找一个"通过/不通过"的测试结果，而是在看你发现问题的能力和解决问题的态度。具体来说：
-
测试范围必须覆盖设备的所有攻击面。如果你的设备有Wi-Fi、蓝牙、USB、以太网四种接口，渗透测试需要逐一测试每个接口的攻击向量。只测了一个接口的报告会被打回来。
-
测试必须在生产等效配置上进行。"生产等效"的意思是：相同的硬件平台、相同的软件版本（精确到build号）、相同的配置参数。在开发板上用debug版本做的渗透测试不被接受。
-
所有发现必须追踪到最终状态。渗透测试报告不只是列出发现的漏洞，还需要标注每个漏洞的最终处理结果——已修复、接受残余风险（附理由）、计划在后续版本修复（附时间线）。
-
测试方法论需要说明。FDA不指定具体的测试方法，但你需要在报告中说明你用了什么方法论（如OWASP Testing Guide、PTES）、测试了哪些攻击向量、用了什么工具（如Burp Suite、Metasploit）。
渗透测试报告的最低要求结构
| 报告章节 | 内容 |
|---|---|
| 1. 测试范围 | 设备型号、软件版本号、硬件平台、测试的攻击面列表 |
| 2. 测试环境 | 测试环境配置与生产环境的对比说明 |
| 3. 测试方法论 | 采用的测试框架、工具、攻击向量列表 |
| 4. 测试结果 | 按漏洞严重度排序，每个发现包含：描述、CVSS评分、复现步骤 |
| 5. 修复状态追踪 | 每个发现的当前状态（已修复/接受风险/计划修复），修复证据或接受理由 |
| 6. 重新测试结果 | 修复后的回归测试结果，确认高危/严重漏洞已关闭 |
| 7. 残余风险评估 | 未关闭的残余风险及其接受理由 |
第6点（重新测试）是很多企业漏掉的。FDA期望你对修复后的版本至少做一轮回归测试，确认之前发现的漏洞确实被关闭了。只做一轮测试、修了几个问题但没有重新验证——这种报告在FDA看来是"半成品"。
标签中的网络安全信息披露
FDA在指南的Section VII中列出了设备标签（包括IFU和使用说明）中需要包含的网络安全信息。这是2026年缺陷频率排第四的领域。
标签中必须包含的网络安全信息
| 信息类别 | 具体内容 | 常见遗漏 |
|---|---|---|
| 连接接口披露 | 列出设备所有的网络/通信接口（Wi-Fi、蓝牙、USB、以太网、串口等） | 只列出"主要"接口，遗漏调试端口或工程接口 |
| 支持寿命声明 | 明确设备获得网络安全更新和支持的时间期限 | 不提供，或含糊地说"持续支持" |
| 补丁/更新获取方式 | 用户如何获取和安装安全补丁 | 只说"联系厂商"，没有具体流程 |
| 用户安全措施 | 用户可采取的网络安全防护措施（如修改默认密码、网络分段） | 完全不提及用户的责任 |
| 安全事件报告 | 发现安全事件时的报告渠道 | 没有提供联系方式或报告流程 |
| 已知局限性 | 设备网络安全方面的已知限制 | 不愿意主动披露任何弱点 |
支持寿命（support lifetime）是一个相对新的要求。FDA要求你在标签中明确说明你承诺为该设备提供网络安全更新到什么时候。这个日期需要与你实际的维护计划一致，不能随便写一个"10年"然后实际上两年就停更了——那样做会跟你自己的质量体系程序矛盾。
常见问题与解答
我的设备没有联网功能，还需要处理网络安全吗？
FDA对"连接能力"的定义比你想象的宽。如果你的设备有USB接口可以导出数据、有蓝牙用来配对配件、有串口用来固件升级——这些都被视为"连接能力"。FDA看的是技术能力，不是设计意图。如果你的设备确实完全没有通信接口（纯模拟设备、机械装置），那么网络安全要求不适用。但这种情况在当下的器械市场中越来越少见了。
SBOM必须包含操作系统吗？
是的。FDA期望SBOM覆盖设备中所有软件组件，包括操作系统（无论是Windows Embedded、Linux发行版还是实时操作系统）。操作系统通常是攻击面的重要组成部分， omitting it from the SBOM makes the document incomplete in FDA's view.
如果你用的是定制Linux发行版，SBOM需要列出内核版本、用户空间工具链、系统库等。如果你用的是Windows IoT，需要列出Windows版本号、补丁级别、启用的服务和组件。这些信息不只是给FDA看的——当下一个像Log4Shell那样的漏洞出现时，你需要能快速判断你的设备是否受影响。
附录1的控制项可以合并吗？
可以，但需要有文档说明。比如"认证"和"授权"在你的设备架构中可能紧密耦合（同一套身份管理系统同时处理认证和授权），这种情况下可以在同一份设计文档中描述，但建议在控制矩阵中分别列出，标明引用的文档章节和测试证据编号。不要让审查员自己去猜哪项控制在哪里。
渗透测试可以自己做吗？
技术上可以，FDA没有强制要求第三方执行。但我们的建议是找第三方，原因有两个。一是独立性问题——自己测自己的系统，很难做到客观。FDA审查员对第三方报告的接受度更高。二是专业度问题——渗透测试需要专门的技能和工具，大多数器械企业的研发团队不具备这个能力。如果预算有限，至少请第三方做一次基线测试，后续的回归测试可以自己做。
我的510(k)已经提交了但还没批准，需要按新指南补充材料吗？
大概率需要。如果FDA在你提交后发出了补充信息请求（Additional Information, AI letter），且其中涉及网络安全内容，FDA会按2026年2月3日的终稿指南来评估你的补充材料。建议主动对照终稿指南检查你的网络安全材料，特别是附录1控制矩阵和SBOM格式，在FDA发AI letter之前就把缺口补上。
参考资源
- FDA Final Guidance: Cybersecurity in Medical Devices (2026年2月3日终稿) — FDA官方终稿指南全文，所有上市前网络安全要求的原始出处
- Medcrypt: Navigating the 2026 FDA Cybersecurity Landscape — Lessons from the Top Deficiencies — 基于实际FDA审查反馈的缺陷模式分析，本文"最高频缺陷"部分的主要数据来源
- DLA Piper: FDA Issues Revised Cybersecurity Premarket Submission Guidance — 法律视角的指南解读，QMSR对齐和法定义务的分析
- Hattrick IT: What Changed in the Updated FDA Cybersecurity Guidance — 逐条对比2025草案与2026终稿的变化，适合已经熟悉旧版的企业快速掌握差异
- L4B Software: FDA Cybersecurity Medical Device OS Perspective — 从操作系统和嵌入式平台角度解读指南要求，适合使用Linux/RTOS的器械企业
- Exponent: Navigating FDA's Cybersecurity in Medical Devices Guidance — 工程咨询视角的指南解读，SPDF实施和安全测试的实务建议
相关文章
FDA ASCA检测报告实验室尽调：中国企业510(k)如何避免实验室资格撤回和数据完整性风险
FDA ASCA计划让510(k)审查加速，但2025年9月FDA首次撤销多家实验室资格暴露了数据完整性风险。本文为中国器械出口商提供ASCA实验室选择、资格验证、报告包构建和应急切换的完整操作指南。
FDA ASCA检测报告尽调：中国企业510(k)提交前必须做的实验室资格审查
FDA ASCA（符合性评估认证方案）为510(k)和De Novo提交提供测试报告快速通道，但2025年已有2家ASCA认证实验室被FDA撤销资格。中国医疗器械出口商在选择检测实验室时，必须独立评估实验室的资质状态、数据完整性和ASCA范围覆盖。本文提供实验室选择清单、ASCA报告接受包构建方法、撤回应对策略和重新测试决策树。
FDA人因验证失败后的补救研究：summative test没过，什么时候能桥接、什么时候必须重做
中国医疗器械企业summative人因验证测试失败后的完整补救路径：根因分类、桥接研究vs全面重做决策树、IFU/培训修改策略、残余风险论证和FDA回复证据包。