Achieve Regulatory Compliance by Improving Security for Your SaMD Apps

Mobile health (mHealth) app use is exploding around the world. In 2024, 43% of the United States used mHealth apps in some fashion; in India use was as high as 70%. And there’s still room for growth: by 2032, the market is expected to be worth almost 90 billion dollars. The rise of smartphones globally also presents ample opportunity: in 2022, smartphone penetration of mHealth apps was only 76%. This is projected to rise to 92% in 2030.

Millions of patients rely on mHealth applications to track key health metrics. Some common uses include glucose monitoring, medication reminders, and help managing chronic conditions. Medical device manufacturers now offer apps that sync with patient devices and act as a medical device itself. Patients can download these apps on their phones to easily monitor and share vital data with their care provider. The FDA terms these apps as “Software as a Medical Device”, abbreviated as SaMD. The International Medical Device Regulators Forum defines SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." The IMDRF has a complete guide with more information about the definition of a SaMD and its associated use cases.

These revolutionary medical innovations dramatically improve the quality of patient care. Yet, while these innovations are exciting, they are not risk-free. A great deal of sensitive patient information is being stored and exchanged via these applications. Additionally, many SaMD applications have built-in integrations with other components of the healthcare system. Thus, SaMD app developers must meet strict regulations and compliance requirements, like what’s demanded of healthcare providers to ensure the safety and privacy of patients using their apps.

Some example regulations include FDA healthcare requirements in the US or EU-MDR regulations in the EU. The risk of sabotage or tampering is specifically mentioned in section D.3.2.3 of EU-MDR regulations. This requirement gives guidance to assess unforeseen risks that cannot be estimated based on harm alone, and only applies to SaMD. Therefore, proper security controls must be implemented to drastically reduce risk probability as much as possible. Developers of SaMD apps are advised to install strong security measures throughout the SDLC to mitigate risk as much as possible, like the risk of tampering threats from malicious actors.

For the best defense against outside threats such as these, developers must keep security in mind throughout the development lifecycle. Incorporating security into development alleviates compliance challenges and offers a multitude of benefits. We’ll go through in detail what proper security measures look like, how to implement them, and why they’re important to achieving compliance goals.

Which mHealth apps require regulatory approval?

Not all mHealth apps are created equal. For instance, a calorie tracking app on your smartphone is not the same as a glucose monitoring app for a diabetic patient that syncs with the data provided by the glucose monitor itself. Thus, the FDA and other regulations, like EU-MDR, treat both very differently when it comes to regulatory requirements and enforcement.

You might think ALL mHealth apps that handle personal data and have access to personal health records are subject to regulatory approval. Surprisingly, this is not the case.

In general, the FDA regulates a small subsegment of mHealth apps, which are medical devices. SaMD apps that must meet FDA approval requirements include apps that meet the definition of a medical device or pose a risk to patient safety. One example is FibriCheck, which uses the camera of your smartphone to detect heart rhythms and identify any irregularities. FDA approval is also required for apps that are an accessory to regulated medical devices, like SaMD mobile apps.

A recent SaMD success story is Dexcom, the first FDA-approved over-the-counter glucose monitor. Dexcom pairs its glucose monitor with an app that can be downloaded on user’s smartphones to monitor and track their glucose levels. Because Dexcom’s glucose monitor and app adhere to FDA regulations, patients can feel confident in the safety and efficacy of Dexcom’s technology as well as the security of Dexcom’s associated mobile application when storing their personal data.

Each type of app referenced above requires strong security measures to be in place to ensure the data provided, collected, and transmitted by the application and / or embedded technology in the app is secure. In order for these apps to hit the market, regulatory bodies like the FDA or EU lay out specific security requirements they must meet.

What are the regulatory requirements for SaMD applications?

Strict requirements outlined by regulatory bodies like the FDA must be met by SaMD developers prior to going to market and maintained afterwards. This is not limited to just the FDA. EU-MDR and other regulatory agencies and regulations lay out specific requirements that SaMD publishers must comply with in order to go to market in their respective regions. Some relevant examples are:

IEC 62304

An international standard regarding medical software development, including SaMD. It details lifecycle requirements when developing medical software and SaMD, and includes a framework that outlines software development, validation, and maintenance.

ISO 13485

The international standard for a Quality Management System (QMS) when designing and manufacturing medical devices. To comply, an SaMD developer must demonstrate successful implementation of an effective QMS. This includes a continuous improvement process as well as meeting customer and regulatory requirements for SaMD certification.

ISO 14971

This international standard outlines proper risk management application to medical devices, including SaMD. It includes a framework to identify potential hazards, risk estimation and evaluation, and implementing risk controls.

ISO 27001

The international standard for an Information Security Management System (ISMS). This is particularly important to SaMDs that deal in sensitive health data. The standard assists organizations in managing asset security, including financial information, IP, and employee data (login credentials, etc.).

IEC 62366

The process for usability engineering in medical device development. For SaMD developers, it highlights how to optimize interactions between a system and its users, which directly impacts software efficacy and safety.

Complying with these regulatory standards is an absolute must. Not doing so represents significant consequences for SaMD developers. Yet, significant roadblocks exist in the mHealth app development process that delay compliance. The following section discusses in detail the specific consequences of not achieving compliance, as well as the challenges facing mHealth app publishers.

Consequences of not achieving compliance

Significant penalties exist for applications that do not achieve compliance with regulatory bodies. Fines are steep, financially damaging, and grind development cycles to a halt. According to the FDA, app publishers can be fined up to $15,000 for each violation found, and multiple violations can be pursued simultaneously. There are similar financial penalties for failure to meet EU-MDR compliance requirements, including product recalls and even legal action.

App development for these healthcare applications is extremely costly and time consuming. The compliance strategy has to be well thought-out and present at each stage of development. Any delays or regulatory roadblocks will not only increase costs, but also negatively impact time to market. Innovation evolves at a rapid pace in this industry. Every second counts and to be late to market due to regulatory delays is a bitter pill to swallow with damaging ripple effects.

SaMD developers cannot ignore the consequences of poor security posture and lack of compliance either. The healthcare industry remains the industry with the highest cost of a data breach, averaging $9.77 million in 2024. But it’s not just the financial repercussions of the data breach itself. The damage to brand reputation cannot be overstated. Applications that experience breaches experience the ire of their customers and lose trust from the market. These effects are much longer lasting and more difficult to recover from.

Challenges to achieving regulatory compliance

SaMD developers continue to face expanding and increasingly strict regulatory requirements. The evolving regulatory environment presents unique challenges that must be tackled head on. Recently, the National Library of Medicine conducted a systematic review of the challenges that face mHealth app developers. The review identified nine primary challenges facing mHealth app developers based on an analysis of 32 primary studies published between 2008 and 2020.

Overall, the top challenge facing developers was lacking security guidelines and regulations regarding secure mHealth app development. A complex regulatory landscape with a myriad of regulations can be quite cumbersome to the development process. Thus, the importance of a well-communicated compliance strategy cannot be overstated.

The second most common challenge was developers not possessing the knowledge nor expertise required to develop secure mHealth apps. It takes a great deal of expertise to develop mHealth and, specifically, SaMD applications. However, the skillset is not a 1:1 transfer to developing security protections. A solution that can make security an integrated part of the development process will greatly ease the burden facing these developers.

Rounding out the top three was a lack of stakeholder involvement during the development process. For strong security posture, it’s critical that a clear line of communication is established early in development between security analysts and software engineers. Without a streamlined method of communication, discrepancies will exist and manifest setbacks to development.

Are mHealth apps secure?

Threat actors and the necessity for mobile app protection are not exclusive to mHealth or SaMD app developers. Healthcare app security should be a top priority for developers. What is unique to mHealth and SaMD apps is the type of data they store and handle. mHealth apps store personal identifiable information (PII) and protected health information (PHI), which is protected by laws like HIPAA or GDPR. This sensitive data is part of what makes mHealth apps a ripe target for malicious actors.

These organizations must combat a wide range of threats and security risks. The National Library of Medicine conducted a study to analyze the security risks of 20,000 mHealth apps on the Google Play Store. Among the most impactful security risks were unencrypted communication (45% of apps), sending personal data on unsecured traffic (23%), and packaging suspicious codes (1.8%). All of these practices pose substantial risks to users of these apps and to the app publishers themselves. But there are measures to identify risks, increase app resilience and strengthen security posture.

The STRIDE framework

The FDA recommends the STRIDE threat modeling framework for SaMD app developers to segment security risks, and features it in the FDA’s playbook for threat modeling in medical devices. Both resources give organizations a practical guide to help ease the burden of compliance and mitigate security risks. Below is a description and application of the STRIDE framework letter by letter.

Spoofing

The act of spoofing is defined as deceiving a system into identifying a falsified entity as a true entity. Think of it as using another’s login credentials to gain access into a healthcare system the perpetrator normally would not be able to access.

Tampering

Tampering is a persistent and significant security risk for mobile applications, especially in mHealth apps. When a system or environment is intentionally modified to change its intended behavior without authorization, that is considered tampering. The rise of telehealth has exposed new tampering risks, such as chat functions with medical providers. Communication functions within the app can be maliciously manipulated, which may cause patient harm. Because tampering is easier to scale than other types of attacks, it is quite difficult to reign in once it has begun. Shifting security left in the development lifecycle, ideally at the beginning of app development, builds tampering protections into the application right at the start.

Repudiation

Bad actors may manipulate an app so it disputes the authenticity of actions taken by its users. For example, an app that contains prescription order information can be manipulated to deny a prescribed treatment has been transmitted to the patient. This poses a serious medical risk to patients treating all kinds of conditions and can become life-threatening.

Information Disclosure

Data leaks and breaches are, unfortunately, all too common in the healthcare industry. Many reasons exist as to why, but poor healthcare app security measures are a common denominator. The HIPAA journal identified in a 2024 report that 58 million patients had their records exposed through August. Insecure data storage practices are a main culprit for these breaches, which have plagued the healthcare industry since 2020.

Denial of Service (DoS)

Malicious actors will often deploy malware to facilitate distributed denial of service (DDoS) attacks. DDoS blocks legitimate access or system functionality from the organization and users. By deploying these attacks, bad actors can declare a ransom in order to grant access back. The Health Sector Cybersecurity Coordination Center noticed in Q1 of 2023 that ransom DDoS attacks are increasing their frequency, growing by 24% quarter-over-quarter and 67% year-over-year.

Elevation of Privilege (EoP)

Individuals carrying out mobile attacks will grant themselves access to functions that would normally be prevented by security protocols. In relation to mHealth apps, a threat actor may grant themselves administrator status to access all patient data records, including PII and PHI, financial information, etc.

Security controls for mHealth application protection

Organizations inside and outside mHealth must incorporate security controls to boost protection against threats and mitigate risks. Some controls exist to primarily protect the flow of information into and out of the app. Others examine and protect the code of the app itself. The best approach is a multi-layered mobile app protection strategy. We’ll dive into some specific measures below.

Mobile application security testing

Mobile Application Security Testing (MAST) tools perform tests that measure security risks and identify app vulnerabilities prior to release. Security testing throughout the development lifecycle gives developers actionable insights into security risks and dependencies, like improper credential usage or inadequate privacy controls. These are two of the risks featured on the OWASP Mobile Top 10, a list of the top ten security risks facing mobile apps, including SaMD applications.

MAST tools like AppSweep integrate directly with developer tools like Github so teams can practice CI/CD workflows. By leveraging these tools developers are able to shift left security development and implement protections for known and unknown vulnerabilities prior to publishing their apps. As a result, malicious actors are never given the chance to exploit these weaknesses.

Code hardening & Obfuscation techniques

Static analysis is the examination of an app’s resources and source code. Threat actors will use static analysis to analyze the source code of an application. These actors will use tools like decompilers to unlock the internal logic of your application in order to steal sensitive information, like PII, or to extract login credentials. Once the logic is unlocked, threat actors have the ability to reverse engineer your application or gain access to tertiary systems.

Code hardening is a layer of protection against static analysis to prevent these negative outcomes. There are several popular techniques and practices to implement code hardening. Some common examples include code virtualization, call hiding your API keys, and code obfuscation.

Code obfuscation hides the internal logic of your app’s code from bad actors. Classes, fields, and entire libraries are renamed, among other actions, to conceal the code. Essentially, the code becomes randomized, significantly increasing the difficulty for malicious actors attempting to tamper with your code.

Runtime application self-protection (RASP)

On the other side of static analysis is dynamic analysis. Dynamic analysis examines the app’s behavior during runtime. Jailbreaking, hooking, and rooting are common examples of dynamic attacks on your application. Threat actors will use these techniques to intercept communication to servers, steal decryption keys, and more. For complete mobile app protection, an application requires strong defenses against both static and dynamic analysis.

A key component of protecting against dynamic analysis is runtime application self-protection (RASP) checks. RASP checks prevent app tampering during runtime by monitoring both the app and the environment it runs within. RASP checks are injected into the application for specific detection of malicious actions. Some example detections that might be implemented via RASP checks are jailbreak detection, debugger detection, repackaging detection, code tracing detection, and hook detection.

The RASP checks will identify these threats and take pre-programmed actions set by the app developer. For instance, if a jailbreak attempt is detected, the application can be set to respond accordingly with a range of responses. An example of the most significant response would be automatically crashing the session, immediately preventing any negative outcomes from being achieved by the threat actor.

Real-time threat monitoring

Implementing security into your code during the development lifecycle is essential to strong mobile app protection. But what about after your app is released? This is where threat monitoring tools come into play.

Threat monitoring increases security posture by monitoring your application for threats like hooking or jailbreak detection amongst your userbase across different geos, app versions, and devices. These tools include vital metadata with each threat to understand the full context and make it easier to know the appropriate course of action to remediate the threat. Tools like ThreatCast deliver real-time custom alerts and notifications when a breach does occur. Security and development teams alike are able to leverage threat monitoring solutions to streamline communication against threats, stay vigilant, and take action in real-time.

How a leading SaMD developer meets regulatory compliance

A leading SaMD developer came to Guardsquare with the challenges outlined earlier in this blog. This SaMD developer specialized in developing Android and iOS apps for medical devices and their connected systems. Thousands of patients across various clinical domains rely on their applications. Facing strict regulatory requirements and lacking a standardized security solution, they were in search of a tool that would meet their compliance needs. The tool also needed to be easy to implement and protect sensitive patient data.

The SaMD developer understood that poor app security could expose their patient’s sensitive data, threatening their privacy and wellbeing. In extreme instances, it could even become life threatening. Thus, the app developer required that the solution offered robust security protection of their apps and SDKs, particularly against reverse engineering and tampering.

During their examination of different solutions, the development team discovered DexGuard and iXGuard. Both tools offer advanced code obfuscation, which the SaMD found invaluable for protecting their assets and sensitive data against tampering and reverse engineering. These advanced code hardening and code obfuscation techniques supported consistent and reliable operations.

The company also leveraged the built-in RASP checks in DexGuard and iXguard to protect their apps from dynamic analysis. By implementing RASP checks, the mHealth app developer protected their app from attackers using debuggers, code tracing tools, or hooking frameworks.

After installing DexGuard and iXGuard, the SaMD developer was able to stay multiple steps ahead of attackers, thanks to multi-layer polymorphic protection. This technique gives each app build different code hardening and RASP configurations. RASP checks are also placed in different locations, significantly increasing the difficulty for attackers to break into the app. Attackers are unable to leverage prior knowledge to facilitate attacks. Essentially, the clock resets each time an attack is attempted.

And, because they were able to build a comprehensive, more holistic protection strategy, the SaMD developer eliminated redundant and less effective security tools. In the Chief Solutions Officer’s own words, “we’re able to stay on top of cornerstone regulatory mandates from the FDA such as 13485, 62304 and HIPAA (as well as emerging guidance) and, European Union such as GDPR & EU-MDR, without compromising performance”.

Take the first steps towards meeting SaMD regulatory compliance

Mobile health applications represent a market full of innovation and opportunity. But with that opportunity comes significant risks. mHealth app providers, particularly those developing SaMD apps, must remain vigilant and steadfast when it comes to protecting their apps and patient data. They also cannot afford to lose their focus on meeting strict compliance regulations in a fast-moving landscape.

A comprehensive approach that offers complete protection and integrates into each stage of the development lifecycle is the best path forward. Not only does such an approach streamline communication, it also eases the regulatory burden that faces SaMD app developers.

To learn more about complete mobile app protection from Guardsquare and how its products can assist you in meeting your regulatory needs, speak with our mobile app security experts today.