FDA Cybersecurity Guidance 2026: What Changed?

On February 3, 2026, the FDA quietly reissued its cybersecurity guidance for medical devices. If you're in the middle of a development cycle or preparing for FDA submission, you might be wondering: do I need to change everything I've been working on?

The short answer: probably not.

The longer answer: it depends on whether you were already following the previous version, and whether you understand what actually changed.

What Actually Changed

The February 2026 update to "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" made one primary change: replacing references to the Quality System Regulation (QSR, 21 CFR 820) with the new Quality Management System Regulation (QMSR).

That's it. The core cybersecurity requirements remain the same.

Understanding the QSR to QMSR Shift

In February 2024, the FDA finalized a rule modernizing its quality system requirements by harmonizing with international standards. Specifically, the QMSR incorporates by reference ISO 13485:2016, the internationally recognized standard for quality management systems in medical devices.

This change took effect February 2, 2026—just one day before the cybersecurity guidance update.

What this means in practice:

Instead of following FDA's standalone quality system regulation, manufacturers now need to comply with ISO 13485 as incorporated into 21 CFR Part 820. For cybersecurity, this is significant because ISO 13485 explicitly requires risk management throughout the product lifecycle (Subclause 7.1) and software validation (Subclause 7.3.7).

The updated cybersecurity guidance simply aligns its references and recommendations with this new regulatory framework.

What Stayed the Same (Everything That Matters)

All the substantive cybersecurity requirements from the June 2025 guidance remain in effect:

1. Secure Product Development Framework (SPDF)

The recommendation to use an SPDF, a set of processes that reduce vulnerabilities throughout the device lifecycle, is unchanged. The guidance still recommends frameworks like AAMI TIR45, IEC 81001-5-1, or ANSI/ISA 62443-4-1.

2. Software Bill of Materials (SBOM)

Section 524B of the FD&C Act still requires SBOMs for "cyber devices"—which includes most connected medical devices. The guidance continues to recommend machine-readable SBOMs following NTIA's minimum elements, plus additional information like:

Software support level (actively maintained, abandoned, etc.)
End-of-support dates for components
Known vulnerabilities, including those in CISA's Known Exploited Vulnerabilities Catalog

3. Security Architecture Requirements

The guidance still expects detailed security architecture documentation, including:

Global system views
Multi-patient harm views
Updateability/patchability views
Security use case views

4. Threat Modeling and Risk Assessment

The requirement for comprehensive threat modeling and security risk assessments separate from (but connected to) safety risk assessments remains fully intact.

5. Cybersecurity Testing

Recommendations for penetration testing, vulnerability scanning, fuzz testing, and other security validation activities are unchanged.

6. The Five Core Security Objectives

Your device still needs to address:

Authenticity (including integrity)
Authorization
Availability
Confidentiality
Secure and timely updatability and patchability

Why This Update Matters

Even though the changes are primarily administrative, this update signals something important: the FDA's commitment to international harmonization while maintaining rigorous cybersecurity expectations.

The ISO 13485 Connection

By tying cybersecurity guidance to the QMSR (and therefore ISO 13485), the FDA is making cybersecurity an explicit part of your quality management system—not a separate compliance exercise.

This has practical implications:

Design and Development (ISO 13485 Subclause 7.3): Cybersecurity controls must be integrated into your design inputs, design outputs, design verification, and design validation. You can't bolt on security at the end.

Risk Management (ISO 13485 Subclause 7.1): Your risk management processes must now explicitly address cybersecurity risks alongside traditional safety risks. This means documenting how security threats could lead to patient harm.

Change Management (ISO 13485 Subclause 8.5): When cybersecurity vulnerabilities are discovered post-market, your corrective and preventive action (CAPA) processes must address them systematically.

What This Means for Global Markets

If you're pursuing both FDA clearance and CE marking (or other international regulatory approvals), the alignment with ISO 13485 reduces duplicative work. The quality processes you build for FDA compliance will largely satisfy international requirements.

What You Should Do Now

If You Were Already Following the June 2025 Guidance

Continue what you're doing. Update any internal documentation that references "21 CFR 820" or "QSR" to reference "QMSR" or "ISO 13485" instead, but your actual processes and deliverables remain valid.

Quick checklist:

✅ Review your quality procedures for correct regulatory citations
✅ Ensure your design and development procedures reference ISO 13485 subclauses
✅ Update any submission templates to reference QMSR instead of QSR
✅ Verify your risk management process addresses both safety and security

If You Haven't Started Yet

Now is actually a good time to begin. Here's why:

1. The requirements are stable. After multiple iterations (2014, 2023, 2025, and now 2026), the core expectations are well-established. The February 2026 update suggests the FDA isn't planning major substantive changes in the near term.

2. The framework is clear. The guidance provides specific recommendations for what FDA expects in premarket submissions. Use it as a roadmap.

3. Earlier is cheaper. Building security into your architecture from day one is exponentially less expensive than retrofitting it later. We've seen projects spend 4-6 months and hundreds of thousands of dollars fixing security issues discovered mid-development.

Key areas to focus on:

Security Architecture (Start Here): Design your system with security in mind from the beginning. Define trust boundaries, authentication mechanisms, and data flow security before writing code.

Threat Modeling: Identify potential security risks early. This informs your entire development approach and helps you make architecture decisions that reduce vulnerabilities.

SBOM Management: Start tracking your software components now. Don't wait until submission to discover you don't know what's in your product or can't get vulnerability information from third-party suppliers.

Testing Strategy: Plan for security testing throughout development, not just at the end. Include penetration testing, vulnerability scanning, and fuzz testing in your verification and validation plans.

If You're Mid-Development

Assess where you stand against the guidance recommendations:

Gap Analysis Questions:

Do you have a documented security risk management process separate from your safety risk assessment?
Can you produce an SBOM for all software components in your device?
Have you performed threat modeling for your system architecture?
Do you have documented security architecture views (global system, multi-patient harm, updateability)?
Have you conducted security testing beyond standard software verification?

If you answered "no" to any of these, address those gaps before submission. FDA reviewers will look for this documentation.

The Bigger Picture: FDA's Quality Management Evolution

This cybersecurity guidance update is part of a broader FDA initiative to modernize its quality system requirements and align with international standards.

What's driving this:

Global Harmonization: By adopting ISO 13485, the FDA is reducing regulatory divergence between markets. This benefits both manufacturers (less duplicative work) and patients (faster access to safe devices globally).

Risk-Based Approach: The QMSR emphasizes risk management throughout the product lifecycle—perfectly aligned with how cybersecurity must be managed. Security risks evolve over time and require continuous monitoring and response.

Modern Development Practices: The updated framework better accommodates agile development, iterative design, and continuous improvement—all essential for medical device software in 2026.

Common Questions

Do I need to resubmit if I received clearance under the old guidance?

No. Devices cleared or approved under previous versions of the guidance remain valid. However, if you submit modifications or new versions, expect FDA to apply current expectations.

Does this affect my postmarket cybersecurity obligations?

No. Postmarket cybersecurity requirements remain as outlined in FDA's "Postmarket Management of Cybersecurity in Medical Devices" guidance. You still need to monitor for vulnerabilities, release patches, and report incidents as appropriate.

What if I'm using a different quality framework than ISO 13485?

The QMSR requires compliance with ISO 13485 as incorporated by reference in 21 CFR 820. If you were previously following only the old Part 820, you'll need to transition to ISO 13485. If you're already ISO 13485 certified, you're ahead of the game.

How does this affect IDE submissions?

The cybersecurity recommendations for IDE submissions (outlined in Appendix 3 of the guidance) remain unchanged. You still need to include cybersecurity risks in informed consent, provide architecture views for safety-critical functionality, and include an SBOM.

What Hasn't Changed: The Challenge Remains the Same

Whether you call it QSR or QMSR, the fundamental challenge hasn't changed: building medical device software that is both innovative and secure, that moves quickly through development while maintaining rigorous documentation, that integrates seamlessly into clinical workflows while defending against sophisticated cyber threats.

The updated guidance doesn't make this easier or harder. It simply reinforces that cybersecurity is not optional, not secondary, and not something you can defer until later in development.

The Path Forward

The February 2026 update is primarily a housekeeping exercise—aligning cybersecurity guidance with the new QMSR framework. But it serves as a useful reminder: FDA expects cybersecurity to be an integral part of your quality management system, not a separate compliance activity.

Three takeaways:

If you're already compliant: Keep doing what you're doing. Update your references, but your processes remain valid.
If you're starting now: Use the current guidance as your roadmap. The requirements are stable, the framework is clear, and building security in from the start will save you time and money.
If you're mid-development: Conduct a gap analysis against the guidance recommendations. Address gaps before submission, not during FDA review.

The good news? The path to FDA cybersecurity compliance is clearer than ever. The challenging news? The bar remains high, and for good reason—patient safety depends on it.

Need Help Navigating FDA Cybersecurity Requirements?

At Hattrick, we're building our quality management system specifically to support secure, compliant medical device software development. We understand both the technical challenges of building secure systems and the regulatory requirements of demonstrating that security to the FDA.

Whether you're just starting development, mid-project and need guidance, or preparing for submission, we can help you build FDA-ready medical device software.

Get in touch: hattrick-it.com/contact