Medical Device Cryptography and Trusted Updates

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 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

• Post-Quantum Cryptography for Medical Devices (2026)The 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.
• FDA Security Control Categories: What Reviewers Expect Per CategoryThe 8 security control categories every cyber device must cover, and the evidence FDA expects for each one.
• 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.
• 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.
• Legacy Medical Device Cybersecurity: The 2026 FDA GuideSBOM reconstruction, vulnerability triage without source code, and end-of-support communication for devices cleared before Section 524B.
• FDA Cybersecurity Testing Requirements: 2026 TaxonomyTen families of cybersecurity testing the Feb 2026 guidance expects, mapped to eSTAR v7.0 slots and recognized standards.

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.
• ANSI/AAMI SW96Medical Device Security Risk ManagementThe consensus standard for medical device security risk management - asset, threat, vulnerability, likelihood, severity, and residual risk acceptability.
• 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.
• 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.

From the blog

• Key Exchange in Medical Device CybersecurityLearn how secure key exchange protects connected medical devices. Covers TLS, PKI, MitM/replay risks, key provisioning, rotation, and FDA-ready evidence.
• Medical Device Authentication and Access Control | Blue GoatMedical device authentication and access control: what the FDA's Feb 2026 guidance expects for credentials, privilege levels, biometrics, and audit logs.
• Code and Data Integrity Controls for Medical DevicesCode and data integrity controls explained: signed firmware, secure boot, anti-rollback, and the evidence the FDA expects for each in premarket review.
• Secure Update Infrastructure for Medical DevicesHow to design, isolate, and defend the update channel for connected medical devices - signed manifests, dual-bank A/B, rollback protection, HSM-backed.
• Medical Device OTA Update VulnerabilitiesExplore the hidden dangers of OTA update vulnerabilities in this insightful article. Aligned with the FDA's Feb 3, 2026 premarket cybersecurity guidance.
• Patch and Update Mechanism TestingSection 524B(b)(1) makes patchability statutory. What the FDA's Feb 2026 guidance expects in the patch and update mechanism test evidence, the test cases.

Related FDA deficiencies

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

• Missing SPDF Documentation

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

  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
• Insufficient Secure Boot Evidence

  Reviewers want test evidence that secure boot, signed updates, and root-of-trust controls function as claimed.

  Response playbook
• Inadequate Post-Market Cybersecurity Plan

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

  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.

• Software as a Medical Device (SaMD) CybersecurityShares FDA 2026 Guidance, Section 524B, IEC 81001-5-1 · Same service track: Secure MedTech Product Design

  Software as a Medical Device is a cyber device whenever it has software and the ability to connect to the internet, which is nearly always.

  • ISO/TR 80002-2 and Validating Cybersecurity Tools (2026)GuideISO/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 vs SiMD: What Manufacturers Need to KnowArticleLearn the difference between SaMD and SiMD, why it matters for FDA strategy, and how to build secure-by-design medical devices across your product.
  • SaMD Cybersecurity FDA Requirements: 2024 Compliance GuideGuideMaster SaMD cybersecurity FDA requirements. Learn premarket submission needs, SBOM standards, and postmarket monitoring for SaMD under Section 524B.

  Is my cloud-only software a medical device?

  If it meets the FDA's definition of a 'device' under FD&C Act Section 201(h) and is intended for diagnosis, treatment, prevention, or mitigation of disease, it's SaMD - regardless of whether it ever runs on a hardware device. The IMDRF SaMD framework is the international reference; the FDA's Digital Health Center of Excellence publishes US-specific guidance. If you're unsure, the right move is a regulatory-strategy consult before you've shipped, not after.

  More Software as a Medical Device (SaMD) Cybersecurity FAQs
• MedTech Cybersecurity StandardsShares FDA 2026 Guidance, Section 524B, ANSI/AAMI SW96 · 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.
  • IEC 81001-5-1 Security Risk Assessment GuideGuideLearn how to implement IEC 81001-5-1 security risk assessments for FDA compliance. Expert guidance on medical device lifecycle security mapping.

  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, ANSI/AAMI SW96 · 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