As someone who’s worked in the development and certification of embedded medical software, I can tell you this: achieving compliance with FDA regulations and IEC 62304 isn’t just a regulatory exercise—it’s a journey. And like any journey, it’s full of challenges, unexpected turns, and some hard-won insights.
If you’re a CEO, CTO, or in a leadership role at a medical device company, this article is for you. You don’t need to be an engineer to understand the stakes. What you do need is a clear sense of what certification involves, where the risks lie, and how to prepare your teams (and budgets) for success.
What’s at Stake?
Embedded medical software isn’t just software. It’s the invisible engine inside pacemakers, insulin pumps, infusion devices, imaging systems—you name it. And because people’s lives depend on these systems, regulatory bodies treat them with the gravity they deserve.
In the U.S., the FDA regulates these devices under the Federal Food, Drug, and Cosmetic Act. In parallel, the international standard IEC 62304 lays out a lifecycle framework for medical device software. Together, they represent a powerful one-two punch: you need to meet both to access global markets and maintain credibility with customers, investors, and partners.
The First Big Challenge: Understanding the Landscape
When we started the certification process, one of the first hurdles was simply understanding the language. The FDA speaks in guidance documents and CFR references. IEC 62304 speaks in software lifecycle processes, risk classes, and V&V. You quickly realize that everyone—from engineers to executives—needs a working knowledge of both worlds.
Tip: Invest early in cross-functional education. A day of training can save you weeks of back-and-forth later on.
Process Pain: Getting Agile Teams to Fit Waterfall Documentation
Many companies now use Agile or hybrid development models. But IEC 62304—and to some extent, the FDA—expects documentation that looks more like traditional Waterfall: defined stages, signed-off requirements, formal verification steps.
This disconnect was one of our biggest struggles. Our dev team was moving fast, iterating weekly. Meanwhile, our compliance consultants were asking for traceability matrices and formal test coverage.
We didn’t want to kill innovation—but we had to put structure in place. The solution was not to abandon Agile but to layer documentation and traceability tools on top of our process.
Tip: Use tools that integrate with your development environment to automatically generate the audit trail regulators expect.
Classification Confusion
IEC 62304 requires you to classify your software system into Class A, B, or C—based on the risk associated with potential software failure. FDA doesn’t use the same system, which can cause confusion.
Many teams underestimate their risk class. For instance, if your software has even a small role in life-support functions, you’re likely looking at Class C—the most demanding level.
What we learned is: be conservative in your classification. The overhead is higher, but the risk of underclassifying is greater: failed audits, delayed approvals, and even liability if something goes wrong in the field.
Documentation Overload
You will hear a lot about “design history files” (DHFs), “software requirements specifications” (SRS), “verification and validation” (V&V) plans, and much more. IEC 62304 is very specific about what needs to be documented across the lifecycle.
The reality? Most teams aren’t ready for this level of formality. And you can’t generate it retroactively—at least not without pain.
We had to retrofit documentation for code that was already running in test devices. It wasn’t fun, and it slowed us down.
Tip: Bake documentation into your development culture early. Treat it as part of the deliverable, not an afterthought.
Third-Party Software and Open Source: A Hidden Minefield
Another common oversight is the use of third-party libraries and open-source components. Many embedded systems depend on them. But under both FDA and IEC 62304, you’re responsible for verifying the safety and performance of every component, including external code.
We had a case where an open-source TCP/IP stack caused unexpected behavior during power failure recovery. Because we hadn’t validated it properly, it triggered a significant delay during our 510(k) submission.
Tip: Maintain a clear inventory of all software components, including open-source. Document how each one is tested, and be ready to justify their inclusion in your system.
Cybersecurity: The Evolving Target
The FDA has become increasingly focused on cybersecurity, and rightfully so. IEC 62304 doesn’t cover cybersecurity deeply, but it intersects with newer standards like IEC 81001-5-1 and guidance from NIST.
The challenge is that cybersecurity isn’t static—it evolves constantly. The software you wrote last year might pass today’s tests but fail tomorrow’s.
Tip: Establish a secure software development lifecycle (secure SDLC) early on. Think of it as an investment, not a cost. It’s better to spend on prevention than to face a post-market recall or reputational damage.
Testing and Verification: It’s Not Just Unit Tests
Many developers assume that if their code passes unit tests, they’re good to go. Unfortunately, that’s not enough.
Both the FDA and IEC 62304 require system-level testing, requirements traceability, and independent verification for certain classes of software. This goes far beyond the usual CI pipeline.
Clear and compliant regulatory writing is essential for navigating FDA and IEC 62304 documentation requirements.
We had to bring in an independent test team to verify critical functions, which added cost and time—but ultimately gave us stronger confidence in the system.
Resource Planning: The Hidden Costs
Certification isn’t just a technical project—it’s a resource-heavy, time-consuming endeavor. Companies often underestimate the budget required for compliance: regulatory consultants, documentation specialists, tool licenses, training, and even dedicated QA personnel.
We made the mistake of trying to “fit certification into” existing team workloads. It didn’t work. We had to step back and allocate dedicated resources to get through the process.
Tip: Treat certification as a product in itself, with its own team, timeline, and budget.
Post-Market Surveillance: The Job Isn’t Done at Approval
Even after FDA clearance or CE marking, your responsibilities continue. You need a robust post-market surveillance plan, including procedures for handling software updates, user complaints, and potential recalls.
IEC 62304 requires you to monitor field performance and feed lessons back into your lifecycle process. This means ongoing investment in tools and processes—even years after initial release.
Final Thoughts
Certification is hard. But it’s also a huge competitive advantage. Companies that get this right are better prepared for audits, quicker to respond to issues, and more trusted by regulators and customers alike.
If you’re leading a team building medical device software, I won’t sugarcoat it—this is a marathon, not a sprint. But with the right mindset, tools, and preparation, you can get there.
And when your device goes to market knowing it meets the highest safety standards? That’s a reward that’s worth every step.
