FDA Enforcement Discretion (2026) for Medical Software & Apps

October 29, 2026
Contact Person:
Malte Bucksch

by | Oct 29, 2026 | Medical Software

FDA Enforcement Discretion (2026) for Medical Software & Apps

“If your health app does anything medical, the FDA will want a mountain of documentation and a clearance before your first patient ever opens it.”

That is what most founders hear when they start building medical software for the US market. And for many products, it is true. If your product qualifies as a medical device, the US Food and Drug Administration (FDA) expects you to comply with a long list of regulatory requirements: Quality management system (QMS), Design documentation, Risk management, Postmarket duties etc.

That is months of work, a lot of documentation and a good chunk of money before your first user ever sees the app.

But it is not true for all medical software or apps. If your product is low-risk enough, the FDA intentionally does not enforce these strict requirements on it.

This is called enforcement discretion.

If you are building a coaching app, a tracking app or a reminder app for patients, chances are good that your product falls under enforcement discretion. In that case, there is no FDA submission, no FDA review and no FDA inspection standing between you and your launch. That saves you a lot of time and money.

But how do you know whether your product qualifies? And what does enforcement discretion mean for topics like quality management and documentation? This article gives you the answers.

Table of Contents

1. What is enforcement discretion and how does it help me?

Let’s start with the basics. US law defines what a medical device is, in Section 201(h)(1) of the Federal Food, Drug, and Cosmetic Act (FD&C Act). In simple terms, a product is a medical device if it is intended to be used for diagnosing, treating, curing, mitigating or preventing a disease or another medical condition. Software can be a medical device too.

That definition is very broad. Even a simple app that coaches people with diabetes to eat healthier can, strictly speaking, be intended for the mitigation or treatment of a disease. So on paper, it may be a medical device.

The FDA knows that regulating every one of these apps like a pacemaker would make no sense. So for certain types of software that qualify as a medical device, the FDA has decided that the risk is low enough that it will not enforce the legal requirements for medical devices. In the FDA’s own words, it does not, “at this time, intend to enforce requirements under the FD&C Act”.

That is enforcement discretion. If your software is a medical device, it stays one on paper. The FDA just chooses not to enforce the rules.

Important: There is no application, no registration and no approval letter for enforcement discretion. You do not “apply” for it. You look at your product, compare it with the FDA’s guidance and decide yourself whether it falls under enforcement discretion. The FDA does not confirm this decision unless you actively ask (more on that in chapter 7).

2. Is your software a medical device at all?

Before you check whether you qualify for enforcement discretion, you should check whether your software is a medical device in the first place. If it isn’t, you don’t need to bother with medical device regulation at all.

A lot of health-related software is not a medical device. The 21st Century Cures Act from 2016 explicitly excluded several types of software from the device definition (Section 520(o) of the FD&C Act), for example:

  • Administrative software: scheduling, billing, practice management
  • General wellness software: apps that promote a healthy lifestyle without referring to a disease, for example a fitness or sleep tracker
  • Electronic health record functions: software that stores and displays patient records
  • Data transfer and display: software that only transfers, stores or displays data without analyzing it
  • Certain clinical decision support (CDS) software: software that gives recommendations to doctors in a way that lets them independently review the basis for the recommendation

What decides whether your software is a medical device is not the technology. It is the intended use, meaning what you say your software is for. This includes your website, app store description, marketing material and even what you tell customers or investors. The same app with the same functionality can be a medical device or not, depending on how you describe it.

Decision tree with three outcomes: not a medical device, enforcement discretion or regulated medical device

Figure 1: Three possible outcomes for your software. Enforcement discretion only becomes relevant if your software is a medical device.

3. The big benefit of enforcement discretion

So what does enforcement discretion actually give you? A lot. If your software falls under enforcement discretion, the FDA does not enforce the legal requirements for medical devices, at least for now. In practice, this means:

  • Premarket review: no 510(k) or De Novo submission and no months of waiting for the FDA’s decision
  • Registration and listing: no registration of your company and product with the FDA and no annual registration fee
  • Inspections: no FDA inspection of your company and processes
  • Postmarket duties: no formal FDA reporting obligations after launch

What about the QMS and the design documentation? The FDA recommends that you have them anyway, but it does not check them. More on that in the next chapter.

Comparison of FDA requirements for a regulated device and for software under enforcement discretion

Figure 2: What changes under enforcement discretion compared to a regulated medical device.

The premarket submission is a big block of effort and waiting time in the whole process. So even if you decide to keep a lean QMS and proper documentation, enforcement discretion can save you many months on the way to the market.

4. Do you still need a QMS and documentation under enforcement discretion?

This is probably the most common question about enforcement discretion. The situation is simple:

  • The law requires it: Strictly speaking, if your software is a medical device, the FDA’s quality management requirements (21 CFR Part 820) generally apply to it, unless the classification regulation for that device type exempts it. Enforcement discretion itself does not remove this requirement. It only means that the FDA does not intend to enforce it. Since February 2026, 21 CFR Part 820 is called the Quality Management System Regulation (QMSR) and is directly based on ISO 13485, the international standard for quality management of medical devices.
  • The FDA recommends it: In the FAQ of its guidance, the FDA states that it believes “all manufacturers of medical device software should have in place an adequate quality management system”. This includes risk management, good design practices and proper verification and validation.
  • The FDA does not check it: For software under enforcement discretion, the FDA does not enforce these requirements. The FDA does not review your QMS or your documentation.

So pragmatically speaking: Whether you build a QMS and technical documentation is your own entrepreneurial decision. You should build the processes and documentation but the FDA will not ask for it (as of now).

That means that in reality some teams with a product under enforcement discretion start with a lean QMS from day one. Others focus on the product first and add structure later. Others skip the documentation entirely (which is not a recommendation but what happens in practice).

Before you decide, you should know exactly what you are choosing. Three things are worth keeping in mind:

1. It is tolerance, not an exemption: Enforcement discretion is not an exemption written into the law. The law only preserves the FDA’s right to exercise enforcement discretion (Section 520(o)(4) of the FD&C Act). Enforcement discretion is a policy in an FDA guidance document, and guidance documents are not binding, not even for the FDA. Guidance documents also change from time to time, and with them the exact scope of enforcement discretion. The guidance on clinical decision support software alone was revised in January 2026 and corrected again a few weeks later. A product that falls under enforcement discretion today does not automatically fall under it after the next revision.

2. The real risk is being wrong about enforcement discretion: Enforcement discretion only works if your product really falls under it. If the FDA comes to the conclusion that your app goes beyond what is covered, for example because your marketing promises more than coaching, then your product was a regulated medical device from day one. Without a QMS, without documentation and without an FDA review. That is the scenario that leads to warning letters and forced product changes.

3. Other markets and partners may expect more: Enforcement discretion is a US concept. Other markets have their own rules, and partners such as hospitals, health insurers or pharma companies may ask for quality evidence anyway.

Good to know for the EU: The EU Medical Device Regulation (MDR) has no enforcement discretion. The same coaching app that the FDA leaves alone can be a medical device in the EU that needs CE marking. Under the MDR’s software classification rule (Rule 11), such apps often end up in a risk class that requires a review by an independent notified body. If you plan to launch in Europe later, read our guide on whether your software is a medical device under the MDR: Guide: Is your software a medical device? and our guide on classification of software medical devices.

Our recommendation: In any case, what you should definitely do is to document why your product falls under enforcement discretion (see chapter 7). If anyone ever questions your status, whether the FDA, an investor or a partner, you have a clear answer ready. Even better is a confirmation from the FDA itself, for example through a 513(g) request.

5. Will there be (unannounced) audits for software under enforcement discretion?

Highly unlikely if you are right about your assessment on the enforcement discretion. Your product is not even registered with the FDA. Routine FDA inspections are planned based on the FDA’s registration database, so the FDA usually does not know that your product exists. It can still inspect any device manufacturer for cause but this is highly unlikely.

That does not mean the FDA can never notice you. The FDA stays responsible for medical devices, including those under enforcement discretion. If your product attracts attention, for example through user complaints, reports of harm or bold marketing claims, the FDA can look into it.

6. Does your product qualify for enforcement discretion?

The main source for this is the FDA guidance “Policy for Device Software Functions and Mobile Medical Applications” from 28 September 2022. According to Section V.B of this guidance, the FDA generally intends to exercise enforcement discretion for software functions that:

  1. “Help patients (i.e., users) self-manage their disease or conditions without providing specific treatment or treatment suggestions; or”
  2. “Automate simple tasks for health care professionals.”

These two sentences are the core of enforcement discretion. If your software does one of these two things, and nothing more risky on top, you have a good chance.

Low risk is the common denominator

All examples of enforcement discretion have one thing in common: low risk for patients. A helpful way to estimate the risk of your software is the risk framework of the International Medical Device Regulators Forum (IMDRF), an international group of medical device regulators that includes the FDA. It sorts software into four categories, based on how serious the patient’s condition is and how much the software influences medical decisions:

IMDRF risk matrix with categories I to IV, Category I highlighted as more likely candidates for enforcement discretion

Figure 3: Risk categories for medical software according to the International Medical Device Regulators Forum (IMDRF). Source: IMDRF, Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations (N12, 2014). The highlighting of Category I follows the NIH overview, not the IMDRF or the FDA.

Category IV is the highest risk, Category I the lowest. As a rule of thumb, software in Category I is a more likely candidate for enforcement discretion, for example an app that only informs about a non-serious condition. The National Institutes of Health (NIH) gives the same advice in its overview of enforcement discretion for startups.

Important: This table is an orientation, not an FDA rule. Whether your software falls under enforcement discretion is decided by the FDA’s guidance documents and their examples, not by the IMDRF category.

Examples

The guidance gives three typical categories as examples. In simple words:

  • Coaching and reminder apps for patients: apps that coach people with conditions like diabetes, high blood pressure, heart disease or obesity to eat healthier, exercise more, reduce salt or take their medication on a fixed schedule, using simple prompts. The FDA only means apps that patients can safely use on their own without a doctor watching, and that don’t replace seeing a doctor for serious conditions.
  • Photo apps for communicating with a doctor: apps that use the phone camera to take and send pictures to a health care professional, for example of a skin lesion or a wound, to support what the patient would otherwise describe in words
  • Simple medical calculators: software that does the simple calculations that doctors learn in medical school and use every day, for example Body Mass Index (BMI), mean arterial pressure, the APGAR score for newborns, the Glasgow Coma Scale or a delivery date estimator

The two FDA criteria for enforcement discretion and three typical example categories

Figure 4: The two criteria from Section V.B of the FDA guidance and the three typical example categories.

More concrete examples

Appendix B of the same guidance lists 18 more concrete examples. They include, among others:

  • apps that help patients with diagnosed psychiatric conditions such as depression or anxiety keep up their coping skills, for example with a “skill of the day”
  • apps that track medication and remind users to take it
  • apps that track and display trends of vital signs such as heart rate or blood pressure
  • apps that help people with prediabetes eat better or move more
  • apps that let users call a nurse or send an emergency alert
  • symptom checkers that list possible conditions and tell users when to see a doctor
  • etc.

Where enforcement discretion ends

The line is usually crossed when your software stops supporting and starts deciding. Typical examples that are not covered by enforcement discretion:

  • Specific treatment suggestions: for example an app that calculates the insulin dose a diabetic should inject. A diabetes app that logs blood sugar and motivates you to exercise can fall under enforcement discretion. Once it tells you how much insulin to take, it is a regulated device.
  • Diagnosis: software that tells a user they have a specific disease, for example based on sensor data or photos
  • Analyzing medical images or signals: software that evaluates X-rays, ECG signals or similar data

You find examples of software that the FDA actively regulates in Appendix C of the same guidance. Comparing your product with Appendix B and Appendix C is usually the fastest way to see where you stand.

Software that supports, like diet coaching for diabetes, versus software that decides, like an insulin dose calculator

Figure 5: Software that supports can fall under enforcement discretion. Software that decides is usually a regulated device.

Two more places where enforcement discretion shows up

The 2022 guidance is the main source, but not the only one. In January 2026, the FDA updated two other guidance documents that are relevant for many software products:

  • General wellness products (6 January 2026): If your product is a lifestyle app or a wearable that promotes a healthy lifestyle, check this guidance. Software that only promotes a healthy lifestyle without any link to a disease is not a medical device at all. If your low-risk product links a healthy lifestyle to a chronic disease, for example by saying it “may help living well with type 2 diabetes”, the FDA does not intend to examine whether it is a device or whether it meets the device requirements.
  • Clinical decision support software (29 January 2026): If your software gives recommendations to doctors, check this guidance. It now includes enforcement discretion for software that gives only one recommendation, if that is the only clinically appropriate option and the software meets the other criteria.

7. How do you know for sure?

Since nobody confirms enforcement discretion for you automatically, you have two options to get certainty.

Option 1: Ask the FDA

The FDA offers several ways to ask:

  • Email: For the question whether your software is a medical device, the FDA’s Digital Health Center of Excellence can be reached at digitalhealth@fda.hhs.gov. For general questions about regulatory requirements, you can contact the FDA’s Office of Industry and Consumer Education (OICE, formerly DICE) at AskOICE@fda.hhs.gov. If you still cannot decide after that, the FDA’s Device Determination mailbox at DeviceDetermination@fda.hhs.gov is the next step.
  • 513(g) Request for Information: This is the formal way. You send the FDA a description of your software, what it is used for and your labeling or marketing material, and pay a fee. The FDA generally answers within 60 days with a confidential letter that tells you how it sees your product. The answer is not a formal approval, but it is the FDA’s written view and the best protection you can get.
  • Pre-Submission (Pre-Sub): If you already expect to need a 510(k) or De Novo, a Pre-Sub lets you get FDA feedback on your planned submission before you submit it. Questions about whether your product is a device or which requirements apply are outside the scope of a Pre-Sub. For those, use a 513(g) request.

Three steps to more certainty: document your reasoning, ask the FDA by email, file a 513(g) request

Figure 6: The more formal the route, the more certainty you get about your status.

Our recommendation: Whether you ask the FDA or not, write down your reasoning. A one or two page document is enough: what your software does, your exact intended use, which example from the guidance it matches and why it does not cross the line. Then review your marketing texts and every new feature against this document. Check your enforcement discretion status regularly, for example once a year, because the FDA’s guidance documents change. Document each check. This gives you a clean paper trail if the FDA ever asks.

Yearly cycle: document why you qualify, check marketing and new features, check FDA guidance updates, file the result

Figure 7: A yearly check keeps your paper trail up to date.

Option 2: Support with developing medical software for the FDA

At QuickBird Medical, we develop medical software and medical apps for the US and the EU market. We support you from the first assessment to the launch:

  • Regulatory assessment: We help you find out whether your software is a medical device at all, which risk class it falls into and whether enforcement discretion applies.
  • Development: We build your app or software.
  • Regulatory requirements: We cover everything your product needs, from quality management to the documentation for an FDA submission or CE marking.

Not sure where your product stands? Learn more about our FDA-compliant software development or get in touch with us directly.

8. Helpful resources for deciding about enforcement discretion

All of these are official FDA sources:

Further reading from other sources:

9. Conclusion

Enforcement discretion is one of the most useful and least known concepts in US medical device regulation. If your software helps patients manage their condition without telling them what treatment to take, or automates simple tasks for doctors, the FDA will most likely leave you alone. No 510(k), no FDA registration, no FDA inspection. Whether you build a QMS and technical documentation anyway is your decision: the FDA recommends it, but it does not check it.

But it is tolerance, not an exemption. Your software is still a medical device on paper. Whether it falls under enforcement discretion is your own assessment. The FDA does not confirm it unless you ask, but it has the final word if it ever takes a closer look. The biggest risk is not an audit. It is getting this assessment wrong, for example because your marketing promises more than your product is allowed to do.

So our advice: check your intended use carefully against the FDA’s examples, write down your reasoning, keep your marketing in line with it and ask the FDA if you are unsure.

Are you planning to develop medical software?

If you want to develop software for the US market, let us know. We specialize in medical device development for the US market under FDA requirements and for the EU market under the MDR.