Early-Stage Medical Device Cybersecurity Readiness Checklist

Download the free PDF version to print it or share it with your team. No form, no email required.

This checklist is for teams building connected wearables, mobile applications and cloud platforms, from prototype through pre-submission. It covers the cybersecurity items worth thinking through while your hardware and software design are still moving, so decisions stay cheap to change. It is a starting point, not a substitute for a full threat model, risk assessment or FDA premarket cybersecurity documentation package. When you are close to submission, move on to the eSTAR 7.1 submission checklist and the 18 deliverables map.

Why this matters

The FDA's February 3, 2026 premarket cybersecurity guidance recommends building cybersecurity into a device through a Secure Product Development Framework (SPDF): a lifecycle approach that starts at initial design and continues through disposal. Most teams meet that expectation late, after the architecture is fixed, and end up rebuilding diagrams and component lists from memory. The items below are organized around the early questions that feed the SPDF, so threat modeling, security risk assessment, the SBOM and the rest of the premarket package start with real inputs instead of a blank page.

1. Intended use and device classification

• Document the intended use for each function of the device separately (for example, a monitoring function alongside a general wellness feature).
• If the device combines a medical function with a non-medical one, write down how the two are isolated from each other.
• Note every wireless or radio frequency interface, including Bluetooth, even where a given function does not use it.
• Confirm your intended FDA submission pathway with your regulatory team; documentation expectations follow from it.

2. Hazard analysis and the cybersecurity connection

• Start a short, informal list of ways the device could harm a patient, with or without a cyberattack (for example, a wrong sensor reading leading to a wrong treatment decision).
• Keep that list separate from your threat list. The hazard analysis is a patient-safety deliverable your team owns under ISO 14971.
• As you build your threat list in section 5, flag anywhere a cyber threat could cause one of these hazards.

That link (threat leads to control leads to test leads to patient harm) is the traceability spine your formal threat model and risk assessment will document. Your hazard analysis, intended use and system architecture are the three starting inputs we ask for in any engagement.

3. System architecture and data flow diagram

• Sketch how data moves: wearable to mobile app to cloud.
• Record the connectivity at each hop (Bluetooth from wearable to phone; Wi-Fi or cellular from phone to cloud).
• Turn the sketch into a lightweight data flow diagram using DFD3 (Shostack's model): external entities, processes, data stores, dataflows, and a trust boundary wherever data crosses from one party's control to another.
• Once you pick a cloud provider, document its security posture and where its responsibility ends and yours begins.
• List third-party components and libraries you do not control. For each one, track support status (maintained, no longer maintained, abandoned) and end-of-support date.

The FDA expects support status and end-of-support dates in your SBOM, on top of the component list itself. They are far easier to capture as you adopt each component than to reconstruct later.

4. Interoperability

• If your app will ever sync with Apple Health, a provider portal or an EHR, add that connection to your diagram as an external entity, even if it is a future feature.
• Note what data crosses that connection in each direction, and whether a compromise on either side could affect the other.
• Note the data exchange standard you would use (HL7, FHIR or a vendor API); each carries its own security expectations.

The FDA treats interoperability as its own risk category, with two dedicated deliverables in the premarket package: an interoperability risk assessment and interoperability labeling.

5. Early threat identification (STRIDE and CIA)

• Apply STRIDE to your diagram: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Capturing a threat matters more than getting the category exactly right.
• Tag each threat with what it threatens: confidentiality, integrity or availability.
• Keep classification separate from scoring. Exploitability is scored on one axis; patient harm severity, owned by your team under ISO 14971, on another.
• Flag any threat that could trigger a hazard from section 2.

Our method uses STRIDE to classify, a CVSS-based rubric to score exploitability, and ISO 14971 for severity: three separate judgments, not one blended score. This follows the MITRE/MDIC Playbook for Threat Modeling Medical Devices, which the FDA references for this process.

6. Authentication, authorization and access control

• Confirm how a user's identity is established on the app and cloud account (authentication).
• Separately, decide what each role may view, change or delete (authorization). The FDA expects both addressed.
• Confirm whether the wearable and app authenticate each other, especially over Bluetooth.
• Plan unique credentials or keys per device or account; no shared or hardcoded defaults.
• Plan automatic logoff or a session timeout on the app.

7. Data protection and integrity

• Confirm encryption in transit between wearable, app and cloud.
• Confirm encryption at rest for stored health data.
• Identify which data is protected health information and handle it separately from wellness data.
• Plan how you will detect altered or corrupted data (integrity), not only unauthorized reading (confidentiality).

8. Code and firmware integrity

• Verify a digital signature before accepting an update or booting, not only at first install.
• Plan for secure boot so the device only starts verified software.
• Disable or restrict debug ports such as JTAG or UART before shipping. Prototypes often leave them open.
• Consider tamper-evident seals on the enclosure.

Data integrity asks whether your readings were altered; code integrity asks whether the software producing them is the software you built. A device that encrypts data perfectly while booting unverified firmware still has a real gap.

9. Logging and monitoring

• Decide which security events the app and cloud log: logins, failed logins, pairing attempts, configuration changes, access to health data.
• Plan how logs are protected from tampering and how long they are kept.
• Make sure logs could support an incident investigation without exposing more patient data than needed.

10. Resiliency, recovery and disposal

• Decide what happens if connectivity, the cloud or a component fails: does the device fail safely or keep running on stored data?
• Plan backup and recovery for cloud-stored health data.
• Plan how device and account data are wiped when a unit is lost, returned or decommissioned.

11. Updatability and patchability

• Decide how firmware and software updates are delivered and verified, including protection against rollback to an older, vulnerable version.
• Document how long components will keep receiving security updates after launch.

12. Vulnerability handling and disclosure

• Decide how a researcher or user can report a suspected vulnerability to you.
• Start a simple process to log and track reports; a shared inbox and a spreadsheet are enough for now.
• Know that a premarket submission needs a formal coordinated vulnerability disclosure process and a postmarket monitoring plan.

13. Vulnerability monitoring

• Periodically check your component list against the National Vulnerability Database and CISA's Known Exploited Vulnerabilities (KEV) catalog.
• When you adopt a new component, check it once and record the date.

14. Looking ahead to FDA premarket cybersecurity

• Record design decisions and the reasoning behind them as you make them.
• Know that cybersecurity labeling and an MDS2 form will be expected; the access, logging, backup and disposal answers above feed them directly.
• Plan dedicated cybersecurity documentation and testing once hardware and software are stable and market viability is established, rather than on the prototype.
• Revisit this checklist whenever a major decision changes: cloud provider, connectivity, or the boundary between medical and non-medical functions.

Standards this checklist draws on: the FDA premarket cybersecurity guidance (February 3, 2026), Section 524B of the FD&C Act, ISO 14971, ANSI/AAMI SW96:2023, the MITRE/MDIC Playbook for Threat Modeling Medical Devices, and DFD3 (Shostack).

How Blue Goat Cyber approaches this

Most teams that come to us early end up choosing one of two paths: our full-service FDA premarket cybersecurity package, which covers every cybersecurity document in the submission, or a medical device penetration test once the design is stable. Either way, it starts with a scoping call and a fixed fee, and every project gets its own project manager.

After kickoff, we set up a shared Slack channel and secure file shares and ask for your intake documents: instructions for use, software architecture, hazard analysis and any threat model you already have. If you don't have a threat model yet, we can build it for you. The work in this checklist maps straight onto that intake. Your data flow diagram, component list and early threat notes become the starting material, so nothing you write at the prototype stage gets thrown away.

All testing is done by our own in-house team and is never subcontracted. You get a short tear sheet after the first round of testing, then the full report, and we retest at no extra cost until the findings are closed.

FAQ

When should a medical device startup start cybersecurity work?

Start the cheap parts at the prototype stage: intended use, a rough data flow diagram, a component list with support status, and basic design choices like signed updates and per-device keys. Bring in a team like ours for formal documentation and penetration testing once hardware and software are stable. Testing a prototype that is still changing means paying to test it twice.

Does a wellness feature fall outside FDA cybersecurity rules?

Not automatically. Section 524B looks at what the device is capable of, including its radio frequency interfaces. If a wellness feature shares hardware or connectivity with a medical function, it can stay in scope even if users can turn it off. Document how the two functions are isolated and use the FDA's Multiple Function Device Products guidance as your reference.

Is this checklist a replacement for a threat model?

No. It prepares the inputs a threat model needs: a data flow diagram, an early threat list, a hazard list and a component inventory. The formal threat model, security risk assessment and SBOM are still required in an FDA premarket submission. If you don't have a threat model, Blue Goat Cyber can create one from these inputs as part of an engagement.

What should we send Blue Goat Cyber to get started?

Your instructions for use, software architecture, hazard analysis and any existing threat model. If some of these are still drafts, send the drafts. The data flow diagram and component list from this checklist are useful too. We confirm scope on a short call and then quote a fixed fee.

How much does a medical device penetration test cost?

Penetration tests start at about $15,000 for a simple device with a reasonable turnaround and no travel. The final price depends on the device's interfaces, connectivity and test setup, and we give you a fixed fee after the scoping call. Retests until findings are closed are included.

Do I need to fill in a form to get the PDF?

No. The PDF is a free, direct download with no email or form required. You can print it, share it with your team, or use this page as the working version. Both contain the same 14 sections.

What comes after this checklist?

Once your design is stable, move to the formal premarket work. The 18 deliverables map shows every cybersecurity document the FDA expects and where it goes in eSTAR, and the eSTAR 7.1 submission checklist walks through the full submission.

Talk to a regulatory cybersecurity team

Want help working through any item above, or a second opinion on where your prototype stands? Book a discovery session and we will review your architecture, components and early threat list with you, and tell you what to settle now versus later.