Blog

Picture a ten-person MedTech company building a connected glucose monitor. A hospital's procurement team asks for the SBOM, or FDA asks for the threat model behind the 510(k), and nobody has it ready. Not because the team is careless. Until FDA's 2023 Cybersecurity Guidance and MDCG 2019-16, nobody asked for these documents. Now every connected device needs them. Not because the team is careless. Until FDA's 2023 Cybersecurity Guidance and MDCG 2019-16, nobody asked for these documents. Now every connected device needs them. Nobody on the team has that ready. Not because they're careless. A ten-person team usually doesn't have a full-time security person, and this work was never on the plan until someone asked for it. Picture a ten-person MedTech company building a connected glucose monitor. A hospital's procurement team asks for the SBOM, or FDA asks for the threat model behind the 510(k), and nobody has it ready. Not because the team is careless. Until FDA's 2023 Cybersecurity Guidance and MDCG 2019-16, nobody asked for these documents. Now every connected device needs them.

A regulatory affairs professional posted something on Reddit last week that sums up a problem we see constantly. Her company built an entire department for regulatory intelligence, spanning medical devices, pharma, and consumer products across global markets, with a RIM system plus extra tools stacked on top. Her conclusion: the tools tell her something changed. They don't tell her what to do about it. She also tried AI for triage. "Incredibly unreliable," as she put it.

It used to be a normal plan: build the device first, add the cybersecurity documentation later. That plan doesn't work anymore. The gap between "later" and "too late" keeps getting shorter.

Buyers evaluating medical device software partners no longer start with a Google search. Increasingly, they open ChatGPT, Perplexity, or Claude and type something like: "Recommend a reliable company for developing AI powered medical device software under a 100k budget." That shift is quietly rewriting the rules of B2B discovery in health tech. Most vendors, including well established ones, have no idea how invisible they already are. We decided to find out where Thaumatec stood.

It started before anyone in healthcare asked for it. A patient gets their routine blood work back through an online portal. Their doctor hasn't responded yet. So they do what feels natural in 2026 — they paste the results into ChatGPT and ask what it means. They don't feel anxious waiting. They feel informed. This is happening millions of times a day. And as of January 2026, it's no longer just a workaround — it's a product.

Every digital health acquisition or Series B round eventually reaches the same moment: a technical reviewer opens the data room, starts asking questions, and the deal’s momentum quietly stalls. It rarely stalls because the product doesn’t work. It stalls because nobody can answer three questions with confidence — and in regulated software, “we’ll get back to you on that” is not an answer an investor or acquirer wants to hear. After reviewing technology stacks across dozens of SaMD and connected device companies, the same three questions surface almost every time. Here they are, along with why each one trips up otherwise strong companies.

The CE mark is on the wall. The FDA clearance came through. Your medical device software is live in hospitals, clinics, or in the hands of patients. Now what? For most MedTech and HealthTech companies, the answer to that question is dangerously unclear. Development teams move on to the next product. Regulatory affairs focuses on new markets. And the software running on real devices, in real clinical environments, is left to run itself. It won't.

When you are deep in development, the pressure is straightforward: get the product built, get it certified, get it live. Everything else feels secondary. The problem is that some of the decisions that seem secondary during development turn out to matter a lot once the device is running in real clinical environments. We have worked through enough of these situations with MedTech teams to know which ones come up again and again. Here is what we see most often, and how we help teams get ahead of it.

You launched. The CE mark is on the wall. Your medical device software is live in hospitals, clinics, or in the hands of patients. Now what? For most MedTech companies, the answer to that question is dangerously vague. Development teams move on to the next product. Regulatory affairs focuses on new markets. And the software running on real devices, in real clinical environments, is left to run itself. It won't.

There's a version of a connected medical device that works perfectly in a demo. Sensors read correctly. Data flows to the cloud. The app displays real-time vitals. Investors are impressed. Then comes the real world: a hospital network with strict security requirements, a regulatory submission that stalls for six months because the technical documentation doesn't cover cybersecurity risk management, a penetration test that finds critical vulnerabilities in the firmware. This is not an unusual story. It's the standard trajectory for healthtech companies that treat cybersecurity as something to sort out after the product works.