The new guidance doesn’t change what connected medical product teams already know and it formalizes what many have been doing out of necessity. But it does raise the bar on how security must be demonstrated across the product lifecycle.
FDA Cybersecurity Expectations Are Now Law
In June, 2025, FDA finalized its guidance on Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, replacing the 2023 version and putting Section 524B of the FD&C Act into full effect.
The document outlines what FDA expects in terms of secure design, labeling, and documentation expected in premarket submissions for devices with cybersecurity risk. Its aim is to promote consistency, support efficient review, and ensure that connected medical devices are resilient to real-world cybersecurity threats.
For most engineering teams, the expectations won’t be surprising, but they are now legally enforceable. Cybersecurity practices are no longer just “strongly recommended.” They are required, and FDA will expect clear, traceable evidence that secure design, update mechanisms, and postmarket response are built into your system architecture.
Here’s what the guidance now explicitly calls for:
- Ongoing lifecycle management of cybersecurity, including secure update mechanisms, vulnerability response, and postmarket monitoring
- Alignment with ANSI/AAMI SW96 as a recognized standard for software security risk management
- Documentation that supports system-level traceability
This update doesn’t shift the direction of regulation, rather it catches up to what many connected device teams have already been doing. For years, software teams have had to make these decisions without consistent regulatory direction, often relying on internal best practices or tech industry norms. This final move brings long-needed clarity and gives structure to what secure development should look like across embedded, app, and cloud systems in the medical space.
Cybersecurity Is Now a Software Architecture Problem
FDA’s updated guidance makes it clear that security isn’t something you test for at the end. It has to be designed into the system and FDA now wants to see how those decisions are made, executed, and maintained over time.
“Manufacturers must design, develop, and maintain devices with cybersecurity in mind to ensure device safety and effectiveness.” — FDA Guidance, Section I.A
FDA now expects your architecture to support security across the product’s lifecycle and not just at launch. That includes secure update mechanisms, system-level traceability, and coordination across embedded, mobile, and cloud layers. It’s no longer sufficient to build security features; your system must show it can maintain them over time, under real-world conditions.
Specifically, your system needs to:
- Detect emerging threats
- Respond without compromising safety or function
- Document how those risks are evaluated and addressed across the stack
This puts pressure on how your embedded, mobile, and cloud systems are architected together. Disconnects often surface in the seams between those platforms, especially where coordination was never fully tested. We’ve seen update flows that worked in isolation but failed under integration. BLE app logic that assumed perfect connection timing. Cloud infrastructure that could handle telemetry but couldn’t revoke access or deploy security updates without manual workarounds.
These aren’t small edge cases. Under this guidance, they become signs of a system that wasn’t built with lifecycle security in mind. It’s not enough to implement security mechanisms. You need to demonstrate how your architecture enables ongoing risk management with traceability, predictability, and coordinated ownership across the product ecosystem.
Where Teams Tend to Miss the Mark
The challenges this guidance brings into focus aren’t new, but the bar for how clearly they’re addressed has changed. We’ve worked with teams navigating all of the following, and under the new guidance, each becomes more consequential.
- Patchability and update readiness: Firmware update strategies that previously “worked” may now raise flags if they lack rollback support, coordinated timing across platforms, or documentation showing how updates are managed postmarket.
- Traceability gaps: Security features that function correctly but lack alignment to risk documentation or update planning now create exposure. Regulators want to see how controls were implemented and not just that they exist.
- Disjointed ownership: When decisions around security, updates, or architecture live in separate teams, it shows up as inconsistency in planning, coordination, and lifecycle coverage. This is exactly what FDA now wants addressed system-wide.
- Unclear security posture: Controls without context or maintenance strategy may have passed before. Today, regulators expect a clear story of how security was defined, verified, and aligned to structured risk management practices like SW96.
These exposures often start where systems were built in isolation without shared planning for updates, documentation, or risk response. We see this in update flows that don’t account for rollback, mobile apps that lack traceable security actions, and cloud systems that can’t respond to device-level incidents. These used to be operational challenges. Now, they’re compliance risks.
What reviewers will look for is not just whether your system functions securely, but whether your architecture and process support security over time. That includes documented update mechanisms, defined workflows for vulnerability monitoring and response, and alignment with standards like SW96. You’ll need to show how those controls were planned, implemented, and maintained in a traceable, predictable way.
What This Means Now for Software Teams
What gets built and how it’s built now carries compliance weight. FDA isn’t just evaluating documentation. It’s assessing whether your system design, update strategy, and cross-platform execution show long-term control over cybersecurity risk.
That means:
- Architecture decisions should account for update flows, rollback handling, and cross-platform coordination, not just core functionality.
- Traceability isn’t just a documentation exercise. It must show how controls map to risks across firmware, mobile apps, and cloud systems.
- Update infrastructure should be designed with lifecycle risk in mind, not retrofitted post-launch or during submission prep.
FDA doesn’t just want working systems. It wants systems that can demonstrate security resilience early, clearly, and throughout the entire lifecycle. That makes software architecture, documentation, and process alignment as critical as product features.
The Value of Experience in Meeting Regulatory Demands
Designing for compliance with today’s FDA expectations means making the right technical decisions early—across embedded systems, mobile apps, and cloud infrastructure—and ensuring those decisions hold up under scrutiny months or years down the line.
That’s difficult to do without prior exposure to what actually works. Experienced partners bring value by helping teams avoid common missteps, align on architecture decisions that support secure updates and traceability, and structure development around what regulators will expect to see without slowing delivery.
We work alongside engineering and product teams to:
- Build update mechanisms that integrate cleanly across the system, not just at the firmware level
- Identify gaps in architecture that could introduce compliance or integration risk later
- Align development workflows and documentation to regulatory expectations like IEC 62304 and SW96
- Support decision-making under real-world constraints (timelines, legacy systems, shifting requirements)
This kind of support helps reduce uncertainty, bring clarity to decision-making, and accelerate the path to readiness when it matters most.
Where This Leaves Development Teams
For most teams, this guidance won’t introduce new concepts, but it does change what needs to be shown, how early it needs to be built in, and how closely systems will be scrutinized.
Security decisions now have to be reflected in architecture, workflows, and documentation that hold up across the entire product lifecycle. That’s not just about meeting regulatory expectations. It’s about building systems that are ready for what happens after launch.
Whether you’re assessing your update path, reviewing documentation strategy, or working through architectural tradeoffs, now is the time to make sure your development practices are aligned before those gaps become real blockers to approval, delivery, or trust.
If you’re reevaluating your system architecture or software readiness, learn more about how we work with teams building connected medical products.
