Shifting medtech compliance left: Lessons from the cybersecurity industry

Not too long ago, software security looked a lot like medtech compliance does today. Security was done at the end of the development process. Not by design, but by default. The product was built, then handed off to the security team for review. By the time issues surfaced, features were fully built. Engineers would have to go back in, and timelines slipped. Everyone in the industry knew this pattern was broken, but nobody had the fix.

The acceleration of software development and the security gap it created

In the early 2010s, a few things converged. Amazon, Google, and Facebook were competing for users in real time, and the companies that could ship a feature, measure how it performed, and iterate fastest were pulling ahead. Amazon had spent years and enormous capital building the infrastructure to operate at that pace, and in 2006 turned it into a product anyone could rent. AWS made Amazon's advantage, speed to market, accessible to companies that couldn't afford to build it themselves.

Companies like Flickr, Etsy, and Netflix jumped on what that unlocked as soon as it became available. Etsy went from deploying code twice a week to over fifty times a day. The movement that emerged came to be called DevOps, built around the idea that development and operations shouldn't be two separate worlds, and that the wall between them was a bottleneck to be dismantled. Security, however, wasn't part of this change.

Security was still a separate team, sitting at the end of the pipeline, expecting weeks of runway that development was no longer providing. Vulnerabilities were making it into production faster than they could be caught. The end-of-cycle security model had been designed for an earlier era's pace.

How software solved the speed-security problem

The answer the industry landed on was Shift Left: moving security checks earlier in the development process, into the design phase, the sprint, and the tools engineers were already using. A practice called DevSecOps (development, security, and operations unified into a single continuous workflow) was built around making that integration operational. Security stopped being a final gate and became a continuous thread.

Medtech compliance is at a similar inflection point now, the pressure coming from AI-enabled devices, SaMD, design and manufacturing capabilities that are advancing faster than ever, and a pace of development that medtech's compliance infrastructure wasn't built to track. A device's algorithm can update every few weeks; the compliance processes built around it were designed for products that changed once every few years. The prescription for medtech is the same one software security landed on: move compliance earlier, into the decisions being made during development, not the documentation sprint that follows them.

Medtech's version of the security silo

An FDA study of medical device recalls published back in 1990 found that 44% of them could have been prevented through better design controls: catching problems earlier during the design phase, before a single unit was ever manufactured. The most frequent causes were design failures, software issues, and non-conforming materials.

At the time, the FDA's solution was the Quality System Regulation (QSR), enacted in 1997 and with it, the birth of the Design History File. Before it, FDA regulation only covered manufacturing quality: how devices were produced, tested, and distributed. The design and development phase — where the decisions most likely to cause harm were being made — sat outside that framework entirely. The QSR extended regulation upstream for the first time, requiring manufacturers to document design and development decisions as they were made.

But in practice, the compliance record continued to be assembled largely at the end of development. The infrastructure to continuously execute on that intent didn't yet exist, until now.

Where eQMS platforms fall short

Electronic quality management systems — eQMS platforms — digitized the compliance record into centralized, version-controlled documentation. But an eQMS is still a separate system that quality teams populate manually. Development happens in one set of systems. The compliance record lives in another. A human still has to bridge that gap, pulling information from development tools, translating it into compliance language, and entering it into the QMS. The gap between where development happens and where the record lives remained open.

What cloud did for software deployment, eQMS leaves undone for compliance generation. AWS removed the infrastructure barrier that had prevented teams from deploying at speed by making the underlying capability automatic, not just better organized. eQMS organizes the record, but can't read a pull request, a risk log, or an architecture diagram and derive from it what a regulator needs to see. AI systems run continuously across every system where development happens, consuming information and acting as a control tower to translate it into compliance-ready artifacts. They take on the initial creation work that quality teams have always had to do themselves, refocusing human review and judgment on finalization, not assembly.

That's what's finally making shift-left compliance operational in practice, not just principle.

The current breakdown of the end-of-cycle compliance model

Software was already straining the model of leaving record assembly to the end. AI — being used both inside devices and to physically make them — is breaking it.

The QSR's design controls logic rested on an assumption that held for hardware: catch problems during design, before manufacturing begins, and you've caught them before they can cause harm. AI devices don't work that way. The FDA's list of cleared AI-enabled medical devices has more than doubled since 2022, now approaching 1,500. And the failure modes that matter most for these devices often don't exist at design. They emerge from the interaction between the algorithm, the real-world data it encounters in clinical use, and the environment it operates in. A single update, when it does go wrong, can ripple across the entire system in ways hardware changes simply don't.

The recall data tells the same story. A study from researchers at Johns Hopkins, Yale, and Georgetown found that design and development-related factors account for 50% of recalls for FDA-cleared AI-enabled devices. AI failures emerge later, in deployment. Even with a clean DHF, they arrive after the record has closed.

AI is the starkest example, but not the only one. Any device with a software update cycle faces a version of this same problem.

QMSR, effective February 2026, replaced predictable inspection checklists with scrutiny of how a quality system operates day to day. Manufacturers participating in the FDA's Voluntary Improvement Program with already continuous, live quality systems are seeing submission review and approval times drop 75 to 90%. The future of regulation is continuous real-time risk management rather than point-in-time reviews.

Finally shifting compliance left

For the first time, the infrastructure exists to execute on what the QSR always required — a compliance record built continuously alongside the product, not reconstructed after the fact. That's exactly what the QMSR rewards: quality systems that reflect how a company actually operates, not just how it performs at inspection time.

The FDA identified quality's underlying timing problem in 1990 and wrote the fix into law in 1997. For the decades since, assembling compliance records after the fact was difficult, but done. With AI, software-enabled devices, rapidly advancing manufacturing, and continuous deployment, that's no longer the case. Infera exists to close that gap.