The Startup MDVisit Website →
← Back to blog

3 Cybersecurity Deliverables FDA Requires for U.S. SaMD

October 1, 2026
3 Cybersecurity Deliverables FDA Requires for U.S. SaMD

The FDA's February 2026 final guidance, read alongside FD&C Act Section 524B, requires sponsors of qualifying cyber devices to submit a machine-readable SBOM, a lifecycle-based cybersecurity management plan, and demonstrable patch and update capability as part of premarket review. Postmarket, the same statute requires a plan to monitor, identify, and remediate vulnerabilities. For SaMD teams, this means security can no longer sit outside the quality system: it is now part of what FDA considers device safety.

TL;DR:

  • Most cloud-connected SaMD are classified as cyber devices under Section 524B, requiring detailed lifecycle cybersecurity documentation in submissions.
  • Key documents include a cybersecurity management plan, a machine-readable SBOM, vulnerability testing reports, and patch plans, all of which must demonstrate operational maturity.
  • FDA expects cybersecurity evidence to be integrated into existing quality systems, linking security objectives directly to design controls and risk management.
  • Postmarket obligations mandate continuous monitoring, coordinated vulnerability disclosure, and periodic testing to maintain device security throughout its lifecycle.
  • Early engagement with regulatory advisors can help identify missing artifacts and operational gaps, improving review chances and reducing delays.
The StartupMD
Build Stronger Healthcare SaaS Foundations
The StartUp MD helps healthcare SaaS teams navigate growth challenges with tailored advisory and fractional consulting from medicine and business.
Explore The StartUp MD

Table of Contents

What the February 2026 guidance covers and why it matters for SaMD

The February 2026 guidance is the controlling document for cybersecurity content in premarket submissions. It supersedes the June 27, 2025 version and earlier iterations. It applies broadly to devices that include software or device software functions with cybersecurity risk, which covers most SaMD by definition. FDA treats cybersecurity as inseparable from device safety, which is why the guidance ties directly into the Quality Management System Regulation under 21 CFR Part 820 and its alignment with ISO 13485. A vulnerability that could alter device output or availability is, in FDA's framing, a safety issue with a technical cause rather than a separate IT concern.

The 2025 update folded in the requirements Congress created through the Food and Drug Omnibus Reform Act, which added Section 524B to the FD&C Act. The February 2026 revision carries that structure forward with updated recommendations on documentation and labeling.

A few structural points matter for planning:

  • The guidance replaces prior premarket cybersecurity guidance documents rather than supplementing them.
  • It applies to devices with cybersecurity risk, not only devices with obvious network connectivity.
  • Section 524B obligations became effective for applicable submissions on March 29, 2023, so the statutory floor predates this guidance update.

Who must comply: defining a 'cyber device' under Section 524B

Section 524B does not apply to every device with software. It applies to a "cyber device," a term defined by a three-part statutory test: the device includes software validated, installed, or authorized by the sponsor; it has the ability to connect to the internet; and it contains any technological characteristics that could make it vulnerable to cybersecurity threats. Most cloud-connected SaMD, and a good share of locally installed software with update mechanisms, will meet this test.

The obligation reaches across submission types, not just one pathway. Affected filings include:

  • 510(k) submissions for cleared devices with network or update functions.
  • De Novo requests for novel software-based devices.
  • PMA, HDE, and PDP submissions where applicable.
  • IDE submissions supporting clinical investigations of connected software.

Practical red flags include cloud hosting, remote firmware or software updates, API integrations with EHRs, and any Bluetooth or Wi-Fi communication path. If a reviewer can plausibly ask "how do you patch this in the field," the device is very likely a cyber device.

Premarket documentation FDA expects for cyber-device SaMD submissions

A submission for a qualifying cyber device is judged on lifecycle evidence, not a single security narrative. FDA's expectations, drawn from the final guidance and the accompanying FAQ document, fall into five categories sponsors should build in sequence:

  1. Cybersecurity management plan. This document describes how the sponsor will monitor, identify, and address vulnerabilities across the total product lifecycle, not just before clearance.
  2. Machine-readable SBOM. The guidance recommends including commercial, open-source, and off-the-shelf components, with per-component support status and end-of-support dates, aligned to NTIA baseline attributes.
  3. Security risk management report. This ties threat modeling to exploitability, showing how identified threats map to specific controls and residual risk decisions.
  4. Testing evidence. Security requirement testing, vulnerability testing, and penetration testing results should specify scope, methodology, and whether testing was performed independently of the development team.
  5. Patch and update plans. Sponsors describe both a regular update cadence and an out-of-cycle process for critical vulnerabilities, including expected timelines for each.

The guidance is explicit that lifecycle evidence, meaning coordinated vulnerability disclosure processes, ongoing monitoring, periodic testing, and proof of patch delivery, is often the hardest part of the submission to assemble, because it requires operational maturity rather than a one-time report. A cross-functional gap assessment, run early, catches most of the missing pieces before they become review-cycle delays. For a structured starting point, this seven-item FDA cybersecurity checklist walks through the artifacts most startups underestimate.

Pro Tip: Build your SBOM and threat model in parallel, not sequentially. Threat modeling without a finished component inventory produces gaps that surface late, usually during FDA's review.

Parallel SBOM and threat model workflows

Security objectives, SPDF, and how to align cybersecurity with the QMS

FDA's guidance organizes premarket expectations around five security objectives: authenticity and integrity, authorization, availability, confidentiality, and secure or timely updateability. Each objective needs traceable evidence, not a narrative claim, and that evidence should live inside your existing quality system rather than in a parallel security folder.

Practically, that means folding Secure Product Development Framework practices into design controls under 21 CFR Part 820 and the equivalent ISO 13485 records your quality system already produces. A few integration points make the biggest difference:

  • Architecture diagrams and interface descriptions should identify data flows and trust boundaries, not just functional blocks.
  • Design inputs should reference specific security objectives, so design verification records can trace back to them.
  • Risk management files should treat security threats as inputs to the same hazard analysis used for clinical risk, not a separate document.

Teams that treat design controls and security controls as one system, rather than bolting security on after architecture is set, generally produce cleaner traceability matrices and fewer review questions. Guidance on meeting 21 CFR 820.30 and IEC 62304 design control expectations for software can help teams structure this from the start.

Consensus standards and SBOM norms: what helps your evidence package

Recognized consensus standards strengthen a submission but do not replace the documentation Section 524B requires on their own. IEC 81001-5-1 is an FDA-recognized standard covering secure health software lifecycle processes, and citing conformity gives reviewers a familiar structure to check evidence against. ISO 14971 and IEC 62304 play a similar supporting role for risk management and software lifecycle processes respectively, but none of the three satisfies Section 524B by itself.

For SBOMs, the practical minimum comes from NTIA's baseline attributes, which the guidance references directly. At a minimum, each component entry should include:

  • Supplier name, component name, and version identifier.
  • Unique identifier and relationship to other components.
  • Author of the SBOM data and timestamp of generation.

Sponsors that add per-component support status and end-of-support dates on top of this baseline tend to answer FDA's follow-up questions on patch feasibility before they are asked.

Postmarket obligations: monitoring, CVD, triage, and when reporting is required

Clearance is not the finish line. FDA's postmarket cybersecurity guidance sets expectations that continue for the life of the device, and Section 524B makes several of them statutory rather than advisory. The core postmarket cycle looks like this:

  1. Monitor continuously. Risk-based monitoring, informed by sources like the NIST National Vulnerability Database and CISA's Known Exploited Vulnerabilities catalog, should feed into a documented triage process.
  2. Run coordinated vulnerability disclosure. A published CVD process gives outside researchers a channel to report issues, and FDA expects sponsors to act on what comes through it.
  3. Test periodically. Point-in-time testing at clearance is not sufficient; periodic security testing should reflect the current threat environment, not the one that existed at submission.
  4. Distinguish routine from reportable changes. FDA's guidance sets criteria for when a cybersecurity update qualifies as a routine patch versus a correction or removal reportable under 21 CFR Part 806, and sponsors should document the assessment either way.

Getting this triage judgment wrong in either direction creates problems: over-reporting burns internal resources and regulatory goodwill, while under-reporting risks a compliance finding. The documentation trail, not just the final decision, is what FDA wants to see if it asks.

Practical readiness checklist: artifacts and operational capabilities

Before a submission goes in, a SaMD team should be able to produce a specific set of artifacts on demand, not assemble them under deadline pressure. The starting list includes:

  • A complete, machine-readable SBOM with per-component support status.
  • A threat model with a traceability matrix linking threats to controls to test results.
  • Security test reports covering requirement testing, vulnerability testing, and penetration testing.
  • Validated update and rollback procedures, tested rather than described.

Beyond documents, reviewers increasingly expect proof of operational capability: can the team identify which fielded devices run a vulnerable version, notify affected users, and deploy a patch within a stated timeline? That proof usually comes from a dry run, not a policy document. Supporting records worth having ready include a published CVD policy, test plans with pass/fail criteria, and the SOPs that govern patch release.

Pro Tip: Run a tabletop exercise simulating a critical vulnerability disclosure before you submit. It exposes gaps in your patch timeline faster than any document review will.

How FDA reviewers evaluate cybersecurity evidence and common gaps

Reviewers are looking for a clear chain: threat identified, control applied, test performed, residual risk accepted or mitigated. Submissions that present this chain with an indexed evidence table, rather than scattered across multiple appendices, tend to move faster. Clear architecture views and a machine-readable SBOM, rather than a static PDF table, also reduce back-and-forth.

The most common gaps that trigger requests for information include:

  • Incomplete SBOM metadata, particularly missing end-of-support dates for open-source components.
  • Threat models that stop at identification without mapping to exploitability or clinical impact.
  • Patch deployment claims with no evidence the update process was actually tested.

A common set of SaMD submission gaps shows up across specialties, and most of them trace back to treating cybersecurity documentation as a compliance exercise instead of an engineering discipline.

Practical implementation notes from The StartUp MD

In advisory engagements, sequencing matters more than volume of documentation. Building the SBOM first, then the threat model, then test evidence, avoids the late-stage rework that triggers RFIs when the pieces do not line up. Operational fixes that shorten time-to-market tend to be unglamorous: real version tracking across deployed instances, an update pipeline that has actually been exercised, and one accountable owner for cybersecurity rather than a shared responsibility that nobody executes. Engaging advisory support before the submission is drafted, rather than after a deficiency letter arrives, is generally when it adds the most value.

Perspective: cybersecurity as clinical safety and operational capability

Cybersecurity documentation gets treated as a regulatory tax when it should be treated as product quality. That framing shift changes outcomes: teams that build lifecycle evidence early see fewer RFIs, and investors increasingly read a mature SBOM and patch process as a signal of operational discipline, not just compliance box-checking. The gap a fractional Chief Medical Officer is built to close is exactly this one, where clinical judgment and technical execution need to move together instead of in sequence. Treat cybersecurity as part of what makes the device work, not an add-on IT requires.

— Paul Bergeron MD, MBA

How The StartUp MD helps SaMD teams get submission ready

Assembling a cybersecurity package that satisfies Section 524B takes clinical judgment as much as technical documentation, which is where a fractional Chief Medical Officer earns their keep. Specialized consultancies work with healthcare SaaS and SaMD teams on this kind of readiness work.

The StartupMD

  • Pre-submission gap assessments that identify missing artifacts before FDA does.
  • SBOM and lifecycle process buildout, including CVD policy and patch cadence documentation.
  • Evidence packaging that connects threat models, test results, and design controls into one traceable narrative.

If your team is approaching a premarket submission for a connected SaMD product, our advisory and fractional CMO services are built for this kind of hands-on regulatory and clinical work.

Authoritative FDA documents and standards records

Bookmark the February 2026 final guidance for premarket content, the postmarket cybersecurity guidance for lifecycle obligations, and the Federal Register notice documenting the guidance's regulatory history. A standards-based penetration testing methodology is useful when scoping independent security testing.

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

Sources

FAQ

What does the February 2026 FDA guidance require for SaMD?

The guidance requires SaMD sponsors of qualifying cyber devices to submit a cybersecurity management plan, a machine-readable SBOM, and evidence of security testing and patch capability as part of the premarket submission. It supersedes prior premarket cybersecurity guidance and incorporates Section 524B requirements directly.

What makes a SaMD product a 'cyber device' under Section 524B?

A device is a cyber device when it includes sponsor-validated software, can connect to the internet, and contains characteristics that could make it vulnerable to cybersecurity threats. This three-part test applies regardless of submission pathway, including 510(k), De Novo, and PMA filings.

Is an SBOM required for every FDA medical device submission?

An SBOM is required specifically for qualifying cyber devices under Section 524B, and FDA recommends it be machine-readable with per-component support and end-of-support information. The requirement draws on NTIA baseline attributes as the minimum standard for component metadata.

How does IEC 81001-5-1 relate to FDA cybersecurity requirements?

IEC 81001-5-1 is an FDA-recognized consensus standard covering secure software lifecycle processes that can support a submission's evidence package. Conformity to the standard strengthens documentation but does not by itself satisfy Section 524B's statutory requirements.

When should a SaMD company get regulatory advisory support for cybersecurity readiness?

Engaging advisory support before drafting a submission, rather than after receiving a deficiency letter, generally produces the smoothest review timeline. The StartUp MD's advisory and fractional CMO services are structured for exactly this kind of pre-submission gap remediation.