Software as a Medical Device (SaMD) Cybersecurity

SaMD - software that meets the medical-device definition without being embedded in hardware - is one of the fastest-growing FDA submission categories and one of the most cybersecurity-sensitive. Cloud backends, mobile apps, and standalone clinical software inherit all the FDA premarket requirements plus a much broader attack surface than embedded devices. This hub pulls together the services, guides, blog posts, and standards that explain what SaMD-grade cybersecurity looks like under the Feb 2026 guidance, IEC 62304, IEC 81001-5-1, and Section 524B.

Services

• Secure MedTech Product Design

  Architecture review, control selection, and secure development guidance from concept through V&V - aligned with FDA's Secure Product Development Framework.

• Full-Service FDA Premarket Cybersecurity

  Full-service, end-to-end: we deliver 100% of the artifacts FDA reviewers expect for 510(k), De Novo, PMA, PDP, and HDE submissions under §524B, plus IDE applications under 21 CFR 812 and the FDA's February 3, 2026 premarket guidance - traceable, complete, and current.

• Medical Device Threat Modeling

  Comprehensive threat modeling per FDA Section V.A.1 - covering supply chain, deployment, environment of use, and decommission risks for the full device system.

• FDA-Compliant SBOM Services

  Machine- and human-readable SBOMs with NTIA minimum elements (now stewarded by CISA), vulnerability mapping, and end-of-support tracking - built for FDA review.

• Medical Device Penetration Testing

  Hardware, firmware, mobile, and cloud - tested by operators with both red-team and medical-device experience. Reports built for FDA reviewers.

In-depth guides

• SaMD Cybersecurity FDA Requirements: 2024 Compliance GuideMaster SaMD cybersecurity FDA requirements. Learn premarket submission needs, SBOM standards, and postmarket monitoring for SaMD under Section 524B.
• EU AI Act vs FDA AI/ML Cybersecurity for DevicesHow EU AI Act Article 15 obligations compare to the FDA's PCCP framework and Section 524B for AI/ML SaMD.
• The SPDF PlaybookA practical, ungated guide to building a Secure Product Development Framework (SPDF) that FDA accepts, the eight pillars, the artifacts each one produces, and a pre-submission readiness checklist you can score yourself against.
• The MedTech Cybersecurity Standards DecoderA plain-English field guide to FDA Section 524B, IEC 81001-5-1, AAMI TIR57, ANSI/AAMI SW96, ISO 14971, and 8 more medical device cybersecurity standards, what they require, how they connect, and what FDA expects in your eSTAR premarket submission.
• IEC 81001-5-1 Security Risk Assessment GuideLearn how to implement IEC 81001-5-1 security risk assessments for FDA compliance. Expert guidance on medical device lifecycle security mapping.

Standards & guidance

Defined entries from our MedTech Cybersecurity Standards Glossary.

• FDA 2026 GuidanceFDA Premarket Cybersecurity Guidance (Feb 3, 2026)The FDA's final premarket cybersecurity guidance, effective February 3, 2026. Defines the seven-section cybersecurity submission format reviewers now enforce at Technical Screening, replacing the 2023 draft. Operationalizes Section 524B of the FD&C Act.
• Section 524BFD&C Act Cyber Device RequirementsSection 524B of the FD&C Act (the statutory partner to 21 CFR 807.81) was added by the Consolidated Appropriations Act, 2023. It gives the FDA explicit authority to require a complete cybersecurity package in every premarket submission for a cyber device, and to refuse submissions that lack one. It works alongside 21 CFR 807.81, which sets the 90-day 510(k) filing floor.
• SPDFSecure Product Development FrameworkA documented framework that shows security activities are integrated across the device lifecycle - not bolted on at the end. Includes secure requirements, threat modeling, secure coding, V&V, vulnerability management, and post-market response.
• IEC 81001-5-1Health Software Security ActivitiesThe international standard the FDA points to for the Secure Product Development Framework (SPDF). Defines security activities at each lifecycle stage - planning, requirements, design, implementation, V&V, release, and post-market.
• ISO 14971Medical Device Risk ManagementThe umbrella risk-management standard for medical devices. Defines hazard identification, risk estimation, risk evaluation, risk control, and residual risk evaluation. Cybersecurity risks must be reconciled here so a security control never silently introduces a safety hazard.
• ISO 13485Medical Device Quality Management SystemThe international QMS standard for MedTech. Covers design controls, document control, CAPA, supplier management, and post-market surveillance. The QMSR final rule (effective Feb 2, 2026) harmonizes 21 CFR Part 820 with ISO 13485.

From the blog

• SaMD vs SiMD: What Manufacturers Need to KnowLearn the difference between SaMD and SiMD, why it matters for FDA strategy, and how to build secure-by-design medical devices across your product.
• What Is Software as a Medical Device?Understand Software as a Medical Device (SaMD), its regulations, types, and impact on healthcare. Learn how SaMD aids diagnosis, treatment, and monitoring.
• Cybersecurity Best Practices for DevicesDiscover cybersecurity best practices for medical device design, from threat modeling to FDA-aligned lifecycle management, to protect patients and data.
• Risk-Based Testing for Medical Device SoftwareRisk-based testing for medical device software: prioritize cases by patient harm severity, threat model coverage, and FDA cybersecurity expectations.

Related FDA deficiencies

The deficiency letters reviewers most often write on submissions in this topic area. Each links to the full response playbook.

• Inadequate Vulnerability Management Plan

  Your VM plan lacks defined triage timelines, a coordinated vulnerability disclosure path, or a documented patch-deploy mechanism.

  Response playbook
• Inadequate Post-Market Cybersecurity Plan

  Your post-market plan lacks monitoring, patching commitments, customer communications, or end-of-support handling.

  Response playbook
• Non-Conformant SBOM

  Your SBOM is missing required minimum elements, transitive dependencies, or is delivered in an unsupported format.

  Response playbook
• Missing SPDF Documentation

  Reviewers cannot find evidence that your QMS implements a Secure Product Development Framework integrated with design controls.

  Response playbook

Related topics

Adjacent hubs in the same regulatory lifecycle, with the guides, articles, tools, and questions they cover that this hub does not.

• MedTech Cybersecurity StandardsShares FDA 2026 Guidance, Section 524B, SPDF · Same service track: Full-Service FDA Premarket Cybersecurity

  The standards MedTech teams actually need are a short list: ISO 14971 for safety risk management, ANSI/AAMI SW96:2023 for security risk management, AAMI TIR57 as its predecessor and companion, IEC 62304 for software lifecycle, IEC 81001-5-1 for secure development, and UL 2900 series where a certification is contractually required.

  • EU MDR vs FDA Medical Device Cybersecurity: A Side-by-Side CrosswalkGuideHow EU MDR/IVDR cybersecurity requirements compare to FDA Section 524B and the February 2026 guidance - Annex I §17.2, MDCG 2019-16, SBOM, vulnerability handling, and postmarket obligations.
  • AAMI TIR57 Risk Management for Medical DevicesArticle
  • 21 CFR Part 820 and Medical Device CybersecurityArticleHow 21 CFR Part 820 (and the 2026 QMSR update aligning it to ISO 13485) governs cybersecurity: design controls, CAPA, document controls, and Section 524B evidence.

  Which standards does the FDA actually require?

  The FDA requires compliance with statute (Section 524B) and 21 CFR Part 820 / QMSR. They recognize - but don't strictly mandate - consensus standards like AAMI SW96, IEC 81001-5-1, and ISO 14971. In practice, declaring conformance to those standards is the cleanest path through review.

  More MedTech Cybersecurity Standards FAQs
• IDE CybersecurityShares FDA 2026 Guidance, Section 524B, SPDF · Same service track: Full-Service FDA Premarket Cybersecurity

  Section 524B(a) does not list IDEs, so the statute's premarket cybersecurity content requirements do not attach to an investigational device exemption.

  • IDE Cybersecurity Requirements: The Investigational Device Guide (2026)GuideWhat cybersecurity documentation an IDE application needs under 21 CFR 812 and the FDA February 3, 2026 premarket guidance, and why Section 524B does not apply.
  • FDA IDE Cybersecurity Requirements: 2026ArticleWhat the FDA's Feb 2026 guidance recommends for IDE cybersecurity: informed consent, architecture views, SBOM, labeling, and what's not required yet.
  • Pathway crosswalkToolCompare what IDE, 510(k), De Novo, and PMA each expect on cybersecurity evidence.

  Does Section 524B apply to IDE submissions?

  No. Section 524B(a) enumerates 510(k), De Novo, PMA, PDP, and HDE; an IDE is submitted under a different section of the FD&C Act. Cybersecurity still applies through binding regulation: 21 CFR 812.25 requires the investigational plan to describe the device, the methodology, and the risks to subjects, and the February 3, 2026 guidance describes the cybersecurity content FDA expects there. The distinction matters because the content lands in the investigational plan rather than in an eSTAR cybersecurity section.

  More IDE Cybersecurity FAQs
• 510(k) CybersecurityShares FDA 2026 Guidance, Section 524B, SPDF · Same service track: Full-Service FDA Premarket Cybersecurity

  A 510(k) cybersecurity package for a cyber device includes the SPDF narrative, threat model, security risk assessment tied to ISO 14971, machine-readable SBOM with VEX, security architecture views, penetration and vulnerability testing evidence, postmarket monitoring plan with coordinated vulnerability disclosure, and cybersecurity labeling.

  • FDA Premarket Cybersecurity Submission Checklist GuideGuideEnsure your 510(k) or PMA is compliant. Use our checklist for FDA premarket cybersecurity submissions, covering SBOM, threat models, and pen testing.
  • 510(k) Cybersecurity Requirements Every Maker Must MeetArticleFDA 510(k) cybersecurity requirements - threat model, SBOM, testing, postmarket plan - scaled across 510(k), De Novo, and PMA pathways under Section 524B.
  • Letter to File vs SIR vs Special 510(k) crosswalkToolMap a security-relevant change to the right pathway and see the cybersecurity evidence each decision requires.

  How is 510(k) cybersecurity different from De Novo or PMA?

  The seven-section cybersecurity package the FDA expects is the same across 510(k), De Novo, and PMA - the differences are scope and depth. 510(k) reviewers focus heavily on substantial equivalence to a predicate, so the threat model and risk assessment have to show that any new connectivity, software, or interfaces don't change the safety profile in a way the predicate didn't address. PMA goes further on manufacturing and quality-system evidence; De Novo allows special controls that can include cybersecurity-specific requirements.

  More 510(k) Cybersecurity FAQs

Get FDA cleared without the cybersecurity headaches.

30-minute strategy session. No cost, no commitment - just answers from people who've shipped 250+ FDA submissions.