I’ve helped dozens of medical device manufacturers prepare for FDA cybersecurity submissions. The most common mistake I see is teams treating cybersecurity as a documentation exercise. They build a threat model. They write a risk assessment. They generate an SBOM. They compile everything into a PDF and call it done.
Then the FDA asks a simple question: show me how this vulnerability traces back to your threat model. And the room goes quiet.
The Document Problem
Most manufacturers have the right information. They’ve done threat modeling. They’ve identified risks. They’ve written requirements. They’ve tracked vulnerabilities. The problem is none of it is connected.
Here’s what the workflow actually looks like at most companies. An engineer builds a data flow diagram in the Microsoft Threat Modeling Tool and generates threats. Good start. But getting that data out is its own project. The tool exports to XML, not Excel. So someone has to parse or convert the XML before they can even start working with the threat data in a spreadsheet.
And the Microsoft tool does have requirements built in, but they’re stock ones that Microsoft created for software data flows. If your product has physical components, hardware interfaces, or anything beyond a standard software architecture, those requirements don’t apply. So you’re writing your own anyway.
Now someone is manually mapping each custom requirement to each threat in a spreadsheet. Copying and pasting between columns, manually writing requirement IDs, and eyeballing whether every threat has coverage.
The SBOM lives in a JSON file someone exported six months ago. The vulnerability log lives in another spreadsheet. The risk assessment lives in yet another one. Requirements are scattered across tabs and Confluence pages.
When an auditor or FDA reviewer asks “how does CVE-2024-6345 on setuptools relate to your threat model and what controls mitigate it?” someone has to manually trace through four different documents, three different tools, and two different file formats. That takes hours. If it can be done at all.
This is the gap the FDA is looking for. Not whether you have documents. Whether those documents are connected.
What Traceability Actually Means
This isn’t optional. The FDA’s premarket cybersecurity guidance and Section 524B require that threats trace to the controls and requirements that mitigate them. They want to see that every cybersecurity risk has been identified, assessed, and mitigated with clear evidence linking each step.
In practical terms that means:
A component in your architecture should link to the threats identified against it. Each threat should link to the security requirements and controls that address it. When a vulnerability is found on that component, it should link to the threat it relates to and the residual risk that documents the remaining exposure. If a patch resolves that vulnerability, it should link back to the vulnerability and the risk.
Requirement to threat to vulnerability to residual risk to patch. A complete chain. Every link traceable. Every decision documented with who made it and when.
That’s not a PDF. That’s a system.
The FDA knows this is hard. They also know that most manufacturers are doing it manually. Diagramming in one tool, exporting to a spreadsheet, manually mapping controls, manually linking vulnerabilities. Every handoff is a place where traceability breaks.
The Spreadsheet Breaks
I’m not going to pretend spreadsheets can’t work for this. For a single product with a handful of components and a few dozen vulnerabilities, a disciplined team can maintain traceability in Excel. I’ve seen it done.
But it breaks. Every time.
It breaks when you update the SBOM and the vulnerability list changes but the links to the risk assessment don’t update. It breaks when someone edits the threat model but forgets to update the corresponding requirements tab. It breaks when two people are working in the same spreadsheet and one overwrites the other’s changes. It breaks when an auditor asks to see the version history and all you have is “ThreatModel_v3_FINAL_revised2.xlsx.”
The bigger your portfolio gets, the faster it breaks. Two products with 50 components each and quarterly SBOM updates means thousands of links that need to stay accurate across dozens of documents. The math doesn’t work.
What Good Looks Like
The best submissions I’ve been involved with share a common trait: the cybersecurity evidence isn’t compiled at the end. It’s generated continuously as the product evolves.
When an engineer identifies a threat, it’s immediately linked to the component it affects and the requirements that mitigate it. When a vulnerability scan finds a new CVE, the vulnerability record is automatically linked to the affected component. When someone assesses the residual risk, they can see the threat, the requirements, and the vulnerability all in one place without switching tools.
The evidence doesn’t need to be “gathered” for an audit because it was never scattered in the first place. Every link exists from the moment it was created. Every change is tracked with a timestamp and an author.
When the FDA asks “show me the trace,” the answer is a click, not a project.
From Static to Living
The shift I’m describing isn’t just about making audits easier. It’s about fundamentally changing how product security works.
A static document captures a point in time. A living system captures the current state. When a new vulnerability drops next Tuesday, a document doesn’t update itself. A connected system shows you exactly which products are affected, which threats are relevant, and which risks need reassessment.
That’s the direction the industry is moving. The FDA’s increasing emphasis on post market surveillance and ongoing vulnerability management makes it clear they expect manufacturers to maintain cybersecurity continuously, not just at submission time.
We built Product Security Hub around this idea. Architecture, threats, requirements, SBOMs, vulnerabilities, and residual risks all live in one platform. Every record is linked to every related record. When something changes, the connections persist. When someone asks “show me the trace,” it’s a 10 second click through, not a 10 day document hunt.
If you’re still compiling cybersecurity evidence from scattered documents for every audit, there’s a better way. And it starts with treating traceability as infrastructure, not paperwork.