Software as a Medical Device (SaMD) Cybersecurity

Services

• Secure MedTech Product Design

  Security requirements, architecture review, threat modeling, and design-stage artifacts aligned with the FDA's February 2026 premarket cybersecurity guidance. Manufacturer-owned design approval and risk acceptance.

• FDA Premarket Cybersecurity Package

  Full-service: we produce the full cybersecurity documentation set 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.

• Medical Device SBOM Services

  Medical device SBOM services with source, build, and binary evidence reconciliation, component vulnerability assessment, and support-status verification. SPDX by default; fixed fee after scoping.

• Medical Device Penetration Testing Services

  Medical device penetration testing services across agreed hardware, firmware, wireless, app, and cloud attack paths. Threat-traced Test Plan, Test Cases, and Test Report for FDA submission documentation.

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 Section 524B, IEC 81001-5-1, ANSI/AAMI SW96, ISO 14971, and more: what each requires and how they connect in eSTAR.
• IEC 81001-5-1 Security Lifecycle Evidence TablePractical IEC 81001-5-1 evidence mapping: lifecycle activities, artifact owners, review questions, and a worked traceability example for health software.
• 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, issued February 3, 2026. Provides nonbinding recommendations for cybersecurity documentation and explains Section 524B obligations. It directly supersedes the June 27, 2025 guidance; September 2023 was a final guidance, not a draft.
• 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: FDA Premarket Cybersecurity Package

  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.
  • IEC 81001-5-1 Explained: Health Software Security RequirementsArticleIEC 81001-5-1 explained: the health software security activities it requires, how it builds on IEC 62304, and how it supports an FDA SPDF.
  • Post-Quantum Cryptography for Medical Devices (2026)GuideA plain-language guide for device engineers: what to change in your design this quarter, what the new algorithms actually do, what is coming, and how to write your position into the submission.

  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: FDA Premarket Cybersecurity Package

  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: FDA Premarket Cybersecurity Package

  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 Submission GuideGuideAssemble the cybersecurity content of an IDE application: Appendix 3's five elements, the binding 21 CFR 812.25 requirements behind them, and risk-scaled documentation breadth.
  • 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