Back
on
by

Is Your Mobile Medical App FDA-Regulated? A Five-Step Decision Tree

Mobile Medical App Regulation
A mobile medical app (MMA) is a software application running on a smartphone or tablet that performs a medical function — diagnosing, treating, monitoring, mitigating, or preventing disease. The FDA regulates MMAs that meet the definition of a medical device and carry significant patient risk; many lower-risk MMAs fall under enforcement discretion and are not…

A mobile medical app (MMA) is a software application running on a smartphone or tablet that performs a medical function — diagnosing, treating, monitoring, mitigating, or preventing disease. The FDA regulates MMAs that meet the definition of a medical device and carry significant patient risk; many lower-risk MMAs fall under enforcement discretion and are not actively regulated.

This guide reflects FDA’s current policy for device software functions, the cybersecurity requirements in section 524B of the Federal Food, Drug, and Cosmetic Act, and FDA’s published position on predetermined change control plans. Each document is named where it applies, so you can check the source rather than take the summary on trust.

The Five-Step Test

Work the five steps in order. Each one ends the assessment or sends you to the next. Intended use governs throughout: what you claim the app does in its labeling, marketing, and interface determines its status, not how the code is written.

Five-step decision tree for determining if a mobile medical app is subject to FDA regulation. Step 1 asks whether the app diagnoses, treats, cures, mitigates, or prevents disease — if no, the app is not a mobile medical app and not subject to FDA regulation. If yes, proceed to Step 2: assess risk level. High risk leads to FDA regulation. Low risk proceeds to Step 4. Medium risk proceeds to Step 3, which asks whether the app falls under FDA enforcement discretion — if no, the app is subject to FDA regulation; if yes, proceed to Step 4. Step 4 asks whether the app performs health IT functions affecting clinical decisions — if yes, the app is subject to FDA regulation; if no, proceed to Step 5. Step 5 asks whether the app provides patient-specific analysis or recommendations — if yes, the app is subject to FDA regulation; if no, the app falls under enforcement discretion and is not actively regulated.

Step 1. Does the app meet the statutory definition of a device?

A software function is a device if it is intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease, or intended to affect the structure or any function of the body. The test is your stated intended use, established through claims, labeling, and promotional material.

  • No. The app is outside FDA’s device authority. The assessment ends here.
  • Yes. Continue to Step 2.

Step 2. What is the consequence if the app malfunctions?

Risk determines class, and class determines the submission route. Ask what happens to a patient if the app returns a wrong result, fails silently, or becomes unavailable.

  • Minimal consequence. Likely Class I or a candidate for enforcement discretion. Continue to Step 3 to confirm.
  • Moderate consequence. Likely Class II and a 510(k) route. Continue to Step 3.
  • Serious injury or death. Likely Class III and a PMA route. Continue to Step 3, and treat the remaining steps as confirmation rather than as a likely exit.

Step 3. Does a statutory exclusion or enforcement discretion apply?

Two different mechanisms can take an app out of active FDA regulation, and the difference matters more than it first appears.

A statutory exclusion means the function is not a device. Section 3060 of the 21st Century Cures Act amended section 520(o) of the Federal Food, Drug, and Cosmetic Act to exclude five categories of software outright. An exclusion is law. It does not depend on FDA’s current enforcement posture.

Enforcement discretion means the function is a device and FDA has stated that it does not intend to enforce applicable requirements against it. FDA sets out the categories in its policy for device software functions. Discretion is policy, not law, and FDA can narrow it.

For a product plan, the practical difference is durability. An exclusion remains in effect unless the intended use changes. Discretion holds unless the intended use changes or FDA revises the policy. Build on an exclusion where you can, and if you are relying on discretion, know that you are and record the basis.

Step 4. Does your app perform health IT functions affecting clinical decisions?

Clinical decision support software is excluded from the device definition under section 520(o)(1)(E) only when it meets all four of the following criteria. Failing any one of them makes the software a device.

  • It does not acquire, process, or analyze a medical image, a signal from an in vitro diagnostic device, or a pattern or signal from a signal acquisition system. This is the criterion most apps fail. Processing an image or a waveform ends the exclusion on its own, whatever the app does with the result.
  • It displays, analyzes, or prints medical information about a patient, or other medical information such as peer-reviewed clinical studies and practice guidelines.
  • It supports or provides recommendations to a health care professional about the prevention, diagnosis, or treatment of a disease or condition. Note the audience. Software that gives recommendations to a patient rather than to a professional is outside this exclusion.
  • It is intended to enable the health care professional to independently review the basis for its recommendations, so that the professional does not rely primarily on them. This is a design requirement, not a disclaimer. The inputs, the logic, and the relevant evidence have to be visible enough that a competent professional could reach the same conclusion without the software.

FDA set out its interpretation of these criteria in its final guidance on clinical decision support software, issued September 28, 2022. The guidance reads the criteria more narrowly than many developers expected, particularly on the fourth, so the guidance rather than the statute alone is the document to design against.

Step 5. Does the app provide patient-specific analysis or a recommendation?

Interpretation is the dividing line. Software that moves, stores, or displays data without interpreting it generally stays outside active regulation. Software that analyzes a specific patient’s data and returns a result, a score, an alarm, or a course of action is performing a device function.

  • No analysis or recommendation. The app displays or transfers data only, and is likely outside active regulation. Confirm against the device data system policy before relying on it.
  • Patient-specific analysis or a recommendation. The app is a regulated device. Identify the class from Step 2 and plan the submission accordingly.

Where the five steps leave you

If any step ended the assessment, record which one and why, and revisit it whenever the intended use or the feature set changes. A single added claim can move an app from excluded to regulated without a line of new code. If you reached the end of Step 5, the app is a regulated device, and the next decisions are classification, submission pathway, and the quality system the submission will draw its evidence from.

Regulated vs Unregulated MMAs — Examples

The decision tree above identifies which category your app falls into. The examples below show what each category looks like in practice. The line between regulated and unregulated isn’t always obvious from a product description — intended use, the specificity of the analysis, and the clinical decisions the app influences all matter.

Examples of Regulated Mobile Medical Apps

Apps that drive or directly inform clinical decisions are typically subject to FDA regulation. Examples include: insulin dose calculators that recommend specific dosing based on glucose readings; ECG analysis apps that interpret cardiac rhythms and flag arrhythmias; wearable cardiac event monitors with FDA-cleared diagnostic algorithms; AI-based image analysis apps for dermatology, radiology, or pathology; closed-loop or hybrid closed-loop diabetes management algorithms; and clinical decision support apps that provide treatment recommendations beyond what a clinician would derive from displayed data alone.

Examples of Mobile Medical Apps Under Enforcement Discretion

Apps that support patients or providers without driving clinical decisions typically fall under enforcement discretion or are entirely outside FDA regulation. Examples include: medication reminder apps that don’t calculate dosing; health and wellness logging apps that track diet, exercise, mood, or symptoms without providing clinical interpretation; apps that automate simple medical calculations a clinician would otherwise do by hand; apps that organize patient health information for self-management; basic fitness trackers; and educational apps that present medical information without personalizing it to a specific patient’s clinical situation.

2026 FDA Regulatory Updates Affecting Mobile Medical Apps

FDA expectations for mobile medical apps have evolved significantly since 2023. Three updates matter most for any MMA developer working through an FDA submission in 2026: cybersecurity premarket requirements under section 524B of the Federal Food, Drug, and Cosmetic Act (now enforceable for every applicable submission), the FDA’s finalized guidance on AI/ML-enabled device software functions, and the framework for Predetermined Change Control Plans (PCCPs) that allows planned model updates without resubmission. The three updates work together — most modern MMAs need to address all three.

Cybersecurity Premarket Requirements (Section 524B)

Section 524B of the Federal Food, Drug, and Cosmetic Act requires cybersecurity information in premarket submissions for cyber devices. It was added by the Consolidated Appropriations Act, 2023, signed December 29, 2022, and took effect March 29, 2023. FDA began issuing Refuse to Accept decisions for submissions that did not contain the required information on October 1, 2023, so this is a completeness gate, not a review comment.

Is your app a cyber device?

Section 524B applies only to a device that meets all three of the following. If your app fails any one of them, the section does not apply to it.

  • It includes software validated, installed, or authorized by the sponsor.
  • It can connect to the internet. The capability is what counts, not whether a particular unit is connected in the field.
  • It contains technological characteristics that could be vulnerable to cybersecurity threats.

Most connected mobile medical apps meet all three. An app that performs its device function entirely on the handset with no network capability may not, and that is worth establishing early rather than assuming.

What a submission has to contain

  • A plan to monitor, identify, and address postmarket vulnerabilities and exploits, including a coordinated vulnerability disclosure process.
  • Evidence of a secure product development framework that provides reasonable assurance that the device is cybersecure, together with the means to make postmarket updates and patches available.
  • A software bill of materials covering commercial, open-source, and off-the-shelf software components.

The software bill of materials is the item teams most often leave until submission, and it is the hardest to reconstruct after the fact. It is a build-time output, not a document.

AI/ML-Enabled Mobile Medical Apps

Two distinct FDA guidance documents address AI-enabled device software, and they have different statuses: the PCCP guidance is final, while the lifecycle and marketing-submission guidance remains in draft form. Neither should be described as a binding regulation.fda+1

Predetermined change control plans. FDA’s final guidance, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, was originally issued on December 4, 2024; the current version was issued on August 18, 2025. It describes FDA’s recommendations for documenting planned software modifications, the methods used to develop, validate, and implement them, and their potential impact on safety and effectiveness.

Lifecycle management and marketing submissions. FDA issued Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations as a draft on January 7, 2025. As of October 8, 2026, FDA continues to list it as a draft and “not for implementation.” It proposes recommendations for managing risks and documenting the design, development, and implementation of AI-enabled devices throughout the product lifecycle, including transparency and bias-related considerations.fda+1

Good Machine Learning Practice. FDA, Health Canada, and the UK MHRA jointly released 10 GMLP guiding principles in October 2021. FDA’s current GMLP page also highlights the final IMDRF document released in January 2025, which builds on those principles. These documents can inform development practices but should not be presented as a standalone substitute for applicable submission requirements.

Predetermined Change Control Plans (PCCPs)

A PCCP allows manufacturers to seek FDA authorization for specified, planned changes to the software function of an AI-enabled device as part of a marketing submission. FDA’s current final guidance recommends three components: a Description of Modifications, a Modification Protocol, and an Impact Assessment. When changes are implemented consistently with an authorized PCCP, manufacturers may avoid a separate marketing submission for each covered modification; the plan does not provide blanket permission for unrestricted model updates.

The current PCCP guidance was issued on August 18, 2025, following its original issuance on December 4, 2024. It represents FDA’s current recommendations and does not replace applicable statutory or regulatory requirements.

Frequently Asked Questions About Mobile Medical App FDA Regulation

What is a mobile medical app (MMA)?

A mobile medical app (MMA) is a software application running on a smartphone, tablet, or other mobile platform that performs a medical function — diagnosing, treating, curing, mitigating, or preventing disease. The FDA defines MMAs in its 2019 guidance on mobile medical applications and regulates those that meet the definition of a medical device and pose a meaningful risk to patients.

Is a fitness tracker considered a mobile medical app under FDA regulation?

Most fitness trackers are not considered mobile medical apps under FDA regulation. Apps that track steps, calories, sleep, or general wellness without diagnosing or treating disease fall outside the FDA’s definition of a medical device. However, fitness apps that include features like ECG analysis, blood pressure monitoring, or arrhythmia detection do meet the definition and are FDA-regulated — Apple Watch’s ECG feature is a well-known example.

What is FDA enforcement discretion for mobile medical apps?

FDA enforcement discretion is the agency’s policy of not actively enforcing regulatory requirements for certain low- to moderate-risk mobile medical apps that technically meet the definition of a medical device but pose limited risk to patients. Apps under enforcement discretion can be marketed without 510(k) clearance, but they must still meet certain quality and labeling expectations. Enforcement discretion is not an exemption — the FDA can change its position if a product turns out to pose an unexpected risk.

What’s the difference between a Mobile Medical App and Software as a Medical Device (SaMD)?

Mobile Medical App (MMA) and Software as a Medical Device (SaMD) overlap heavily. SaMD is the IMDRF-defined term for software intended for medical purposes that performs those purposes without being part of a hardware medical device. MMA is the FDA’s term for the same category, specifically when the software runs on a mobile platform like a smartphone or tablet. Most MMAs are also SaMD; the terms are largely interchangeable, but SaMD is the broader and more international term.

Do mobile medical apps need to comply with FDA cybersecurity requirements?

Yes. Since 2023, FDA premarket submissions for mobile medical apps that address cybersecurity must include detailed cybersecurity documentation under section 524B of the Federal Food, Drug, and Cosmetic Act. Required content includes a Software Bill of Materials (SBOM), threat modeling, vulnerability assessment, and a plan for monitoring and addressing post-market vulnerabilities. Apps that fail to meet these requirements face refusal-to-accept (RTA) decisions, blocking their submission from substantive review.

How do AI and machine learning affect mobile medical app FDA regulation?

FDA’s AI-related recommendations include the final PCCP guidance, originally issued December 4, 2024 and updated August 18, 2025, and the separate lifecycle and marketing-submission draft guidance issued January 7, 2025, which remains draft as of October 8, 2026; see the AI/ML-Enabled Mobile Medical Apps section above for the distinction.

Determined Your App Is FDA-Regulated? Here’s What Comes Next.

If the decision tree confirmed your mobile medical app is subject to FDA regulation, the path from here typically runs through five steps: regulatory strategy and pathway selection (510(k), De Novo, or PMA), software lifecycle development under IEC 62304, quality management under ISO 13485, risk management under ISO 14971, and cybersecurity submission documentation under FDA section 524B.

Sequenex builds regulated mobile medical software every day, with all of these standards already operationalized inside an ISO 13485-certified QMS. Whether you’re navigating your first FDA submission or scaling an existing MMA, we can help map the regulatory path and execute the engineering work alongside it.

Talk to a SaMD Regulatory Specialist

Want to schedule a demo of NEX?

Contact us
SaMD and Connected Devices Software Experts
© 2026 Sequenex. All rights reserved.