The pilot with the regional health system is nearly signed. Then their security team sends over the vendor assessment, and two questions stop the room. “Describe the security testing performed on your mobile applications in the last 12 months.” And: “Provide evidence that PHI is protected at rest and in transit on the device.”<\/p>\n
Your team knows the app is reasonably secure. What you do not have is evidence: no test reports, no record of what was found and fixed, no map of where patient data actually goes once it reaches a phone. The pilot slips a quarter while you assemble it.<\/p>\n
HIPAA does not hand you a mobile testing checklist, which is why so many health tech teams get caught here. This guide covers what the Security Rule actually expects, where PHI tends to leak in iOS, Android, Flutter, and React Native apps, how to test for it, and how to produce the evidence that partners and auditors ask for.<\/p>\n
This article is practical security guidance, not legal advice. Work with qualified counsel on your specific HIPAA obligations.<\/em><\/p>\n HIPAA applies to covered entities (health plans, health care clearinghouses, and most providers) and to their business associates: vendors that create, receive, maintain, or transmit protected health information on their behalf. If your app is offered to patients through a provider or health plan, or handles their PHI under contract, you are very likely a business associate and you will be signing BAAs.<\/p>\n If your app is direct-to-consumer and not working on behalf of a covered entity, HIPAA may not apply at all. That does not mean you are unregulated. The FTC’s Health Breach Notification Rule, amended in 2024, explicitly covers many health apps that fall outside HIPAA, and state privacy laws add their own requirements. The security work in this guide is the same either way. What changes is who you answer to.<\/p>\n The HIPAA Security Rule is deliberately technology-neutral. It never mentions mobile apps, certificate pinning, or Keychain. Instead, it sets safeguards and expects you to implement them based on your own risk analysis. For a mobile app, the most relevant pieces are:<\/p>\n Risk analysis<\/strong> (45 CFR 164.308(a)(1)(ii)(A)): an accurate and thorough assessment of the risks to the confidentiality, integrity, and availability of ePHI. Your mobile app is part of that system, and so is every device it runs on.<\/p>\n Evaluation<\/strong> (164.308(a)(8)): periodic technical evaluation of whether your safeguards still work. Security testing is the most direct way to show this.<\/p>\n Access control<\/strong> (164.312(a)(1)), including encryption and decryption of ePHI as an addressable specification.<\/p>\n Audit controls<\/strong> (164.312(b)), integrity<\/strong> (164.312(c)(1)), and person or entity authentication<\/strong> (164.312(d)).<\/p>\n Transmission security<\/strong> (164.312(e)(1)): protecting ePHI as it moves over networks.<\/p>\n “Addressable” does not mean optional. It means you must implement the safeguard or document why an equivalent alternative is reasonable. For PHI on a mobile device, it is very hard to justify not encrypting.<\/p>\n HHS has also proposed a significant update to the Security Rule. The proposal would require vulnerability scanning at least every six months, penetration testing at least annually, and would remove the addressable distinction for encryption in most cases. As of mid-2026, final action has been pushed back to 2027 at the earliest, so the current rule remains in force. Building those testing habits now means you are ready whichever way the final rule lands, and it is already what health system security teams expect to see.<\/p>\n OWASP MASVS gives you a concrete way to turn those safeguards into testable requirements. In health apps, the same leak points come up again and again.<\/p>\n Lab results, visit notes, and images cached in plain key-value stores<\/a>, SQLite databases, or files without platform data protection. This maps to MASVS-STORAGE-1 and CWE-312. On iOS, check data protection classes. On Android, check where files are written and whether they are encrypted with Keystore-backed keys.<\/p>\n Full API responses printed during development and never removed. In Flutter, On both platforms, app data can be included in device or cloud backups unless you exclude it. PHI that leaves the device this way is outside every control you designed.<\/p>\n Sensitive screens captured in the app switcher snapshot, in screenshots, or in screen recordings. Push notifications that put a diagnosis or a lab value on the lock screen. These fall under MASVS-PLATFORM-3. Notification content is often set server-side, so test the whole flow, not just the app.<\/p>\n Weak TLS configuration, or certificate validation disabled “temporarily” for a staging environment and shipped to production. This maps to MASVS-NETWORK-1, CWE-295, and directly to the transmission security standard.<\/p>\n Analytics, attribution, and session replay SDKs<\/a> that receive PHI because a developer passed a patient object into an event. If a vendor receives PHI and has no BAA with you, that is a compliance problem on top of a security one.<\/p>\n Here is a pattern that shows up in reviews of Flutter apps using Dio. It looks like ordinary development scaffolding:<\/p>\n Accepting every certificate means anyone positioned on the network, such as a hostile Wi-Fi hotspot, can intercept lab results in transit. The log interceptor writes the same PHI to the device log on every request.<\/p>\n The fix keeps platform TLS validation on and stops PHI from ever reaching logs:<\/p>\n If staging needs a private certificate authority, trust it through build-specific platform configuration (an Android network security config for debug builds, for example), not by disabling validation in shared code. Then add a CI rule that fails the build if You can make real progress without new tooling. Here is a sequence that produces both better security and the evidence you will be asked for.<\/p>\n Map where PHI goes.<\/strong> Follow each type of PHI from the API to the screen: what the app stores, caches, logs, displays, sends in notifications, and passes to SDKs. This map is the backbone of your risk analysis, and you will reuse it in every vendor assessment.<\/p>\n Run static analysis on every platform.<\/strong> Scan Swift, Kotlin, Dart, and JS\/TS code for insecure storage, disabled certificate validation, logging of sensitive fields, and hardcoded credentials. Map findings to MASVS controls so they translate into the language auditors use.<\/p>\n Test the running app.<\/strong> Install a release build on a test device, proxy its traffic, and confirm TLS is enforced. Inspect the app’s sandbox after a normal session for PHI in files, databases, and preferences. Check the app switcher snapshot, screenshot behavior on sensitive screens, and what notifications show on a locked device.<\/p>\n Check your dependencies and SDKs.<\/strong> Inventory third-party components, check them for known vulnerabilities, and confirm which ones receive data. Any vendor that could receive PHI needs either a BAA or a code change that stops the data from reaching it.<\/p>\n Test your APIs.<\/strong> The mobile app is only the front door. Check that APIs enforce authorization per patient record, since broken object level authorization is one of the most common ways health data is exposed.<\/p>\n Pentest at least annually and after major changes.<\/strong> Automated testing finds a lot. An experienced tester finds the logic flaws and chained issues that scanners do not, and a pentest report is the single piece of evidence partners ask for most often.<\/p>\n Keep the evidence.<\/strong> Save scan reports, pentest reports, remediation records with dates, and documented risk acceptance decisions. Retain HIPAA-related documentation for six years, as the Security Rule requires. The goal is that the next vendor assessment takes an afternoon, not a quarter.<\/p>\n A one-time assessment before the big pilot is achievable. Repeating it on every release is not, for most teams. A Series A health tech company ships often, across two or more platforms, with one or two people who own security alongside everything else. Testing slips between releases, PHI leaks are introduced in screens nobody re-reviews, and the evidence folder goes stale right when the next partner asks for it.<\/p>\n Nandee is an AI Mobile Application Security Engineer built for exactly this kind of continuous testing.<\/p>\n Test every release.<\/strong> Nandee runs SAST, DAST, and SCA\/OSS analysis across native iOS, native Android, Flutter, and React Native apps, along with API scanning and privacy analysis to surface where sensitive data flows. CI\/CD integrations make testing part of how you ship rather than a project before each audit.<\/p>\nFirst, Does HIPAA Apply to Your App?<\/h2>\n
What the Security Rule Actually Requires<\/h2>\n
Where PHI Leaks in Mobile Apps<\/h2>\n
Local storage and caches<\/h3>\n
Logs and crash reports<\/h3>\n
debugPrint<\/code> still writes in release builds. Logs then flow into crash reporting tools, which become an unplanned PHI processor. This is MASVS-STORAGE-2 and CWE-532.<\/p>\nBackups<\/h3>\n
The screen itself<\/h3>\n
Network traffic<\/h3>\n
Third-party SDKs<\/h3>\n
A Common Finding in Flutter Health Apps<\/h2>\n
\/\/ Vulnerable: certificate validation disabled (CWE-295) and full\n\/\/ request and response bodies logged in every build (CWE-532).\nimport 'dart:io';\nimport 'package:dio\/dio.dart';\nimport 'package:dio\/io.dart';\n\nDio buildApiClient() {\n final dio = Dio(BaseOptions(baseUrl: 'https:\/\/api.clinic.example.com'));\n\n dio.httpClientAdapter = IOHttpClientAdapter(\n createHttpClient: () {\n final client = HttpClient();\n \/\/ Added to get past the staging certificate. Never removed.\n client.badCertificateCallback = (cert, host, port) => true;\n return client;\n },\n );\n\n dio.interceptors.add(LogInterceptor(requestBody: true, responseBody: true));\n return dio;\n}<\/code><\/pre>\nimport 'package:dio\/dio.dart';\nimport 'package:flutter\/foundation.dart';\n\nDio buildApiClient() {\n final dio = Dio(BaseOptions(\n baseUrl: 'https:\/\/api.clinic.example.com',\n connectTimeout: const Duration(seconds: 10),\n ));\n\n \/\/ No custom HttpClient and no badCertificateCallback: default\n \/\/ certificate validation applies. Use a properly trusted certificate\n \/\/ for staging instead of disabling checks in code.\n\n if (kDebugMode) {\n \/\/ Debug builds only, and only method, URL, and status. Never bodies or headers.\n dio.interceptors.add(LogInterceptor(\n requestHeader: false,\n requestBody: false,\n responseHeader: false,\n responseBody: false,\n ));\n }\n return dio;\n}<\/code><\/pre>\nbadCertificateCallback<\/code> appears anywhere in the codebase.<\/p>\nHow to Test a Health App for HIPAA Readiness<\/h2>\n
Why This Is Hard to Sustain<\/h2>\n
How Nandee Helps Health Tech Teams Stay Ready<\/h2>\n