Mobile Medical Applications: FDA & EU MDR Regulatory Guide (2026)
Complete regulatory guide to mobile medical apps in 2026 — FDA Policy for Device Software Functions, when mobile apps are regulated as medical devices vs wellness products, the 2026 General Wellness and CDS guidance updates, EU MDR classification under Rule 11, mobile-specific cybersecurity and privacy requirements, app store compliance, and step-by-step classification strategies for mobile health developers.
The Mobile Health App Landscape in 2026
Mobile health applications have moved from novelty to clinical infrastructure. There are now over 350,000 health apps available across major app stores, and the FDA has cleared or approved over 1,450 AI-enabled medical devices as of early 2026 — many of which include mobile components.
But the regulatory line between a "wellness app" and a "mobile medical app" remains one of the most misunderstood areas in digital health. The same smartphone sensor can power a step counter (not regulated) or an arrhythmia detector (regulated as a medical device). The difference lies entirely in intended use and marketing claims.
In January 2026, the FDA issued two updated guidance documents that significantly reshape how mobile health apps are regulated: the revised "General Wellness: Policy for Low Risk Devices" and the revised "Clinical Decision Support Software" guidance. The FDA's device center is also expected to update its "Policy for Device Software Functions and Mobile Medical Applications" later in 2026, as signaled in the CDRH proposed guidance list for fiscal year 2026.
This guide covers the complete regulatory framework for mobile medical applications in the US and EU.
When a Mobile App Is a Medical Device
The FDA's Function-Based Approach
The FDA does not regulate mobile apps based on the platform they run on. A software function that diagnoses disease from ECG data is regulated the same way whether it runs on an iPhone, a desktop computer, or a dedicated medical device. The FDA's September 2022 guidance "Policy for Device Software Functions and Mobile Medical Applications" is explicit:
"In general, if a software function is intended for use in performing a medical device function (i.e., for diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease), it is a medical device, regardless of the platform on which it is run."
The FDA applies regulatory oversight to only those mobile app functions that (1) meet the definition of a medical device and (2) could pose a risk to patient safety if they fail to function as intended.
Three Categories of Mobile Health Apps
The FDA organizes mobile health software into three categories:
Category 1: Not a Device (No FDA Oversight)
These apps do not meet the definition of a medical device and are not regulated:
- Electronic copies of medical textbooks
- Appointment schedulers
- General health education and reference tools
- Apps that simply log, record, or track general wellness data without medical interpretation
Category 2: May Be a Device — Enforcement Discretion
These apps may technically meet the device definition but pose low risk, so the FDA exercises enforcement discretion:
- Apps that help patients self-manage their disease without providing specific treatment suggestions
- Apps that provide simple alerts or reminders for medications
- Apps that automate simple healthcare provider tasks
- General wellness apps that make no specific medical claims
Category 3: Regulated Device Software Functions (Active FDA Oversight)
These apps meet the device definition and could pose patient risk if they fail:
- Apps that transform a mobile platform into a regulated medical device (e.g., using the camera as a diagnostic tool)
- Apps that connect to and control an existing regulated medical device
- Apps that perform patient-specific analysis and provide diagnosis or treatment recommendations
- Apps that are accessories to regulated medical devices
The 2026 General Wellness Guidance Update
On January 6, 2026, the FDA issued an updated "General Wellness: Policy for Low Risk Devices" guidance, superseding the 2019 version. This is particularly relevant for mobile health apps that measure physiological parameters.
The 2026 update expands the range of physiological parameters that can be measured within the general wellness framework, as long as specific criteria are met:
Two key factors determine if a product is a general wellness product:
Is the product for general wellness use? — The product must be intended for maintaining or encouraging a healthy lifestyle, or to serve as an adjunct to disease management but unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.
Is the product low risk? — The product must present a low risk to user safety. The guidance provides examples of risk characteristics to evaluate.
New examples in the 2026 guidance for mobile/wearable products:
- A wrist-worn wearable that outputs multiple biomarkers (sleep hours, sleep quality, pulse rate, blood pressure) for activity and recovery assessment
- A wearable providing blood glucose estimations for monitoring nutritional impacts using minimally invasive microneedle technology
- A wearable measuring multiple physiological parameters for fitness and wellness purposes
Critical boundary: If the app or device crosses into making specific medical claims — diagnosing a condition, recommending treatment, or making clinical interpretations — it moves from general wellness into regulated medical device territory. The dividing line is driven by how products are marketed and used, not just by what they technically measure.
The 2026 CDS Guidance and Mobile Apps
The January 2026 "Clinical Decision Support Software" guidance (updated January 29, 2026) also affects mobile health apps, particularly those providing decision support.
Under the 21st Century Cures Act (Section 520(o)(1)(E) of the FD&C Act), software is excluded from the device definition if it meets all four criteria:
- Not intended to acquire, process, or analyze medical images, signals, or patterns
- Intended to display, analyze, or print medical information about a patient (or information from a medical device)
- Intended to support or provide recommendations to an HCP about the prevention, diagnosis, or treatment of a disease or condition (the HCP can independently review the basis for the recommendation)
- Intended to allow the HCP to independently review the underlying logic
Key 2026 update: FDA stated it intends to exercise enforcement discretion for CDS functions that provide only one clinically appropriate recommendation, provided it is not time-critical and meets the other criteria. This softens the previous position that any single-recommendation tool would be regulated.
For mobile apps specifically: Software functions that support or provide recommendations to patients or caregivers — not HCPs — meet the definition of a device. FDA does not apply the CDS exclusion to patient-facing tools. Patient-facing mobile apps that provide diagnostic or treatment guidance are regulated devices.
Mobile Medical App Classification Examples
Not Regulated (Category 1)
| App Type | Why Not Regulated |
|---|---|
| Step counter / pedometer | General wellness, no medical claims |
| General nutrition tracker | No disease-specific claims |
| Medication reminder (time-based only) | Does not suggest or adjust dosing |
| Hospital finder / physician directory | Reference information only |
| Medical dictionary / textbook | Educational, no patient-specific function |
Enforcement Discretion (Category 2)
| App Type | FDA Rationale |
|---|---|
| Diet tracker for diabetes management | Helps self-management but does not provide specific insulin dosing |
| Meditation and stress management | General wellness, low risk |
| Period tracker / fertility awareness | General reproductive health tracking |
| Simple exercise prescription app | Provides general recommendations, not patient-specific |
| Blood pressure log that displays trends | Data display only, no clinical interpretation |
Actively Regulated (Category 3)
| App Type | Regulatory Basis |
|---|---|
| ECG analysis app that detects atrial fibrillation | Transforms phone into diagnostic device; cleared as 510(k) |
| App that controls insulin pump dosing | Accessory to regulated device; Class II/III |
| AI skin lesion analysis with diagnosis | SaMD providing specific diagnostic output |
| Blood glucose monitoring app with insulin calculation | Patient-specific treatment recommendation |
| App that connects to and calibrates a regulated sensor | Accessory to regulated device |
EU MDR Classification of Mobile Medical Apps
Rule 11: Software Classification
Under EU MDR Annex VIII, Rule 11, software that provides information used for diagnostic or therapeutic purposes is classified as:
- Class III — if decisions may cause death or irreversible deterioration
- Class IIb — if decisions may cause serious deterioration or require surgical intervention
- Class IIa — all other diagnostic/therapeutic decision-support software
Unlike the FDA, the EU MDR does not have broad enforcement discretion categories. If mobile software meets the definition of a medical device in the EU, it must undergo conformity assessment. A mobile app that would qualify for FDA enforcement discretion in the US may require CE marking in the EU.
MDCG Guidance on Standalone Software
The MDCG has issued guidance clarifying that:
- Mobile apps with a medical purpose are medical devices under the MDR
- The intended purpose, not the platform, determines classification
- Apps that provide clinical information used in decision-making are classified under Rule 11
- Wellness apps without a medical intended purpose fall outside the MDR
Practical US vs EU Comparison
| App Function | FDA Status | EU MDR Class |
|---|---|---|
| General fitness tracker | Not regulated (wellness) | Not regulated (no medical purpose) |
| Period tracker with fertility predictions | Enforcement discretion | Likely not regulated if no medical claims |
| Blood pressure trending display | Enforcement discretion | Class IIa (provides diagnostic information) |
| AI skin cancer screening | Regulated (510(k)/De Novo) | Class IIb or III |
| Insulin dose calculator | Regulated (Class II/III) | Class IIb or III |
| Medication adherence tracker | Enforcement discretion | Likely Class I or IIa |
| Clinical decision support for HCPs | May be excluded (CDS criteria) | Class IIa (Rule 11) |
Regulatory Pathways for Mobile Medical Apps
FDA Pathways
510(k) (Premarket Notification): The most common pathway for mobile medical apps. Requires demonstrating substantial equivalence to a legally marketed predicate device. Most cleared mobile medical apps (ECG monitors, glucose monitors, imaging tools) use this pathway.
De Novo Classification: For novel mobile apps without a valid predicate. Creates a new classification regulation and can serve as a predicate for future 510(k) submissions. Many AI-powered diagnostic apps have used this pathway.
PMA (Premarket Approval): Required for Class III mobile apps — those that support or sustain human life or present a potential unreasonable risk of illness or injury. Rarely needed for standalone mobile apps but may apply to apps controlling life-sustaining devices.
Enforcement Discretion: For mobile apps that technically meet the device definition but pose low risk. FDA does not enforce premarket requirements but reserves the right to do so.
EU MDR Pathway
Self-certification (Class I): Low-risk mobile apps classified as Class I can be self-certified. The manufacturer drafts a Declaration of Conformity and registers the device. However, most mobile SaMD falls into Class IIa or above.
Notified Body assessment (Class IIa, IIb, III): Most mobile medical apps require Notified Body involvement for conformity assessment. The manufacturer must:
- Compile technical documentation per MDR Annex II and III
- Implement a quality management system (ISO 13485)
- Conduct a clinical evaluation per MDR Article 61
- Register in EUDAMED (mandatory from May 28, 2026)
- Appoint an EU Authorized Representative (if outside the EU)
- Draft and maintain post-market surveillance documentation
Mobile-Specific Compliance Requirements
Cybersecurity for Mobile Medical Apps
The FDA's June 2025 cybersecurity guidance applies to mobile medical apps. Key requirements:
- Secure Product Development Framework (SPDF): Implement cybersecurity throughout the software lifecycle
- Software Bill of Materials (SBOM): Required for all software components, including mobile libraries and SDKs
- Threat modeling: Must address mobile-specific threats:
- App store distribution risks
- Device theft and unauthorized access
- Insecure data storage on device
- Network interception (public Wi-Fi)
- API vulnerabilities
- Reverse engineering and tampering
- Encryption: All PHI and health data must be encrypted at rest (on device) and in transit
- Authentication: Appropriate authentication mechanisms for the risk level
- Secure communication: TLS 1.2+ for all network communications
Privacy and Data Protection
US Requirements:
- HIPAA compliance if the app handles PHI on behalf of a covered entity
- FTC Health Breach Notification Rule for health apps not covered by HIPAA
- State privacy laws (California CCPA/CPRA, and others)
EU Requirements:
- GDPR compliance for any app processing personal data of EU residents
- Lawful basis for processing health data (typically explicit consent)
- Data protection impact assessment (DPIA) required for health data processing
- Privacy by design and by default
- Right to access, rectification, and erasure
- Data minimization — collect only what is necessary
App Store Compliance
Both Apple App Store and Google Play have health-specific review requirements:
Apple App Store:
- Apps that provide medical advice or diagnose conditions must be published by recognized institutions
- Apps referencing medical therapies must be from licensed healthcare professionals or organizations
- Privacy policy required and linked in app metadata
- HealthKit data cannot be sold to advertisers
Google Play:
- Health-related apps must comply with the Health apps policy
- Apps handling sensitive health data must implement appropriate security
- Data safety declarations are mandatory
- Medical device claims may trigger additional review
Building a Mobile Medical App: Step-by-Step Regulatory Strategy
Step 1: Define Intended Use Precisely
The single most important step. Document:
- Who will use the app (patients, clinicians, caregivers)
- What the app does (specific functions, not features)
- What claims you will make (marketing, app store description, website)
- What data the app collects and how it is used
Key insight: The FDA and EU regulators evaluate intended use based on all available evidence, including marketing materials, app store descriptions, website copy, social media, and user instructions. If your marketing makes medical claims, the app will be regulated as a medical device — even if your internal documentation says otherwise.
Step 2: Classify Under FDA and EU MDR
- Apply the FDA's function-based approach: Does the app meet the device definition? Does it pose patient risk?
- Apply the 2026 General Wellness criteria: Does the app qualify as a general wellness product?
- Apply the CDS criteria (if applicable): Does the app meet all four exclusion criteria?
- Apply EU MDR Rule 11: What class is the app under the MDR?
- Document the classification rationale for both jurisdictions
Step 3: Determine the Regulatory Pathway
- If the app is not a device: No premarket requirements (but document the rationale)
- If FDA enforcement discretion applies: No premarket submission needed, but maintain quality documentation
- If regulated by FDA: Choose 510(k), De Novo, or PMA based on classification and predicate availability
- If regulated under EU MDR: Engage a Notified Body (for Class IIa+) or self-certify (Class I)
Step 4: Implement the Quality Management System
- IEC 62304 for software lifecycle processes
- ISO 14971 for risk management (include mobile-specific risks)
- ISO 13485 for the quality management system (required for EU MDR, recommended for FDA)
- IEC 81001-5-1 for cybersecurity lifecycle
- IEC 62366-1 for usability engineering (mobile-specific usability considerations)
Step 5: Build Technical Documentation
| Document | FDA | EU MDR |
|---|---|---|
| Intended use / indications | Required | Required |
| Software requirements specification | Required (IEC 62304) | Required (IEC 62304) |
| Architecture design | Required (IEC 62304) | Required (IEC 62304) |
| Risk management file | Required (ISO 14971) | Required (ISO 14971) |
| Cybersecurity documentation | Required (SPDF, SBOM) | Required (IEC 81001-5-1) |
| Verification and validation | Required | Required |
| Clinical evaluation | If applicable | Always required (Article 61) |
| Usability evaluation | If applicable | Required (IEC 62366-1) |
| Declaration of Conformity | N/A | Required |
| Labeling / IFU | Required | Required (MDR Annex I) |
Step 6: Address Post-Market Requirements
| Activity | FDA | EU MDR |
|---|---|---|
| Adverse event reporting | MDR (MedWatch) | Vigilance system (Article 87) |
| Periodic safety reporting | Not typically required for Class II | PSUR (Article 86) |
| Post-market surveillance | Complaint handling, CAPA | PMS plan and report (Article 84-85) |
| Software updates | Design change control | Design change control + vigilance if needed |
| Cybersecurity monitoring | Ongoing vulnerability management | Ongoing vulnerability management |
| Registration and listing | Required | EUDAMED registration (from May 2026) |
Common Pitfalls and How to Avoid Them
1. Wellness Claims That Cross the Line
A blood pressure tracking app that simply displays readings is enforcement discretion territory. But add a feature that says "Your readings suggest hypertension — consult your doctor about medication options" and you have crossed into regulated territory. The fix: either stay within pure data display, or commit to the full regulatory pathway.
2. Ignoring EU MDR Requirements
Many mobile health companies launch in the US first and treat the EU as an afterthought. But the EU MDR sets a higher baseline — most mobile SaMD is at least Class IIa — and requires Notified Body involvement, ISO 13485 certification, and full clinical evaluation. Plan for both jurisdictions from the start.
3. Inadequate Cybersecurity Documentation
The FDA has been rejecting submissions with insufficient cybersecurity documentation since Section 524B took effect in March 2023. Mobile apps are particularly vulnerable because they use numerous third-party libraries, operate on untrusted networks, and store data on devices that can be lost or stolen. SBOM, threat modeling, and vulnerability management are not optional.
4. Marketing Claims Inconsistent with Classification
Your internal documents say "wellness only" but your website says "detects early signs of heart disease." Regulators evaluate the totality of evidence. Ensure consistency across all channels: website, app store listings, social media, press releases, user manuals, and internal documentation.
5. Treating Software Updates as Minor
Every software update to a regulated mobile app must be evaluated through the design control process. An update that changes the algorithm, adds new functionality, or modifies the intended use may require a new premarket submission. Establish clear SOPs for evaluating change impact before release.
Key Takeaways
Intended use drives everything: The FDA regulates based on what your app does and claims to do, not the platform it runs on.
The 2026 guidances expand flexibility but add guardrails: The updated General Wellness and CDS guidances broaden the scope of products eligible for enforcement discretion, but the boundary between wellness and medical device remains strict.
Patient-facing CDS is always regulated: Unlike HCP-facing CDS tools that may qualify for exclusion, patient-facing mobile apps that provide diagnostic or treatment recommendations are regulated devices.
EU MDR sets a higher bar: Plan for EU compliance from the beginning. Most mobile SaMD is Class IIa or above in the EU, requiring Notified Body assessment and full quality management.
Cybersecurity is non-negotiable: Section 524B, the FDA cybersecurity guidance, and EU MDR GSPR requirements all demand robust cybersecurity documentation, SBOM, and vulnerability management.
Document your classification rationale: Whether your app is regulated, subject to enforcement discretion, or not a device — document the decision and the evidence supporting it. This is your first line of defense in any regulatory inquiry.
Sources and Further Reading
- FDA Policy for Device Software Functions and Mobile Medical Applications (September 2022)
- FDA General Wellness: Policy for Low Risk Devices (January 2026, updated)
- FDA Clinical Decision Support Software (January 2026, updated)
- FDA Content of Premarket Submissions for Device Software Functions (June 2023)
- FDA Cybersecurity in Medical Devices (June 2025, updated February 2026)
- CDRH Proposed Guidances for Fiscal Year 2026 — includes planned update to "Policy for Device Software Functions"
- EU MDR 2017/745, Annex VIII, Rule 11
- MDCG 2019-16: Guidance on Cybersecurity for Medical Devices
- IEC 62304: Medical Device Software — Software Lifecycle Processes
- IEC 62366-1: Usability Engineering for Medical Devices
- 21st Century Cures Act, Section 3060