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

I've watched a lot of medical-device teams treat "secure SDLC" as a documentation exercise. They build their software the same way they always have, then near the end of verification someone says, "we need cybersecurity docs," and a regulatory consultant gets asked to generate them. The submission goes out. Six weeks later, the Additional Information request lands. Now the team is in rework while the launch slips.

Secure SDLC is a development practice, not a deliverable. If security shows up only at the documentation stage, it's already too late to do it well. This post is the version I wish more teams had read before they started coding.

What "secure SDLC" actually means for a medical device

The textbook definition — security integrated at every stage — is correct but unhelpful. What it means in practice for a medical device team is:

• Threat modeling happens before architecture is locked. Not after.
• Security requirements are written alongside functional requirements. Not appended later.
• Code reviews check for security defects, not just functional bugs. Same review, same reviewers, expanded checklist.
• Verification covers controls, not just features. If a control exists, there is a test case that exercises it.
• The SBOM is generated by the build, not assembled by hand in week 47.
• Patching, monitoring, and incident response have an owner before launch. Not after.

Every one of those bullets maps to an artifact a reviewer will ask for. Building them through the normal development workflow costs almost nothing extra. Reverse-engineering them post-hoc costs months.

SDLC stage → security activity → FDA artifact

Here is the mapping I use when I'm walking a team through gap analysis. It's the operational view of what FDA expects in the cybersecurity package, reshuffled so each artifact lines up with the dev stage that produces it.

Dev stage	Security activity	Output / FDA artifact
Planning	Define scope, regulatory pathway, threat actors of interest, cybersecurity acceptance criteria	Section in Cybersecurity Management Plan
Requirements	Derive security requirements from threat actors + intended use	Security requirements in SRS; risks captured in threat model
Architecture	Identify trust boundaries, data flows, attack surfaces; complete threat model	Security Architecture Views; Threat Model
Architecture	Score threats, select controls	Cybersecurity Risk Assessment; Cybersecurity Controls
Architecture	Document how cyber risks with safety impact flow into ISO 14971	Safety & Security Assessment of Vulnerabilities
Implementation	Apply secure coding standards; track controls in code	Code reviewed against checklist; controls traceability
Implementation	Generate SBOM as a build output	Software Bill of Materials
Implementation	Continuously scan dependencies against NVD and CISA KEV	SBOM analysis, anomalies log
Verification	Run unit and integration tests for controls	Test cases tied to control IDs
Verification	Run independent security testing (penetration + fuzz)	Cybersecurity Testing Report
Verification	Analyze unresolved anomalies for cyber relevance	Assessment of Unresolved Anomalies
Pre-release	Roll everything into the submission summary	Security Risk Management Report; Cybersecurity Metrics
Post-market	Monitor SBOM, patch, respond, update	Cybersecurity Management Plan execution

If you can build a project plan that produces every row on the right side of that table as a natural output of work happening in the middle column, you don't need a separate "cybersecurity documentation phase." The documentation is just the residue of the work.

What goes wrong in practice

I've seen the same failures repeat across teams of different sizes:

Threat modeling done after the architecture freezes. The threat model identifies a trust boundary that should have been somewhere else, but moving it now would cost two sprints. The team accepts the risk instead. The reviewer notices.

Security requirements that aren't testable. "The system shall be secure" is not a requirement. "The system shall require multi-factor authentication for any administrative function" is. If you can't write a test case for it, it doesn't belong in the SRS.

SBOM assembled by hand at the end. Someone grep's package.json, copies what they find into a spreadsheet, calls it the SBOM. Half the transitive dependencies are missing. The reviewer asks for a CycloneDX or SPDX file generated by tooling, and the team has to redo it under deadline pressure.

Controls in the design doc but not in the code. The risk assessment says signed firmware is implemented. The build produces an unsigned image because nobody wired the signing step into CI. This shows up in penetration testing if you're lucky, in the field if you're not.

Penetration test scoped too narrowly. The team scopes pen testing against the device firmware only and skips the cloud back-end the device talks to. The reviewer notices that the cloud component has unique attack surface and asks for a separate test.

Post-market is a paragraph instead of a plan. The Cybersecurity Management Plan says "we will patch in a timely manner" with no defined cadence, no owner, no escalation path. Reviewers grade this.

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

If you've already started development and you're reading this thinking you're behind, you probably are — but the work to catch up is mechanical. In order:

1. Take inventory. What components, what languages, what interfaces, what data flows, what trust boundaries. Write it down as it is, not as you wish it were.
2. Generate a real SBOM from the build. Use the tooling appropriate to your stack — syft, cyclonedx-cli, dotnet-CycloneDX, whatever fits. Get a CycloneDX or SPDX file from CI, not a spreadsheet.
3. Run a threat model against the inventory. STRIDE or PASTA or whatever framework your team will actually use. The framework matters less than producing a list of threats with IDs that the risk assessment can reference.
4. Map existing controls to threats. You probably already have authentication, encryption, input validation, and logging. Document what's there and which threats each piece addresses. Gaps become the remediation backlog.
5. Decide who owns post-market cybersecurity before submission. A name on the Cybersecurity Management Plan, not a function.

Doing all five in one sprint is realistic for a team that has working software. Skipping any of them is a guarantee of pain at submission.

At CyberMed we've seen

The teams that ship cleanly on the first submission share one thing: they treated the security work as engineering work, not regulatory work. The artifacts the FDA wants are the byproducts of decisions the engineering team had to make anyway. The teams that struggle treat the artifacts as a separate documentation deliverable and end up reverse-engineering decisions that were never deliberate.

The shortcut, if there is one, is to start with the artifacts list and work backward. If the threat model is what reviewers want to see, then the threat model is what the architecture team produces during architecture. Not at the end. Not by a different team.

[NEEDS: anonymized launch-timeline example from Andres — a team that did or didn't get this right]

Where to go next

If you're early in development, the FDA cybersecurity requirements overview covers the full artifact set. For the risk-assessment piece specifically, the 12 essential rules.

If you need help wiring this into an existing program, our services page lists the engagement models we use, and Software DHF setup covers the broader software quality system that secure SDLC fits inside. If you're past the planning stage and just need the cybersecurity work done, the 30-day CyberSprint is the fixed-scope path.