See for yourself – run a scan on your code right now

Healthcare providers increasingly use mobile apps and web applications as part of the move to telemedicine. As of July 2021, analyst McKinsey noted that telehealth utilization had stabilized at levels 38 times higher than before the COVID pandemic. Additionally, McKinsey pointed out that investment in virtual care and digital health fueled innovation, finding that venture capital firms tripled investments in digital health technologies in 2020 as compared to 2017. The emphasis on telehealth brings security challenges. Many healthcare-focused apps provide mobile and web facing interfaces. If you’re a developer creating a digital health technology, then you need to make sure that your app meets the HIPAA compliance requirements.

What does HIPAA compliance for health applications mean for developers?

The Healthcare Insurance Portability and Accountability Act (HIPAA) set out the standards for managing Protected Health Information (PHI). Fundamentally, the HIPAA Security Rule sets the stage for the safeguards that protect PHI. The Health Information Technology for Economic and Clinical Health (HITECH) Act applied these safeguards to electronic health record (EHR) technology.

As web and mobile apps became the norm, the Department of Health and Human Services (HHS) published a 2016 guidance around health applications.

How much does it cost to develop a HIPAA-compliant app?

If an app is developed to create, receive, maintain, or transmit ePHI on behalf of a covered entity or was provided by or on behalf of a covered entity, then the software company becomes a business associate.

Problematically, HIPAA’s Security Rule Safeguards create extra work for developers. According to research from 2019, the average cost of developing an enterprise mobile app falls anywhere between $100,000 and $500,000.

While securing all applications is important, the potential for HIPAA fines makes it even more mission-critical when developing mobile health (mHealth) apps that fall under the law. This means that developers need to take additional precautions to protect themselves and their companies.

5 tips for developing HIPAA-compliant apps

If you’re developing an mHealth app, you need to make sure that you have all the appropriate technical safeguards in place to mitigate risk and ensure compliance.

Review access controls

Fundamental to any application is establishing strong access controls. The access controls need to include:

  • Unique user identification: each user has their own name/number for logging into the application and being tracked
  • Automatic logoff: applications must have a “timeout” that terminates a session after a certain amount of time
  • Apply principle of least privilege: applications sharing patient information must provide the appropriate permissions limitation so that any people or entities receiving ePHI can only access what they really need

Ensure appropriate patient authentication

As you build out your application, you need to make sure that you put the appropriate patient authentication controls in place. Since malicious actors target ePHI, simply requiring a username and password may not be enough.

Your app must incorporate multi-factor authentication, including at least two of the following options:

  • Password or Personal Identification Number (PIN)
  • Biometrics (face ID, fingerprint)
  • Object (token, smartphone)

Apply encryption

Encryption for HIPAA-compliant apps includes both data-in-transit and data-at-rest.


For data-in-transit, your app should encrypt data using SSL/TLS. Best practices would be to use HTTPS protocol for all communications. However, at minimum, you should apply SSL/TLS to the following:

  • Registration pages
  • Pages containing ePHI
  • Authorization cookies


Because mobile apps store data on both a cloud server and the user’s device, you need to make sure that any mobile app also encrypts data-at-rest.

To protect data that your app stores locally, you need to apply 256-bit AES encryption.

Focus on the OWASP Top 10 Web Application Security Risks

Most mobile healthcare apps also have a web interface. If you’re building an mHealth app and plan to have a web app as well, you need to mitigate the OWASP Top Ten Web Application Security Risks which are:

  • Broken Access Control
  • Cryptographic Failures
  • Injection
  • Insecure Design
  • Security Misconfiguration
  • Vulnerable and Outdated Components
  • Identification and Authentication Failures
  • Software and Data Integrity Failures
  • Security Logging and Monitoring Failures
  • Server Side Request Forgery

Validate security

Building security into your software development lifecycle (SDLC) is fundamental to creating a HIPAA-compliant mHealth app. A primary way to ensure continued security as part of the SDLC is to go through the code review process, including source code.

If you’re designing a health application, you first need to know the most common vulnerabilities used to undermine security. This means knowing the indicators and signatures of those vulnerabilities so that you can identify them in your code.

A lot of teams are taking a DevSecOps approach to building mHealth apps. With DevSecOps, you build security directly into your processes. Usually, it includes embedding security into all areas of the SDLC by incorporating technology, automation, and optimization.

By continuously reviewing code for potential security vulnerabilities, you can prevent many from going to production. It’s important to keep in mind that not only must your app be HIPAA-compliant, but you must be as well. If you’re continuously validating security as part of your regular cycles, then you’re able to meet other HIPAA requirements, like those under the Administrative Rule.

Securing the Application Development Life cycle to Meet HIPAA Compliance Requirements

HIPAA compliance — both for your app and for your team — is hard. It’s also incredibly important to protect users of the app, and your organization’s financial security. A HIPAA violation can cost anywhere from $100 at the low end to upwards of several million dollars.

With ShiftLeft’s Next-Gen SAST (NG-SAST), you can easily build security directly into your development processes. Our NG-SAST gives you a way to efficiently uncover potential risks with real-time code analysis. Our Intelligent Software Composition Analysis (SCA) also gives you a way to scan for attacker exploitability. This means that you reduce the number of false positives so that you can focus on the vulnerabilities that pose the greatest risk, and more efficiently meet your SLAs.

ShiftLeft CORE gives you a single platform for both AppSec and Dev deployment cycles. You can complete tests in minutes, including static analysis, software composition analysis, and secrets detection.

To learn more about securing web facing applications to meet HIPAA compliance requirements, visit the ShiftLeft secure coding training site for free courses.

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit:


See for yourself – run a scan on your code right now