Published: July 7, 2026
Start medical device cybersecurity at concept, before the first architecture diagram is signed off, not after design freeze. The FDA's February 3, 2026 final premarket cybersecurity guidance treats security as a design-control activity under the Secure Product Development Framework (SPDF), which means threat modeling, security requirements, and architecture views must exist as design inputs, not retrofits. Teams that wait until verification or submission prep routinely lose 6-18 months to rework, resubmissions, and a fresh 510(k) instead of a Letter-to-File.
If your team is two years into product development and still says "we're not ready for cybersecurity yet," you are not early. You are late, and the cost has already been paid, you just haven't seen the invoice.
That invoice arrives in one of three ways: a Refuse to Accept (RTA) hold on your 510(k), an Additional Information (AI) letter listing cybersecurity deficiencies that force architectural changes, or a postmarket vulnerability that pulls the device off shelves. Each one resets your timeline by quarters, not weeks.
The good news: the fix is not "spend more." It is "sequence correctly." Cybersecurity done at the right phase of design controls is cheaper than the same work done later, because the artifacts you produce (threat model, security requirements, SBOM, architecture views) double as design inputs the FDA already requires under 21 CFR 820.30.
Key Takeaways
- The correct start point is concept phase, before design freeze, when threat modeling and security requirements become design inputs under 21 CFR 820.30.
- Teams two years into development without a threat model are not "not ready" — they have unresolved architectural risk that will surface in an FDA Additional Information letter.
- The February 3, 2026 FDA premarket cybersecurity guidance made SPDF a gating criterion for 510(k) and PMA acceptance under Section 524B, so backfilling security late means backfilling a design history file.
- Six specific activities have to happen before design freeze: threat model, security risk assessment, security architecture views, authentication and update mechanism decisions, SBOM baseline, and vulnerability handling plan.
- Retrofit cost for a connected Class II device runs 4–10x the cost of doing the same work at concept, plus deferred revenue from missed submission windows.
- If you are already late, the recovery play is a focused 6–8 week security architecture sprint that produces the FDA-required artifacts against your current design.
Table of Contents
- Why this matters
- When should you actually start medical device cybersecurity?
- What does "not ready for cybersecurity" actually mean?
- Which cybersecurity activities happen in which design phase?
- What does it cost to start late?
- You are two years in with nothing — what now?
- How Blue Goat approaches this
- FAQ
Why this matters
The FDA's Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (final, February 3, 2026) made the Secure Product Development Framework a gating criterion for premarket acceptance under Section 524B of the FD&C Act. Reviewers now expect cybersecurity artifacts to be traceable to design inputs, not appended as a submission-time attachment.
Two standards codify what "traceable" means. AAMI TIR57 defines security risk management as a parallel process to safety risk management under ISO 14971, executed across the design lifecycle. IEC 81001-5-1 (adopted by the FDA in 2024 as a recognized consensus standard) defines security activities per lifecycle phase, mapping cleanly onto IEC 62304's software lifecycle.
The practical effect: the FDA reviewer opens your Design History File and expects to see security requirements alongside functional requirements, a threat model referenced in your design inputs, and verification evidence (pen test, SBOM scans) traceable to those inputs. A submission that pastes cybersecurity in as a standalone section, with no design-control trail, is the pattern the FDA's FY2024 CDRH performance report flags as a top cybersecurity deficiency category in AI letters.
When should you actually start medical device cybersecurity?
Concept phase, before the first architecture review. That is the honest answer, and it is not a marketing answer — it is what 21 CFR 820.30 and IEC 81001-5-1 require when read together.
Three decisions get locked in during concept and early design that determine 80% of your cybersecurity submission risk:
- Authentication model. How does a user, service, or peer device prove identity? Changing this after design freeze means changing every interface.
- Update mechanism. How does the device receive verified software updates in the field? Bolt this on late and you get a postmarket vulnerability management plan the FDA will not accept.
- Trust boundary. What crosses the network, what stays local, what touches PHI? Move a trust boundary after V&V and you re-run the whole risk file.
These are not "cybersecurity features." They are architecture decisions the security team either informs early or discovers late. Discovery-late is the two-year-in scenario.
What does "not ready for cybersecurity" actually mean?
When a MedTech founder says "we're not ready for cybersecurity," they usually mean one of four things. Each has a different real answer.
| What they say | What it usually means | The real answer |
|---|---|---|
| "We don't have a threat model yet" | Nobody has looked at attack surface | You are ready — this IS the starting activity |
| "The device isn't final" | Architecture is still moving | You are the most ready — freeze security decisions with the architecture |
| "We can't afford a pen test" | Budget is thin | Pen testing is the last step, not the first — don't do it yet |
| "We'll do it before submission" | Deferring to Q4 | You will miss submission window; SPDF artifacts take 3–6 months to produce cleanly |
The pattern: teams conflate "cybersecurity" with the single most expensive activity (penetration testing) and defer the whole discipline. Threat modeling and security requirements — the activities that actually need to happen early — cost engineering time, not tooling budget.
Which cybersecurity activities happen in which design phase?
Mapped to IEC 62304 software lifecycle phases, extended with IEC 81001-5-1 security activities:
| Phase | Cybersecurity activities | Deferable? |
|---|---|---|
| Concept / planning | Security posture, applicable regulations, framework choice (SPDF, JSP2, 81001-5-1) | No |
| Requirements | Threat model v1, security requirements, security risk assessment | No |
| Architecture / design | Architecture views (global, multi-patient harm, updateability, security use case), auth + update + trust decisions, SBOM baseline | No |
| Implementation | Secure coding standards, SAST, dependency scanning, SBOM maintenance | Partial |
| Integration & verification | Security testing, fuzz testing, threat model v2, vulnerability scanning | No |
| Release | Penetration test, final SBOM, VEX, labeling, CVD process | Yes — this is the correct time |
| Postmarket | Vulnerability monitoring, patch cadence, incident response, SBOM refresh | Ongoing |
The February 3, 2026 FDA guidance requires four architecture views in the premarket submission: global system view, multi-patient harm view, updateability view, and security use case view. All four are architecture-phase artifacts. If your architecture is done and these views do not exist, they cannot be produced accurately — they will be reverse-engineered, and reviewers can tell.
What does it cost to start late?
For a connected Class II device, order-of-magnitude estimates from Blue Goat engagements:
See also: Medcrypt vs Finite State vs Blue Goat Cyber, CVSS 3.1 vs 4.0 for Medical Devices, and Hire Cybersecurity Consultant vs. In-House.
| Timing | Full SPDF artifact set cost | Timeline impact |
|---|---|---|
| Concept phase | $30–60K, absorbed into design work | Zero — runs in parallel |
| Post design freeze | $80–150K | 2–4 months added |
| Pre-submission scramble | $150–300K | 4–8 months added (miss submission window) |
| Post-AI letter response | $200–500K + resubmission | 6–18 months added |
| Postmarket vulnerability recall | $500K–$5M + revenue loss | Unbounded |
The retrofit multiplier is not because security work is inherently more expensive later. It is because late security work triggers cascading rework: architecture change → re-verification → re-validation → new threat model → new pen test → updated submission.
You are two years in with nothing — what now?
The recovery play is not "start over." It is a focused 6–8 week security architecture sprint that produces the FDA-required artifacts against your current design, identifies which existing decisions have to change, and separates "fix before submission" from "document as accepted residual risk."
The sequence:
- Week 1–2: Threat model against as-built architecture. Identify assets, entry points, trust boundaries, adversary profiles.
- Week 2–4: Security risk assessment tied to AAMI TIR57 / ISO 14971 harm outcomes. This produces your security risk file.
- Week 3–5: Four FDA architecture views produced against current design. Gaps become findings.
- Week 5–7: Security requirements traced to design inputs. Gap remediation plan for anything that cannot be documented as-is.
- Week 6–8: SBOM baseline, VEX, CVD policy, postmarket monitoring plan.
Penetration testing comes after — once the artifacts are in place, the pen test is the verification activity, not the discovery activity.
How Blue Goat approaches this
Blue Goat Cyber runs this exact 6–8 week sprint for MedTech teams who realize late that cybersecurity has to be a design-control artifact, not a submission attachment. Our team — CISSP-, OSCP-, and ex-military-red-team-credentialed engineers who work only on medical device cybersecurity — produces the threat model, security risk file, four architecture views, SBOM baseline, and postmarket plan the FDA expects under the February 3, 2026 guidance.
We also handle FDA premarket cybersecurity submissions end-to-end. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.
Related reading: Cybersecurity Before MVP vs After Market Fit covers the pre-MVP decisions, and FDA Pen Test Timing for Submission covers when penetration testing actually belongs in the sequence.
FAQ
When should medical device cybersecurity start in product development?
It should start at concept phase, before the first architecture review is signed off. Threat modeling, security requirements, and framework selection are design inputs under 21 CFR 820.30 and IEC 81001-5-1. Waiting until verification or submission prep means backfilling design-control artifacts, which is what the FDA flags most often in Additional Information letters.
Is it ever too late to start medical device cybersecurity?
No — but the recovery cost grows quickly. A team two years into development can still produce a compliant Secure Product Development Framework artifact set in 6–8 weeks against the as-built design. What is not recoverable is the low cost of doing it at concept: retrofit engagements run 4–10x the concept-phase cost.
Can we just do a penetration test and call it cybersecurity?
No. Penetration testing is a verification activity that comes near release. Without a threat model, security requirements, and architecture views in place first, a pen test has nothing to verify against, and the FDA does not accept a pen test report as a substitute for SPDF artifacts under the February 3, 2026 guidance.
What if our device is "not final" yet?
That is the ideal state to start cybersecurity, not a reason to defer. Security decisions made while architecture is still moving are cheap; security decisions imposed after freeze are expensive. The three decisions to lock down early are authentication model, update mechanism, and trust boundary.
Does Section 524B apply if we haven't submitted yet?
Yes. Section 524B of the FD&C Act applies to any device that meets the definition of a "cyber device" at the time of submission. If your device includes software, has the ability to connect to the internet, and could be vulnerable to cybersecurity threats, 524B applies to your 510(k), De Novo, or PMA — regardless of when you started thinking about it.
How long does it take to produce the FDA-required cybersecurity artifacts?
Cleanly, from a standing start, 3–6 months for a Class II connected device when done in parallel with normal design work. Compressed under submission pressure, 6–8 weeks with a focused sprint. Both are cheaper and faster than an Additional Information letter response, which adds 6–18 months.
Ready to stop deferring?
If your team is deep into product development without a threat model, security risk file, or architecture views, you are one FDA letter away from a resubmission. Book a medical device cybersecurity consultation and we will scope a 6–8 week sprint that produces the SPDF artifact set your submission needs. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.
About the author
Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance, and has run the concept-phase-to-submission sequence for dozens of Class II and Class III connected devices. Read more about Christian.