When a Medical Device Recall Is an App: Software Device Recalls in Canada

A recall does not always arrive on a pallet. In October 2026, Health Canada posted a Type II health product recall for the FreeStyle Libre 3 App, the mobile application that people with diabetes use to read a continuous glucose sensor. Nothing physical was shipped back to a warehouse. The corrective action was a software update. The event still carried the full weight of a medical device recall under Canadian law, with reporting duties, timelines and records that many software and quality teams are not ready to meet.

For years, Canadian regulatory and quality teams have treated recalls as a problem of physical product: a bottle, a catheter, a surgical tray. Software has changed that picture. When an app, an algorithm or a firmware update is itself a regulated medical device, a defect in that software can trigger the same obligations as a defective implant. This article explains when software is a medical device in Canada, when a software fix becomes a recall, and the practical controls importers, distributors and manufacturers need in place before the next release goes wrong.

Executive summary

Software can be a regulated medical device in Canada, either on its own as Software as a Medical Device (SaMD) or as software that forms part of a device system. When a change to that software is made after sale to correct a defect that could affect safety, performance or compliance, it meets the regulatory definition of a recall under the Medical Devices Regulations (SOR/98-282), even when the fix is delivered as an app update. The 24 hour reporting clock and the record duties apply the same way they do to physical product.

Key takeaways:

A software update can be a recall. The Medical Devices Regulations define a recall to include any post sale action to correct a device because of a possible safety, performance or compliance problem.
The FreeStyle Libre 3 App recall (RA-82855, Type II) shows how a cybersecurity patch can itself introduce a defect that becomes a reportable correction.
A manufacturer or importer that decides to recall without a Ministerial order must notify Health Canada in writing within 24 hours of the decision.
App store and over the air updates are a distribution channel. If you cannot show who received which version, your recall records will not hold up.
Not every software change is a recall. Routine feature releases that do not correct a defect are not recalls, but the decision must be documented with a risk assessment.
Treat cybersecurity, software quality and field actions as one connected system, not as separate IT and regulatory silos.

What happened with the FreeStyle Libre 3 App recall

In short: Abbott identified a security update for the FreeStyle Libre 3 App, and an earlier version of that security fix introduced a defect that, under certain conditions, could cause a prolonged loss of communication between the app and the glucose sensor. Health Canada posted it as a Type II health product recall and told users to update the app to the current version. The corrective action was software, but the regulatory event was a recall.

According to the Health Canada recall notice, Abbott Diabetes Care Ltd. advised that a security update to the FreeStyle Libre 3 App was required to maintain the security of the apps. The notice states that, following the security update on Android and iOS, the fix implemented to mitigate a sensor impersonation vulnerability introduced an unintended defect that, under certain conditions, can result in prolonged loss of communication between the mobile application and the sensor. Customers were advised to immediately update their app to the current version to rectify the issues.

For a continuous glucose monitor, a loss of communication between the app and the sensor is not a cosmetic bug. The app is how many users see their glucose readings and trend alerts. That is why the issue was treated as a device performance and compatibility problem, not an ordinary software nuisance.

Field	Detail from the Health Canada notice
Product	FreeStyle Libre 3 App (Android and iOS)
Company	Abbott Diabetes Care Ltd.
Identification number	RA-82855
Recall class	Type II
Recall date	16 October 2026
Date published	26 October 2026
Affected versions	App versions 3.6.4 to 3.6.8
Issue	A security fix for a sensor impersonation vulnerability introduced a defect that can cause prolonged loss of communication between the app and sensor
Corrective action	Update the app to the current version

When is software a medical device in Canada?

Short answer: software is a medical device when it has a medical purpose. Health Canada regulates Software as a Medical Device (SaMD), defined as software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. Software that drives or is built into a hardware device, and software that works with a device system, is also captured within the medical device framework.

Health Canada uses the International Medical Device Regulators Forum (IMDRF) definition. Its guidance on Software as a Medical Device states that SaMD is a medical device and includes in vitro diagnostic (IVD) medical devices, and that software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device. General wellness apps that only maintain or encourage a healthy lifestyle are excluded. The guidance represents the first phase of SaMD policy in Canada.

SaMD versus software in a device

The distinction matters because it decides which rules attach, but it rarely removes software from regulation altogether. Three broad situations arise:

Standalone SaMD. Software that performs a medical purpose on its own, such as an algorithm that analyses images or flags a clinical result, is a medical device in its own right.
Software that drives a device. Software that controls or is embedded in hardware is regulated as part of that hardware device, not as separate SaMD.
Software that works with a device system. An app that displays readings from a sensor, as in a continuous glucose monitoring system, is part of a licensed device system. A defect in the app can affect the safety and performance of the whole system.

How SaMD is classified, Class I to IV

As with other devices, Health Canada classifies SaMD into four risk classes under the Medical Devices Regulations, where Class I is the lowest risk and Class IV the highest. For non IVD SaMD, two factors drive the class: the significance of the information the software provides to a healthcare decision, and the state of the healthcare situation or condition the software is intended for.

Significance of information the software provides	Non serious condition	Serious condition	Critical condition
Treat or diagnose	Class I or II	Class II or III	Class III
Drive clinical or patient management	Class I or II	Class II or III	Class II or III
Inform clinical or patient management	Class I or II	Class I or II	Class I or II

The exact class is confirmed by the Medical Devices Bureau when it reviews the licence application. The practical point for quality teams is that higher class software carries higher expectations for its design file, its risk management and the discipline around any change made after it reaches the market.

When does a software fix become a recall?

Short answer: a software fix becomes a recall when it is made after the device has been sold to correct a defect that could put health at risk, could make the device fail to meet a claim, or could make it fall short of the regulations. The Medical Devices Regulations define a recall broadly, and the word correct is written into the definition.

Section 1 of the Medical Devices Regulations (SOR/98-282) defines a recall to include any action taken by a manufacturer, importer or distributor of a medical device, after the device has been sold, to recall or correct the device, or to notify its owners and users of its defectiveness or potential defectiveness, after becoming aware that the device may present a risk of injury to health, may fail to conform to a claim relating to its effectiveness, benefits, performance characteristics or safety, or may not meet the requirements of the Act or the Regulations.

Read that definition against an app update. A field update pushed to correct a defect that affects how a device performs is a correction of a sold device. On the plain wording, that is a recall, whether the fix travels by courier or by app store. The delivery method does not change the legal character of the action.

What is not a recall

Not every software release is a recall. A routine feature update, a user interface refresh or a planned enhancement that does not correct a defect tied to safety, performance or compliance is not a recall. The key is that the decision should be documented. A short, dated risk assessment that explains why a given release is an enhancement and not a correction is exactly what an inspector will want to see if the question is ever raised.

Keep recalls separate from licensing changes. A change to a device, including its software, can be a significant change that requires a licence amendment before the new version is sold. That is a different obligation from recall reporting. A single software release can, at the same time, be a correction you must report as a recall and a significant change you must license. The expectations for higher class device licences are a useful reference point here.

What you must report, and the clock that starts

Short answer: if you decide to recall a device in Canada without a Ministerial order, you must notify Health Canada in writing within 24 hours of the decision, provide a full information package on or before the day the recall begins, and report the results within 30 days of completing it. Software recalls follow the same schedule.

The reporting duties sit in sections 63 to 65 of the Medical Devices Regulations. They apply to manufacturers and importers, with a scope limit: the recall reporting sections apply where the device is likely to cause injury, or could cause serious injury, to the health of a patient, user or other person. The same framework, the definitions, the classes and the 24 hour clock, is covered in our guide to medical device recall reporting and the 24 hour clock. Health Canada assigns the recall a class from I to III based on risk, which we explain in how Canada classifies a recall as Type I, II or III.

Stage	Deadline	What you provide (voluntary recall)
Decision to recall	Within 24 hours of the decision	Written notice to Health Canada with device identification, licence number and a preliminary risk evaluation (section 63.2)
Recall begins	On or before the day the recall starts	Full information package: risk evaluation, number of affected units, distribution list, recall communications, recall strategy and dates, and action to prevent recurrence (section 64)
Recall completed	Within 30 days of completion	The results of the recall and the action taken to prevent a recurrence (section 65)

Two points often surprise software teams. First, an importer may prepare and submit the information on the manufacturer's behalf if the submissions are identical, and the manufacturer must advise Health Canada in writing that it is doing so. Second, distributors are not off the hook: a distributor that conducts a recall must keep records, including a risk evaluation and the actions taken to prevent recurrence. Records must be kept for the useful life of the device plus two years, or for as long as the device is sold in Canada, whichever is longer.

Why software recalls trip up quality systems

Short answer: software recalls fail on the same points as physical recalls, plus a few that are unique to code. The most common gaps are a distribution channel nobody controls, poor version traceability, and no field action procedure that mentions software at all.

These are the issues we see most often when we review software field actions and recall readiness:

The app store is an uncontrolled channel. Section 64 asks for the names of the people the device was sold to and the number of units. If your app reaches users through a public store with no account level record, you may not be able to produce a defensible distribution list or confirm who installed the fix.
Version traceability is weak. You must know which versions are affected and which users are still on them. The Libre notice named specific affected versions for a reason. Without version analytics, you cannot scope the recall or prove it is complete.
Recall versus enhancement is decided informally. A developer ships a quiet fix and no one assesses whether it was a correction. The missing artifact is a documented risk based decision.
The field action SOP does not cover software. Many recall procedures assume a physical product and a return. They have no path for an over the air update, an app store submission timeline or a forced update.
Cybersecurity patches live outside the quality system. When security fixes are treated as pure IT work, they skip change control and verification. The Libre case shows the result: a security patch that introduced a performance defect.
CAPA stops at the symptom. Fixing the broken version is not enough. A complete ISO 14971 risk management file and a CAPA should ask how a fix was released without catching the new defect, and what verification will prevent a repeat.

The parallel is worth noting. In the United States, the FDA has moved in the same direction, treating prescription drug software and companion apps as part of the regulated product. Canadian device makers that export should expect scrutiny of software field actions on both sides of the border.

Software recall readiness checklist

Use this checklist to test whether your organization could run a software device recall today, not after a scramble. It is the basis of the downloadable worksheet below.

Confirm in writing whether each software product is SaMD, software in a device, or software that works with a device system, and record its device class.
Maintain version analytics so you can identify, at any time, which users or installations are on which version.
Keep a distribution record for software, including app store channels, that can support a section 64 distribution list.
Hold a documented, risk based decision for every release that explains whether it is a correction (recall) or an enhancement.
Bring cybersecurity patches inside change control, with risk assessment and verification before release.
Maintain a field action SOP that covers over the air updates, app store timelines and forced updates, not just physical returns.
Pre draft the section 63.2 notice template so the 24 hour clock does not catch you unprepared.
Define who makes the recall decision, and record the name, title and date when it is made.
Keep an up to date risk management file for each software device and link it to your complaint and incident data.
Set record retention for software recalls at the device useful life plus two years, or the sales period in Canada, whichever is longer.
Run a mock software recall at least once a year to test traceability, timelines and records.

Common mistakes to avoid

Calling it an update to avoid the word recall. The regulation looks at what you did and why, not what you named it. A correction of a sold device is a recall regardless of the label.
Assuming an app is not a device. If the software has a medical purpose or works with a device system, it is regulated. The marketing name does not decide the status.
Missing the 24 hour notice. The clock starts when you decide to recall, not when the fix is ready. Teams lose days deciding whether to report at all.
Treating cybersecurity as separate from quality. Security and performance are linked. A patch is a device change and belongs in change control.
No way to prove the recall is complete. Without version adoption data, you cannot show Health Canada that users moved to the fixed version.

How MFLRC can help

MFLRC helps device and digital health companies treat software with the same regulatory discipline as hardware. We build and review field action and recall procedures that cover over the air and app store updates, carry out gap assessments against the Medical Devices Regulations, and help you classify software as SaMD or software in a device. We develop the SOPs, risk management files and change control processes that make a software recall defensible, and we provide Quality Assurance Person and audit support so your quality system is ready before an inspection, not after one. For companies that also export, we align Canadian and United States expectations for software and combination product field actions.

If a software defect has already surfaced, we can help you run the recall decision, meet the 24 hour notice and assemble the section 64 package without missing a step. If you are planning ahead, a readiness review now is far cheaper than a scramble during a live event.

Ready to pressure test your software recall readiness? Talk to MFLRC or book a consultation and we will map your current procedures to what Health Canada expects.

Book a Software Recall Readiness Review

Frequently asked questions

Is a mobile app really a medical device in Canada?

It can be. If an app has a medical purpose and performs it without being part of a hardware device, it is Software as a Medical Device and is regulated like any other medical device. An app that works with a device system, such as a continuous glucose monitor, is part of that licensed system. Apps that only promote general wellness are excluded.

Does a software update count as a recall?

Yes, when the update is made after the device is sold to correct a defect that could affect safety, performance or compliance. The Medical Devices Regulations define a recall to include correcting a device, so the fix being software does not change the obligation. A routine feature release that corrects no defect is not a recall.

How quickly must we tell Health Canada?

For a recall you decide to run without a Ministerial order, you must notify Health Canada in writing within 24 hours of the decision. A full information package is due on or before the day the recall begins, and the results are due within 30 days of completing it.

What if the app reaches users through the Apple App Store or Google Play?

The public store is your distribution channel, and you are still expected to support a distribution picture and to show that affected users moved to the fixed version. Build version analytics and a software distribution record now, because you cannot reconstruct them during a live recall.

Is a cybersecurity patch a device change?

Yes. A security patch changes the device and should pass through change control, risk assessment and verification. The FreeStyle Libre 3 App case shows why: a security fix introduced a performance defect that then had to be corrected as a recall.

Who is responsible, the manufacturer, the importer or the distributor?

All three have duties. Manufacturers and importers carry the reporting obligations, an importer may file on the manufacturer's behalf if the submissions are identical, and distributors must keep recall records including a risk evaluation and the actions taken to prevent recurrence.

The bottom line

The FreeStyle Libre 3 App recall is a preview of where device regulation is heading. As software becomes the device, or an inseparable part of it, the line between an IT release and a regulated recall gets thinner. The organizations that cope well will be the ones that decided, in advance, how to tell a correction from an enhancement, how to trace versions, and how to start the 24 hour clock without panic. Software does not get a lighter set of rules. It gets the same rules, delivered faster.

Treat your next app release as a potential field action waiting to happen, and build the records that would let you run it cleanly. That is the difference between a quiet update and a compliance event.