Key Takeaways
-
Healthcare attack surface management spans five distinct surfaces: external, internal, Internet of Medical Things (IoMT), third-party, and identity. Each surface requires continuous discovery and monitoring beyond traditional information technology (IT) assets.
-
Clinical criticality drives prioritization because an unpatched infusion pump poses far greater patient-safety consequences than an unpatched workstation. Common Vulnerability Scoring System (CVSS) scores alone are insufficient.
-
Legacy and unpatchable medical-device firmware shifts remediation toward network segmentation, compensating controls, and passive monitoring instead of routine patching.
-
Third-party and business-associate exposure often remains unseen until a breach occurs. Continuous external monitoring and dark-web intelligence close much of this visibility gap.
-
Cyble delivers artificial intelligence (AI)-native attack surface management that unifies external discovery, third-party monitoring, and managed takedowns to support both patient safety and Health Insurance Portability and Accountability Act (HIPAA) risk-analysis requirements.
See your healthcare attack surface in action
The Five-Surface Model for Healthcare Attack Surface Management
The five-surface model gives healthcare teams a practical way to scope attack surface management (ASM) programs. Each surface behaves differently in a clinical environment, and a program focused only on internet-facing assets leaves most attack paths unmonitored.
The five surfaces are:
-
External surface: Internet-facing domains, patient portals, telehealth endpoints, application programming interface (API) gateways, and forgotten or shadow infrastructure such as staging servers, test instances, and subsidiary domains that were never decommissioned.
-
Internal surface: Clinical workstations, imaging systems such as picture archiving and communication systems (PACS), laboratory information systems, and flat network segments where lateral movement can reach patient care systems without crossing a meaningful security boundary.
-
Medical device and Internet of Medical Things (IoMT) surface: Connected medical devices with legacy or unpatchable firmware, including infusion pumps, patient monitors, ventilators, and diagnostic equipment.
-
Third-party surface: Business associate and managed service provider (MSP) connections that extend the attack surface beyond the organization’s own perimeter. Business associates were involved in 43% of all large healthcare breaches reported in the first half of 2026, up from an average of 20% between 2009 and 2017.
-
Identity surface: Clinician and staff credentials that, when exposed on criminal markets, convert directly into access to protected health information (PHI).
Healthcare ASM must span all five surfaces. A program that monitors external domains while leaving IoMT devices undiscovered and business associate connections unmonitored maps the front door while leaving the loading dock open.
Five-Step Process for Healthcare Attack Surface Management
The healthcare ASM lifecycle runs as a sequence of five steps. Each step has a healthcare-specific dimension that separates it from generic ASM practice.
-
Discover assets across all five surfaces. Discovery must run continuously rather than at a single point in time because clinical environments change with every new device deployment, vendor connection, and telehealth rollout.
-
Identify ownership and clinical context. Every discovered asset needs an owner, a clinical function classification, and a determination of whether it creates, receives, maintains, or transmits electronic protected health information (ePHI). Without clinical context, teams fall back to CVSS scores, which do not reflect patient impact in a care environment.
-
Determine exposure and prioritize by clinical criticality. This step is where healthcare ASM diverges most sharply from generic practice. An unpatched infusion pump and an unpatched scheduling workstation may share a vulnerability, yet the infusion pump’s direct connection to patient therapy places it in a different remediation tier regardless of CVSS parity.
-
Remediate or mitigate. Patchable assets follow standard vulnerability management cadences. Legacy or unpatchable medical devices require network segmentation, virtual patching, passive monitoring, and documented compensating controls. Both Food and Drug Administration (FDA) guidance and the International Medical Device Regulators Forum (IMDRF) N70 framework explicitly endorse network segmentation as a primary compensating control for devices that cannot be patched.
-
Continuously monitor. A point-in-time scan produces a point-in-time picture. Clinical environments change daily as new devices connect, vendor tunnels open, and telehealth platforms expand, so monitoring must run continuously to maintain an accurate exposure picture.
A critical operational gap in many healthcare ASM programs is the lack of correlation between an internal medical device inventory and external attack surface visibility. Internal inventories often reflect what someone remembered to document. External discovery shows what is actually reachable from outside the organization, including forgotten staging servers, test instances, and devices connected by facilities teams without IT awareness. The American Hospital Association (AHA) national advisor for cybersecurity and risk has noted that programmable logic controllers (PLCs) and operational technology are routinely connected to hospital networks by facilities teams without IT’s knowledge. Correlating internal records with external discovery closes that gap.
Inventorying and Mapping IoMT and Connected Medical Devices
Connected medical devices function as first-class assets in a healthcare ASM program. They are not an exception category. The IoMT attack surface differs from the IT attack surface in three structural ways that change how teams must manage it.
The legacy and unpatchable firmware problem. Medical devices are designed to last 15 to 20 years, while vendors typically support the underlying software for only three to five years, creating a structural security gap that widens annually. When a patch does not exist or cannot be applied without vendor approval and clinical engineering sign-off, remediation relies on network segmentation, compensating controls, and behavioral monitoring. The United States Department of Health and Human Services (HHS) 405(d) Health Industry Cybersecurity Practices (HICP) 2023 Edition identifies attacks against network-connected medical devices as one of the top five threats facing the healthcare and public health sector and directs organizations to extend cybersecurity practices from other HICP domains to medical device management.
The firmware vulnerability visibility problem. The FDA and Cybersecurity and Infrastructure Security Agency (CISA) joint alert on the Contec CMS8000 patient monitor, issued on January 30, 2025, described a critical backdoor linked to an IP address in Beijing that allowed remote actors to execute unverified files, a backdoor that had been present for over 13 years undetected. The FDA’s published mitigation required disabling networking functions rather than issuing a patch that restored full capability. The exposure was reachable and could not be resolved through standard patch management.
The inventory correlation problem. As noted earlier, internal device inventories are often incomplete. External discovery shows what is actually reachable from outside the organization. Correlating internal device inventories with external attack surface visibility highlights the gap between what the organization believes is protected and what is actually reachable.
A device inventory for IoMT risk management should capture:
-
Device type and model
-
Unique device identifier (UDI)
-
Clinical function
-
Physical location
-
Operating system and firmware version
-
Network interfaces
-
Communication protocols
-
Vendor support status
-
Responsible owner
An inventory that is never mapped to Common Vulnerabilities and Exposures (CVEs) and CISA Known Exploited Vulnerabilities (KEVs) provides little operational value.
Managing Third-Party and Vendor Attack Surface in Healthcare
Third-party exposure often remains invisible because it sits in someone else’s environment. The notification clock for a covered entity can start before the covered entity knows a business associate has been compromised. The Xsolis breach in June 2026 gave an attacker four days of network access after a single phishing email, exposing approximately 1.4 million records. Covered entities in the Xsolis client list had no visibility into that window until notification arrived.
Point-in-time annual questionnaires do not solve this problem. A business associate that passes an annual review in January can be compromised in February, and the covered entity may not know until the associate files a breach notification or the data appears on a criminal market. The AHA national advisor for cybersecurity and risk has stated that adversaries have mapped healthcare’s critical third-party dependencies and target them precisely because the covered entity has less visibility into the vendor’s environment.
The CISA Internet Exposure Reduction Guidance recommends that organizations build an authorized external-exposure inventory that includes vendor connections. For every discovered service, including those operated by third parties, organizations should record an owner, system purpose, authentication method, data sensitivity, and business justification. Unknown assets require investigation.
Monitor these third-party signals:
-
Continuous monitoring of business associate and MSP external attack surfaces for newly exposed services, credential leaks, and ransomware forum mentions
-
Dark web monitoring for data attributed to business associates appearing on criminal markets or leak sites before formal notification
Escalate when any of these triggers occur:
-
Credential exposure linked to a business associate’s domain
-
Ransomware group mention of a named vendor
-
Newly internet-exposed service on a business associate’s infrastructure that touches ePHI
-
Annual written verification of technical safeguard deployment, as proposed under the 2024 proposed HIPAA Security Rule changes, supplemented by continuous monitoring
These third-party monitoring practices also feed directly into HIPAA compliance obligations.
How Attack Surface Management Maps to HIPAA Risk Analysis Requirements
Attack surface management for healthcare operationalizes the HIPAA Security Rule’s risk analysis and risk management requirements. Continuous discovery and attribution produce the asset inventory and exposure picture that a risk analysis depends on. Without that foundation, the risk analysis remains incomplete.
HHS Office for Civil Rights (OCR) Director Paula Stannard has stated that lack of risk analysis “is the most common compliance failure we see in security rule investigations,” with regulators frequently finding incomplete, outdated, or non-existent risk analyses. Every recent OCR resolution agreement citing a Security Rule violation has named failure to conduct an accurate and thorough risk analysis as a root finding.
The 2024 proposed HIPAA Security Rule changes, published in the Federal Register on January 6, 2025 as a Notice of Proposed Rulemaking (NPRM) under docket HHS-OCR-2024-0020, would require regulated entities to maintain a written technology asset inventory covering every component of their electronic information systems that may affect the confidentiality, integrity, or availability of ePHI, and a network map illustrating how ePHI moves through those systems. Both the inventory and the network map would need review and updates at least once every 12 months and whenever a change in the entity’s environment or operations may affect ePHI, including adoption of new technology assets, newly recognized threats, mergers or consolidations, security incidents, or relevant changes in law.
The current HIPAA Security Rule remains fully in effect while rulemaking proceeds. As of July 2026, the Office of Management and Budget (OMB) regulatory agenda lists final action for July 2027, and OCR has stated explicitly that the current Security Rule applies throughout the rulemaking process. Organizations that build ASM programs aligned to the proposed requirements build toward a documented compliance posture under the current rule while preparing for the proposed one.
The HHS 405(d) HICP 2023 Edition reinforces this alignment. Its IT asset management practice states that asset management is critical to ensuring appropriate cybersecurity controls across all assets, and its vulnerability management practice directs organizations to use asset management to support identification and management of vulnerabilities. The January 2026 OCR Cybersecurity Newsletter, published by HHS on January 8, 2026, focuses on system hardening and security baselines for protecting ePHI and directs regulated entities to monitor authoritative vulnerability sources such as the National Institute of Standards and Technology (NIST) National Vulnerability Database and the CISA Known Exploited Vulnerabilities Catalog. Asset visibility and external monitoring together surface risks that internal processes alone cannot detect.
The compliance benefit is concrete. A documented, time-stamped record of when an exposure was first detected is precisely what a regulator asks for. An ASM program that produces continuous, time-stamped discovery records gives a compliance committee the evidentiary foundation it needs.
What to Look For in a Healthcare Attack Surface Management Capability
The following capability criteria apply to any healthcare ASM evaluation. They are organized by function rather than by vendor ranking.
-
External discovery across the full IPv4 and IPv6 space: The capability should scan every reachable address, not a sampled subset, to surface forgotten staging servers, test instances, and shadow infrastructure that internal records do not reflect.
-
Entity resolution to your own assets: Mentions of the organization, including obfuscated spellings and cross-language references, should be resolved to the correct entity before they become alerts, avoiding manual triage for basic attribution.
-
Correlation between internal device inventories and external visibility: The capability should bridge the gap between what the organization documented internally and what is actually reachable from outside, including devices connected by facilities teams without IT awareness.
-
Third-party and business associate monitoring: Continuous monitoring of vendor external attack surfaces and dark web mentions should supplement traditional questionnaires.
-
Continuous monitoring instead of point-in-time scans: Clinical environments change daily, so a scan cadence measured in months produces a stale picture within weeks.
-
Remediation or takedown workflow attached to the finding: Discovery that ends at an alert hands the hard part back to the team. The capability should include a path from finding to resolution. That path might be a remediation workflow, a compensating control recommendation, or a managed takedown for external threats such as phishing sites and lookalike domains.
When evaluating vendors against these criteria, look for evidence of each capability rather than marketing claims. Cyble is an AI-native cybersecurity company unifying intelligence-driven security across the entire digital attack surface, and its platform illustrates how these capabilities work in practice.
Cyble Vision is the flagship platform for cyber threat intelligence (CTI), ASM, and digital risk protection (DRP). ODIN, Cyble’s internet-wide asset discovery engine, maps internet-facing assets across the full IPv4 and IPv6 space. This includes shadow and forgotten infrastructure and produces an external view of the organization’s perimeter as an attacker sees it. Entity resolution runs at ingestion, so mentions are resolved to the correct organization before they become alerts, including across languages and obfuscated spellings. Native managed takedown removes phishing sites, lookalike domains, and fake apps against service level agreements (SLAs), with a reported 98% takedown success rate.
Cyble reports visibility into more than 15,000 darknet marketplaces and a 95% signal-to-noise ratio, based on Cyble internal telemetry.
Cyble integrates with more than 70 enterprise platforms, including Splunk, Microsoft Sentinel, IBM QRadar, Cortex XSOAR, and ServiceNow, so findings land in the workflow the security team already uses rather than in an isolated dashboard. The examples listed are representative, not exhaustive. See the current integration list for details.
Frequently Asked Questions (FAQ)
What is attack surface management for healthcare?
Attack surface management for healthcare is the continuous discipline of discovering, inventorying, attributing, and monitoring every digital asset that a health system exposes to potential compromise. The scope extends beyond servers and cloud workloads to include connected medical devices, patient portals, telehealth endpoints, and vendor connections. The resulting asset inventory serves two simultaneous purposes. It is a patient-safety artifact because a compromised infusion pump or imaging system can directly affect care delivery. It is also a compliance artifact because the HIPAA Security Rule risk analysis requirements depend on an accurate, current picture of what the organization exposes and where its vulnerabilities lie.
How is healthcare ASM different from generic ASM?
Three structural differences separate healthcare ASM from generic practice. First, as noted, clinical criticality should drive prioritization rather than CVSS score alone. An unpatched device directly connected to patient therapy carries different consequences than an unpatched administrative workstation, even when both share the same vulnerability identifier. Second, legacy and unpatchable device firmware changes the remediation options available. Many connected medical devices cannot be patched on a normal cadence because the vendor has not issued a fix, because applying one requires clinical engineering approval, or because the device is in active patient use. Remediation in those cases relies on network segmentation, compensating controls, and passive monitoring. Third, regulatory exposure turns discovery and attribution into compliance obligations. A time-stamped record of when an exposure was first detected is the evidentiary artifact a regulator asks for after a breach, so continuous discovery becomes a compliance function as well as a security function.
What are the three key components of attack surface monitoring?
Attack surface monitoring in healthcare rests on three interdependent components. The first is continuous discovery, which systematically identifies every asset across all five surfaces on an ongoing basis rather than through periodic scans. The second is attribution and clinical context, which assigns each discovered asset an owner, a clinical function classification, and a determination of whether it handles ePHI so that exposure findings carry the context needed for prioritization. The third is correlation, which connects internal device inventory records with external attack surface visibility to identify the gap between what the organization believes is protected and what is actually reachable from outside. Without all three components operating together, monitoring produces either incomplete coverage or findings without the context needed to act.
How does ASM support HIPAA risk analysis?
The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. That assessment depends on knowing what assets exist, what they expose, and what vulnerabilities affect them, which is precisely what a continuous ASM program produces. The 2024 proposed HIPAA Security Rule changes would formalize this dependency by requiring a written technology asset inventory and network map, reviewed and updated at least annually and after material environmental or operational changes. Even under the current rule, which remains fully in force, HHS OCR enforcement consistently identifies failure to conduct an accurate risk analysis as the most common compliance failure in security rule investigations. An ASM program that produces continuous, time-stamped discovery records gives the compliance function the evidentiary foundation a risk analysis requires and the documentation trail a regulator asks for.
Do we have to replace our existing security stack?
Attack surface management for healthcare is designed to complement an existing security stack. Internal tools such as security information and event management (SIEM) platforms, endpoint detection and response (EDR) solutions, and security operations center (SOC) workflows observe what happens inside the environment. ASM and external threat monitoring observe what is reachable and exposed from outside, including credentials circulating on criminal markets, business associate compromises, and forgotten infrastructure that internal tools cannot see. The two disciplines work together. Cyble Vision integrates with more than 70 enterprise platforms so findings land in the tools the team already uses and function as a force multiplier for the existing stack.
Conclusion: Next Steps for Healthcare Attack Surface Management
The five-surface model, covering external, internal, medical device and IoMT, third-party, and identity surfaces, provides the scope a healthcare ASM program requires. The five-step lifecycle of discover, identify ownership and clinical context, prioritize by clinical criticality, remediate or mitigate, and continuously monitor provides the sequence. The HIPAA mapping provides the compliance justification a board or compliance committee needs to approve the investment.
The core argument is straightforward. In healthcare, discovery and attribution matter more than raw vulnerability counts because the asset inventory is both a patient-safety artifact and a compliance artifact. A program that counts CVEs without clinical context produces a list. To produce a defensible security posture, a program must correlate internal device inventories with external attack surface visibility, prioritize by clinical criticality, and produce time-stamped discovery records.
Practical next steps for security, risk, and compliance leaders:
-
Conduct an internal assessment against the five surfaces to identify which surfaces currently have discovery and monitoring coverage and which do not.
-
Align with compliance stakeholders on the asset inventory requirements under the current HIPAA Security Rule and the proposed changes published January 6, 2025, noting that the current rule remains fully in force.
-
Gather requirements for continuous monitoring of business associate and vendor connections, given that business associates were involved in 43% of large healthcare breaches in the first half of 2026 (as noted earlier).
-
Evaluate ASM capabilities against the criteria above, including external discovery, entity resolution, internal and external inventory correlation, third-party monitoring, continuous operation, and an attached remediation workflow, before selecting a solution.
Request a Demo — see what Cyble finds in your environment