
Published: June 10, 2026
Part of our FDA 2026 medical device cybersecurity submission series. For the full overview, start with FDA Cybersecurity Requirements for Medical Devices (2026).
Start medical device cybersecurity before you write the first line of MVP code, not after market fit. Three architectural decisions - authentication model, update mechanism, and data trust boundary - cost a few engineering days when made before MVP and 6-18 months of rework when made after. The FDA's February 3, 2026 final guidance treats these as design-control artifacts, which means retrofitting them after market fit triggers re-validation, a fresh threat model, a fresh pen test, and often a new 510(k) instead of a Letter-to-File.
Why founders defer cybersecurity (and why the math is wrong)
The conventional MedTech startup playbook says: prove the product works, prove people want it, then harden it for the FDA. That sequence is correct for clinical evidence and reimbursement strategy. It is catastrophically wrong for cybersecurity.
The reason is structural. Cybersecurity is not a feature you bolt on - it is a property of your architecture. Three of your earliest engineering decisions silently determine what your security risk file will look like at submission, what your pen test will find, and how many cybersecurity deficiencies you will receive in your first FDA AI letter. Those decisions are:
- How devices and users authenticate
- How the device receives updates
- Where the trust boundary sits between device, app, and cloud
Make those decisions casually during MVP and you will spend 6-18 months rebuilding them before you can submit. Make them deliberately on day one and you will spend a few extra engineering days.
The cost of waiting, by decision
Authentication model
Before MVP: Pick an authentication design that scales (per-device certificates issued at provisioning, short-lived tokens, mTLS to the backend). A senior engineer can implement the framework in 1-2 weeks. The threat model writes itself.
After market fit: You have a deployed fleet on a shared API key or a username/password the field-service team types into a tablet. Reviewers will reject this. You now have to design a new auth system, migrate every fielded device to it without bricking units in clinical use, rewrite your security risk file from scratch, and pay for a fresh pen test. Realistic timeline: 4-8 months. Realistic cost: $150K-$400K in engineering, $40K-$80K in pen test and consulting, plus the opportunity cost of delaying clearance.
Update mechanism
Before MVP: Build a signed-update path - code-signing keys, a verified bootloader, an A/B partition or rollback story, a way to revoke a compromised version. About 3-4 weeks of firmware work for an engineer who has done it once.
After market fit: Devices in the field cannot accept signed updates because the bootloader was never designed to verify them, or the device has no rollback partition, or the signing infrastructure was never set up. Section 524B of the FD&C Act requires you to have "a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures." Without a secure update path, you cannot patch. Without the ability to patch, the FDA may not clear the device at all. Retrofitting a secure update mechanism onto fielded hardware sometimes requires a hardware revision, which is the most expensive change in MedTech.
Trust boundary
Before MVP: Decide explicitly what the device trusts, what the companion app trusts, and what the cloud trusts. Document the data flows. This is the threat model whether you call it that or not.
After market fit: You discover during pen testing that the device implicitly trusts anything the app sends, the app implicitly trusts anything the cloud sends, and the cloud implicitly trusts the app. Closing those gaps means re-architecting the protocol between the three layers, which usually means re-validating clinical functions because the validated software changed.
The honest list: what you can defer
Not everything needs to happen on day one. The mistake is treating cybersecurity as monolithic. Here is what you can legitimately defer past MVP without paying the cost-of-delay tax:
- Full SBOM tooling and automation. You need an accurate SBOM at submission. You do not need a CI pipeline that generates SPDX and runs VEX correlation on every commit during MVP. Maintain a manual component list during MVP, automate before you submit. See our SBOM topic hub for what the FDA actually expects in the submission.
- Formal coordinated vulnerability disclosure program. You need a CVD policy and intake channel at launch. You do not need a fully staffed PSIRT during MVP. A documented inbox, a triage SLA, and a written policy meet the bar.
- Postmarket monitoring infrastructure. You need a postmarket cybersecurity plan in the submission. You do not need the production monitoring stack running during MVP. The plan describes what you will build by launch.
- Penetration testing beyond design review. Save the formal pen test for when the architecture is stable. Doing it on MVP code is throwing money at a moving target. But have a security architect review your design before you build the MVP - that is free and prevents the expensive findings.
The decision rule
Use this test on any engineering decision during MVP:
If we ship this and it becomes a problem, can we fix it with a software update without changing the threat model?
If yes, defer. If no, decide it now.
- Adding a new clinical feature later? Fixable. Defer.
- Adding a new authentication factor later? Fixable. Defer the factor; do not defer the framework.
- Changing the trust boundary later? Not fixable without re-architecting. Decide now.
- Adding an update mechanism later? Not fixable on fielded hardware. Decide now.
What the FDA actually looks for at submission
When you hit submission, reviewers under the February 3, 2026 final guidance expect the seven-section eSTAR cybersecurity package: security risk management, threat modeling, third-party software components (SBOM), security assessment of unresolved anomalies, security architecture views, security testing, and cybersecurity labeling. Every one of those sections is downstream of the three architectural decisions above.
Teams that built cybersecurity into the MVP produce that package in 4-8 weeks of documentation work. Teams that bolted it on after market fit produce it in 4-8 months of engineering work, then 4-8 weeks of documentation work, then often receive an Additional Information letter that adds another 6-12 weeks.
Practical next steps
If you are pre-MVP, the highest-ROI move is a pre-MVP security architecture review - typically a one-week engagement that locks in the three decisions above and writes the first draft of your threat model. It is the single cheapest cybersecurity work you will ever do, because it prevents the work you would otherwise do twice.
If you already shipped an MVP and are approaching market fit, the next move is a gap assessment against the 2026 guidance so you know exactly which of those three decisions you got right, which you got wrong, and what the cost-and-timeline of fixing each one looks like before you start the FDA pre-submission process.
The math does not change. Cybersecurity gets exponentially more expensive the later you address it. The only variable you control is when you start.
Related posts
- FDA Cybersecurity Guidance: What Device Makers Must Know - the full breakdown of the February 3, 2026 final guidance every founder reads next.
- Medical Device SBOM: FDA Requirements and Submission Guide - what the SBOM looks like in the submission once the architecture is locked in.
- FDA Deficiency Letter vs RTA vs Hold Letter - what happens when you skip the early work and reviewers come back with questions.