The FDA finalized its updated cybersecurity guidance in February 2026, completing the transition to the QMSR framework. For teams deep in regulatory operations, the change is largely procedural. But for teams earlier in the journey — building proof of concepts, designing first-generation connected devices, or scaling from prototype toward a commercial product — the underlying message is one teams need to be fully up to speed on. And if it isn’t already familiar territory, the time to catch up is now.
The guidance reinforces something we see consistently in connected device development:
The difference between programs that move through FDA review cleanly and those that encounter friction usually isn’t technical capability. It’s whether cybersecurity was treated as an architecture decision early on or as a documentation exercise closer to submission.
Those two approaches produce programs that look similar on paper and function very differently in practice.
What the Regulatory Framework Is Actually Asking For
The QMSR framework (now the permanent regulatory foundation for medical device quality systems) is built around continuous process, not point-in-time compliance. For cybersecurity specifically, that means the FDA isn’t just asking whether you have the required deliverables. It’s asking whether your security posture is the output of a defined, repeatable process embedded in your quality operations.
The distinction matters: an SBOM, a threat model, a vulnerability disclosure policy — these are deliverables. A Secure Product Development Framework (SPDF) is the process that produces and maintains them across the lifecycle of the product. QMSR expects the latter. For teams earlier in development, understanding that distinction before the build is significantly less expensive than reconciling it during or after.
The Decision That Gets Deferred and What It Costs
Early-stage connected device teams face real competing priorities. Getting the device to work, validating clinical utility, securing the next funding round, so security architecture often lands on a list of things to address before submission, not things to design from the start. That’s understandable. It’s also where the problem begins.
What we see happen is this, and often it starts a step further back than you might expect. On less experienced teams, engineering builds connectivity into the product and assumes security can be addressed later. It can’t, not cleanly. Retrofitting security into a system that wasn’t designed with the eventual security solution in mind creates significant technical debt, and it’s almost always more expensive than doing it right from the start.
On more experienced teams, the failure mode is subtler: the security work itself is often good (strong encryption, proper authentication, thoughtful key management, etc.), but the process governing those decisions is missing. When threat modeling happens, what triggers a security review, how vulnerabilities are tracked and resolved, how security decisions are documented and traced back. This lives in engineering knowledge rather than in a defined process inside a quality system.
The FDA can tell the difference. An SPDF-aligned program has a visible process logic that runs through its documentation. One that didn’t is harder to obscure than teams expect.
When a quality system eventually gets built, security sits adjacent to it rather than inside it. The two functions reference each other but weren’t designed together. The SBOM exists, but it’s maintained manually, separately from the QMS cadence. Threat models were done, but they’re dated documents rather than living artifacts tied to design milestones. Security decisions were made well, but the record of why, and by what process, is thin.
Retrofitting that integration later is time-consuming, disruptive, and often happens under the pressure of a submission timeline when there’s no good time to do it.
What Getting It Right Early Actually Looks Like
The implementation doesn’t need to be fully built out at the PoC stage. What does need to happen early is the architecture itself, designed intentionally, through an SPDF, so that the security process grows with the product and integrates naturally into the quality system as that system matures.
In practice, that means a few things. Threat modeling isn’t a one-time activity before submission — it’s tied to design milestones from early development, lightweight at first and more rigorous as the product matures. Security decisions are documented as they’re made, in a form that can be absorbed into the design history file without reconstruction. The SPDF is defined early, even simply, so there’s a process to build on rather than a practice to formalize retroactively.
If you’re earlier in your security thinking, BLE Security: Where to Begin, covers the foundational framework for how to approach connected device security design.
None of this requires a large team or a dedicated security function. It requires treating security architecture the same way you treat any other foundational system decision: as something that’s much easier to get right at the start than to retrofit once the product (and the organization) has grown around a different approach.
Why This Matters Now
QMSR being the permanent framework is what makes this the right moment to think about it. The regulatory environment is no longer in transition. Teams building connected devices today are building against a stable, process-oriented framework that will govern their submissions and their post-market obligations for the foreseeable future.
The question worth asking early isn’t whether your cybersecurity deliverables will satisfy a submission checklist. It’s whether the process producing those deliverables is designed to live inside your quality system and whether you’re building that architecture now or planning to build it later.
In our experience, later is always harder. And it’s almost always more expensive than it needed to be.
Ready To Go Deeper?
Understanding the distinction between documentation and process is the first step. The second is execution.
Henry Anfang breaks down exactly what that looks like in practice: the seven artifacts the FDA expects, how to produce them at each development phase, and how to integrate them into your workflow from day one.
