Cybersecurity Before MVP vs After Market

Part of our FDA 2026 medical device cybersecurity submission series. For the full overview, start with FDA Cybersecurity Requirements for Medical Devices (2026).

Why This Matters

Section 524B became effective March 29, 2023 and applies to qualifying cyber-device 510(k), PMA, PDP, De Novo, and HDE submissions. The February 3, 2026 final guidance explains the FDA's recommendations. eSTAR submissions undergo technical screening, not the traditional RTA checklist, before substantive review. Missing cybersecurity content can delay review.

Late security findings can require redesign and repeat testing. Assess engineering work and submission impact for the actual device; this article does not establish typical revenue losses or a cost multiplier.

The standards stack reviewers expect here is consistent regardless of timing: AAMI SW96 (FDA Recognized Consensus Standard 13-131) for security risk management, IEC 81001-5-1 for the secure software lifecycle, IEC 62304 for software classification, and ISO 14971 for the risk file. Building the architecture to satisfy all four early is materially cheaper than satisfying any one of them late.

Already deep into product development? This post covers the pre-MVP versus post-market-fit decision. If you're two years in and still saying "we're not ready for cybersecurity yet," read When to Start Medical Device Cybersecurity in Product Development, it maps every SPDF activity to its correct design-control phase and outlines a gap-review and recovery sequence for teams that started late.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA Cybersecurity resources for medical devices; FDA Cybersecurity in Medical Devices FAQs (Section 524B).

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:

1. How devices and users authenticate
2. How the device receives updates
3. Where the trust boundary sits between device, app, and cloud

Poor early decisions can require substantial redesign before submission. Plan and estimate the work for the actual architecture rather than assuming a fixed schedule.

The cost of waiting, by decision

Authentication model

Before MVP: Assess authentication and authorization for devices, users, applications, and services. Choose supported mechanisms and key-management processes, with measurable security requirements.

After market fit: A shared credential may require identity, authorization, revocation, and deployed-device migration changes. Assess safe rollout, repeat testing, and updated risk documentation before estimating cost or duration.

Update mechanism

Before MVP: Design authenticated updates, protected verification keys, and recovery appropriate to the device and safety constraints. Implementation time depends on the platform and existing update design.

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.

Baking cybersecurity in before MVP?

Blue Goat Cyber is a medical-device-only cybersecurity firm. Our team runs the threat modeling, penetration testing, and FDA-facing documentation MedTech submissions live or die on. → Secure MedTech product design consulting

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, triage targets, and a written policy are useful starting points; adequacy depends on the device and process.
• 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. Early targeted penetration testing can still be useful for high-risk design assumptions; final submission evidence should represent the submitted configuration. But have a security architect review your design before you build the MVP - that can identify expensive design risks early.

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, consider deferral only after assessing safety, regulatory obligations, and development risk. If no, address the architecture 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 a cybersecurity documentation 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.

Early security work can reduce redesign and make documentation easier to assemble. Documentation, remediation, and review timelines depend on device complexity and evidence quality; there is no universal early-versus-late schedule.

Practical next steps

For a stage-by-stage plan, use the startup roadmap for medical device cybersecurity alongside these architecture decisions, from early development through submission and postmarket support.

If you are pre-MVP, consider a security architecture review covering authentication, updates, and trust boundaries, with an initial threat model. Agree duration and deliverables after reviewing the architecture.

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 can become more expensive when late findings require architectural changes. The only variable you control is when you start.

Should Cybersecurity Show Up in Your Go-to-Market Messaging?

Cybersecurity belongs in your go-to-market plan for the same reason the architectural decisions in this article belong pre-MVP: the FDA already requires the documentation for clearance, so the only real choice is whether you also use it commercially. Hospitals and patients evaluating a connected device are increasingly wary of the same risks this guide covers, and a manufacturer that can describe its security posture clearly, rather than treating it as a hidden compliance cost, has an answer ready when a procurement team asks.

Four elements translate directly from your premarket work into market-facing trust signals:

1. A coordinated vulnerability disclosure program. The same CVD intake channel required for a 524B(b)(1) postmarket plan is also what a hospital security team wants to see before purchase.
2. Transparent patch and update communication. The regular and out-of-cycle update cadence you documented for the FDA is the same information that reassures a buyer the device will stay supported.
3. Documented access controls. Authentication and authorization protocols that satisfy a reviewer's threat model also answer a hospital's own security questionnaire.
4. A visible SBOM commitment. Being able to say the device's software inventory is monitored and current, not just filed once at submission, differentiates the device from one where that question gets no clear answer.

None of this requires inventing new work. It requires packaging the architectural and documentation decisions already made before MVP, the ones this article treats as design cost rather than redesign cost, into language a buyer can evaluate. A go-to-market plan that stays silent on security leaves that question to be raised, and possibly mishandled, during a procurement review instead of addressed on the manufacturer's own terms. Manufacturers who get the pre-MVP architecture right have the easier version of this problem: the evidence already exists, and go-to-market only has to communicate it.

How Blue Goat approaches cybersecurity for early-stage medtech

Blue Goat Cyber works with pre-revenue and post-PMF medtech teams the same way: we right-size the work to where the device actually is. For a pre-MVP team, that means a lightweight threat model, an architecture review, and a written deferral log so reviewers can see what was conscious versus accidental. For a post-PMF team racing to submission, it means a full Section 524B package against the FDA's Cybersecurity in Medical Devices final guidance dated February 3, 2026: SBOM with optional VEX analysis, complete threat model, risk-tiered penetration test, and the postmarket Cybersecurity Management Plan. Our team holds CISSP and OSCP credentials and includes ex-military red team operators. See the medical device cybersecurity services overview. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

Related reading: What Investors Ask Medical Device Founders About Cybersecurity.

Frequently Asked Questions

Related posts

• When to Start Medical Device Cybersecurity in Product Development - the full lifecycle timing map for teams asking "when do we actually start?", including the recovery sprint if you're already late.
• FDA cybersecurity guidance - 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.