HIPAA compliance and ePHI exposure: what the audit misses and attackers find first
Amara OkaforApril 29, 2026
Key takeaways
HIPAA compliance audits are point-in-time assessments of documented controls. They do not test what is reachable from the internet on the day an attacker looks.
In Vulnox assessments of healthcare organizations, the most common ePHI exposure source is not an unpatched CVE -- it is a misconfigured ancillary service the compliance team did not know existed: a cloud fax integration, a patient portal subdomain, a decommissioned API that still responds.
Hardcoded API keys in client-side JavaScript are the fastest path to patient records in modern healthcare web applications. The key is visible to anyone who opens browser developer tools. No authentication bypass required.
Medical devices connected to clinical networks introduce external attack surface that almost no healthcare organization tracks systematically. The device itself may not be internet-facing, but the management interface often is.
A healthcare organization can pass a HIPAA Security Rule audit and simultaneously have patient data indexed by search engines through an unprotected cloud storage bucket. These are not contradictions -- they are different layers of the same environment.
TL;DR
HIPAA defines what controls should exist. It does not verify what is actually reachable. The external attack surface of a healthcare organization -- patient portals, API endpoints, cloud storage, third-party integrations, medical device management interfaces -- changes faster than any annual audit cycle can track. The exposures that produce breaches are almost never in the controls the audit reviewed. They are in the infrastructure the audit did not know to look at.
The portal that passed the audit
A regional health system had just completed a HIPAA compliance audit. The patient portal vendor provided an attestation. The audit reviewed access controls, encryption in transit, and the Business Associate Agreement. All of it checked out. Six weeks later, Vulnox ran an external assessment. The portal's JavaScript bundle -- publicly served, no authentication required -- contained a hardcoded API key. The key provided read access to a patient data endpoint. The endpoint returned records including names, dates of birth, procedure codes, and insurance identifiers. Approximately 50,000 records were accessible. The audit did not test the JavaScript. The audit was not wrong by its own standards. Its standards were set for a different problem than the one that existed.
The CISO's reaction was not denial. It was genuine surprise that an audit costing six figures had not included a check that takes under ten minutes to run manually. That gap -- between what compliance frameworks require and what external exposure actually looks like -- is where the majority of healthcare breach surface lives.
Why HIPAA audits and external exposure are measuring different things
The HIPAA Security Rule is built around administrative, physical, and technical safeguard categories. The technical safeguards cover access controls, audit controls, integrity, authentication, and transmission security. These are all internal control categories. They describe what your systems should do when operating as designed.
External exposure is a different question. It asks: what can an unauthenticated user reach from the internet, and what does that access return? This question is not answered by reviewing your access control policies. It is answered by running enumeration against your external surface and observing what responds.
The distinction matters because the two assessments produce different findings. An internal audit can confirm that your production database requires authentication and that credentials are properly managed -- and simultaneously miss that a developer left a backup of that database in a publicly accessible S3 bucket six months ago during a migration. The audit checked the database. The bucket was not in scope because no one knew it existed.
Example
Cloud fax services are a consistent finding in healthcare assessments. A physician's office adopts a cloud fax platform to receive patient referrals because it is faster than traditional fax infrastructure. The integration is set up by a non-technical administrator using the vendor's default configuration. Default settings on several major cloud fax platforms do not restrict document indexing. The faxed referrals -- containing patient names, referring diagnoses, and insurance information -- become discoverable via Google within days. The physician's office has HIPAA policies governing fax handling. Those policies were written for a physical fax machine.
The mechanism here is not a vulnerability in the traditional sense. There is no CVE. No exploit chain. The data is accessible because a configuration option was not changed from its default state, and no one audited the external behavior of the service after it was deployed. Standard vulnerability scanners do not detect this because standard vulnerability scanners look for known vulnerabilities, not for data that is accessible because it was placed in a publicly reachable location.
What external assessments find in healthcare environments
Assessment base: Vulnox digital footprint and vulnerability assessments, healthcare segment, 2023-2024
Ancillary service exposures outnumber application vulnerabilities
In Vulnox healthcare assessments, the most frequently discovered ePHI exposure source is not the primary patient portal or EHR system -- both of which typically receive significant security attention -- but the surrounding ecosystem: scheduling integrations, telehealth platforms, billing service portals, laboratory result delivery systems, and referral management tools. These systems are procured by clinical or administrative staff, deployed quickly, and rarely included in security assessments because they are not considered core infrastructure.
The compliance audit scope is usually defined by the organization's own understanding of what systems handle ePHI. Systems the organization does not categorize as ePHI-handling are not included. An external attacker does not share that categorization. They look at what responds and what it returns.
Hardcoded credentials in patient-facing JavaScript
Client-side JavaScript in patient portals and scheduling applications is served publicly by definition -- it runs in the user's browser. When developers embed API keys or service account credentials directly in JavaScript to simplify integration development, those credentials are accessible to anyone who views page source or opens the browser console. In Vulnox assessments, this finding appears in a meaningful proportion of custom-built or heavily customized patient-facing applications. The credentials typically provide access to patient data APIs with broader scope than the portal UI exposes.
This is not a sophisticated finding. It requires no exploitation technique. It requires reading the code the server sends to every visitor. The reason it persists is that JavaScript credential exposure is not in the HIPAA audit checklist and is not caught by server-side vulnerability scanners, which do not execute and analyze client-side code.
Medical device management interfaces on public-facing infrastructure
Healthcare organizations often segment clinical device networks from administrative networks, but the management and monitoring interfaces for those devices are sometimes accessible from broader network segments that connect to the internet. Vulnox has identified imaging system management interfaces, infusion pump configuration portals, and patient monitoring dashboards accessible from external scans in healthcare environments. These interfaces often run on older software with known vulnerabilities and default credentials that have never been changed.
The device itself -- the infusion pump, the imaging system -- may be properly isolated. The software used to configure and monitor it is a separate attack surface. Healthcare organizations track device inventories for clinical purposes. They rarely track the network-accessible management interfaces of those devices as attack surface.
Decommissioned systems that still respond
Healthcare organizations replace systems regularly: EHR migrations, portal upgrades, billing system transitions. The old system gets turned off in the operational sense -- users stop logging in, the data is migrated. The server itself continues running, the DNS entry is never removed, and the application continues to respond to requests. In one Vulnox assessment, a legacy patient scheduling system that had been replaced 14 months earlier was still accessible, still held patient appointment data from before the migration, and had not received a security patch in over a year.
Decommissioning a system and decommissioning its network presence are two separate steps. The second step is skipped more often than the first.
The finding that produces the most resistance: your vendor's attestation is not your assessment
Common belief
Healthcare organizations routinely accept vendor-provided HIPAA attestations, SOC 2 reports, and compliance certifications as evidence that the vendor's system is secure. The reasoning is: the vendor was audited by a third party, the audit passed, therefore the integration is safe to deploy.
What we found
In the patient portal case described above, the vendor's attestation was legitimate. Their system, when properly configured, did not expose the API key in JavaScript. The organization had customized the portal during implementation, and the customization introduced the exposure. The attestation covered the standard product. It said nothing about the customized deployment. No one at the organization understood those were different things.
A vendor's SOC 2 report covers the vendor's internal controls. It does not cover how their system was configured in your environment. A patient portal vendor can have a clean SOC 2 and simultaneously ship a product where the default configuration exposes data if the customer does not change specific settings. The vendor is not non-compliant. Your deployment is misconfigured. These are categorically different findings.
The same applies to HIPAA attestations. An attestation says the vendor's system is capable of being operated in a HIPAA-compliant manner. It does not say the instance you deployed last Thursday is operating correctly.
This matters because the vendor attestation is typically the only security review that happens at the point of procurement. The organization checks the box, signs the BAA, and deploys. No one runs an external scan against the deployed instance to verify that the production configuration matches what the attestation describes.
The external attack surface categories healthcare security programs miss
Cloud storage buckets from data migrations
EHR migrations, billing system transitions, and infrastructure moves frequently involve temporary cloud storage as a staging layer. The bucket gets created, the data gets loaded, the migration runs, and the bucket does not get deleted or access-restricted when the migration completes. Healthcare organizations in the middle of or recently post-migration consistently show at least one cloud storage resource with broader access than intended.
Third-party scheduling and telehealth integrations
Telehealth platforms, online scheduling tools, and patient communication services are adopted rapidly by clinical operations teams without security review. These platforms handle patient identifiers, appointment details, and in the case of telehealth, often connect to systems that hold clinical data. The integration is built by the vendor's onboarding team using credentials that are rarely rotated afterward.
Search engine-indexed documents
Patient intake forms, consent documents, and clinical reference materials stored in web-accessible directories without a robots.txt restriction get indexed by search engines. This is not a theoretical risk. Running a targeted search against a healthcare organization's domain with filetype filters for PDF or DOC regularly returns documents that were placed on a web server for clinical workflow convenience and never intended to be publicly discoverable.
Subdomain takeover from acquired or closed facilities
Hospital systems that have acquired practices, merged with other systems, or closed facilities often retain DNS entries for the acquired organization's infrastructure long after the underlying servers are decommissioned. If the DNS entry points to a cloud service that has been cancelled, an attacker can register a new account with that service and claim the subdomain. The subdomain then serves attacker-controlled content under the healthcare organization's domain.
What an external attacker enumerates against a healthcare organization
- Step 1
ASN and IP range enumeration
Output:CIDR blocks, associated cloud provider ranges, and any IP addresses hosting services that respond with organizational identifiers in SSL certificates or HTTP headers.
Purpose:Establish the full IP footprint attributed to the healthcare organization, including cloud-hosted resources that may not appear in DNS.
- Step 2
Certificate transparency log review
Output:Full historical subdomain list including patient-portal, scheduling, imaging, lab-results, and any subdomain pattern suggesting clinical or administrative function.
Purpose:Identify every subdomain for which an SSL certificate has ever been issued, including historical subdomains no longer in active DNS.
- Step 3
Service discovery and response analysis
Output:Map of services by subdomain, with particular attention to management interfaces, API documentation endpoints, and any service returning data before authentication.
Purpose:Determine what each discovered host is running and what it returns to an unauthenticated request.
- Step 4
Client-side code review
Output:List of any API keys, tokens, or endpoint paths extractable from publicly served JavaScript without any authentication.
Purpose:Retrieve and analyze JavaScript bundles served by patient-facing applications for embedded credentials, API endpoint paths, and data structure disclosure.
- Step 5
Document indexing check
Output:List of indexed PDFs, CSVs, or other documents accessible via search engine queries against the organization's domain.
Purpose:Identify any documents indexed by search engines from the organization's domains containing patient or clinical data.
Where HIPAA ePHI exposure risk is heading
Within two years, at least one significant healthcare breach will be publicly attributed to a subdomain takeover on a DNS entry retained from an acquired or merged facility. The mechanism exists, the conditions are present at most large health systems, and it has not yet produced a named breach.
Hospital system consolidation has accelerated over the past decade. Each merger or acquisition adds DNS infrastructure from the acquired organization that gets lower operational priority than the clinical integration work. The security implications of retained DNS entries pointing at decommissioned infrastructure are not well understood outside specialized external attack surface teams. The ingredients are in place.
Confidence: mediumIf no publicly attributed healthcare breach involves subdomain takeover via acquired-facility DNS in the 2025-2027 period, this prediction is wrong.Regulatory enforcement actions will begin citing specific external exposure findings -- accessible patient portals, indexed documents, misconfigured cloud storage -- as evidence of HIPAA Security Rule violations in the absence of an actual breach. This is currently rare. It will become standard within three years as OCR develops better external scanning capability.
The HHS Office for Civil Rights has historically required a breach to trigger a significant enforcement action. Their auditing capacity is expanding and the technical tools for identifying external ePHI exposure without a reported breach are the same tools any security team can run. As OCR's technical sophistication increases, proactive identification of external exposure will drive enforcement actions independent of breach notification.
Confidence: mediumIf, by 2028, fewer than three OCR enforcement actions cite externally discoverable ePHI as a primary violation finding without an associated breach notification, this prediction is wrong.
What I actually think about the HIPAA compliance framework as a security tool
HIPAA is not a security standard. It is a minimum documentation standard with security-adjacent requirements. The Security Rule's technical safeguard requirements are written at a level of abstraction that allows an organization to satisfy them with controls that would embarrass any practicing security engineer. 'Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights' is a requirement. It describes a concept. It does not describe a configuration.
I am not arguing that HIPAA should be replaced. I am arguing that healthcare organizations should stop treating HIPAA compliance as a proxy for security posture. They are measuring different things. A compliance audit tells you whether your documentation of controls is sufficient. An external assessment tells you what an attacker can reach. Both are useful. Only one of them tells you whether your patients' data is exposed right now.
The organizations I see with the best actual security posture are not the ones that have spent the most on compliance consulting. They are the ones that run continuous external exposure monitoring alongside their compliance program, treat the two as different functions with different methodologies, and do not assume one covers the other.
Counterargument
The counterargument is that HIPAA compliance at least establishes a floor -- without it, many healthcare organizations would have no structured security program at all, and the floor is better than nothing. That is true. My position does not require HIPAA to be useless. It requires that healthcare security leaders stop treating it as sufficient.
One thing to do this week
Run a Google search against your primary domain with the query: site:yourdomain.com filetype:pdf. Review the first two pages of results. Any PDF that appears in those results is indexed, publicly accessible, and retrievable by anyone. If any of those PDFs contain patient names, dates of birth, procedure information, or insurance details, you have an active ePHI exposure that did not require any technical attack to discover. Fix the storage permissions on whatever bucket or directory is serving those files, and submit a removal request to Google Search Console. That is a 30-minute remediation that your last compliance audit almost certainly did not catch.
Further Reading
Digital Footprint
digital footprint analysisVulnerability Assessment
vulnerability assessment servicesHIPAA compliance framework guide: Security Rule, HICP, and the 2013 Omnibus
HIPAA ePHI exposure gapsHIPAA Official Homepage
HIPAA official regulationsNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkDigital Footprint and Monitoring - ThreatNG
digital footprint monitoring
Frequently Asked Questions
Can a healthcare organization be HIPAA compliant and still have ePHI exposed externally?
Yes. HIPAA compliance audits review documented controls -- access policies, encryption configurations, BAAs -- at a point in time. External ePHI exposure typically comes from misconfigured ancillary services, decommissioned systems still running, cloud storage buckets from data migrations, or third-party integrations deployed outside the audit scope. These can exist simultaneously with a clean compliance audit because they are different layers of the environment.
What is the most common source of ePHI exposure in healthcare external assessments?
In Vulnox healthcare assessments, the most frequent exposure source is not the primary EHR or patient portal -- both typically receive security attention -- but the surrounding ecosystem: scheduling integrations, cloud fax services, telehealth platforms, billing portals, and laboratory result delivery systems. These are deployed by clinical or administrative staff, rarely included in security assessments, and often retain default configurations that were not designed with external exposure in mind.
How do hardcoded API keys in patient portal JavaScript expose patient data?
Patient portal JavaScript is served publicly -- it runs in the user's browser, so it must be delivered before authentication. If a developer embeds an API key directly in that JavaScript to simplify integration work, the key is visible to anyone who opens browser developer tools and reads the source. The key typically provides access to a patient data API with broader scope than the portal UI exposes. No authentication bypass is required. The key is just there.
Does a vendor's SOC 2 report or HIPAA attestation mean the deployed integration is secure?
No. A vendor SOC 2 covers the vendor's internal controls. A HIPAA attestation says the vendor's system is capable of being operated in a compliant manner. Neither document covers how the system was configured in your specific deployment. Customizations, implementation choices, and post-deployment configuration changes are outside the scope of vendor attestations. The deployed instance needs its own external assessment, separate from any vendor-provided documentation.
What is a subdomain takeover and why does it affect healthcare organizations specifically?
Subdomain takeover occurs when a DNS entry points to a cloud service that has been cancelled or decommissioned, allowing an attacker to register a new account with that service and serve content under the original subdomain. Healthcare organizations are particularly exposed because hospital system consolidation leaves DNS infrastructure from acquired or merged facilities in place long after the underlying systems are shut down. The subdomain then resolves to attacker-controlled content under the healthcare organization's trusted domain.
How can patient documents end up indexed by search engines?
Documents stored in web-accessible directories without a robots.txt restriction or proper access controls get crawled and indexed by search engines in the normal course of their operation. This frequently affects patient intake forms, consent documents, and clinical reference materials placed on web servers for staff convenience. A targeted search using site: and filetype: filters against a healthcare organization's domain regularly surfaces documents the organization did not intend to be publicly accessible.
What external exposure checks should healthcare organizations run independent of HIPAA audits?
At minimum: a certificate transparency log review to identify all historical subdomains, a check of publicly accessible cloud storage buckets across all accounts, a review of client-side JavaScript on patient-facing applications for embedded credentials, a search engine document discovery check using site: queries, and a port scan of the full IP range attributed to the organization's ASN. None of these are HIPAA audit activities. All of them consistently produce findings in healthcare environments.
Related Articles
Basic digital footprint check: what free tools find and what they miss
A basic digital footprint check using free tools takes less than an hour and reliably surfaces subdomains, certificate history, and indexed content. What it misses — assets with no DNS record, credential material in archived repositories, and vendor-created infrastructure — is where the regulatory exposure lives.
SaaS digital footprint: what customer-facing infrastructure exposes before anyone attacks
In Vulnox assessments, the average SaaS company has 11 externally reachable assets its own team cannot name. That gap between what you think you expose and what is actually visible is where most breaches begin.
Digital footprint exposure and data protection risk: what regulators find that internal teams miss
Forgotten subdomains, undocumented SaaS integrations, and exposed API keys are data protection violations waiting to be discovered -- by a regulator, not your internal team. Vulnox assessments found at least one forgotten subdomain in 71% of environments reviewed. Here is what that exposure looks like through a regulatory lens.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.