On this page
Published: · Updated:
Key Takeaways
- The correct start point is concept phase, before design freeze, when [threat modeling](/services/medical-device-threat-modeling "medical device threat modeling") and security requirements become design inputs under ISO 13485:2016 Clause 7.3 under the QMSR.
- 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](/services/fda-cybersecurity-deficiency-response "FDA cybersecurity deficiency response").
- The February 3, 2026 FDA guidance encourages an SPDF and allows alternatives satisfying applicable requirements; [Section 524B](/guides/fda-cybersecurity-guidance "FDA premarket cybersecurity") separately establishes statutory duties for covered submissions.
- 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.
- Late cybersecurity changes can require architecture updates, repeat testing, and revised evidence; the cost depends on the device and change.
- If work starts late, first review the as-built architecture, existing evidence, and gaps, then agree a device-specific remediation scope and schedule.
Start cybersecurity at concept, not at submission. The threat model should exist before the architecture freezes, because it generates security requirements that become design inputs, and design inputs are cheap to add and expensive to retrofit. Teams that begin after verification usually discover an unsigned update path or an unauthenticated interface they cannot change without reopening design controls and repeating testing.
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. The effect on the schedule depends on the finding and response work.
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 ISO 13485:2016 Clause 7.3 under the QMSR.
Why this matters
The FDA's Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (final, February 3, 2026) encourages an SPDF while allowing other approaches that satisfy applicable requirements. Section 524B separately establishes duties for covered cyber-device submissions. 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 / ANSI/AAMI SW96:2023 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.
Security requirements, architecture, risk decisions, and test results should remain traceable within the manufacturer’s controlled records. The FDA guidance, Sections IV and V, supports these connections; it is not a dataset ranking deficiency causes.
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 ISO 13485:2016 Clause 7.3 under the QMSR and IEC 81001-5-1 require when read together.
Three early design decisions can materially affect the cybersecurity evidence and later remediation work:
- 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 | Assess missing evidence and remediation before committing to a submission date |
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, optional 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 recommends 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?
Late work can involve redesign, repeat security testing, updated risk decisions, and revised submission evidence. No validated engagement-cost dataset is presented here, so this article does not assign universal prices or delay estimates.
| Work affected | What to review |
|---|---|
| Architecture | Authentication, trust boundaries, update paths |
| Evidence | Threat model, risk assessment, SBOM, test scope |
| Schedule | Device readiness, access, remediation, retesting |
See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, CVSS Score for Medical Devices: How to Calculate and Use It, and Medical Device Software Development: A Compliance Guide.
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 approach is to review the current design and evidence, identify changes needed before submission, and document manufacturer-owned residual-risk decisions. Agree scope and schedule after reviewing the actual gaps, rather than promise a universal sprint duration.
The sequence:
- Architecture review: Threat model against as-built architecture. Identify assets, entry points, trust boundaries, adversary profiles.
- Risk assessment: Security risk assessment tied to AAMI TIR57 / ISO 14971 harm outcomes. This produces your security risk file.
- Architecture evidence: Four FDA architecture views produced against current design. Gaps become findings.
- Requirements and remediation: Security requirements traced to design inputs. Gap remediation plan for anything that cannot be documented as-is.
- Inventory and postmarket planning: 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
For the full scope of what we deliver, see our medical device cybersecurity services.
Blue Goat Cyber scopes the recovery work against the actual device, available evidence, and remediation needs. Our team includes CISSP- and OSCP-credentialed practitioners focused on medical device cybersecurity. The work can include threat modeling, security risk assessment, architecture evidence, an SBOM, and postmarket planning.
We also handle FDA premarket cybersecurity submissions end-to-end. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.
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 ISO 13485:2016 Clause 7.3 under the QMSR 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. Review the as-built architecture and existing evidence first. Remediation, testing, and document preparation depend on the gaps and device readiness. There is no universal six-to-eight-week recovery time or verified retrofit multiplier in this article.
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?
The schedule depends on system boundaries, existing documents, device access, software maturity, remediation, and retesting. Agree milestones after a gap review. Do not confuse an engagement start date with delivery of a submission-ready package.
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 review the gaps and agree the scope and delivery milestones. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.
- FDA guidance- U.S. FDA