FDA Premarket Cybersecurity Deliverables & eSTAR v7.1 Map

This guide combines the practical deliverable explanations with the guidance-to-eSTAR map. The framework is an organizational tool, not a substitute for the statute, the guidance, or the applicable submission template.

Use the map to check evidence coverage and document applicability. Statutory obligations apply to covered cyber-device submissions; supporting recommendations and attachment organization depend on the device, pathway, and applicable template. Use the eSTAR template applicable to a 510(k) or De Novo submission. Organize PMA evidence for its applicable submission format rather than assuming the same eSTAR fields.

Why this matters

Section 524B of the FD&C Act establishes duties for applicable cyber-device submissions. The FDA’s February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, contains nonbinding recommendations for cybersecurity design and submission evidence. Keep those recommendations distinct from statutory requirements and from the questions in a submission template.

Missing or inconsistent evidence can prompt requests for clarification. A structured map helps the manufacturer identify gaps and trace threats to controls, tests, findings, and risk decisions. It does not establish that a submission will be accepted or authorized.

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 February 3, 2026 guidance addresses devices with cybersecurity considerations more broadly than the statutory cyber-device definition. Assess both guidance applicability and the specific submission duties. Software presence alone does not establish that Section 524B applies.

How cybersecurity documentation scales with device risk

Cybersecurity evidence should be scoped to architecture, interfaces, dependencies, intended use, and potential patient harm. Device class or connectivity alone does not determine cybersecurity risk.

These are illustrative comparisons, not case studies or exemptions. A surgical robotic system with cloud connectivity and multiple interfaces may need more detailed analysis than a device with narrowly scoped interfaces. Limited connectivity does not establish low risk, fewer applicable architecture views, or permission to omit evidence. Preserve traceability from threats and risks to controls, tests, findings, and manufacturer-owned residual-risk decisions.

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

For where these cybersecurity deliverables fit into software lifecycle records, see the IEC 62304 deliverable map and manufacturer responsibilities. It distinguishes direct clause support, partial support, and subjects outside IEC 62304. The manufacturer retains software classification, development planning, configuration management, general software verification and validation, QMS approval, risk acceptance, and release decisions. This cross-reference does not establish IEC 62304 conformity or make eighteen separate documents a universal FDA requirement.

The table is a working evidence map. Read the status column together with the statutory discussion below. A recommended artifact need not be a separate document, and a missing table row does not by itself establish a deficiency.

What belongs in the cybersecurity evidence set?

The map names the evidence; these explanations describe its purpose. Maintain controlled source records and clear references rather than duplicating the same content across attachments.

Risk report, threat model, and assessment

The Risk Management Report connects the system description, threat model, security risk assessment, controls, test evidence, and residual-risk disposition. STRIDE classifies threats; it does not assign a risk score. Assess cybersecurity exploitability separately from security impact and from the manufacturer’s ISO 14971 patient-harm severity. See medical device risk methodology.

SBOM supporting material and unresolved anomalies

An SBOM inventories the actual software components. Supporting material documents component versions, suppliers, support status, end-of-support information, vulnerability assessment, and how the inventory will stay current. Assess known unresolved software anomalies for security implications, controls, and residual-risk disposition rather than listing defects without analysis.

Cybersecurity measures and metrics

Metrics explain how the manufacturer measures and monitors its processes. Examples include remediation against internally defined targets, time from vulnerability discovery to patch availability, and trends in recurring test findings. These are illustrative measures, not universal FDA-prescribed targets or service-level commitments. See cybersecurity measures and metrics.

Controls, architecture views, and test evidence

Controls can address authentication, authorization, encryption, logging, hardening, segmentation, and behavior under malicious input. Architecture evidence explains data flows, trust boundaries, shared infrastructure, security use cases, and authenticated update paths. Trace the relevant threats to the controls and to tests that exercise them.

Penetration testing produces a Test Plan, Test Cases, and a Test Report. State whether device firmware, cloud services, APIs, companion applications, wireless interfaces, and service tools are in scope. Test cases and abuse cases should link to documented threats and controls. Report findings, clean results, remediation, and risk disposition; distinguish patient-impact findings from other security impacts. Consider DAST, fuzzing, and protocol testing where appropriate to the assessed scope. See medical device penetration testing.

Customer security documentation and interoperability

Cybersecurity labeling explains security capabilities, supported configurations, update support, and manufacturer and customer responsibilities. JSP2-aligned documentation and MDS2 can support communication of that information; neither is a universally mandated FDA submission format. Keep customer documents consistent with the controlled submission evidence.

Interoperability analysis addresses external-system dependencies, authentication and authorization, data integrity, timing, failure conditions, and unexpected or malicious behavior across interfaces. Explain relevant constraints in labeling. See the Medical Device and Health IT Joint Security Plan.

Planning and maintaining the evidence

Start the map during development. Let software requirements, architecture, risk analysis, and security test records inform the cybersecurity evidence as they evolve. Version the records in the manufacturer’s SDLC and QMS, assign owners, and assess whether product changes affect downstream artifacts. Reusable patterns support consistency; they do not replace device-specific review or postmarket maintenance.

Section 524B duties and supporting evidence

For applicable cyber-device submissions, Section 524B(b)(1) addresses a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures. Section 524B(b)(2) addresses processes and procedures to provide reasonable assurance that the device and related systems are cybersecure, including postmarket updates and patches. Section 524B(b)(3) addresses the SBOM. An SBOM and a management plan do not replace the processes and procedures duty.

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 plan, processes, and inventory should stay connected throughout the product lifecycle.

Traceability is its own Appendix 4 element

Appendix 4 of the February 2026 guidance identifies traceability among its recommended documentation elements. A traceability matrix can connect the evidence without requiring parallel copies of the same information.

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. That structure lets engineers and reviewers follow a threat from origin to disposition. Incomplete links should be resolved or explained; the matrix does not determine the FDA’s review outcome.

Using the eSTAR cybersecurity workflow

The cybersecurity workflow in the current non-IVD eSTAR template includes questions and attachment references for risk management, architecture, controls, testing, labeling, and postmarket planning. Follow the template’s applicability instructions when using an alternative workflow. A shorter form footprint does not remove an applicable statutory duty or substitute for supporting evidence.

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.
• Cybersecurity Metrics has an explicit attachment reference. Cite the relevant evidence consistently with the template instructions.

eSTAR v7.1 (September 21, 2026): no new cybersecurity fields

eSTAR v7.1 is now the current template for both nIVD and IVD submissions, available on the FDA eSTAR program page. It is a minor update. Based on the version history inside the template, it changes these fields and sections, none of them in cybersecurity:

Every cybersecurity field in the table above sits in the same place in v7.1 as in v7.0, so the map applies to both versions. Check the actual template version and submission instructions rather than assuming an existing package needs no changes.

Deliverable by deliverable, checked against the v7.1 version history:

The only v7.1 changes that touch a cyber device submission sit outside these deliverables: re-check the company and contact details against the new state dropdown, and drop any answer to the removed Intended Population question.

Common eSTAR cybersecurity attachment mistakes

Check these documentation issues before submitting; their presence alone does not establish an RTA or deficiency outcome:

• Attaching the SBOM as a PDF screenshot of a spreadsheet instead of a machine-readable SPDX or CycloneDX file. eSTAR accepts attachments, but reviewers need 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 Test Report without the guidance-recommended information on 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.
• Letting an MDS2 or other customer security document contradict the submission labeling. MDS2 is a useful disclosure format, not a universal FDA-required form.
• Leaving external interfaces and dependencies unexplained. Assess whether interoperability risks and labeling recommendations apply to the device’s actual data exchanges.

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 coverage review, not an automatic acceptance gate. Record applicability and supporting references for each item. Walk it against the February 3, 2026 FDA premarket cybersecurity guidance and the non-IVD eSTAR v7.1 template before validating eSTAR.

Section 524B evidence for applicable cyber-device submissions:

• 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.
• Cybersecurity processes and procedures address the Section 524B(b)(2) duty, including updates and patches for the device and related systems.

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 addresses applicable external exchanges and is cited in the relevant template field.
• 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 cited consistently with the applicable template’s attachment instructions. For what goes in it, see cybersecurity measures and metrics for medical devices, which includes a worked insulin pump example.

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 documents 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, if used, is consistent with cybersecurity labeling and customer-facing security information.
• 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.

Use unresolved items to plan the remaining work. A checked list does not establish regulatory compliance or predict an FDA decision.

How Blue Goat Cyber approaches this

Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. We use the deliverable map to define scope, assign evidence owners, and connect threats, controls, tests, and risk decisions. The evidence is tailored to the device and the agreed engagement rather than produced as eighteen mandatory standalone files.

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 Director of Penetration Testing 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.
• Medical Device SBOM Services for FDA Premarket Submissions covers deliverables 4 and 5.
• FDA Premarket Cybersecurity Services covers the full 18.

FAQ

Is the FDA February 2026 premarket cybersecurity guidance binding?

No. The guidance contains nonbinding recommendations. Section 524B establishes statutory duties for applicable cyber-device submissions. Plan evidence against both, while keeping legal duties, guidance recommendations, and template instructions separate.

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

The guidance addresses devices with cybersecurity considerations, including devices outside a premarket submission. A 510(k) exemption does not automatically create a submission-specific Section 524B duty. Assess the device and applicable pathway. Use relevant evidence in lifecycle and quality records; do not apply eSTAR attachment instructions to a submission that is not being filed.

Where do Architecture Views attach in eSTAR v7.1?

Architecture Views have their own field in eSTAR v7.1, 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 required under the February 2026 guidance?

No. The guidance recommends cybersecurity information in labeling, such as interfaces, ports, protocols, SBOM availability, update support, and end-of-support dates, but it does not require a specific form. The MDS2 (Manufacturer Disclosure Statement for Medical Device Security, ANSI/NEMA HN 1-2019) is an FDA-recognized consensus standard and a common way to present much of that information. Hospitals usually ask for it during procurement, so keeping your MDS2 consistent with your submission labeling avoids conflicting answers.

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

Assess the actual interfaces and dependencies, including companion apps, hospital systems, and cloud services. Where no external exchange exists, document that boundary and explain non-applicability. Do not infer non-applicability from a marketing description such as “standalone.” Evidence depth should follow the assessed risks and the applicable guidance recommendations.

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

The v7.1 version history describes a minor update with no new cybersecurity fields relative to v7.0. The earlier cybersecurity workflow changes should not be described as newly introduced in v7.1. Check the template’s actual version history and confirm that each applicable question points to the intended attachment and page.

Does PMA use eSTAR?

Use the electronic submission format applicable to the pathway. The 510(k) and De Novo eSTAR mapping here should not be treated as the PMA attachment layout. Assess PMA cybersecurity content against the guidance and applicable PMA instructions, including the status of any electronic template. See the FDA PMA cybersecurity requirements guide for the PMA-specific layout.

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

The FDA’s RTA policy addresses applicable cyber-device submissions that lack information required by Section 524B. This guide’s 18 rows are not eighteen statutory acceptance gates. Review the policy and submission instructions directly; whether a particular gap prompts RTA or a later request depends on the submission and review context.

Do we need eighteen separate documents for every submission?

No. The number describes Blue Goat’s evidence framework, not a universal FDA document count. Several evidence elements can share a controlled document when the applicable template permits it and the references are clear. Document scope and applicability; do not treat a combined file, document count, or page count as proof of completeness.

How many pages of cybersecurity documentation does the FDA prescribe?

The FDA sets no universal cybersecurity page count. Document length depends on the device, system boundaries, risks, evidence, reports, and appendices. Use the map to plan coverage and traceability, not to estimate completeness from the number of pages.

How does the guidance recommend documenting cybersecurity testing?

Provide the scoped plan, test cases or procedures, results, findings, remediation status, and risk disposition. Describe tester independence and expertise, scope, duration, and methods. SAST, penetration testing, fuzzing, DAST, and protocol testing address different questions; select methods based on the device and its attack surface rather than assuming every method applies identically.

What is a postmarket cybersecurity management plan?

It describes vulnerability monitoring, report intake and triage, risk assessment, coordinated disclosure, remediation, updates and patches, and communication. Connect those activities to the SBOM and the controlled security risk file. For applicable cyber-device submissions, distinguish the plan under Section 524B(b)(1) from the processes and procedures duty under Section 524B(b)(2).

Can we reuse deliverables across a product family?

Reuse controlled evidence only after checking device and version differences. Shared policies, tooling, and architectural elements may remain relevant; changed interfaces, software components, intended use, or risk controls can require updates to the threat model, SBOM, tests, labeling, and risk assessment. The manufacturer retains change-impact assessment, risk acceptance, and release decisions.

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.1 and want a second pair of eyes on the 18 deliverables, Blue Goat scopes the evidence for 510(k), De Novo, and PMA submissions. Book a discovery session and we will walk your evidence with you.

Free tools for this

• eSTAR Cybersecurity Checklist - walk the cybersecurity attachment contents before you lock the eSTAR.