How to Create FDA-Compliant Cybersecurity Traceability Matrices in 2026

The FDA has issued guidance on the cybersecurity of medical devices for premarket review and safety and effectiveness assessment. (You can find it on the FDA website. It was issued on February 3, 2026.) The guidance document states, in several places, that your risk management report should provide traceability, and that this should show the connections between the elements mentioned earlier in the guidance document: the threat model, the cybersecurity risk assessment, your SBOM, and your testing documentation.

What FDA asks for

However, FDA uses the word “should” throughout the guidance, which means that traceability is recommended, but a particular matrix format is not required. If you do include a traceability matrix, we suggest that it be organized as a set of four matrices, showing the links between the four elements mentioned above. This blog post will walk you through what each matrix should include, and will give you examples you can copy for your own documentation.

Note that these traceability recommendations apply to devices with cybersecurity considerations, including devices containing software, firmware or programmable logic, regardless of connectivity. The statutory requirements in Section 524B, however, apply only to cyber devices - i.e., devices that include software validated, installed or authorized by the sponsor, have the capability to connect to the internet, and contain technological characteristics validated, installed or authorized by the sponsor that could be vulnerable to cybersecurity threats.

In order to follow the FDA recommendations:

The risk management report in Section V.A should also summarize the evaluation methods, state the residual risk conclusion and detail the mitigation activities.

The cybersecurity aspect of the QMSR goes under design and under verification in particular. ISO 13485 Subclause 7.3.4 says design output must be in a form that enables verification against design input, and Subclause 7.3.6 covers verification. The ability to trace security requirements throughout the development process helps demonstrate compliance with both.

Under Architecture:

Traceability of architecture elements backwards to user and medical device system security requirements (Section V.B.2). In other words show how you've met both sets of security requirements.

traceability forwards. Show how you architecture fulfils these requirements, and more importantly addresses the risks identified in the cybersecurity risk analysis. At this point the guidance book recommends that you have architecture explicitly laid out with cybersecurity risks and mitigations and links to the risk management process. These links should extend throughout the cybersecurity risk management documentation.

Under Verification:

Show through testing that you've met each security design input, and through threat mitigation testing that you've addressed the risks identified in each architecture view (Section V.C). Those risks and mitigations should be traceable back to the architecture view and correspondingly to the security requirements.

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

As described in Section V.A, this matrix links each threat to sufficient test case evidence to demonstrate that the risk is addressed. Each row includes a threat ID and description (from your threat model), risk ID, pre- and post-mitigation assessment, components in scope (from your SBOM) and known vulnerabilities, test cases and results. (Note: the components and CVEs used are for illustration purposes only and not specific recommendations for your system.)

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 addresses exploitability, not probability, as per the FDA’s recommendations (Section V.A.2). If you use CVSS, the FDA cites it in its postmarket guidance, and MITRE’s device-adapted rubric explains how to apply it. The vulnerabilities column addresses the FDA’s Section V.A.4(b) recommendations to assess vulnerabilities (including CISA’s Known Exploited Vulnerabilities catalog entries, which the guidance says to design out).

Threat modeling for cloud-connected medical devices should include entries that identify each threat.

Matrix 2: architecture elements to security requirements

Section V.B.2 recommends that architecture views trace architecture elements to security requirements. This matrix documents any security-relevant architecture element from the Global System View or Security Use Case View, which requirement(s) it meets, how it is implemented, and how it was verified.

A time-based code plus badge does not by itself establish two-factor authentication: both may be possession factors. The authentication examples here and in Matrix 3 need evidence of two distinct factor types.

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

For these requirements we address the eight control categories in the FDA’s guidance (see Section V.B.1 and Appendix 1) that the security requirement falls under (Authentication; Authorization; Cryptography; Code, Data, and Execution Integrity; Confidentiality; Event Detection and Logging; Resiliency and Recovery; and Updatability and Patchability). The requirements in the middle column are the control requirements the FDA asks for in Section V.B.1, and our post on the architecture security view for medical devices explains how each view informs this table.

Matrix 3: security requirements to test cases

The FDA recommends showing evidence that each security design input was implemented (Section V.C). This matrix links to the evidence. Each security requirement is linked to the test cases that verify it, the verification method used to demonstrate that requirement was met, the test type, pass/fail criteria and test 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

Verify that you actually did it, and not just that the feature works. Include negative tests. Show how your controls hold up under attack. Section V.C lists, from fuzzing to attack surface analysis to penetration testing, belongs in this matrix too, mapped to the requirements it exercised.

And here's how to conduct medical device penetration testing and what FDA looks for in the report: 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 fields 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

How to document the transfer of security risks into the safety risk assessment process (see V.A.2)

Use the master matrix of security risks. Add a column or a link to a table that identifies the risks which have been evaluated for potential safety impact, and indicate the corresponding file(s) in which this information is recorded in the ISO14971 file. You may also reference the relevant guidance in TIR57 and SW96 on this topic. Our book section on safety and security risk integration covers how to document it.

Unresolved anomalies

For each unresolved software anomaly (see V.A.5), indicate the potential impact on security and safety (including the corresponding CWE categories, where appropriate). This can be captured in a short table, or in the master matrix of security risks, that contains the change request ID of each issue, the impact assessment, any planned or implemented mitigations, and the rationale for acceptance. It should be noted that a defect or condition which may result in no injury or loss if it occurs by chance may qualify as a vulnerability if it can be exploited intentionally.

How to build and keep it

• One identifier scheme. Provide an identifying naming convention, with prefixes to denote the different element type (examples include TH-, RA-, REQ-SEC-, TC-SEC-, etc.) This convention is documented in the master matrix of security risks. Additionally, document each element’s identifier (including TC/RA and test evidence), and ensure that once assigned, an identifier is not changed. ID mismatches can lead to requests for clarification.
• One tool. Put your security requirements, threats, controls and tests in the same database as your software requirements and pull out separate views for the eSTAR sections, one for cybersecurity and another for software, two documents from one source of truth.
• Check it in the build. Check this database into your build system and write one script that flags requirements that don’t have tests, risks that don’t have controls and controls that don’t have implementation references. This will highlight gaps before your reviewer does so your submission will be stronger.
• Keep it alive. Use a traceability matrix beyond your submission and keep it up to date. New assets, threats and vulnerabilities emerge all the time. Reviewers may expect you to be able to point to the correct cell in your matrix to answer questions like which devices does this CVE affect?
• Match versions. Make notes of where your component version in your SBOM doesn’t match the version in your vulnerability table or the version the pen tester tested, reviewers want explanations of any discrepancies.

What reviewers flag

You can help avoid Additional Info requests on traceability if your cells all refer to the appropriate IDs for the row and column items. For example reviewers may ask for clarification about:

• Risk assessments where rows don’t refer to the appropriate threat IDs, so they are unsure if you considered all of them.
• 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, library and version, and the method of key management.

Each shortcoming may be a link missing between documents or a gap in the underlying work or evidence. The matrices above help identify those gaps.

Need help with cybersecurity traceability or the full documentation package? Check out 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.