FDA Premarket Cybersecurity Deliverables & eSTAR v7.0 Map

All 18 FDA premarket cybersecurity deliverables, mapped to the February 3, 2026 guidance sections and the non-IVD eSTAR v7.0 cybersecurity fields. Built from 250+ FDA submissions with zero cybersecurity rejections.

For a cyber device that requires a premarket submission, treat all 18 deliverables as required. Scale each one to the device, and omit a line only with a documented justification when it does not apply. eSTAR is the submission template for 510(k) and De Novo; a PMA follows the same guidance content in its own format.

Key takeaways

• A cyber device under Section 524B(c) needs all 18 deliverables in a premarket submission, not a curated subset.
• Two of the 18 are statutory under Section 524B itself: the SBOM (524B(b)(3)) and the Cybersecurity Management Plan (524B(b)(1)). These cannot be omitted under any circumstances.
• The other 16 are required in practice. The FDA February 3, 2026 premarket guidance calls for them, the non-IVD eSTAR v7.0 template gates on them, and missing any single line draws a deficiency or a Refuse to Accept hold.
• Traceability is a named documentation element (Appendix 4) that runs across every deliverable. It is carried by the Risk Management Report's matrix and is the spine of the package.
• eSTAR v7.0 added a shorter alternative cybersecurity workflow aligned to the current guidance, but the underlying deliverables are unchanged.

Table of contents

• What counts as a cyber device under Section 524B(c)

• The 18 deliverables, the FDA guidance section, and the eSTAR v7.0 field

• The two statutory must-haves: SBOM and Cybersecurity Management Plan

• Traceability is its own Appendix 4 element

• What changed in eSTAR v7.0 for cybersecurity

• Common eSTAR cybersecurity attachment mistakes

• Submission-ready checklist: the 18 deliverables, line by line

• How Blue Goat Cyber approaches this

• FAQ

Why this matters

A 510(k), De Novo, or PMA for a cyber device is held to two parallel standards. Section 524B of the FD&C Act is the binding statute. The FDA premarket cybersecurity guidance of February 3, 2026 is nonbinding in form but is the operative interpretation reviewers apply to every submission. eSTAR is the template that enforces both: if a required cybersecurity field is missing, eSTAR will not validate, and the FDA will not accept the submission. The same is true of a PMA in its own format.

The cost of a missing line is real. A Refuse to Accept hold restarts the clock. A Major AI deficiency adds 90 to 180 days. The 250+ submissions Blue Goat Cyber has supported are organized around making sure no line is missing, and that every line is traceable back to a threat and forward to a test result.

What counts as a cyber device under Section 524B(c)

Section 524B(c) defines a cyber device by three characteristics, and a device meets the definition when it has all three: it includes software validated, installed, or authorized by the sponsor; it has the ability to connect to the internet; and it contains technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

The connectivity prong is the one that catches teams out most often. "Ability to connect" is read broadly. A device that pairs to a phone over Bluetooth, syncs to a vendor cloud, or talks to a hospital network over Wi-Fi or Ethernet meets the prong, even if the connection is intermittent or optional. A device whose only network path is through a separate gateway still meets the prong if the sponsor validated, installed, or authorized that gateway as part of the system. For the full statutory walk-through, see the FDA 524B cybersecurity requirements explained guide.

The Feb 3, 2026 guidance is broader than 524B itself. It applies to devices with cybersecurity considerations generally, including 510(k)-exempt devices, IDE, BLA, and IND submissions. Cyber devices under 524B(c) are a subset of what the guidance covers; the deliverables below are the full set the guidance asks for.

The 18 deliverables, the FDA guidance section, and the eSTAR v7.0 field

#	Deliverable	Status	FDA guidance (section and Appendix 4 element)	eSTAR v7.0 cybersecurity field
1	Risk Management Report	Required	Sections V and VI.B; the umbrella report	Security risk management report (attach)
2	Threat Model	Required	V.A.1; Threat Model	Threat model (attach) plus methodology plus architecture-views question
3	Cybersecurity Risk Assessment	Required	V.A.2; Cybersecurity Risk Assessment	Risk assessment (attach) plus exploitability-not-probability question
4	Software Bill of Materials (SBOM)	Statutory (524B(b)(3))	V.A.4; SBOM	Software Bill of Materials (attach)
5	Component Support and End-of-Support	Required	V.A.4; Vulnerability Assessment and Software Support	Support level plus EOS date per component; component-vulnerability assessment (attach)
6	Assessment of Unresolved Anomalies	Required	V.A.5; Unresolved Anomalies Assessment	Assessment of Unresolved Anomalies (attach)
7	Measures and Metrics	Required	V.A.6; Measures and Metrics	Cybersecurity Metrics (attach)
8	Security Requirements and Control Coverage	Required	V.B.1, Appendix 1; Requirements	Cybersecurity Controls
9	Security Architecture Views	Required	V.B.2, Appendix 2; Architecture Views	Architecture Views; and the threat-model architecture-views question
10	Static Application Security Testing (SAST)	Required	V.C; Testing	Cybersecurity Testing
11	Penetration Testing: Test Plan	Required	V.C; Testing	Cybersecurity Testing
12	Penetration Testing: Test Cases	Required	V.C; Testing	Cybersecurity Testing
13	Penetration Testing: Test Report	Required	V.C; Testing (five required elements)	Cybersecurity Testing
14	Cybersecurity Labeling	Required	VI.A; Labeling	Cybersecurity Labeling (cite attachment and page)
15	MDS2	Required	VI.A; Labeling	Cybersecurity Labeling (cite attachment and page)
16	Cybersecurity Management Plan	Statutory (524B(b)(1))	VI.B; Management Plan	Cybersecurity Management Plan (attach)
17	Interoperability Risk Assessment	Required	V.A.3; within threat model and risk assessment	Interoperability Risk Assessment and V&V
18	Interoperability Labeling	Required	VI.A; Labeling	Interoperability labeling (cite attachment and page)

The guidance is nonbinding in form, but these are what demonstrate the reasonable assurance of cybersecurity the law requires. In practice, a missing line is a deficiency.

The two statutory must-haves: SBOM and Cybersecurity Management Plan

SBOM under Section 524B(b)(3). The statute itself requires a software bill of materials, including commercial, open-source, and off-the-shelf software components. The Feb 2026 guidance refines what good looks like: a machine-readable format (SPDX or CycloneDX), component name and version, supplier, support status and end-of-support date, and a paired component-vulnerability assessment. The SBOM is also the input to postmarket monitoring under the Cybersecurity Management Plan; the two artifacts are designed to compose. See the SBOM for medical devices guide for format selection and field-level requirements.

Cybersecurity Management Plan under Section 524B(b)(1). The statute requires a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and procedures for the timely release of patches. The Feb 2026 guidance expands the plan to include vulnerability intake, triage criteria, communication channels, patch cadence by severity, and the relationship between postmarket findings and the premarket security risk file. See the cybersecurity management plan guide for the deliverable structure.

The other 16 lines do not have an explicit statutory hook, but they are the evidence reviewers use to conclude that 524B(b)(2) (reasonable assurance of cybersecurity) is met. Treating them as optional is the fastest path to a Refuse to Accept.

Traceability is its own Appendix 4 element

Appendix 4 of the Feb 2026 guidance enumerates the documentation elements expected in a premarket submission, and traceability is one of them in its own right. It is not a side effect of the other deliverables; it is its own artifact.

In practice, traceability rides on a matrix inside the Risk Management Report. The matrix carries one row per threat scenario and links that threat to the security requirement that addresses it, the control that implements the requirement, the test case that verifies the control, the finding (or "no finding") from the test, and the residual risk justification in the security risk file. When that matrix is complete, a reviewer can walk any single threat from origin to disposition in one read, and every other deliverable in the package is anchored to it. When it is missing or partial, the same reviewer asks for it as a deficiency.

What changed in eSTAR v7.0 for cybersecurity

The non-IVD eSTAR v7.0 release aligned the cybersecurity sections to the February 3, 2026 guidance and added a shorter alternative cybersecurity workflow. The shorter workflow consolidates several questions and attachments into a smaller form footprint when the device threat model and risk assessment are already comprehensive. The underlying deliverables are unchanged: the same 18 artifacts are still expected, in the same FDA guidance sections.

Three practical differences from eSTAR v6.2 matter for the cybersecurity package:

• Architecture Views are explicitly surfaced as their own field, with a paired question inside the threat model section. Submitters need to decide where to cite the artifact (attached separately, or inside the threat model attachment) and answer the question consistently.
• The Interoperability Risk Assessment and V&V field is its own line in v7.0, separate from the general risk assessment attachment.
• The Cybersecurity Metrics attachment is explicit and gates on submission. Teams that previously folded metrics into the management plan need to surface them as a standalone artifact.

Common eSTAR cybersecurity attachment mistakes

These are the recurring problems that draw a Refuse to Accept hold or a Major AI deficiency in the cybersecurity section:

• Attaching the SBOM as a PDF screenshot of a spreadsheet instead of a machine-readable SPDX or CycloneDX file. eSTAR accepts attachments, but reviewers expect to be able to parse the SBOM.
• Submitting a Cybersecurity Management Plan that describes intent but does not specify a patch cadence by severity, a vulnerability disclosure channel, or how postmarket findings feed back into the security risk file.
• Filing a Penetration Testing Report that is missing one or more of the five FDA-required elements: tester independence and expertise, scope, duration, methods, and results.
• Citing Architecture Views inconsistently between the dedicated field and the threat model question, leaving a reviewer unsure which document is authoritative.
• Omitting the MDS2 in favor of a custom labeling artifact. MDS2 is the format reviewers expect under VI.A; a custom replacement draws an AI almost every time.
• Treating Interoperability Labeling as optional for a device that talks to any external system. The guidance reads "any external system" broadly: a Bluetooth pairing with a companion phone qualifies.

For the broader pattern of premarket failure modes, the 12 reasons the FDA rejects medical device cybersecurity submissions guide walks the deficiency taxonomy in detail.

Submission-ready checklist: the 18 deliverables, line by line

Use this as a pre-submission gate. A "no" on any line is either a deficiency risk or a documented justification ready to attach. Walk it in order against the February 3, 2026 FDA premarket cybersecurity guidance and the non-IVD eSTAR v7.0 template before validating eSTAR.

Statutory under Section 524B (cannot omit):

• SBOM is attached in a machine-readable format (SPDX or CycloneDX), with component name, version, supplier, support status, and end-of-support date per component.
• Cybersecurity Management Plan specifies vulnerability intake, triage criteria, patch cadence by severity, coordinated vulnerability disclosure channel, and the feedback loop into the security risk file.

Risk file and traceability (Section V.A and Appendix 4):

• Risk Management Report is the umbrella artifact and contains the traceability matrix.
• Threat Model uses a named methodology (STRIDE, PASTA, or equivalent) and answers the eSTAR architecture-views question consistently.
• Cybersecurity Risk Assessment scores exploitability (not probability) per the Feb 2026 guidance.
• Interoperability Risk Assessment is filed as its own eSTAR v7.0 line, even if the device only pairs over Bluetooth.
• Component Support and End-of-Support is documented per component, with a paired component-vulnerability assessment attached.
• Assessment of Unresolved Anomalies explains why any open anomaly is acceptable for release.
• Measures and Metrics is a standalone attachment in v7.0, not folded into the management plan.

Controls and architecture (Section V.B, Appendices 1 and 2):

• Security Requirements and Control Coverage maps each Appendix 1 requirement to a control in the product.
• Security Architecture Views are attached (Appendix 2: global, multi-patient, updateability, security use case) and the threat model's architecture-views question is answered consistently.

Testing evidence (Section V.C):

• SAST results are attached, including findings, severity, and disposition.
• Penetration Test Plan is attached and predates the test execution.
• Penetration Test Cases are attached and trace to the threat model.
• Penetration Test Report contains all five FDA-required elements: tester independence and expertise, scope, duration, methods, and results.

Labeling (Section VI.A):

• Cybersecurity Labeling is attached, with the eSTAR field citing the attachment and page.
• MDS2 is filed in the HSCC MDS2 format, not a custom replacement.
• Interoperability Labeling is attached for any device that exchanges data with an external system.

Cross-cutting:

• Traceability matrix carries one row per threat, linking to the security requirement, control, test case, finding, and residual risk justification.
• Every omitted line has a documented justification attached, not a silent gap.

If every box is checked or justified, the package matches what reviewers expect to see in 2026. If a line is unchecked without a justification, fix it before validating eSTAR.

How Blue Goat Cyber approaches this

Across 250+ FDA submissions with zero cybersecurity rejections, the deliverable map above is the working spine of every engagement. The Risk Management Report is built first, the traceability matrix is the first cell of every other artifact, and each of the other 17 deliverables is produced against that matrix so the package is internally consistent before it ever reaches eSTAR.

The deliverables themselves are produced by the right specialist in each lane. Threat modeling, security architecture views, and the risk assessment are handled by the security architecture team. SBOM, component support, and the component-vulnerability assessment are handled by the SCA team. SAST is handled by the application security team. Penetration testing (Test Plan, Test Cases, Test Report) is handled by an independent testing team, with technical oversight from the CTO and an independent regulatory review by the VP, Regulatory Affairs and Compliance. The Cybersecurity Management Plan, labeling, and MDS2 are handled by the regulatory team. The Risk Management Report is the deliverable that stitches the rest together.

The relevant adjacent services:

• Medical Device Penetration Testing covers deliverables 11, 12, and 13.
• Threat Modeling Services covers deliverables 2, 3, and 9.
• FDA-Compliant SBOM Services for MedTech covers deliverables 4 and 5.
• FDA Premarket Cybersecurity Services covers the full 18.

FAQ

Is the FDA February 2026 premarket cybersecurity guidance binding?

The guidance itself is nonbinding in form. Every page carries the standard "Contains Nonbinding Recommendations" header. In practice, it is the operative interpretation the FDA applies when reviewing a submission against Section 524B, and failing to follow it produces real Refuse to Accept holds and Major AI deficiencies. Treat it as binding for planning purposes, even though the document is technically nonbinding.

Does this 18-deliverable map apply to a 510(k)-exempt cyber device?

The Feb 2026 guidance applies to devices with cybersecurity considerations generally, including 510(k)-exempt devices. A 510(k)-exempt device does not file a premarket submission, so the eSTAR column does not apply, but the underlying deliverables, especially the SBOM and Cybersecurity Management Plan under Section 524B, are still expected as part of the design history file and quality system records.

Where do Architecture Views attach in eSTAR v7.0?

Architecture Views have their own field in eSTAR v7.0, and a paired question inside the threat model section asks whether they are attached separately or included inside the threat model attachment. Either approach is acceptable, but the answer must be consistent across both places and the citation in the dedicated field must point a reviewer to the right document and page.

Is MDS2 still required under the February 2026 guidance?

Yes. MDS2 (the Manufacturer Disclosure Statement for Medical Device Security) is cited in Section VI.A of the guidance as the expected labeling artifact. The eSTAR cybersecurity labeling field asks for the attachment and page citation. A custom labeling document that covers the same content draws an AI in almost every submission Blue Goat has seen; the format is part of what reviewers are looking for.

Can I omit Interoperability deliverables if my device does not talk to other systems?

Only if it genuinely does not. The interoperability deliverables (17 and 18) are required for any device that exchanges data with another system, and "another system" is read broadly: a Bluetooth pairing with a companion mobile app, an HL7 or DICOM feed to a hospital system, or a sync to a vendor cloud all qualify. If the device is truly standalone with no external data exchange of any kind, the Interoperability Risk Assessment can be a short attestation documenting that fact. The omission needs to be explicit, not silent.

What changed in eSTAR v7.0 for cybersecurity, in practical terms?

eSTAR v7.0 aligned to the February 3, 2026 guidance and added a shorter alternative cybersecurity workflow. Architecture Views, Interoperability Risk Assessment and V&V, and Cybersecurity Metrics are each surfaced as their own field. The underlying 18 deliverables are unchanged. Teams that built their package against v6.2 should re-walk the eSTAR cybersecurity section to confirm the artifacts are cited in the right v7.0 fields.

Does PMA use eSTAR?

eSTAR is the submission template for 510(k) and De Novo. PMA does not use eSTAR; it follows the same Feb 2026 guidance content in its own format under 21 CFR Part 814. The 18 deliverables apply to PMA in full, organized into the PMA sections rather than the eSTAR fields. See the FDA PMA cybersecurity requirements guide for the PMA-specific layout.

What triggers a Refuse to Accept hold under Section 524B?

A submission for a cyber device is subject to RTA if it does not include the cybersecurity information required by 524B. In practice, the FDA's RTA checklist gates on the SBOM, the Cybersecurity Management Plan, the threat model, the cybersecurity risk assessment, and the testing evidence (SAST and penetration testing). Active RTA enforcement under 524B began October 1, 2023. A missing or insufficient line in any of those areas is the most common RTA trigger for a cyber device.

Sources and primary references

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions - U.S. Food and Drug Administration, February 3, 2026 final guidance
• Section 524B of the Federal Food, Drug, and Cosmetic Act - 21 U.S.C. 360n-2
• eSTAR Program - U.S. Food and Drug Administration
• Refuse to Accept Policy for Cyber Devices - U.S. Food and Drug Administration

Talk to a regulatory cybersecurity team

If you are mapping your premarket cybersecurity package to the February 2026 guidance and eSTAR v7.0 and want a second pair of eyes on the 18 deliverables, Blue Goat Cyber ships the full set for 510(k), De Novo, and PMA submissions. Book a discovery session and we will walk your evidence with you.