Medical Device Cryptography and Trusted Updates
Most cybersecurity deficiencies that look like a cryptography problem are really a key management problem: a device that can verify a signature but can never be issued a second key, an update channel with no rollback protection, or a certificate whose expiry falls inside the device's service life. This hub gathers what we publish on authentication and access control, code and data integrity, secure update infrastructure, key exchange, and post-quantum planning. Use it to decide what has to be fixed in hardware before tape-out, what can still change in firmware later, and what evidence belongs in the premarket package versus the postmarket file.
The short answer
Cryptography in a medical device covers four jobs a reviewer will look for separately: authenticating who is talking to the device, protecting data in transit and at rest, proving that firmware and stored data have not been altered, and signing the updates you ship after clearance. Section 524B and the February 3, 2026 final guidance do not name algorithms, but they do expect each control to trace to a threat in your security risk file and to a key that has a documented lifecycle.
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 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.
- 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: The Complete 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 DeviceLearn how secure key exchange protects connected medical devices. Covers TLS, PKI, MitM/replay risks, key provisioning, rotation, and FDA-ready evidence.
- FDA Authentication and Authorization Controls (2026)FDA Authentication & Authorization Controls for medical device manufacturers: what the FDA expects in 2026, gaps that trigger deficiencies, and evidence to prepare.
- Medical Device Code, Data, and ExecutionEnsure medical device security with robust code, data, and execution integrity controls. Learn how FDA guidance shapes premarket cybersecurity for devices.
- Secure Update Infrastructure for MedicalHow 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
Medical Device Cryptography and Trusted Updates - frequently asked questions
Get FDA cleared without the cybersecurity headaches.
30-minute strategy session. No cost, no commitment - just answers from people who've shipped 275+ FDA submissions.