ARTICLE · 1050667
FDA Premarket网络安全技术文档到底要准备哪些?
对于准备510(k)、De Novo、PMA等FDA Premarket Submission的医疗器械制造商，一个非常实际的问题是：
网络安全到底要准备哪些文件？
2026 FDA Cybersecurity Guidance已经给出了相对完整的Submission Documentation框架。
但需要先明确一点：
FDA并不是要求制造商机械准备一套固定名称的文件。
FDA在Appendix 4中特别说明，推荐的网络安全资料应随着产品Cybersecurity Risk、架构复杂程度和连接能力进行Scaling；同时，Appendix中的表格也不应被简单理解为一个Deliverable Checklist。制造商可以按照自身现有文件体系组织这些内容，只要能够完整呈现相应的设计、风险和验证活动。
因此，真正重要的是：
FDA能否从提交资料中看清楚产品的Threat、Risk、Architecture、Control、Testing以及上市后维护之间的完整逻辑。
01
「FDA推荐的网络安全
Submission资料框架 」
FDA-Recommended Cybersecurity Submission Documentation Framework
从2026 Guidance的结构来看，Premarket网络安全资料主要可以归纳为六个部分：
1
Cybersecurity Risk Management Report
2
Threat Modeling/Cybersecurity Risk Assessment
3
SBOM / Vulnerability & Software Support
4
Security Architecture & Security Controls
5
Cybersecurity Testing
6
Labeling & Cybersecurity Management Plan
其中，Threat Model、Cybersecurity Risk Assessment、SBOM、Vulnerability Assessment、Unresolved Anomalies以及Traceability等内容，可以作为Cybersecurity Risk Management Report的一部分，也可以根据企业现有文件体系分别管理。
FDA明确表示，制造商不一定需要为了Submission重新拆分或创建新的独立文件，可以引用现有受控文档中的相关章节。
02
「Cybersecurity Risk Management
Report：整个文件体系的主线 」
Cybersecurity Risk Management Report: The Core
Thread of the Entire Documentation Framework
Cybersecurity Risk Management Report可以理解为整个网络安全Submission资料的“总索引”。
FDA建议，这份报告能够覆盖：
System Threat Modeling
Cybersecurity Risk Assessment
SBOM
Component Support Information
Vulnerability Assessment
Unresolved Anomaly Assessment
并对这些活动形成总结。
报告还应该说明：
Residual Risk Conclusion
已经实施的Risk Mitigation
不同网络安全文件之间的Traceability
因此，这份文件不应该只是另一张Risk Table。
它真正应该回答：
制造商采用了什么方法识别网络安全风险，这些风险如何被控制，以及最终为什么可以认为Residual Risk可接受。
03
「Threat Model：先把整个
Medical Device System看清楚 」
Threat Model: First Understand
the Entire Medical Device System
Threat Modeling是FDA网络安全风险管理的重要输入，FDA建议Threat Modeling贯穿整个Design Process，并覆盖所有Medical Device System Elements。
其内容应该能够识别：
产品资产
潜在Threat
Vulnerability
系统接口
环境假设
Supply Chain
Deployment
Interoperability
Maintenance / Update
Decommission
所以Threat Model不能只针对：
“设备主机里面的软件。”
如果一个产品实际由以下几部分共同组成：
Medical Device + Mobile App + Cloud + Hospital Network + Update Server
那么Threat Modeling就需要从整个System角度进行分析，实际项目中通常还会结合以下一些方式支持分析：
Data Flow Diagram
Trust Boundary
Attack / Threat Surface
Security Use Cases
04
「Cybersecurity Risk Assessment：
Threat最终如何变成Risk？」
Cybersecurity Risk Assessment:
How Does a Threat Become a Risk?
Threat Model回答的是：
“可能发生什么？”
Cybersecurity Risk Assessment进一步回答：
“如果发生，风险是多少，我们应该怎么控制？”
FDA要求Cybersecurity Risk Assessment体现：
识别的Threat和Risk
对应的Security Controls
Mitigation前后的风险
风险评价方法
Acceptance Criteria
Cybersecurity Risk与Safety Risk之间如何进行Transfer或关联
最终最好能够形成逻辑：
1
Threat
2
Vulnerability
3
Exploitability
4
Security Impact
5
Safety Impact
6
Security Control
7
Residual Risk
这一部分尤其不能直接套用传统ISO 14971概率模型。
FDA指出，Cybersecurity Risk更强调Exploitability，而不是简单依赖历史发生概率，因此Security Risk和Safety Risk应被视为不同但相关联的评价过程。
05
「SBOM不能单独提交，
还需要Vulnerability Assessment 」
SBOM Cannot Be Submitted Alone,
a Vulnerability Assessment Is Also Required
SBOM是目前FDA Premarket Cybersecurity非常核心的一份资料，对于Cyber Device，§524B(b)(3)明确要求提交SBOM。
FDA 2026 Guidance进一步建议：
SBOM采用Machine-readable Format，并针对软件组件提供相应的Support Status以及End-of-Support Date。
但SBOM只是基础，FDA还要求制造商识别与产品及软件组件有关的Known Vulnerabilities，包括：
CISA Known Exploited Vulnerabilities（KEV）
并对识别出的漏洞开展：
Safety Risk Assessment
Security Risk Assessment
对应Risk Controls的说明
因此更完整的逻辑应该是：
06
「Unresolved Anomalies也需要重新从Cybersecurity角度评价 」
Unresolved Anomalies Also
Require Cybersecurity Reassessment
软件开发过程中通常都会存在部分尚未解决的Software Anomalies，一个Anomaly从普通Software Risk角度可能被认为影响较小。
但从Cybersecurity角度，它可能成为攻击者主动利用的Vulnerability，FDA因此特别建议：
对于Submission时仍然存在的Unresolved Anomalies，需要进一步评价其可能产生的Security Impact，并考虑相关CWE类别。
例如：
一个偶发的软件异常，在正常使用情况下出现概率很低，但攻击者如果能够主动构造输入，并持续触发该异常，就可能导致：
Crash
其他安全影响
Denial of Service
Privilege Escalation
因此：
Software Anomaly Assessment与Cybersecurity Vulnerability Assessment不能完全割裂。
07
「Unresolved Anomalies也需要
重新从Cybersecurity角度评价 」
Unresolved Anomalies Also
Require Cybersecurity Reassessment
Security Architecture是FDA 2026 Guidance中非常值得重视的一部分。
FDA建议Premarket Submission至少考虑以下几类Architecture Views：
01
Global System View
用于展示整个Medical Device System：
设备
内部和外部连接
Cloud
Software Update Infrastructure
Hospital Network
Patient Home Network
其他Interconnected Elements
02
Multi-Patient Harm View
重点关注：
如果某个网络安全问题被同时利用，是否可能影响多个患者或多台设备。
03
Updateability / Patchability View
重点说明：
软件或Firmware Update如何生成、传输、验证、安装
产品是否能够安全、及时完成Patch
04
Security Use Case View
根据具体功能展示网络安全控制如何工作，例如：
Remote Access
Programming
Data Transfer
Authentication
Cloud Communication
对于结构简单的产品，可能每类只需要有限的View；而对于包含Wireless、Cloud、Commercial OS等复杂系统，FDA预期Architecture Views会相应增加。
08
「Architecture View不是一张漂亮的框图 」
Architecture View Is More Than a Pretty Block Diagram
这点尤其需要注意，FDA需要的是能够支持Review的技术架构资料。
除了图，还需要Supporting Explanatory Text，根据FDA Appendix 2，Architecture Documentation可以进一步涉及：
Assets
Interfaces
Protocol
User Role
Access Control
Authentication
Cryptography
Communication Path
Port / Channel / Frequency
Data / Code / Command Flow
Credential Management
Session Management
Security Configuration
与Risk、Control和Testing间的Traceability
Architecture View的目的不是告诉FDA“系统有哪些模块”，而是让Reviewer看懂安全控制到底在哪里、怎么工作。
09
「Cybersecurity Testing Documentation：
证明Security Controls有效 」
Cybersecurity Testing Documentation:
Demonstrating the Effectiveness of Security Controls
Risk和Architecture都完成以后，还需要通过Testing证明：Security Controls真正有效
FDA明确建议将Cybersecurity Testing Documentation及相关Report / Assessment提交至Premarket Submission。
测试内容可包括：
Security Requirement Verification
Threat Mitigation Testing
Abuse / Misuse Cases
Malformed / Unexpected Input
Robustness Testing
Fuzz Testing
Attack Surface Analysis
Vulnerability Chaining
Known Vulnerability Scanning
Software Composition Analysis
Static / Dynamic Code Analysis
Penetration Testing
Penetration Test Report还需要说明：
测试人员的Independence和Technical Expertise
Testing Scope
Duration
Methods
Results
Findings
Observations
所以FDA要的不是：
“一张Penetration Test Pass报告。”
而是能够判断：
测试范围为什么这样确定、测试覆盖了哪些Risk Controls，以及发现的问题如何被处理。
10
「Cybersecurity Labeling：
用户也属于Risk Control的一部分 」
Cybersecurity Labeling: Users Are Part of Risk Control
网络安全有些风险无法完全通过产品自身设计解决，这时用户的：
安装
网络环境
密码管理
配置
Patch
运行维护
可能成为风险控制的一部分。
因此FDA建议在Labeling中向用户提供充分的Cybersecurity Information。
根据产品情况，可以包括：
网络端口和接口
推荐Firewall和Anti-malware
Password Requirements
Secure Configuration
Software / Firmware Update
Security Event和Logging
Backup / Restore
End of Support / End of Life
Secure Decommission
FDA甚至明确建议说明如何捕获和管理Security Event相关Forensic Evidence，以及设备进入End of Support以后Cybersecurity Risk如何转移和沟通。
所以：
Labeling不是网络安全技术文件最后随便增加几条Warning。
它本身也是整个Risk Control Strategy的一部分。
11
「Cybersecurity Management Plan：
FDA要看“上市以后怎么办” 」
Cybersecurity Management Plan: FDA Wants to Know
“What Happens After Market Launch”
FDA Premarket Submission还有一个很容易被忽略的文件：
Cybersecurity Management Plan
这份文件的核心不是描述产品现在是否安全。
而是回答：
产品上市以后出现新的漏洞怎么办？
FDA建议其中包括：
责任人员
NIST NVD
CISA KEV
Update Process；
Patching Capability
Patch开发和发布周期
漏洞监测来源、方法和频率
Third-party Software Manufacturer信息
Periodic Security Testing
Coordinated Vulnerability Disclosure
Customer Communication
对于Cyber Device，这一要求又与FD&C Act §524B(b)(1)直接关联。
因此，FDA的逻辑非常清楚：
上市后的Cybersecurity能力，也要在Premarket阶段向FDA证明已经规划好。
12
「真正重要的文件其实叫Traceability 」
The Most Important Document Is Actually Traceability
如果要从所有FDA网络安全资料中挑出一个最容易被忽视、但最重要的概念，那就是：
Traceability
FDA明确建议Security Risk Management Report建立：
1
Threat Model
2
Cybersecurity Risk Assessment
3
SBOM
4
Testing
5
Cybersecurity Documentation的Traceability
最终应该能够追溯：
同时还能关联：
SBOM Component→Known Vulnerability→Risk Control→Patch / Postmarket Monitoring
如果这些链条断开，即使企业提交了很多文件，也很容易出现FDA继续追问。
13
「文件不是越多越好，而是要和风险匹配 」
More Documentation Is Not Better, It Should Match the Risk
FDA在Appendix 4中特别强调：
Cybersecurity Documentation需要根据产品风险进行Scaling。
一个只有单一USB接口、软件依赖较少的产品，与一套包含以下内容的医疗器械系统，不应该采用完全相同的文档深度：
Wi-Fi
Bluetooth
Cloud
Hospital Network
Commercial OS
Remote Update
大量Third-party Components
FDA也明确指出，Architecture Views和Threat Modeling最能体现这种Risk-based Scaling。
所以正确的做法不是：
“网上找到一套FDA Cybersecurity模板，然后全部填完。”
而是：
先理解产品，再根据风险决定文件深度。
14
「FDA Premarket网络安全
资料的推荐准备顺序 」
Recommended Preparation Order for
FDA Premarket Cybersecurity Documentation
从实际项目执行角度，建议按照这个顺序：
1
System / Product Architecture
2
Threat Modeling
3
Cybersecurity Risk Assessment
4
Security Requirements
5
Security Architecture & Controls
6
SBOM / Vulnerability Assessment
7
Cybersecurity Testing
8
Residual Risk & Traceability
9
Cybersecurity Labeling
10
Cybersecurity Management Plan
11
Cybersecurity Risk Management Report整合
这个顺序和最终提交文件名称不一定完全相同。
但它符合网络安全设计和风险管理本身的逻辑：
先知道系统是什么、可能发生什么，再决定怎么控制，最后证明控制有效。
这也是FDA Premarket Cybersecurity Documentation真正需要建立的证据链。
[ END ] .
联系我们
Contact us
网络安全服务
Cybersecurity Services
