Most software teams working on medical devices treat cybersecurity the same way they treat accessibility: something you address at the end, before submission, once the product is otherwise done.
The FDA’s Final Guidance on medical device cybersecurity, released on June 27, 2025, makes that approach untenable.
This isn’t a minor update. The 2025 guidance replaces the 2023 version and formally implements Section 524B of the FD&C Act. Cybersecurity is no longer part of the broader safety and effectiveness assessment: it is now an independent regulatory standard.
A device that fails to meet cybersecurity requirements can be denied market authorization on that basis alone.
What changed in the medical device software development process
The 2023 guidance established the foundations (lifecycle thinking, threat modeling, SBOM documentation). The 2025 version makes those foundations enforceable.
The first change worth understanding is the expanded definition of “cyber device”. Under the new guidance, the bar is low: if a device includes software, connects to the internet, directly or indirectly, or has features that could be exploited, it qualifies.
This includes not just the device itself, but related systems: update servers, cloud infrastructure, hospital integration points. If your IVD software connects to a LIS, talks to a cloud backend, or receives over-the-air updates, it almost certainly falls into this category.
The second change is the integration of the Secure Product Development Framework (SPDF) into the Quality Management System. Security is no longer a layer you add before filing: it has to be embedded in design controls, risk management, and validation from the start.
Premarket submissions for cyber devices must now include approximately 12 standardized cybersecurity documents via the eSTAR process. Missing any of them can result in Refuse to Accept decisions before the substantive review even begins.
The third change is the shift from point-in-time submission to continuous lifecycle obligation. Manufacturers are required to maintain active cybersecurity management plans that evolve with emerging threats.
This includes notifying customers of significant vulnerabilities within approximately 30 days of discovery, and documenting the difference between uncontrolled risks (requiring immediate action) and controlled risks, addressed during scheduled maintenance.
Three artefacts that change nature
The practical impact is most evident in three artefacts that IVD software teams already produce, but that the guidance now treats differently.
Threat model evolves with the product
No longer a document you write once during design and file. The threat model is now expected to evolve with the product.
Every significant software change (a new integration, a new communication interface, a dependency update) should trigger a reassessment of the threat surface. Teams that treat threat modeling as a one-time exercise will accumulate gaps that may not be discovered until submission.
SBOM becomes a living document
The Software Bill of Materials becomes a living document rather than a snapshot. The guidance requires SBOMs to cover both first- and third-party components, formatted in standard structures (SPDX or CycloneDX), and updated with every software release.
In practice, SBOM maintenance needs to be built into your release process rather than handled manually before each submission.
Software updates enter the lifecycle plan
Updates need to be planned and documented as part of the medical device software lifecycle, not treated as reactive patches.
The guidance distinguishes between updates addressing uncontrolled risks, which require immediate action and customer notification, and those addressing controlled risks, which can be scheduled.
Your update strategy, including testing, deployment, and communication, needs to be documented as part of your cybersecurity management plan.
What does this mean for IVD software development?
For teams developing or distributing IVD software, the implication is structural. Security can no longer be delegated to a final review before submission.
It needs to be part of how you manage requirements, handle dependencies, plan releases, and document risk.
The SPDF requirement means that security practices (secure coding, access control, cryptography, logging) need to be traceable through your quality system, not just present in the code. Reviewers will look for evidence that security was designed in, not added on.
Teams with mature QMS processes and solid lifecycle documentation have a meaningful advantage here. The overhead for them is incremental.
For teams that treat their QMS as a documentation exercise rather than an operational framework, the gap between current practice and what the guidance requires is substantial.
Building products that can be maintained, not just cleared
At Aimasoft, we think the most important cybersecurity question isn’t whether your submission will be accepted. It’s whether your product can be maintained securely over time.
The FDA guidance formalizes what good IVD software development already requires: a product architecture and a development process that can sustain security over time, not just demonstrate it at a point in time.
That’s a harder problem than submission compliance, and it’s the one worth solving first.
