Regulation Isn’t Slowing MedTech. Legacy Thinking Is.
Table of Contents
As a former FDA regulator, I’ve reviewed submissions, asked uncomfortable questions, and watched companies struggle—not because the regulations were unclear, but because their own systems couldn’t keep up with the products they were trying to build.
My conclusion: the biggest factor holding MedTech back today isn’t the FDA. It’s the legacy tools, processes, and infrastructure the industry still stubbornly clings to.
This isn’t an isolated perspective. In a recent STAT News commentary, Erez Kaminski, our founder, made the same observation: the real bottleneck in MedTech isn’t regulatory burden; rather it’s the legacy systems and outdated workflows companies rely on to build increasingly complex and innovative software-driven products.
We’re running 2025 workflows on 1995 technology
Many MedTech organizations are managing critical development and compliance workflows with tools designed in the 1990s. These systems were never built for modern supply chains. They were never designed for continuous updates, third-party software components, or AI-driven functionality. Yet we keep forcing them to do exactly that.
Why? Inertia.
If you managed to “get through” an FDA approval once, the instinct is to leave well enough alone. Why mess with what appears to work? But here’s the catch: what works for one submission slowly becomes an anchor on everything that follows. The cost surfaces later in slow development cycles, brittle architectures, paralysis around change, and lack of innovation.
The third-party software problem we all ignored
For years, third-party software was treated as a regulatory liability -- not because it was inherently unsafe, but because companies couldn’t prove there was a quality system behind it. Even platforms as ubiquitous as Microsoft offered little visibility into their internal controls. So, the industry worked around this. Regulators quietly pretended not to notice and everyone moved on.
That era is over.
Modern medical devices are built on programmable components, configurable software platforms, and increasingly, machine learning models. EPROM chips alone should have forced a reckoning years ago. When you’re burning functionality into hardware, there’s no room for improvisation. You’re forced to model, verify, and validate it before you commit because once the functionality is in silicon, it can be hard to change.
I still see companies carrying forward binary code written decades ago—code they no longer fully understand, no longer have design documentation for, and are frankly afraid to touch. So, they copy it forward, release after release, submission after submission, hoping nothing breaks.
That’s not compliance. That’s risk accumulation.
The regulations haven’t changed. Your products have
The irony is that the regulations haven’t fundamentally changed. The FDA has been remarkably consistent: know your system, control your changes, show your work. What’s changed is the complexity of the products and the inadequacy of the infrastructure supporting them.
So, legal teams paper over the gaps. Quality teams scramble to assemble evidence after the fact. Engineers build workarounds for systems that slow them down at every turn. Everyone pays the price in delays, rework, and missed opportunities.
What’s next
The future of MedTech won’t be built on static documents, disconnected tools, and tribal knowledge. Rather, it will be built on systems that treat compliance as continuous, operational and verifiable discipline and not a filing exercise you scramble to complete at the end. The longer companies wait to modernize how they build and validate their products, the further behind they’ll fall. Not just with regulators, but with patients who are waiting for better technology to reach them.
I’ll say it again: regulation isn’t the enemy of innovation. Outdated infrastructure is. Modern MedTech isn’t just about smarter devices. It’s about smarter development. AI, simulation, and scalable computing now make it possible to model product behavior earlier, test more scenarios, and optimize performance before a device ever reaches a patient. That’s no longer cutting edge. It’s the new baseline.
The companies that build quality and compliance directly into their development systems will move faster, reduce risk, and deliver better evidence. And patients get what they’ve been waiting for: safer devices, better technology, and innovation that arrives on time.
Paul is a world-renowned software safety expert who joined Ketryx following 25 years at the Food and Drug Administration (FDA). He helped create the FDA’s approach to safety-critical software and medical devices and founded the FDA’s software engineering lab. While holding committee positions with groups that handled medical software safety standards like ISO 13485, ISO/IEC 62304, and ISO 14971, he reviewed over 300 devices, carried out numerous inspections, and provided training to FDA staff on software quality, risk management, and software engineering. Prior to the FDA, he worked 20 years as a systems/software engineer for companies like Ford Motor, Electronic Data Systems, Honeywell, and SAIC. He holds a Master of Science degree in Computer Engineering from Loyola University, Maryland.
