If you’re a medical device engineer, you’ve likely noticed the ground shifting beneath your feet. With the FDA’s latest cybersecurity guidance released in 2025, the expectations for device security have become more stringent than ever, especially for what the agency calls a “cyber device.” The definition is broad: if your product includes software and can connect to a network, it qualifies.
For these devices, the question is no longer if you need a secure architecture, but how you can definitively prove it to regulators. And proof doesn’t come from intentions or high-level plans, it comes from the engineering evidence you produce throughout your development process.
If you’re still getting up to speed on what’s changed, we’ve covered the high-level implications of the new guidance in this article. That piece outlines what the FDA’s updates mean for software teams and why these changes matter for the industry as a whole.
In this article, we’ll break down the FDA’s recommended Secure Product Development Framework (SPDF) into a phased plan that shows exactly how to generate the necessary evidence at each stage of your project.
Adopting a Secure Product Development Framework (SPDF)
Defining the Framework
The SPDF isn’t a new, standalone process you bolt onto your existing work. It’s an end-to-end discipline that integrates security risk management directly into your Quality Management System (QMS) and software development lifecycle (SDLC).
The Cultural Shift
The goal isn’t to add a mountain of extra tasks at the end of a project, but to make security an integral part of every development stage, just like unit testing or code reviews. This shift requires more than just new processes, it demands a cultural change, where security becomes a shared responsibility across teams, rather than the job of a single person or isolated group.
Why the FDA Cares
The FDA’s focus on the SPDF stems from its ability to provide clear, objective evidence that security is a managed, intentional process. It gives you a defensible path to satisfying the new regulations while reducing the risk of last-minute surprises during submission.
The Practical Reality
The key is to make documentation a natural byproduct of your development work, rather than a separate, painful task you save for the end. At first glance, this might feel like additional overhead. But by integrating these practices from the start, you will save significant time and resources, avoiding the costly redesigns and frantic documentation work that delay submissions.
The Roadmap Ahead
What follows is a phased approach that maps SPDF requirements to your actual development workflow. We’ll break it into three phases (Design & Architecture, Implementation & Verification, and Release & Maintenance) and show you exactly which artifacts to produce at each stage.
By the end, you’ll have a clear picture of how to generate the seven core pieces of evidence the FDA expects: threat models, risk analysis, security architecture documentation, traceability matrices, test reports, SBOMs with vulnerability management, and post-market cybersecurity plans.
Phase 1: Design & Architecture (The Foundation of Trust)
This is the phase where you lay the foundation for a resilient, secure device. Getting it right here means you’re building security in, not trying to bolt it on later. The goal is to be proactive, not reactive, creating the artifacts that prove your system is secure by design and treating them as living documents that mature with your product.
Artifact #1: Threat Model & Data Flow Diagrams (DFDs)
You should show regulators that you’ve systematically identified potential cybersecurity threats to your entire medical device system. An actionable way to start is by creating a set of Data Flow Diagrams (DFDs).
A DFD is essentially a visual map, a diagram that illustrates the security architecture of your system. Think of it as the “security contract” for your design; it should be detailed enough that any significant implementation changes automatically trigger a review of the threat model.
For example, the DFD for a smart infusion pump system would be a diagram showing boxes representing the pump, the clinician’s programming tablet, and the backend cloud server. Arrows connecting these boxes would represent every data flow (like commands, alerts, and patient data uploads) and would clearly show where data crosses trust boundaries, like from the secure device to the potentially hostile hospital Wi-Fi network.
From DFDs to Threat Modeling
Once you have your DFDs, you can apply a structured framework like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to analyze them. Looking at our infusion pump DFD, a STRIDE analysis would force us to ask questions like: “Could an attacker spoof commands to the pump?” or “Could they tamper with the firmware update data in transit?”
To make this process efficient and repeatable, consider turning it into a checklist-based review by leveraging established threat libraries like AAMI TIR57 or the MITRE ATT&CK framework. The output is your formal Threat Model, a living document that serves as your first key artifact. It should, at a minimum, contain a log of identified threats, their potential causes, and your proposed mitigations.
Artifact #2: Cybersecurity Risk Analysis Report
Once you’ve identified threats, you should establish a rational, and a documented process for evaluating their risk. This is where you connect cybersecurity risk to patient safety. A practical approach is to use MITRE’s rubric for applying the Common Vulnerability Scoring System (CVSS) to medical devices. This generates a technical exploitability score, which you then combine with a patient harm analysis aligned with ISO 14971 to produce a holistic cybersecurity risk score.
Right Sizing the Effort
However, a key part of managing this process is “right-sizing” the effort. Not all threats warrant a deep-dive analysis. We recommend agreeing as a team to perform the full, detailed scoring analysis only for threats that could plausibly result in a Severity rating of Serious, Critical, or Catastrophic.
For lower-severity threats, you can accept the risk with a brief, documented rationale. For instance, a threat of unauthorized access to a non-clinical diagnostic log on the device might be accepted, while a threat that could alter a drug dosage calculation would demand the most rigorous analysis. This allows you to focus your finite engineering resources where they matter most, demonstrating a mature, risk-based approach.
Artifact #3: Security Architecture & Control Catalog
The FDA guidance makes it clear that your security architecture is the direct, tangible response to your threat model. An effective way to organize this is to create a Security Control Catalog.
This document becomes the central repository that defines each mitigation with a unique identifier and a clear, testable statement (e.g., “SC-047: All firmware updates SHALL be cryptographically signed using ECDSA P-256”). It creates the critical link in your traceability chain, connecting a specific risk to the control that mitigates it and the requirement that will be used for verification. This catalog should be version-controlled right alongside your source code.
Security Architecture Views
Your Security Architecture Views are the visual proof of these controls in action. Instead of relying on a single, high-level block diagram, consider providing focused views that highlight different aspects of your security architecture:
- Global System View: Shows the device within its entire operational ecosystem, highlighting all trust boundaries (e.g., between the device, a mobile app, and a cloud server) and network interfaces.
- Updateability/Patchability View: This dedicated diagram illustrates the secure software update mechanism from end-to-end, detailing every step from image signing on a secure build server, establishing a root of trust on the device, and on-device validation before the update is applied.
- Multi-Patient Harm View: Illustrates the specific controls (e.g., network segmentation, device-level firewalls, encryption of data-at-rest) that prevent a compromise on one device from propagating across the hospital network and causing widespread patient harm.
Phase 2: Implementation & Verification (Generating Objective Evidence)
In this phase, the focus shifts from design to execution and proof. The goal is to build the controls you’ve designed and generate objective evidence that proves they work as intended. This is about creating documented evidence that your design wasn’t just theoretical, but was implemented correctly and functions as expected from a security perspective.
Artifact #4: Requirements Traceability Matrix
To satisfy regulators, it’s important to show a clear connection between the risks you identified, the controls you designed, and the tests that verify those controls. This means providing objective evidence that connects every security risk to a specific architectural control, the code that implements it, and the test that verifies its effectiveness.
An FDA reviewer should be able to follow this “thread” from start to finish without gaps. This is where the Security Control Catalog you created in Phase 1 becomes invaluable.
A Traceability Matrix is the most straightforward way to present this linkage. Modern requirements management tools, like Jira with specialized plugins or platforms, can automate much of this linking process, making it a continuous part of your development workflow rather than a separate task.
Why It’s More Than Just Documentation
This matrix is far more than just a table for regulators; it’s a vital project management tool that ensures no security requirement is accidentally dropped during implementation. The matrix maps the unique ID for each security control to system/software requirements, the code modules that implement them, and finally, the test case IDs that prove they function correctly. By keeping this matrix up to date throughout development, this artifact demonstrates that security is an active, integrated part of your workflow.
Artifact #5: Verification Test Reports & Penetration Test Report
Once your controls are implemented, you should prove empirically that they are effective and your device is resilient, which requires empirical evidence. This requires rigorous verification testing that goes beyond happy-path scenarios to actively challenge the system..
Verification Testing
For every security control in your catalog, we recommend creating a corresponding test protocol designed to prove its effectiveness. For example, if your control states that “firmware updates must be cryptographically signed,” your test report should show evidence that you verified the device explicitly rejects a maliciously crafted, unsigned update. The test log should show the device receiving the bad image, attempting the update, logging a signature validation failure, and safely reverting to the last known good state. This type of evidence leaves no doubt that the control performs as intended under real-world conditions.
Independent Penetration Testing
Another critical artifact from this phase is an unredacted Report from an Independent Penetration Test. The FDA requires a comprehensive, objective assessment of your device’s resilience from a third party. To make this test effective, we recommend providing the testers with your threat model and architecture diagrams. This allows them to move beyond black-box testing and focus on the areas of highest risk.
Your submission should also include your detailed remediation plan for every single finding, regardless of severity. Even minor issues should be addressed, showing regulators that you have a proactive, transparent process for managing vulnerabilities and continuously improving device security.
Phase 3: Release & Maintenance (Preparing for the Real World)
Shipping your device is a major milestone, but your engineering responsibility doesn’t end there. For cyber devices, this final phase is mandatory and shifts the focus from initial development to long-term lifecycle management. The core task is to prepare your device for a world of evolving, real-world threats, ensuring that security remains robust even after the product is in the field.
Artifact #6: SBOM, VEX, and Vulnerability Management Process
The FDA now mandates complete transparency into your software composition via a Software Bill of Materials (SBOM). The most effective approach is to treat the SBOM as a living document, rather than a one-time deliverable.
By integrating SBOM generation tools like Syft directly into your CI/CD pipeline, you can transform the SBOM into the foundational artifact for your entire vulnerability management process. This means your build pipeline can be configured to fail if a developer introduces a new library with a known critical vulnerability, forcing a security review before the code is even merged.
This creates a closed-loop system for ongoing security management. When your automated pipeline generates a new SBOM and a scan reveals a new security vulnerability in one of your dependencies, that CVE becomes a new input into your Cybersecurity Risk Assessment. This feeds both design-level and component-level threats into the same rationalized triage process.
Prioritizing Vulnerabilities with VEX
However, in systems with many dependencies, this can lead to a daunting number of CVEs. This is where a Vulnerability Exploitability eXchange (VEX) document becomes essential. A VEX allows you to efficiently document your analysis of flagged CVEs, allowing you to distinguish between issues that require action and those that don’t.
For example, a flagged vulnerability might be labeled as not_affected with a rationale (e.g., “the vulnerable function in libcurl relates to FTP, which is not compiled into our binary”) or as affected and in need of mitigation. This process keeps remediation efforts focused only on vulnerabilities that pose a genuine risk, rather than overwhelming your team with noise.
Third-party binary components introduce an additional challenge. If you are using these, you should request an SBOM from the supplier. If they cannot provide one, the FDA expects a documented justification for its absence and an analysis of the associated risks. This transparency ensures that even external components are accounted for in your security posture.
Artifact #7: Post-Market Cybersecurity Management Plan
Even after your device is in the field, you are responsible for monitoring, responding to, and managing cybersecurity risks. The FDA requires this to take the form of a formal Cybersecurity Management Plan.
The plan should detail how you’ll monitor for new vulnerabilities (e.g., subscribing to CISA alerts, specific vendor advisories, and monitoring services). It should also clearly assign roles and responsibilities, naming the individuals or teams accountable for ongoing monitoring and response activities.
In addition, the plan should also contain your policy for coordinated vulnerability disclosure (CVD). This policy outlines how you will work with researchers, customers, and other stakeholders when vulnerabilities are discovered. It should also include defined timelines and SLAs for analyzing issues, triaging their severity, and delivering patches to customers.
By treating post-market security as a continuous, structured process rather than an afterthought, you demonstrate to both regulators and customers that your commitment to device safety extends well beyond the launch date.
Making SPDF Standard Practice
By following this phased approach (identifying threats, assessing risk, architecting controls, proving effectiveness, and planning for post-market management) you systematically generate the evidence the FDA expects. More importantly, you build devices that are genuinely prepared for evolving threats.
The shift requires upfront investment. Threat modeling takes time. Traceability matrices need maintenance. Penetration tests cost money. But teams who integrate these practices early consistently report faster submissions, fewer last-minute architecture changes, and more confident responses to post-market vulnerabilities. The documentation becomes a natural byproduct of disciplined engineering rather than a painful pre-submission scramble.
The Bottom Line
Connected medical devices need systematic security evidence from day one. When threat models, traceability, and post-market planning are built into your development process rather than added at submission time, you get both regulatory approval and devices that can respond to real-world threats. That’s what the FDA’s 2025 guidance demands.
At Punch Through, we build connected medical devices with this SPDF process built in. Every project generates these seven artifacts systematically. If you need that engineering capability for your device, let’s talk.
