In June 2023, the FDA cybersecurity guidance for medical devices established new requirements for software developers. This guidance mandated that medical device software developers complete a set of certain activities intended to ensure a secure device design, along with clear guidance on how to document those activities. Since then, the FDA has released more guidance (June 2025) that did not merely change how we approach medical cybersecurity but rather enforced several non-negotiable requirements.
The bottom line is that software teams with well-written company policies that explicitly support cybersecurity activities keep products on track and end users safe.
It is critical to begin with the foundational documents that define the scope, strategy, and governance for secure software development. Similar to the Software Development Plan, the cybersecurity requirements include a Cybersecurity Management Plan. This document should include components such as objectives, timelines, assigned roles within the cybersecurity team, and integration with the software development lifecycle. An implementation tip is to release this plan in parallel to the Software Development Plan so that they are aligned.
Teams often confuse the Security Risk Management Plan with the Cybersecurity Management Plan, but it covers an entirely different area of cybersecurity development, and the FDA requires it. The Security Risk Management Plan defines how cybersecurity risks will be identified, evaluated, and mitigated throughout the phases of a project. Risk evaluation, risk acceptance criteria, and risk acceptability are all key components in evaluating the security risk of a medical device.
Review and update this document during each development phase and keep it separate from the product's Risk Management Plan (ISO 14971).
The FDA mandates one final planning artifact: the Cybersecurity Postmarket Maintenance Plan. This document outlines how you will maintain cybersecurity after product release. The key components include vulnerability monitoring, patch management, and incident response protocols (which can differ on a project/client basis). When implementing this plan, it is beneficial to think about potential project tools, automated vulnerability scanning, escalation paths, and any other monitoring tools that mitigate the vulnerabilities, postmarket.
Now the focus shifts to the analytical processes and tools used for documenting the results. The Threat Modeling Report and Cybersecurity Risk Assessment are two crucial FDA cybersecurity requirements that help us identify, assess, and prioritize risks. The Threat Modeling Report is a systemic analysis that is performed by software developers and software quality assurance engineers to identify potential security threats.
Begin with the product’s software architecture diagrams and transition them into data flow diagrams. This view of the software allows us to define security use cases and assets and the temporal interactions between the system’s components. Finally, identify threats using S.T.R.I.D.E. methodologies (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege).
Why is it so important to complete this activity during the design phase and not downstream? Perform threat modeling throughout the design phase to avoid costly remediation, last minute firefighting, and improving time-to-market without sacrificing device security.
In the Cybersecurity Risk Assessment, we take those same threats identified in the Threat Modeling report and evaluate each one using a risk analysis method defined in the Security Risk Management Plan (previously mentioned). These threats are scored using factors that determine likelihood of occurrence and severity of adverse impact. At this point, the idea is to go through the risks and mitigate them, ideally lowering the risk level in the post-mitigation risk analysis, which concludes the findings. This analysis also assists in drawing ties to any safety-related risks (ISO 14971) and can be traced back to the product’s software risk analysis/software failure mode and effect analysis.
The final phase of cybersecurity work focuses on deliverables that support traceability and regulatory submission. This includes the Security Risk Management Report which summarizes the identified risks and how they are addressed through security controls and verification and validation (V&V). Ideally complete this in Phase 3 and include it in regulatory submissions. Lastly, the Software Bill of Materials (SBOM) provides visibility into the software components that make up your software system. The FDA requires a human-readable and machine-readable copy in the submission.
Throughout this process of building a secure medical device that meets FDA cybersecurity guidance, keep a zero-trust mindset. Challenge default settings while programming or peer-reviewing code, know the enemies at hand, and always consider a different user-perspective. Working with cross-functional teams in product design can help you understand the regulatory landscape and increase the chances for a successful submission!
Uma Gokhale is a Senior Software Quality Assurance Engineer at Veranex.
Correcting a software error or security issue after product release can cost 4 to 5 times more than addressing it during the design phase. (IBM 2008). More currently, software defects have become a leading cause of FDA medical device recalls, with one peer-reviewed study documenting 627 software-related recalls affecting 1.4 million device units over five years. According to McKinsey analysis, these quality problems cost the medical device industry up to $5 billion annually—underscoring why addressing cybersecurity defects during the design phase is critical for both patient safety and business sustainability. (McKinsey, 2018)
Don’t let this happen to you.
The integrated design teams at Veranex focus on meticulously pinpointing market demands, risks and critical user needs from the very beginning. This ensures the selected technologies and medical device software design are optimized for clinical utility and a distinct competitive advantage.
By providing actionable insights upfront and fostering early collaboration with software developers to understand technical constraints, we guide the most effective design and development approach for a secure, compliant, user-centered product and a smooth transition into development.
More broadly, Engineering & Development at Veranex turns promising concepts into robust, submission-ready devices by sitting at the center of the Design & Development continuum. Informed by Research & Strategy, Human Factors, CSMA, and Regulatory Affairs, our multidisciplinary engineering teams translate user, clinical, and commercial requirements into detailed mechanical, electrical, and software designs under ISO 13485 design controls. Design assurance, integrated software, and in-process quality and risk management keep verification, DHF quality, and manufacturability in view from day one. Because Engineering & Development is embedded in the broader Product Design & Engineering business unit and tightly linked to Testing & Verification, Manufacturing Solutions, Preclinical Services, and Clinical Research, your design can move smoothly from feasibility to validated product, ready for both regulators and the market.
Let's explore how our integrated approach can accelerate your path to market.