How to Implement Secure Software Development Lifecycle (SDLC) for Medical Devices

Let's cut to the chase: One of the biggest mistakes medical device manufacturers make is waiting until their software is nearly finished before thinking seriously about cybersecurity.

Wait too long and you'll be knocking yourself out scrambling to put together the documentation FDA expects. And that can, and most likely will, mean months of extra work.

But you can avoid all that extra drama. Consider this: A secure software development lifecycle for medical devices. What it does is build cybersecurity into every state of development.

And here's the crux of it. You create threat models and security architecture diagrams while designing the device, include security requirements in your software requirements specification (SRS), and generate a software bill of materials (SBOM) directly from the build process.

This approach is also set up so you can verify security controls during verification and validation (V&V) and assign someone to manage cybersecurity after the device reaches the market.

There's also a cost-savings aspect. When you do this work as part of normal development, it adds very little extra cost (trying to recreate everything after the software is finished is another story).

Sadly, we've seen far too many teams learn this the hard way. What they typically do is finish development, hire a consultant to prepare the cybersecurity paperwork, and submit everything to FDA.

So, what happens?

Week after week goes by. At first, you shrug it off. These processes take a little time. But after six weeks of waiting, the anxiety kicks in. Finally, an additional information request arrives. You learn that something is missing or your team's work simply doesn't hold up under review.

Suddenly, engineers are revisiting work they thought was finished, and the product launch is slip sliding away ...

If you remember nothing else, remember this:

A secure SDLC isn't just about producing documents for FDA. It's about building security into your device from day one.

This article was created to help you make that happen. This post is the version we wish more teams had read before they started coding.

What does 'secure SDLC' actually mean for a medical device?

If you search for secure software development lifecycle medical devices, you'll find plenty of explanations about integrating security into every stage of development. That's the basic idea, but what does it actually mean for your team?

For starters, it means your team thinks about cybersecurity while making design decisions, not after the software is finished. It also means security becomes part of the work your engineers are already doing.

Here's what a secure SDLC for a medical device should look like:

• Threat modeling starts before the architecture is finalized. You want to identify potential security problems while there's still time to change the design.
• Security requirements go into the software requirements specification (SRS). They should be developed alongside functional requirements, not added as an afterthought.
• Code reviews look for security weaknesses. Your developers are already reviewing code for bugs. They should also be checking for vulnerabilities using an expanded checklist.
• Verification includes security controls. If you've implemented a security control, you need a test case showing that it works.
• Your SBOM comes directly from the build process. An SBOM generated from build tooling is more reliable than a spreadsheet someone puts together just before submission.
• Someone takes responsibility for cybersecurity after launch. Patching, vulnerability monitoring, and incident response all need an assigned owner before the device reaches the market.

Each of these activities produces documentation the FDA expects to see. When they're part of your normal workflow, the additional effort is relatively small.

Wait until development is finished, however, and you could spend months trying to reconstruct the same information.

From SDLC stage to security activity to FDA artifact

One question we hear from medical device teams is, "How do we know which cybersecurity documents we should be creating, and when?"

The easiest way to answer that is to connect each development stage with the security work that needs to happen during that stage.

This is also a useful way to approach a gap analysis. Instead of waiting until submission preparation to figure out what's missing, you can check whether each stage of development is producing the documentation you'll eventually need.

The following table shows the FDA cybersecurity artifacts by development stage, using the artifact names from Appendix 4, Table 1, of the FDA's February 2026 premarket cybersecurity guidance.

Our book chapter on the secure development lifecycle explains these stages in more detail.

Development stage	Security activity	Output / FDA artifact
Planning	Define the scope, regulatory pathway, relevant threat actors, and cybersecurity acceptance criteria.	Section in Cybersecurity Management Plan
Requirements	Develop security requirements based on potential threats and the device's intended use.	Security requirements in SRS; risks captured in threat model
Architecture	Identify trust boundaries, data flows, and attack surfaces. Complete the threat model.	Security Architecture Views; Threat Model
Architecture	Evaluate threats, assess their severity, and select appropriate security controls.	Cybersecurity Risk Assessment; Cybersecurity Controls
Architecture	Document how cybersecurity risks that could affect patient safety are incorporated into the ISO 14971 risk management process.	Method for transferring security risks into the safety risk assessment (part of the Cybersecurity Risk Assessment)
Implementation	Follow secure coding standards and track how security controls are implemented.	Code reviewed against checklist; controls traceability
Implementation	Generate the SBOM automatically during the software build.	Software Bill of Materials
Implementation	Continuously check software dependencies against the NVD and CISA KEV catalogs.	Vulnerability assessment and software support documentation
Verification	Test security controls through unit and integration testing.	Test cases tied to control IDs
Verification	Conduct independent penetration testing and fuzz testing.	Cybersecurity Testing Report
Verification	Review unresolved software anomalies to determine whether they create cybersecurity risks.	Security Assessment of Unresolved Anomalies
Pre-release	Bring the cybersecurity findings, assessments, and supporting evidence together for submission.	Cybersecurity Risk Management Report; Measures and Metrics
Post-market	Monitor vulnerabilities, manage patches, respond to incidents, and maintain updates.	Cybersecurity Management Plan execution

The goal is to make cybersecurity documentation part of the development process rather than a separate project.

When your engineers complete a security activity, the supporting evidence should already exist. By the time you're preparing your FDA submission, you should be organizing documentation, not trying to create it from scratch.

What goes wrong in practice

Even teams with experienced engineers can run into trouble when cybersecurity isn't integrated into their development process.

We've seen the same problems come up repeatedly, regardless of whether a company has five developers or an entire engineering department.

Threat modeling happens too late.

This is one of the most common mistakes. A team finishes its architecture, then conducts a threat model and discovers that a trust boundary should have been designed differently.

Changing the architecture now could mean weeks of additional development. Instead, the team accepts the risk and hopes the documentation will satisfy FDA.

That's why medical device threat modeling timing matters. You want to identify these problems while you can still make changes without disrupting the entire project.

Security requirements are too vague to test.

Writing "the system shall be secure" in your requirements document doesn't accomplish much.

A useful requirement tells your engineers exactly what the software must do. For example, "The system shall require multi-factor authentication for any administrative function."

That gives your verification team something specific to test.

If you can't develop a test case for a requirement, it probably needs more work.

The SBOM is put together at the last minute.

We've seen teams wait until submission preparation to create their software bill of materials.

Someone searches through package.json, copies the dependencies into a spreadsheet, and assumes the job is finished.

Unfortunately, that approach can miss transitive dependencies, the software components that your direct dependencies rely on.

FDA recommends a machine-readable SBOM that includes the NTIA minimum elements. In practice, that means using tools that generate a CycloneDX or SPDX file.

Automating this process also makes it easier to keep the SBOM current as your software changes.

Security controls exist on paper but not in the software.

Your security documentation might say the device uses signed firmware to prevent unauthorized updates.

But what happens if nobody configured the continuous integration (CI) pipeline to sign the firmware?

You could end up shipping an unsigned image even though your risk assessment says the control is in place.

Ideally, your penetration testing team catches the problem. Otherwise, it could remain undiscovered until the device is already in use.

Penetration testing doesn't cover the entire system.

Medical devices rarely operate in isolation anymore.

A device might communicate with a mobile application, cloud service, hospital network, or remote monitoring platform.

If your penetration testing only examines the device firmware, you could miss vulnerabilities in those connected systems.

FDA reviewers may notice that a cloud component has its own attack surface and ask why it wasn't included in the testing scope.

Nobody owns cybersecurity after launch.

A Cybersecurity Management Plan that simply promises to patch vulnerabilities "in a timely manner" isn't much of a plan.

You need to explain how vulnerabilities will be monitored, how quickly your team will respond, when issues will be escalated, and who is responsible for making those decisions.

Having a clearly identified cybersecurity management plan owner helps ensure those responsibilities don't get lost after the product launches.

Five things to do this sprint, regardless of where you are

What if your team is already well into development and you're just now realizing that some of this cybersecurity work hasn't been done?

You may have some catching up to do, but you don't necessarily need to start over.

For teams that already have working software, these five steps can help establish a more structured approach to cybersecurity.

1. Take inventory of what you've built.

Start by documenting your software components, programming languages, interfaces, data flows, and trust boundaries.

Be accurate about what's actually in the system today. This isn't the time to describe what you intended to build.

You need a clear picture of the current architecture before you can identify security gaps.

2. Generate an SBOM from your build process.

Don't try to create a software bill of materials manually.

Use a tool that works with your development environment, such as syft, cyclonedx-cli, or dotnet-CycloneDX.

The goal is to produce a CycloneDX or SPDX file automatically through your CI pipeline.

That way, your SBOM can be updated whenever the software changes.

3. Build a threat model around your existing architecture.

Now that you know what's in your system, look at how someone might attack it.

You can use STRIDE, PASTA, or another established threat modeling framework. What matters most is that your team uses a consistent method and documents the results.

Each identified threat should have a unique ID so you can connect it to your cybersecurity risk assessment.

4. Connect your existing security controls to the threats they address.

Your software probably already includes some security measures, such as authentication, encryption, input validation, or logging.

Document those controls and identify which threats each one is intended to address.

This gives you a clearer picture of what's already protected and where additional work is needed.

Any missing controls can then become part of your remediation backlog.

5. Assign responsibility for post-market cybersecurity.

Before submission, decide who will be responsible for monitoring vulnerabilities, coordinating patches, and managing security incidents after launch.

Document that responsibility in your Cybersecurity Management Plan.

Don't simply assign it to "engineering" or "the security team." Identify a specific person who will be accountable for making sure the work gets done.

For a team with working software, completing these five steps in one sprint may be realistic, depending on the system's complexity and the documentation already available.

More importantly, these steps can help you uncover problems while there's still time to address them before submission.

What the teams that ship cleanly have in common

There's a noticeable difference between medical device teams that move through FDA cybersecurity review with relatively few problems and those that spend months responding to questions.

The teams that do well usually have one thing in common: They treat cybersecurity as part of engineering, not just regulatory compliance.

Their threat models help shape the architecture. Their security requirements guide development. Their verification activities demonstrate that controls actually work.

As a result, much of the documentation FDA wants already exists by the time they're preparing their submission.

Teams that struggle often take the opposite approach. They finish building the software and then try to assemble the cybersecurity documentation afterward.

The problem is that some of the decisions they're supposed to document were never formally made.

If there's a shortcut, it's to identify the required cybersecurity artifacts early and make sure each one is produced during the appropriate development stage.

For example, if FDA expects a threat model, your architecture team should create it while designing the system.

That approach makes a secure software development lifecycle for medical devices easier to manage and helps prevent costly surprises during regulatory review.

Where to go next

If you're still early in development, start with our FDA cybersecurity requirements overview. It explains the documentation and security activities you'll need to consider as your device moves toward submission.

For a closer look at cybersecurity risk assessment, see our guide to the 12 essential rules. You can also explore our book chapter on secure coding practices for practical guidance on implementing security during software development.

If your team already has an established development process, you don't necessarily need to replace it. You need to make sure cybersecurity activities and documentation are built into the workflow you're using.

Our services page explains how we help manufacturers integrate cybersecurity into their development programs. Software DHF setup addresses the broader software quality system that supports a secure SDLC medical device program.

And if you're further along in development and need help completing cybersecurity activities before submission, our 30-day CyberSprint offers a fixed-scope approach.

Need help wiring a secure SDLC into your software DHF? Email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• NIST. National Vulnerability Database. https://nvd.nist.gov/
• CISA. Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Microsoft Learn. Microsoft Threat Modeling Tool threats (STRIDE categories). https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
• ISO 14971:2019. Medical devices, Application of risk management to medical devices. https://www.iso.org/standard/72704.html
• OWASP Foundation. CycloneDX Bill of Materials Specification. https://cyclonedx.org/
• The Linux Foundation. SPDX, System Package Data Exchange. https://spdx.dev/