By Keith Handler, Director of Software and Cybersecurity Engineering
Cybersecurity has quickly become a central part of medical device development and with the FDA’s February 3, 2026, cybersecurity update cybersecurity, it’s now formally tied to device safety and regulatory expectations. Meaning if your device runs software, this applies to you. And yes… any software counts.
Let’s break it down in a conversational way, because this update is big, and teams need clarity, not another 40-page PDF.
Q&A With Keith: What You Actually Need to Know
Q: What did the FDA announce, and why does it matter?
On February 3, 2026, the FDA reissued its cybersecurity guidance to align with the new Quality Management System Regulation (QMSR). This replaces the old QSR and incorporates ISO 13485:2016.
This update explicitly ties cybersecurity into the processes you’re already expected to maintain for safety and effectiveness.
Put bluntly:
Cybersecurity is now treated like any other design risk. If your device has software, you’re in scope.
Q: What’s changed for software-driven devices?
Here’s the short version:
Cybersecurity must now be woven directly into your design controls, risk management process, verification and validation activities, and CAPAs. It’s no longer a standalone deliverable or a late-stage checkbox.
If you were compliant under the QSR last year, that doesn’t automatically mean you’re compliant today under the QMSR.
Q: What’s this new broader definition of a “cyber device”?
This is the part catching people off guard.
A “cyber device” includes anything with potential connectivity, not just intended connectivity. That means:
- dormant wireless modules
- inactive radios
- debug ports, or any port capable of supporting an external peripheral
- chips capable of communication, even if you never turned them on
- “latent” connectivity pathways you forgot existed
- inductive charging
If a component can connect in theory, the FDA considers it in scope.
This suddenly pulls a lot more devices (and a lot more software teams) into the cybersecurity spotlight.
Q: Are the core cybersecurity expectations new?
No, and that’s the interesting part. The update mostly aligns terminology with QMSR and the substantive requirements haven’t softened.
You are still expected to show:
- SPDF (Secure Product Development Framework)
- Robust threat modeling and risk assessment
- Clear, traceable security architecture documentation
- Machine readable SBOMs with support levels, EOL dates, and known vulnerabilities
- Proof the device can be securely patched, updated, and maintained throughout its lifecycle
The FDA’s message is:
We said these things before. Now we expect you to actually do them.
Software-Specific Issues Teams Often Miss
Most engineering and regulatory teams focus on the obvious parts: SBOMs, threat modeling, and documentation…but the February update reinforces deeper software realities that can cause painful gaps later.
- Patchability Isn’t Optional! You Must Prove It Early
It’s not enough to say, “We can update the device.” You must show:
- how you will deliver patches
- how updates are authenticated
- how the device validates them
- how logs are maintained
- how the deployment path stays secure
If your device can’t be updated… that’s a systemic design failure under the new expectations.
- You Now Own Your Third-Party Software More Than Ever
FDA wants transparency and maturity in your software supply chain.
Problem areas include:
- vendors without long-term security support
- modules with undocumented connectivity
- opaque or proprietary architectures
- abandoned open-source libraries
If a supplier won’t support vulnerability management, you inherit that risk.
Expect the FDA to ask how you’re evaluating vendor maturity and software provenance.
- Post-market Cyber Processes Must Be Systematic
You’re not just responsible for the device; you’re responsible for the ecosystem that keeps it secure.
Your organization must show it can consistently:
- track vulnerabilities
- maintain an up-to-date SBOM
- evaluate new and emerging threats
- coordinate disclosure
- deploy patches
- monitor device cybersecurity post-market
If this isn’t institutionalized, the FDA treats cyber weakness as a QMSR system gap, not a one-off issue.
Q: What happens if manufacturers ignore these updates?
A lot, and none of it is fun:
Regulatory
- Submission delays or outright rejection
- 483s and Warning Letters
Quality System
- QMSR non-conformities
- Forced remediation
Post-market
- Recalls
- Safety notices
- Inability to patch devices already in the field
Business
- Hospitals may refuse insecure devices
- Customers may select more cyber-mature competitors
- Market access can slow or stall
- Financial and/or reputational harm resulting from a cyber incident
Worst Case?
Your device is found vulnerable, and you can’t fix it. That’s a business and regulatory dead end.
Q: So how do we navigate all this?
This is where my team at Vantage comes in.
We help manufacturers transition smoothly into the new expectations without slowing development. Here’s what that looks like in practice:
- You give us your code base.
- We provide a vulnerability report; often within an hour.
- We generate an SBOM straight from your software.
- We identify supply chain risks you may not know are there.
- We flag unsafe components before they cause delays.
- We help modernize legacy elements that could block your submission.
And what if something looks like the FDA won’t like it? We’ll tell you and help you fix it.
Final Takeaway
The February 2026 FDA cybersecurity update isn’t a tweak; it’s a dramatic shift in how the FDA evaluates the safety and viability of software-driven medical devices. Cybersecurity is now safety, not an accessory.
The teams that embrace that mindset now will move faster later with fewer surprises in premarket review and far fewer headaches in post-market maintenance.
If you want help interpreting how these changes affect your device, I’m here to talk through it.
