FDA Cybersecurity Documentation

The eSTAR cybersecurity section, written so the reviewer accepts it.

For teams whose submission is on the calendar and whose cybersecurity file isn't, or who have an FDA letter naming the documents that fell short. We write the threat model, risk assessment, SBOM, and the rest of the package against your actual device. Your engineers review it and keep building.

FDA cybersecurity documentation is the set of artifacts a premarket submission needs to show the device is secure by design: a threat model, a security risk assessment, a software bill of materials, security architecture views, the controls and their verification, and a postmarket cybersecurity management plan. Section 524B of the FD&C Act makes this mandatory for cyber devices, and FDA reviews it in the cybersecurity section of the eSTAR. CyberMed writes the full set against your actual device.

By Jose Bohorquez, PhD, President · Updated September 4, 2026

Book a call Check your cyber readiness

You'll talk to a security engineer, not a salesperson. The readiness check takes about three minutes and doesn't require an account.

What brought you here?

The submission is on the calendar

The eSTAR cybersecurity section is a list of document names and a folder of half-finished drafts. Nobody on the team has written a threat model before.

FDA already asked

An Additional Information letter names the documents that fell short. The clock is running and the engineers who understand the device are shipping it.

The documents exist, but they read like a template

A consultant wrote them without touching the architecture. The threat model doesn't match the data flows and the controls have no rationale. You're not confident they'll hold.

What the reviewer opens first

These are the documents FDA's premarket cybersecurity guidance asks for. We write all of them, or the ones you're missing.

Security architecture views

Global system, multi-patient harm, updatability and patchability, and security use case views, drawn from your actual design.

Threat model

Threats mapped to assets, trust boundaries, and data flows, with the method stated and the assumptions written down.

Cybersecurity risk assessment

Exploitability-based scoring, tied to the threat model and to your safety risk file.

Controls specification and rationale

Each control traced to the threats it addresses and the evidence that shows it works.

SBOM and vulnerability analysis

Machine-readable and human-readable SBOM, known vulnerability review, and software level of support.

Unresolved anomalies assessment

Every open anomaly evaluated for security impact, in the format reviewers expect.

Cybersecurity management plan

Post-market monitoring, coordinated vulnerability disclosure, and patch timelines you can operate.

Labeling, metrics, and summary report

Cybersecurity labeling content, the metrics FDA asks for, and a summary report with an eSTAR checklist mapping every document.

Where documentation fails review

The deficiencies we see most often in Additional Information letters aren't about missing documents. They're about documents that don't agree with each other.

A threat model that doesn't match the architecture views, so the reviewer can't trace a threat to a data flow
Controls listed without rationale, so there's no way to tell which threat each one addresses
An SBOM with no vulnerability analysis and no level-of-support statement
Open anomalies with no assessment of security impact
No post-market plan, or one with no owner, no timelines, and no disclosure process
Test results that don't connect back to the risk assessment they were supposed to verify

One author, one story

The same engineers write the architecture views, the threat model, the risk assessment, and the summary report. Every threat traces to a control, every control to evidence, every open anomaly to an assessment. That traceability is what a reviewer is checking for, and it's what a stack of documents from three different sources never has.

If FDA questions anything we prepared, we revise it and write the response at no extra cost.

How it works

1
Kickoff and architecture review
We read what you have, walk the architecture with your engineers, and agree on scope. About two hours of their time.
2
Threat model workshop
One session with the people who built the device. We leave with the assets, boundaries, and data flows the whole package hangs on.
3
We write, you review
We draft every document against your device, not a template. Your engineers check the technical content. Your QA/RA lead signs.
4
eSTAR mapping and submission
Every document lands in the right place in the eSTAR, with a checklist that shows where. If FDA sends a question on anything we wrote, we write the response.

Documentation on its own takes about three weeks. With penetration and fuzz testing it's the 30-day CyberSprint, fourteen deliverables at a fixed price. Need the testing alone? See cybersecurity testing.

FAQ

›Does a 510(k) really need all of these documents?

If your device includes software and can connect to another system or the internet, FDA's premarket cybersecurity guidance expects the full set. The depth scales with the device's risk, but skipping a document is what triggers the deficiency letter.

›We already have drafts. Can you work from them?

Yes. We start with a gap review of what you have, keep what holds up, and rewrite what doesn't. You only pay for the work that's missing.

›How long does it take?

About three weeks for the documentation set once we have access to the architecture and your engineers for the workshop. Add testing and it's the 30-day CyberSprint.

›Who writes it and who signs it?

We write it. Your engineers review the technical content, because it's their device. Your QA/RA lead signs, because it's their submission. The documents are yours to keep and reuse.

›What happens if FDA comes back with questions?

If FDA questions anything we prepared, we revise the document and write the response at no extra cost. It rarely comes to that.

›Do you also do the testing?

Yes. Penetration and fuzz testing is a separate service, and most teams take both together as the CyberSprint so the test report and the risk assessment agree with each other.

Talk it through

Find out which documents are thin before FDA does.

Thirty minutes with a security engineer. Bring whatever you have, including the FDA letter if there is one. You leave with a list of what's missing and what closing it takes, whether or not we do the work.

Book a call Check your cyber readiness

Prefer email? Tell us the device and the submission path in the form. We reply within one business day.