How to Create FDA-Compliant Cybersecurity Traceability Matrices in 2025

A cybersecurity traceability matrix shows an FDA reviewer how each threat you identified became a risk you assessed, a control you built, and a test you ran. FDA's February 3, 2026 premarket cybersecurity guidance asks for exactly that chain. Section V.A says the security risk management report should "provide traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation," and Appendix 4 Table 1 lists Traceability as an element of the report. This post shows the four matrices that deliver it, with example tables you can copy.

What FDA asks for

The guidance uses "should," not "must." Traceability is a recommendation about how to demonstrate safety and effectiveness, and the format is up to you. Three passages define what the reviewer is looking for.

• The risk management report (Section V.A). Beyond listing its elements, the report should summarize the evaluation methods, state the residual risk conclusion, detail the mitigation activities, and provide traceability across the threat model, risk assessment, SBOM, and testing.
• Architecture views (Section V.B.2). The views should "establish traceability of architecture elements to user and medical device system security requirements," and the guidance adds that "such traceability should exist throughout the cybersecurity risk management documentation."
• Testing (Section V.C). Manufacturers should provide evidence that each design input requirement was implemented, and threat mitigation testing tied to the risks in each architecture view.

Under the QMSR, ISO 13485 Subclause 7.3.4 asks that design outputs be in a form suitable for verification against design inputs, and Subclause 7.3.6 covers verification. Traceability is how you show that for security requirements. The guidance cites both.

One scope note. The guidance's recommendations apply to any device with software, firmware, or programmable logic, connected or not. The Section 524B statutory requirements apply only to cyber devices, which must have the ability to connect to the internet. Traceability helps either way, but only the cyber device sponsor has a legal obligation behind the package. Our FDA cybersecurity requirements post covers the full set of documents, and the book chapter on documentation and traceability covers keeping the links alive during development.

Matrix 1: the master matrix

The master matrix is the one the Section V.A passage describes. It runs from threat to test in a single row, so a reviewer can pick any threat and follow it to the evidence that it's controlled.

Each row needs the threat ID and description from the threat model, the risk ID and the pre- and post-mitigation assessment, the SBOM components involved, any known vulnerabilities in those components, and the test cases with results. The table below is illustrative. The component versions and CVEs are examples, not recommendations.

Threat ID	Threat	Risk ID	Assessment (pre / post)	SBOM component	Known vulnerabilities	Test cases	Result
TH-001	Interception or alteration of data on the wireless link	RA-001	High exploitability, remote adjacent / Low after mutual TLS	OpenSSL 3.0.x	CVE-2023-0286, CVE-2023-0215 (patched in deployed version)	TC-SEC-001, TC-SEC-002, TC-SEC-003	Pass; TLS 1.3 only, weak suites rejected
TH-002	Unauthorized firmware loaded through the USB service port	RA-002	Medium exploitability, physical access / Low after signed images	Bootloader 2.0	None identified	TC-SEC-015, TC-SEC-016	Pass; unsigned image rejected, rollback blocked
TH-003	Malformed network packets cause loss of monitoring	RA-003	Medium exploitability / Low after input validation and fail-safe mode	TCP/IP stack 3.2	One open CVE, assessed not reachable	TC-SEC-025, TC-SEC-026	Pass; device enters safe state, alarm raised

The assessment column follows Section V.A.2: exploitability, not probability, scored before and after mitigation. If you score with CVSS, FDA's postmarket guidance cites CVSS and the MITRE rubric adapts it for devices. The vulnerabilities column connects to the vulnerability assessment the guidance asks for in Section V.A.4(b), including any entries in CISA's Known Exploited Vulnerabilities catalog, which the guidance says should be designed out.

Our post on threat modeling for cloud-connected devices covers how to produce the threat IDs that start each row.

Matrix 2: architecture elements to security requirements

Section V.B.2 asks the architecture views to trace architecture elements to security requirements. This matrix lists each security-relevant element from the Global System View and the Security Use Case Views, the requirement it satisfies, how it's implemented, and how that implementation was verified.

Architecture element	Security requirement	Implementation	Verification
Network interface module	REQ-SEC-008: external communications use authenticated encryption	TLS 1.3 with mutual authentication; certificate pinning to the manufacturer update server	Protocol analysis; penetration test TC-SEC-201 to TC-SEC-210
User authentication service	REQ-SEC-001: administrative access needs two factors	Time-based one-time code plus badge; lockout after repeated failures	Unit and integration tests; summative usability task for lockout recovery
Patient data store	REQ-SEC-012: patient data at rest is encrypted	AES-256-GCM; keys derived from the hardware security module; rotation on a defined schedule	Cryptographic validation; key management test
Update manager	REQ-SEC-022: software updates are cryptographically signed and cannot roll back	Signature check against a manufacturer certificate chain; version monotonic counter	Update simulation; TC-SEC-015, TC-SEC-016

The requirements in the middle column should sit in the control requirements FDA asks for in Section V.B.1, organized by the eight control categories in Appendix 1: Authentication; Authorization; Cryptography; Code, Data, and Execution Integrity; Confidentiality; Event Detection and Logging; Resiliency and Recovery; and Updatability and Patchability. Our post on the architecture security view shows how each view feeds this table.

Matrix 3: security requirements to test cases

Section V.C asks for evidence that each security design input was implemented. This matrix is the proof. Every requirement maps to the tests that verify it, with the test type, pass criteria, and result.

Requirement	Test cases	Test type	What was tested	Pass criteria	Result
REQ-SEC-001: two-factor administrative access	TC-SEC-101, TC-SEC-102, TC-SEC-103	Unit; integration; system	Code generation, badge read, access control integration, lockout	Access granted only with both factors; lockout after defined failures	Pass
REQ-SEC-008: authenticated encryption on external links	TC-SEC-201 to TC-SEC-210	Integration; penetration	Handshake, cipher negotiation, certificate validation, interception attempts	Only TLS 1.3 accepted; invalid certificates rejected; no plaintext observed	Pass; no findings
REQ-SEC-022: signed updates, no rollback	TC-SEC-015, TC-SEC-016	System; penetration	Unsigned image, tampered image, older signed image	All three rejected with logged event	Pass

Include negative tests. A requirement verified only by "the feature works" doesn't show the control holds under attack. The vulnerability testing Section V.C lists, from fuzzing to attack surface analysis to penetration testing, belongs in this matrix too, mapped to the requirements it exercised. See how to conduct medical device penetration testing and what FDA looks for in the report, which should state tester independence, scope, duration, methods, and findings.

Matrix 4: SBOM components to vulnerability disposition

Section V.A.4(b) asks the submission to identify all known vulnerabilities in the device and its components, describe how each was found, and give a safety and security risk assessment and the risk controls for each. This matrix is where that lives, keyed to the SBOM.

Component (SBOM entry)	Support status / end of support	Vulnerability	Assessment	Disposition	Verification
OpenSSL 3.0.x	Actively maintained / vendor date stated	CVE-2023-0286, CVE-2023-0215	Not exploitable in deployed version; patched	Updated before release	Software composition analysis report; regression tests
Legacy imaging driver	No longer maintained / past	Remote code execution reported upstream	High exploitability if network reachable	Component isolated to an internal segment; input validation added; replacement planned for next release	Penetration test confirmed no reachable path
JSON parser library	Actively maintained / vendor date stated	Information disclosure in error messages	Low impact; no patient data in affected path	Accepted with monitoring; update scheduled	Risk acceptance recorded; monitoring source listed in management plan

Two columns here come straight from the guidance. The support status and end-of-support date are the two fields FDA asks you to add to the NTIA minimum elements for every component, in the SBOM or in an addendum. The disposition column has to say what you did, and for anything deferred to a future release, Section V.C asks for the plan: which vulnerabilities the release addresses, when, and whether fielded devices get it. Our SBOM requirements guide covers the fields in detail.

The safety handoff

Section V.A.2 asks for "the method for transferring security risks into the safety risk assessment process." Your master matrix should carry a column, or a linked table, that shows which security risks were evaluated for safety impact and where they landed in the ISO 14971 file. SW96 and TIR57 both describe this interface. Our book section on safety and security risk integration covers how to document it.

Unresolved anomalies

Section V.A.5 asks for a security assessment of the unresolved anomalies listed in the software package, including any relevant CWE categories. Add a short matrix or a column: anomaly ID, CWE category if any, security impact assessment, compensating control, and acceptance rationale. An anomaly that is harmless when it happens by accident can be a vulnerability when an attacker triggers it on purpose, and the guidance says so.

How to build and keep it

• One identifier scheme. Prefixes for each element type (TH-, RA-, REQ-SEC-, TC-SEC-, CTRL-) and identifiers that never change once assigned. An ID mismatch between two documents is the most common reason a reviewer stops.
• One tool. Put security requirements, threats, controls, and tests in the same requirements database as your software requirements. Export the cybersecurity view for the eSTAR Cybersecurity section and the software view for the software section. Two documents, one source of truth.
• Check it in the build. A script that flags requirements without tests, risks without controls, and controls without implementation references catches gaps before a reviewer does.
• Keep it alive. Section V.A.6 asks you to update the security risk management documentation as new threats, vulnerabilities, and assets appear through the total product lifecycle. A traceability matrix that stops at submission can't answer the question "which devices does this new CVE affect?"
• Match versions. The component version in the SBOM, the version in the vulnerability table, and the version the penetration tester attacked should be the same. When they aren't, say why.

What reviewers flag

The patterns that draw an Additional Information request on traceability are consistent:

• A risk assessment whose rows don't cite threat IDs, so the reviewer can't tell whether every threat was assessed.
• Controls listed by category with no link to a risk, which reads as a copied control list.
• Requirements with no verifying test, or tests that verify features rather than controls.
• An SBOM with no vulnerability table, or a vulnerability table whose component versions don't match the SBOM.
• "Encryption implemented" where the reviewer needs the algorithm, the library and version, and the key management approach.

None of these is a missing document. Each is a missing link between documents. The matrices above are the links.

Need help with cybersecurity traceability or the full documentation package? See our FDA cybersecurity documentation service, contact us, or email info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• MITRE. Rubric for Applying CVSS to Medical Devices. Version 0.12.04, revised October 27, 2020. https://www.mitre.org/news-insights/publication/rubric-applying-cvss-medical-devices
• NTIA. The Minimum Elements for a Software Bill of Materials (SBOM). July 12, 2021. https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
• ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers. AAMI, 2023.
• AAMI TIR57:2016 (R2023). Principles for medical device security, Risk management. AAMI.
• ISO 14971:2019. Medical devices, Application of risk management to medical devices. ISO.