Scaling embedded medical devices safely: A guide to IEC 62304 & ISO 13485

In one of our latest articles on integrating AI/ML into regulated medical devices, we broke down how machine learning is changing the game in medtech. To be taken seriously in regulated markets, your software needs structure. That means solid processes, clear documentation, and systems that hold up when your product leaves the lab and enters the real world.

This time, we’re looking at embedded medical device software. So, let’s be direct right away: clean code isn’t the whole story (especially when patient safety is on the line!). A single bug or a missing risk control can quickly turn into something serious.

That’s why IEC 62304 and ISO 13485 for embedded systems matter so much. One defines how you build medical software, while the other sets the rules for the quality system around it. Together, they give you the framework to stay compliant, stay safe, and stay audit-ready.

A quick look at what we’ll explore:

• Why IEC 62304 and ISO 13485 matter for embedded medical device software
• What tends to go wrong when there’s no formal development process
• How risk management influences design, testing, and documentation
• What working compliance looks like
• First-hand lessons from embedded projects we’ve helped bring to life

What happens when embedded software in a medical device goes wrong?
Sometimes, nothing serious. Other times, it means a missed heartbeat or the wrong dose of medication. That’s why embedded medical device software standards like IEC 62304 matter.

IEC 62304 is the go-to standard for building medical device software in a way that prioritizes patient safety. It defines your software development lifecycle (SDLC), and this SDLC lives inside your ISO 13485 quality system. The standard lays out how your development process should work.

That’s especially important for embedded systems, where software risks often stay hidden until something breaks. IEC 62304 helps you keep things predictable, especially when it counts.

Understanding software risk

One of the first steps in IEC 62304 is to figure out how risky your software could be if something goes wrong. This process is known as software safety classification. It sets the tone for how thorough your process needs to be.

Overall, this standard isn’t meant to make your life harder but to ensure that when the device ships, it’s safe (safe by design, safe in production, and safe even when things go sideways).

You can follow IEC 62304, write good code, and test it properly. But without proper ISO 13485 compliance, your work still won’t hold up during an audit.

IEC 62304 defines how you build and maintain your software. ISO 13485 is the quality system that surrounds that process. If the two don’t align, things will break down (usually at the worst possible time).

ISO 13485 is the international standard for medical device quality management systems. It outlines how you manage design, suppliers, manufacturing, and post-market actions. While it doesn’t give software-specific rules, it provides the framework where your 62304-aligned development must live.

How it connects to embedded software

ISO 13485 might seem like something for the quality team, but if you’re working on embedded medical software, it affects your work directly.

You can’t start coding until your requirements are properly documented and approved, as required by the QMS. If you’re using open-source or third-party libraries, they count as suppliers, and you’ll need to review and document them.

Later, if there’s a complaint tied to the software, it could trigger a CAPA. You’ll need to explain what went wrong, how you fixed it, and how you’ll prevent it from happening again.

It all happens outside your IDE, but it shapes how your team works. That’s why ISO 13485 matters. It makes sure your software is not just functional, but also traceable and ready for certification.

Why it matters

You can follow IEC 62304 and write solid code. But if your medical device quality management system doesn’t back it up, the audit can still fail.

Auditors care about how decisions are made and risks are managed. If your QMS doesn’t show that, you’ve got a gap.

Once you understand the purpose of IEC 62304 and how it fits within ISO 13485, the next logical question is: how do you actually work with it? The standard outlines several core processes that any compliant medical device software must go through. But instead of viewing these as dry formalities, it helps to think of each process as solving a practical problem during development. Each of these sits under ISO 13485’s design and development controls.

Software development planning

Before anything gets built, you need a plan. Who’s doing what? How is the work organized? What’s the safety class?

This is where you set expectations and define what documents are needed for traceability. For Class B or C, that often includes architecture diagrams, test plans, and traceability tables.
The plan is a part of your ISO 13485 records and helps show that you had structure from day one.

Software requirements analysis

This step connects functionality to risk. Each requirement needs to map back to the risk controls defined in ISO 14971.

Why? Because if a feature manages risk, you need to prove it. Each requirement should link to something in your risk file. That’s what auditors (and your future self too) will expect to see. Under ISO 13485, these requirements must be verified and validated, tying 62304 directly into broader QMS obligations.

Software architectural design

Now’s the time to decide how everything fits together. Speed matters, but so does making sure the system can handle something going wrong.

Good architecture separates critical functions from non-critical ones. That way, if something breaks, it doesn’t bring the whole system down. And for Class C software, this structure can determine how much testing and review you’ll need.

Software detailed design

Here’s where you sketch out how each component will behave. You document how the component receives data, processes it, and what it returns.

Agile teams might hesitate here. But even in iterative development, this level of detail is useful. It ensures everyone’s on the same page. And when you reach verification, you’ll be glad the groundwork is there.

Software unit implementation and verification

Now it’s time to write the code and make sure each function does what it’s supposed to. How much testing you need depends on the software safety class.

For Class A, basic tests are often enough. Class C, on the other hand, requires more rigor (e.g. code reviews, coverage checks, and sometimes static analysis). In fact, the higher the risk, the deeper you’ll need to go.

Software integration and system testing

Once the parts are tested, you bring them together. In fact, this phase plays a key role in embedded software validation for medical devices.

Integration testing checks how well components interact. System testing looks at the software as a whole. Does it do what it’s supposed to? Is it safe? Your testing should confirm both, and trace back to the original requirements.

Software release

Releasing a build is a formal decision that comes with responsibility.

By this point, you should have completed testing, tracked versions, and documented known issues. Everything needed for certification should be in place.

If problems show up later, this documentation helps explain what was known and how decisions were made.

With IEC 62304, risk management becomes part of writing software. It uses ISO 14971 principles to help you spot and control software‑related risks before they reach real patients.

Not sure what that actually looks like? Here’s a breakdown.

Identifying hazardous situations

Start by looking for any scenario where the software could go off track. That includes everything from a major failure to subtle bugs that could still lead to harm.

Implementing risk control measures

When the risks are clear, you need to decide how to keep them in check. Some controls are built into the software. Others come from hardware or user instructions.

Verifying effectiveness of risk controls

Controls only count if they work. You’ll need to confirm that each one does what it’s supposed to. Depending on the risk, that could mean testing, simulation, or formal reviews.

Documentation and traceability

You’ll need to show the link between each risk, how it’s managed, and how you know the control works. This traceability helps your team stay aligned and makes audits easier to handle.

Some medical device software regulatory compliance problems show up more than others. Especially with IEC 62304. In most cases, they trace back to how risk is managed under ISO 14971, usually when the software safety class is defined too late or just on paper.

1. One of the most common mistakes is delaying software safety classification. Teams often start development without defining the safety class. The problem is you now need to go back and collect all the evidence that matches the chosen class. And if it’s Class B or C, you’re likely missing key traceability or test depth.
2. Another common issue is the disconnect between architecture and code. Diagrams might look clean, but the repository often tells a different story. As modules shift and interfaces evolve, the design on paper can quickly fall out of sync with the actual implementation. When this gap widens, it creates friction during reviews and leads to unnecessary complications during audits.
3. Another pattern we often see is documentation that’s created just for the audit. On paper, everything might look complete. But if the team doesn’t actually use those documents day to day, the gap between development and compliance quickly widens.
4. There’s also the mismatch between process and practice. Your QMS might describe a neat, compliant workflow. But your real tools (e.g. Confluence, Jira, Git) might tell a very different story. When those don’t align, traceability suffers. Auditors notice this very quickly as it’s very obvious when the paperwork says one thing but Jira, Git, and real commits tell a different story.

These issues are common. But they’re also avoidable if you build IEC 62304 compliance into your actual workflow.

The thing is you don’t need a perfect process from day one. But if you’re working with medical device software, it’s smart to get a few key things right early. Our compliance experts prepared a couple of decisions that can save you from serious delays (either during audits or after release).

Integrate early with your QMS

Your software team and your quality team should not be living in separate worlds. If your QMS is a Word folder and your actual dev process lives in Jira or Confluence, you’ve got a disconnect.

Ideally, you want the software lifecycle defined in your QMS to mirror what the team actually does. If you’re using sprints, CI/CD, or test automation, they should be reflected in the quality system. In other words, your IEC 62304-aligned software lifecycle should live inside your ISO 13485 quality system (not outside it!). In practice, that often means mapping your IEC 62304 lifecycle directly onto the tools your team already uses (eg. Jira, Confluence, Git) and making sure your ISO 13485 procedures actually reference those tools.

Apply Agile methodologies the right way

IEC 62304 doesn’t ban Agile, but it does expect structure.

That means you need to show how work was planned, executed, and verified. If your backlog has no connection to your risk file or requirements, that’s a red flag. But if your user stories or tasks link to test cases or risk controls, you’re in good shape.

Keep proper documentation for all software lifecycle stages

Some teams document only for the audit. The result is you have docs that no one reads and that often don’t match the actual code.

Useful documentation works differently. It tracks what’s really being built. That means design docs reflect the real system, test plans grow with the product, and requirements are written before development begins. When the team relies on the docs, they stay current, simply because they have to.

Make regular training and audit readiness a habit

Audits shouldn’t come as a surprise. If your team works in line with IEC 62304 and ISO 13485, the audit should just confirm what’s already in place.

Keep things simple but consistent. Internal checks and occasional mock audits help you spot gaps before they become problems. Just as important, make sure training records are complete. If someone joins the team, give them a 20-minute rundown on the standard.

One of our clients, a European startup building an embedded medical device, had prioritized rapid prototyping over compliance and process discipline. Their wearable device worked, collecting data and pushing it to a local dashboard. But they were nowhere near IEC 62304 for embedded software readiness, or anything close to ISO 13485 certified software.

They realized this approach wouldn’t be acceptable in medtech, not with embedded software that affects real patients.

The problem:

The issue started with a lack of structure. There was no defined safety class, the architecture didn’t match the code, and no one could confidently explain how risk was managed. In addition, the paperwork looked fine at first glance, but it didn’t reflect the real development process. What the team did day-to-day looked nothing like what the quality system claimed.

What we did:

• Helped the team define the software safety class early and document the rationale.
• Refactored the system architecture to match what was actually in the repo.
• Set up a lightweight documentation workflow inside their existing tools (Jira + Confluence).
• Brought the dev team into the loop so they understood how ISO 13485 and IEC 62304 applied to their embedded software.
• Added automated traceability mapping between user stories, code commits, and tests.

What the client achieved:

• Cleared their first ISO 13485 audit without major findings.
• Cut onboarding time for new engineers by 40%.
• Reached MVP launch with software and documentation fully aligned to IEC 62304 Class B expectations.
• Landed their first pilot with a hospital group.

We’ve looked at why IEC 62304 and ISO 13485 are essential when it comes to embedded medical device software. As we’ve seen, clean code alone doesn’t cut it as without the right structure (risk-based development, traceability, documentation, and QMS alignment) you’re left exposed during audits and real-world use.

If that sounds familiar or you’re aiming to avoid these challenges altogether, Yalantis can offer assistance from our top experts. We help medtech companies align their development workflows with IEC 62304, embed them into ISO 13485-compliant quality systems, and get their embedded software ready for market.