Ask a founder at a connected-device startup when they plan to deal with cybersecurity, and the honest answer is usually "after the hardware settles down." That answer made sense a few years ago. It makes a lot less sense now, and the companies that have figured that out are hiring security help far earlier than their peers do.
They are not doing it because they enjoy regulatory work. They are doing it because fixing a security problem at the architecture stage costs a fraction of what it costs at the filing stage.
The backdrop is a medical device industry that is getting larger, more connected, and harder to treat as a purely hardware business. The global medical devices market is estimated to be valued at USD 735.12 billion in 2026 and is expected to reach USD 1,203.81 billion by 2033, exhibiting a CAGR of 7.3% from 2026 to 2033. That growth is bringing more devices, more software, more connected infrastructure, and consequently more places where cybersecurity has to be considered before a product reaches the market.
For startups, that creates an interesting intersection. The same market expanding into connected diagnostics, monitoring, therapeutic equipment, and implantable technologies is also creating more regulatory and cybersecurity work. In the U.S. medical devices market, security is increasingly part of the product-development conversation rather than a technical task reserved for the final stretch.
What Changed in the Rules
Section 524B was written into the Federal Food, Drug, and Cosmetic Act in late 2022 and took effect on March 29, 2023. It covers what the statute calls a cyber device, meaning anything that runs software, can reach the internet, and has features that an attacker could plausibly go after. Reaching the internet through a paired phone or a gateway counts. A lot of founders assume their device sits outside that definition. Most are wrong.
Three obligations attach to every cyber device submission:
- A written plan for finding and fixing vulnerabilities after the device is on the market
- Proof that a Secure Product Development Framework was actually used, including the ability to patch the device in the field
- A machine-readable SBOM listing commercial, open-source, and off-the-shelf components
From October 1, 2023 onward, the FDA has been able to refuse a submission outright when this material is missing or thin. The agency's final premarket cybersecurity guidance, issued February 3, 2026, is what reviewers currently measure submissions against. It arrived one day after the Quality Management System Regulation took effect, which pulled ISO 13485:2016 into 21 CFR Part 820 and raised expectations about where cybersecurity work has to sit inside the quality system.
That second detail is the trap. Reviewers are not looking for a security report that arrives at the end. They want evidence that security was designed in, traced, and verified through a controlled process. Nobody can manufacture a design history file backwards.
And that matters across the device spectrum. A startup building a relatively straightforward connected product is dealing with a different risk profile from one developing a high-risk implant, but neither can afford to treat security as something that appears after the engineering work is complete. By device class, Class II (Moderate Risk) products including examples such as infusion pumps and surgical drapes are estimated to account for 56.3% of the medical devices market in 2026. The broader classification also includes Class III (High Risk) devices such as implantable pacemakers and heart valves, and Class I (Low Risk) devices such as bandages and thermometers. The spread illustrates why cybersecurity planning has to be connected to the actual product and its risk profile rather than copied from a generic checklist.
The Problems That Show Up Too Late to Fix
Bring a consultant in six weeks before filing, and the findings tend to be structural rather than cosmetic. A configuration mistake gets patched in an afternoon. The following do not.
- Architecture: Secure boot, where keys live, and whether signed firmware updates can be pushed over the air are all decided when the board is designed. If there is no secure element on the hardware, patchability is not something a sprint can add.
- Interfaces: Bluetooth pairing behavior, GATT permissions, an exposed UART header, the authentication model on the device-to-cloud API. These freeze early, and every one becomes something a reviewer expects to see tested.
- Dependencies: An SBOM reflects library choices made eighteen months earlier. Ripping an unmaintained open-source package out of a validated build triggers requalification, which triggers schedule.
- Traceability: Security requirements need to connect to risk controls, and risk controls to verification evidence, in line with ISO 14971 and AAMI TIR57. Assembling that chain after the fact takes longer than building it as they go.
The money side is easy to model. A cybersecurity deficiency letter, or a refuse-to-accept decision, usually costs a quarter or more. Teams that want the whole scope owned externally, from threat model through eSTAR-formatted documentation, typically start at https://bluegoatcyber.com/ and tie the engagement to design milestones instead of a filing date.
Why the Market is Moving in the Same Direction
The U.S. medical devices market is particularly important to this change. Connected diagnostics, monitoring technologies, therapeutic equipment, and other software-enabled products are entering a healthcare environment where FDA expectations intersect with hospital IT requirements. That creates a two-sided test for startups: can the device satisfy the regulator, and can the finished product satisfy the organization expected to deploy it?
Two very different buyers are now asking the same questions. Reviewers can reject a filing over an inadequate SBOM. Hospital IT and procurement teams, meanwhile, want SBOMs, a vulnerability disclosure policy, and penetration test evidence before anything joins their network. That scrutiny is especially relevant for diagnostic devices, which are estimated to account for 24.4% of the medical devices market in 2026. The segment spans in-vitro diagnostics (IVD), diagnostic imaging, and point-of-care testing, many of which increasingly depend on software, connected platforms, and digital data exchange. As the products become more connected, cybersecurity moves closer to the center of both regulatory review and hospital procurement.
The market also includes a long list of established companies spanning diagnostics, therapeutic technologies, implants, monitoring, and other medical device categories. Key players include Medtronic, Siemens Healthineers, Philips Healthcare, GE Healthcare, Johnson & Johnson, Stryker Corporation, Baxter International, Abbott Laboratories, Boston Scientific, Zimmer Biomet, Thermo Fisher Scientific, Cardinal Health, Edwards Lifesciences, Hologic, and Intuitive Surgical. For startups, these names provide useful context: the connected-device opportunity sits inside a mature and highly competitive healthcare technology ecosystem where compliance, reliability, and security increasingly travel together.
What Early Looks Like in Practice
Startups doing this well line the security work up against engineering milestones
|
Stage
|
Work done
|
What survives into the submission
|
|
Architecture
|
Threat modeling, security requirements
|
Requirements linked to risk controls
|
|
Prototype
|
SBOM generation, dependency analysis
|
SPDX or CycloneDX inventory
|
|
Design freeze
|
Firmware, wireless, mobile, cloud testing
|
Findings mapped back to the threat model
|
|
Verification
|
Requirement and mitigation verification, full pen test
|
Attestation letter, reviewer-ready report
|
|
Pre-submission
|
SPDF narrative, postmarket plan
|
eSTAR cybersecurity package
|
Worth flagging: the 2026 guidance names four separate testing activities. Verifying security requirements, verifying threat mitigations, vulnerability testing, and actual penetration testing. Teams that find this out late often have one of the four and assume it covered the rest.
Investors Started Asking
Diligence caught up to the regulation. Series A and B investors in connected health now probe whether the regulatory pathway carries security risk, since a refused submission says something about how the company is run, not only about the calendar. A startup that can produce a dated threat model, an SBOM it has kept current, and a postmarket vulnerability plan has answered that question before anyone raises it.
Wrap Up
Hiring security expertise early does not delete the submission work. It changes its character. They stop discovering problems and start documenting choices made on purpose.
For a company watching its runway, that is roughly the gap between clearing on the first attempt and spending two quarters writing explanations. Devices keep getting more connected, and the rules are not loosening. The teams treating security as an input to design rather than a box to tick at the end are the ones who ran the numbers first.
