eSTAR Software Documents and Cybersecurity: How They Connect

Direct Answer

Which software documents does eSTAR ask for, and how do they relate to cybersecurity?

The eSTAR software section asks for up to ten documents, set by the FDA's June 2023 guidance on device software functions: documentation level, software description, risk management file, requirements, architecture diagram, design specification, development and maintenance practices, testing, version history, and unresolved anomalies. Each one overlaps with the cybersecurity section. Reviewers expect the same components, risks, requirements, tests, and versions to appear in both, named and numbered the same way.

The software section and the cybersecurity section of an eSTAR are written by different people, often months apart. Reviewers read them side by side. When the architecture diagram shows four components and the threat model shows six, or the software version in the test report differs from the one in the SBOM, the reviewer asks why. This guide walks through each software document, what it covers, how it ties to cybersecurity, and what to check so the two stay consistent.

This guide explains the links. Blue Goat prepares the cybersecurity documents; your software and regulatory teams own the software documents themselves. For the cybersecurity attachments in detail, see the eSTAR cybersecurity attachment guide, the 18 deliverables map, and the eSTAR 7.1 submission checklist.

Why this matters

The FDA's software content guidance (final, June 14, 2023) sets what goes in the eSTAR software section. The February 3, 2026 premarket cybersecurity guidance sets what goes in the cybersecurity section, and for cyber devices, Section 524B makes parts of it a legal requirement. The cybersecurity guidance says security risk management should feed the device's overall risk management, and that security work should be part of the same design process as the rest of the software. In practice, that means the two sections describe one device and should read that way.

The software documents at a glance

Software document	Basic	Enhanced	Cybersecurity link
Documentation level evaluation	Yes	Yes	Cyber risk can be part of why a device is Enhanced
Software description	Yes	Yes	Interfaces and connections define the attack surface
Risk management file	Yes	Yes	Security risks that lead to harm, linked to the security risk file
Software requirements specification	Yes	Yes	Security requirements and controls
System and software architecture diagram	Yes	Yes	Basis for the security architecture views
Software design specification	No	Yes	How security controls are built
Development, configuration management, and maintenance practices	Summary or declaration	More detail	Secure product development framework and update process
Software testing	Summary	More detail	Security testing results and traceability
Software version history	Yes	Yes	Must match the SBOM and tested version
Unresolved software anomalies	Yes	Yes	Each anomaly assessed for security impact

Document by document

1. Documentation level evaluation

You state whether the device needs Basic or Enhanced documentation. Enhanced applies when a failure or flaw in the software could present a hazardous situation with a probable risk of death or serious injury. The level is about safety, not cybersecurity, but a device whose software can be attacked to cause serious harm points toward Enhanced. Check: the worst-case harms in your security risk file should not be more severe than the harms you used to justify the documentation level.

2. Software description

An overview of what the software does, its inputs and outputs, and how it connects to other systems. Cybersecurity link: every interface listed here is an entry point an attacker could use. Check: each connection in the description (Bluetooth, Wi-Fi, USB, cloud API, app) appears in your threat model and architecture views, and the threat model does not include connections the description leaves out.

3. Risk management file

The risk management plan, risk assessment, and risk management report, usually following ISO 14971. Cybersecurity link: the February 2026 guidance expects a separate security risk assessment, but security risks that can cause patient harm also belong in this file. Check: each security risk with a safety impact has a matching hazard in the safety file, linked by ID, with the same severity. Our cybersecurity hazard analysis guide shows how to turn a loss of confidentiality, integrity, or availability into a hazard, harm, and control.

4. Software requirements specification

What the software must do, including functional, performance, and interface requirements. Cybersecurity link: security controls such as authentication, encryption, signed updates, and logging should appear as requirements, so they can be traced and tested. Check: every control in your security risk file traces to a requirement ID, and every security requirement traces to a test.

5. System and software architecture diagram

A diagram of the software's modules, layers, and connections. Cybersecurity link: the cybersecurity section needs architecture views (global system, multi-patient harm, updatability, and security use cases). These should be built from the same diagram, with trust boundaries added. Check: component names and counts match between the software diagram and the security views. See our architecture views guide for what each view shows.

6. Software design specification (Enhanced only)

How each requirement is carried out in the design. Cybersecurity link: this is where reviewers can see how security controls are built, for example which crypto library, where keys are stored, and how the update image is checked. Check: the design matches what the security documents claim. If the security file says keys are in secure hardware, the design should say the same.

7. Development, configuration management, and maintenance practices

For Basic, a summary or a declaration of conformity to IEC 62304. For Enhanced, more detail on the processes. Cybersecurity link: the February 2026 guidance asks for a secure product development framework and a plan to update and patch the device. IEC 81001-5-1 adds security activities to the same lifecycle. Check: the maintenance process described here includes how security patches are released, and matches the update plan in the cybersecurity section.

8. Software testing

A summary of testing at unit, integration, and system level, with traceability to requirements. Cybersecurity link: security testing (penetration testing, fuzzing, and control verification) is reported in the cybersecurity section, but its requirements live in the same requirements specification. Check: security requirements show up in the traceability matrix with a link to the security test report, and the tested software version is stated.

9. Software version history

A list of software versions and changes during development, with the version being submitted. Cybersecurity link: the SBOM, penetration test, and vulnerability assessment must all describe the version you are submitting. Check: the same version number appears in the version history, the SBOM, the test report, and the labeling. If the software changed after testing, explain why the security results still apply.

10. Unresolved software anomalies

Known bugs not fixed before submission, with an assessment of their effect on safety and effectiveness. Cybersecurity link: the FDA's cybersecurity guidance asks for unresolved anomalies to be assessed for security impact too, since a bug can be exploitable. Check: each anomaly has a short security assessment, and any anomaly that is also a known vulnerability appears in the vulnerability assessment with the same rating.

Key requirement

The same device should read the same way in both sections: same components, same version, same risks at the same severity, and controls that trace to requirements and tests.

How to keep the two sections consistent

One source for names and IDs. Keep one component list and one ID scheme for risks, requirements, and tests. Both teams use it.
Freeze the version first. Agree on the submitted version before testing, and record it in one place.
Link the risk files. Every security risk with patient impact points to a hazard ID in the safety file, and back.
Build the security views from the software diagram. Don't redraw the system from scratch.
Run a cross-check before submission. Compare components, versions, severities, and trace links across both sections. Our week 1 test readiness review checks many of the same links before testing starts.

How Blue Goat Cyber approaches this

We prepare the cybersecurity documents: threat model, security risk assessment, architecture views, SBOM, penetration testing, and the management plan. We build them from your existing software documents, use your component names and IDs, and flag mismatches we find so your team can fix them before review. We do not write the general software documents or perform software verification and validation; those stay with your software and regulatory teams. Our FDA Premarket Cybersecurity Services cover the full cybersecurity set, and our penetration testing includes unlimited retests.

FAQ

Which FDA guidance sets the eSTAR software documents?

The June 14, 2023 final guidance, Content of Premarket Submissions for Device Software Functions. It replaced the 2005 software guidance and replaced the old Level of Concern with Basic and Enhanced documentation levels.

Do Basic devices still need cybersecurity documentation?

Yes. The documentation level only changes the software section. If the device is a cyber device under Section 524B, the cybersecurity section applies in full regardless of level.

Should security risks go in the software risk file or a separate file?

Both, linked. The February 2026 guidance expects a security risk assessment that looks at exploitability, separate from the safety risk analysis. Security risks that can lead to harm also belong in the ISO 14971 file, with matching IDs.

Can the security architecture views reuse the software architecture diagram?

Yes, and they should start from it. Add trust boundaries, data flows, and the multi-patient, update, and use-case views the cybersecurity guidance asks for.

What happens if the versions don't match?

Reviewers often ask which version was tested and whether the results still apply. That can add a question to the review. Fix it before you submit, or explain the difference in the submission.

Talk to a regulatory cybersecurity team

If you want your cybersecurity documents built to match your software section, book a discovery call. We'll review what you have and send a fixed-fee proposal. Nothing is billed until you approve it.