For hospitals and clinics, digital health products, medical device makers and the suppliers who connect them
Healthcare runs on systems that cannot simply be switched off to patch: imaging archives, infusion pumps, nurse-call and building systems, electronic health records, and the remote access vendors use to support them. We test what an attacker reaches from a phished clinician, an exposed device or a supplier's connection, and we plan every test around patient safety.
Health records carry diagnoses, medications and identity documents that cannot be reissued like a card number, so they stay valuable for years. Downtime in a hospital is measured in postponed procedures and diverted ambulances, and ransomware groups target the sector because that pressure makes recovery urgent. For device makers the stakes are a recall, a regulator's attention and hospital customers who now send long security questionnaires before they buy. After any incident the first questions are the same: what did the attacker touch, and can the clinical systems be trusted again?
The joint FBI, CISA and HHS advisory on the Daixin Team (AA22-294A (opens in a new tab)), a ransomware group targeting healthcare, describes it getting in through VPN servers: one unpatched, and a legacy one without multi-factor authentication, reached with phished credentials. Remote desktop gateways and vendor support tools offer the same opening, and from there an attacker can reach domain controllers and backups before encrypting anything, so the clinical impact arrives all at once.
PACS servers that answer DICOM queries from the internet hand patient images to anyone who asks. Inside the network the problem is wider: flat segments let a compromised workstation reach pumps, monitors and imaging equipment directly, and many device protocols carry no authentication at all.
Imaging consoles and laboratory analysers often run an operating system the manufacturer certified years ago and will not let you patch without losing support. Those devices depend on compensating controls (isolation, allow-listed connections, monitoring), and a test is how you find out whether the controls hold.
Billing processors, telehealth platforms, clearing houses and device vendors hold standing connections into hospital networks. A breach at one of them becomes an incident at every customer that trusted its connection without limits.
Shared workstations, urgent shift work and inboxes that receive referrals from outside senders make email the easy way in. Proxy login pages that steal a session after multi-factor authentication now appear alongside ordinary credential phishing.
Patient portals, appointment apps and FHIR APIs that check the session but not the patient identifier in the request show one patient's records to another. Digital health products built quickly on cloud services add misconfigured storage and test data copied from production.
The HIPAA Security Rule requires an accurate and thorough risk analysis of electronic protected health information and periodic technical and non-technical evaluation of your safeguards. HHS proposed in January 2025 to make vulnerability scanning every six months and a penetration test every 12 months explicit, and its 2026 Unified Agenda lists that proposal as a long-term action, with final action projected for July 2027. NIS2 lists healthcare providers among its sectors of high criticality and medical device manufacturing among its other critical sectors, with a 24-hour early warning and a 72-hour notification for significant incidents. Israeli databases holding medical information are assigned a security level under the Data Security Regulations, and databases at the high level must be penetration tested at least every 18 months. AI in a medical device is high-risk under the EU AI Act when the device needs a third-party conformity assessment.
The scoping call settles which of these apply to your systems.
Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.
Duration: 5 to 12 working days
Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.
Duration: 5 to 10 working days
An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.
Duration: 4 to 8 working days
iOS and Android testing of the binary, on-device storage and transport, and of the backend API the app calls, replaying the app's own tokens to check whether one user can read another's data. On the device we check what the keychain or keystore stores, whether certificate pinning survives a bypass attempt and what deep links can trigger.
Duration: 6 to 10 working days
Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.
Duration: 2 to 5 days per system, remote or on site
Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.
Duration: Live incidents until recovery is verified; readiness work in days
Closest written-up engagement
Healthcare IoT · Under two weeks
Hospital customers were reporting device API instability. The cause was not load.
Yes, and patient safety sets the rules of engagement. Clinical devices are tested in a maintenance window, on a spare unit or in a lab copy where one exists, and the rules of engagement name the devices that may only be observed, never sent active traffic. A named contact in your clinical engineering team can stop the test at any point.
Only if you decide they must. Most findings can be proven with test patients or synthetic records in a non-production environment. Where a finding can only be shown in production, we prove access to one record you nominate and stop there. Engagement data is encrypted at rest and destroyed on a schedule you set.
The device and its firmware, the update mechanism, the mobile or desktop app that pairs with it, the cloud service it reports to and the clinical network it will sit on. Each finding is tied to the component and interface where it lives, so the report can go to a hospital's security review or into the cybersecurity documentation your regulatory team assembles.
With the external perimeter and remote access, then the path from one phished account to your patient records and backups. That order follows how ransomware intrusions usually begin. A focused network test answering those two questions often does more for a small group than a broad audit, and the scoping call is where we decide which fits.
We pick the checks that apply to your systems and the frameworks you answer to. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.