HIPAA Security for HealthTech: How to Protect ePHI from a Single Compromise
TL;DR: If your platform creates, receives, maintains or transmits health information on behalf of a Health-related entity, HIPAA may apply to you. Preparing for stronger Security Rule expectations by covering the basics will end up costing more. Instead, design your system so no compromised component is enough to expose ePHI.
The US Department of Health and Human Services (HHS) is moving toward more explicit, testable cybersecurity requirements. Health platforms will need to strengthen MFA, encryption, asset maps, testing and audits. That raises the bar, but it does not remove the core catastrophic failure path.
If one trusted component can impersonate a user, change policy or recover plaintext, one compromise can still become an ePHI breach. That is the gap worth closing before the next rule, or attacker, forces another policy redesign.
TideCloak is an Identity, Access, and Authority Management (IAAM) solution designed to move critical authority out of the reach of any single administrator, server, cloud provider or vendor (itself included) to protect PHI from data breaches.
What is Protected Health Information (PHI)?
Protected Health Information (PHI) is broader than most engineering teams assume.
Protected Health Information is any information about a person's health status, health care, or payment for health care that's created, received, stored, or transmitted by a HIPAA-covered entity or its business associates, and that can be linked back to a specific individual.
It's a subset of personally identifiable information, but specifically the kind tied to health records or health services.
HIPAA defines 18 identifiers that turn ordinary information into PHI the moment it's connected to health data:
- Names,
- Geographic details smaller than a state,
- Dates other than year,
- Phone
- Fax numbers,
- Email addresses,
- Social Security numbers,
- Medical record numbers,
- Health plan numbers,
- Account numbers,
- License numbers,
- Vehicle identifiers, serial numbers, such as licence plate numbers
- Device identifiers, serial numbers
- Uniform Resource Locators (URL),
- Internet Protocol (IP) addresses,
- Biometric identifiers,
- Full-face photos,
- Any other unique identifying code.
What is not Protected Health Information (PHI)
Data that can't identify a patient, employment records held by a healthcare organization acting as an employer rather than a provider, and information about someone who has been deceased for more than 50 years is not considered PHI.
Encryption alone does not de-identify a dataset, if the decrypted data still contains the original identifiers.
De-identified or anonymized data (with the above 18 identifiers stripped and a low re-identification risk validated by a statistician) conforms to HIPAA’s Safe Harbor de-identification requirements and falls outside PHI, which is why it can be used for research in ways identified data can't.
What is Electronic Protected Health Information (ePHI)
Electronic PHI, or ePHI, is the same thing as PHI, when it's created, stored, or transmitted electronically, which covers most modern health technology, such as:
- Patient portals,
- Scheduling apps,
- Electronic Health Record (EHR) systems,
- Even a support ticket that references a patient by name.
If your software product provides a service to a covered entity and touches any of that data, you're very likely a business associate under HIPAA regardless of whether you think of yourselves as a health tech company, and you carry similar legal exposure.
PHI is what triggers HIPAA's Privacy Rule (governing use and disclosure) and Security Rule (governing technical, physical, and administrative safeguards), and it's what turns a routine data exposure into a reportable breach with real penalties attached.
What does this mean for HealthTech companies?
The Health Insurance Portability and Accountability Act of 1996 (HIPAA), mandates that Covered Entities implement security controls to protect the confidentiality, integrity, or availability of that information.
Covered entities include hospitals, doctors, health plans, insurers, clearinghouses, and their business associates - such as HealthTech companies or software companies who build software for the Health industry.
Does HIPAA apply to your platform?
HIPAA does not apply to all health data. A software vendor may be a business associate when it creates, receives, maintains or transmits PHI on behalf of a covered entity or another business associate.
For example, a database entry that just says "patient took drug X" isn't PHI on its own, but the moment it's linked to a name, an email, or even just an IP address, it becomes PHI.
Patient portals, cloud storage, remote monitoring and provider-supplied apps can fall within that definition. Some direct-to-consumer wellness apps may not, although other laws can still apply.
A practical self-assessment:
- Are we serving a covered entity or business associate?
- Do we handle individually identifiable health information for that customer?
- Are we doing so on the customer’s behalf?
If the answer is yes, assess your business associate agreements, subcontractors and the full Privacy, Security and Breach Notification obligations against the regulations - not only your technical safeguards.
Should you invest in controls to prevent data breaches of PHI?
For HIPAA violations, civil penalties are tiered by culpability, not by company size.
As of the January 2026 update:
- Tier 1 (violation you were unaware of and couldn't reasonably have avoided) runs $145 to $73,011 per violation.
- Tier 2 (reasonable cause, not wilful neglect) is $1,461 to $73,011 per violation.
- Tier 3 (wilful neglect, but corrected within 30 days) is $14,602 to $73,011 per violation.
- Tier 4 (wilful neglect, not corrected) is $73,011 up to $2,190,294 per violation.
All four tiers share the same annual cap of $2,190,294 for multiple violations of an identical requirement.
Separately, the Department of Justice can pursue criminal charges for knowing violations, ranging from up to $50,000 and a year in prison for a basic knowing violation, up to $250,000 and 10 years for violations committed for commercial advantage, personal gain, or malicious harm.
According to IBM, the average cost of a data breach is $4.99m, without considering the potential harm to the individuals involved in the data breach.
Preventing data breaches by building security controls directly into your software is a worthwhile return on investment.
What the Data Protection Rule requires, and what's about to get stricter
The current Security Rule requires reasonable and appropriate administrative, physical and technical safeguards. ‘Addressable’ coverage is not optional: it requires implementation, an appropriate alternative or documented reasoning. Its technical safeguards cover the following:
- Access control (unique user identification, emergency access, automatic logoff),
- Audit controls (recording and examining system activity),
- Integrity controls (protecting data from improper alteration),
- Person or entity authentication (verifying who’s actually asking), and
- Transmission security (protecting data in transit).
The 2025 proposal would go further once in effect, including asset inventories and ePHI maps, MFA, encryption at rest and in transit with limited exceptions, vulnerability scanning, penetration testing, annual audits and stronger business-associate verification.
The direction is clear: controls should be specific, testable and evidenced. Yet a control can be present and still fail if a “trusted” component can bypass it.
The “one-compromise” test
Ask: If any single administrator, identity service, application server, key system or vendor is compromised, can it expose ePHI?
MFA does not prevent a compromised identity provider from issuing a token, or malware from stealing a live session. Encryption at rest and in transit does not stop plaintext appearing on an application server during use. Logs do not independently prove that a change was authorised if the same system can alter policy and evidence. A break-glass made by a single account is nothing short than a bypass.
Passing the test does not mean predicting every exploit. It means addressing the toughest one.
How TideCloak changes the failure modes which result in PHI Data Breaches
TideCloak is an Identity, Access, and Authority Management (IAAM) solution built from the ground up with different thinking. It is designed to move critical authority out of the reach of any single administrator, server, cloud provider or vendor (itself included).
The distinction is best understood by the failure modes it is designed to remove:
| HIPAA-aligned concern | Residual failure path | TideCloak outcome |
|---|---|---|
| Identity and authentication | A central verifier or administrator can reset credentials, impersonate a user or detach access from the session that created it. | A distinct pseudonymous cryptographic identity is controlled by the user, while authentication and authority are bound to the active client session. |
| Privileged and emergency access | One administrator or standing break-glass account can create and use a master bypass as an insider threat. | Sensitive changes and emergency access require quorum approval, remain time-limited and bound to the designated user session. |
| Person or entity authentication | Password hashes or equivalent verification artifacts can be stolen, modified or attacked offline; a valid login can be detached from the session that created it. | Zero-knowledge, distributed authentication avoids a central reusable password-verifier database and couples the authorization result to the user’s current session. |
| Data protection in use | Data is encrypted at rest and in transit but appears as plaintext on a server or to a key administrator during use. | End-to-end protection is designed to deliver plaintext only to the authorized edge session, without a reusable server-held decryption key. |
| Audit and policy integrity | The same privileged system can change policy, perform the action and influence the record. | Sensitive changes require governed approval and can carry cryptographic evidence of the policy and approvals that produced them. |
Architecture mapping only. HIPAA obligations depend on the entity, use case, deployment and operational safeguards.
Make one compromise insufficient for a data breach
HIPAA’s next requirements will help health platforms close known gaps. The most durable question is whether ePHI stays protected when a trusted component does not.
See how TideCloak makes a single compromise insufficient to expose ePHI, or explore the quickstart.
This article provides general information, not legal advice. Consult qualified counsel about how HIPAA and other health-data laws apply to your organization and product.