Software as a Medical Device (SaMD) Cybersecurity

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 (superseded by CISA's 2026 Minimum Elements for an SBOM, published July 29, 2026), 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

• ISO/TR 80002-2 and Validating Cybersecurity Tools (2026)ISO/TR 80002-2:2017 governs validation of non-device software used in the quality system. How it applies to SBOM generators, SCA scanners, threat modeling tools, and signing pipelines.
• 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 Playbook: Secure Product Development FrameworkA 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.
• IEC 60601 and Cybersecurity: What It Covers (2026)IEC 60601 is an electrical safety and EMC family, not a cybersecurity standard. What each sub-part covers, where it touches security, and the standards that actually apply.
• FDA PCCP: Predetermined Change Control PlansHow to author a Predetermined Change Control Plan the FDA will accept: modifications protocol, methods, impact assessment, and cybersecurity coverage.
• Cybersecurity Management Plan for FDA Submissions: A 2026 GuideWhat goes in the Cybersecurity Management Plan reviewers expect in eSTAR v7.1 Slot 1: scope, governance, QMS integration, postmarket commitments, and the most common deficiency patterns under the FDA's February 2026 final guidance.

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.
• Software as a Medical Device: Definition, Risk, and RulesSoftware as a medical device explained: the IMDRF definition, risk categories, FDA pathways, IEC 62304, and cybersecurity obligations under Section 524B.

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.

  • ISO 14971 vs AAMI TIR57: Hazard Analysis Meets Cybersecurity RiskGuideHow safety hazard analysis and security risk analysis run in parallel and converge at the patient-harm column, with a side-by-side mapping table.
  • 21 CFR Part 820 and Medical Device CybersecurityArticle21 CFR Part 820 explained: the 2026 QMSR shift to ISO 13485, what changed, and how design controls, CAPA, and Section 524B evidence connect.
  • Post-Quantum Cryptography for Medical Devices (2026)GuideThe quantum-resistant algorithms that matter for medical devices, what they cost in flash and bandwidth, the published migration deadlines, and what the FDA expects in your submission today.

  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
• AI/ML Medical Device CybersecurityShares FDA 2026 Guidance, Section 524B, SPDF · Same service track: Full-Service FDA Premarket Cybersecurity

  AI/ML medical devices carry four threat classes traditional models miss: adversarial evasion, training-data poisoning, model inversion and membership inference, and silent performance drift.

  • AAMI CR515:2025: ML Medical Device Cybersecurity (2026)GuideWhat AAMI CR515:2025 covers for machine learning-enabled medical devices, the ML-specific threats it adds to your threat model, and how it interlocks with GMLP, PCCP, AIBOM, and Section 524B.
  • FDA & AI Pen Testing for Medical DevicesArticleWhat the FDA's Feb 2026 premarket cybersecurity guidance says (and doesn't say) about AI-run penetration testing, where AI helps, where it fails a 524B.
  • GMLP Crosswalk: 10 Principles to Engineering ControlsGuideEach of the FDA/Health Canada/MHRA Good Machine Learning Practice principles mapped to concrete engineering, QMS, and documentation controls.

  What cybersecurity risks are unique to AI/ML medical devices?

  Four classes dominate FDA feedback: adversarial evasion (crafted inputs that flip a clinical decision), data poisoning (training-set tampering that biases the deployed model), model inversion / membership inference (reconstructing PHI from model outputs), and performance drift (silent degradation that the security risk file must treat as a hazard, not just a quality issue). Traditional threat models miss all four because they assume a fixed function.

  More AI/ML Medical Device Cybersecurity 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: Investigational Device GuideGuideWhat 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