Medical Devices
A connected medical device is a computer with a patient on the other end. We test it for the manufacturers who build it and the hospitals that run it — and deliver the evidence regulators actually ask for.
Book a ConsultationLong service lives, hard to patch, and patients attached
A connected device carries firmware, wireless telemetry, a companion app, a cloud back end, and clinical interfaces — DICOM, HL7, FHIR — into the hospital network. It stays in service for years, and much of the installed base cannot be patched on anything like an IT schedule.
Regulators now expect evidence. In the US, section 524B requires submissions for “cyber devices” to include a plan for monitoring and addressing vulnerabilities, processes that keep the device and related systems cybersecure with updates and patches, and a software bill of materials. FDA’s premarket guidance asks that penetration test reports state the independence and technical expertise of the testers. FDA does not require a third party — its guidance names independent internal testers as one option, though it notes that a third party may sometimes be needed for appropriate independence. Independence is a field a reviewer reads, and an outside team makes it a strong one. In the EU, no software or security standard is harmonised under the MDR, so “state of the art” is something you argue to your notified body, not something a certificate settles.
Security here can hurt patients by working as intended: a clinician has to be able to reach a device in an emergency. So every access-control recommendation we make is checked against emergency clinical access before we write it — a recommendation that would lock out a clinician is a defect in the recommendation, not a finding.
Three services, tuned to the device
Artificial Intelligence Security (AI-BOM)
AI-enabled device software and the pipeline behind it — training-data provenance, how model updates are delivered and controlled — plus the clinician-facing assistants and agents that can reach patient data. We test the pipeline, not just the model.
Learn more →Post-Quantum Cryptography Readiness (CBOM)
A cryptographic inventory of the device and its ecosystem: firmware and update signing, device identity certificates, and the links that carry patient data. Health records stay sensitive for decades, so data in transit today is a harvest-now, decrypt-later target — and a signing key has to stay trusted for as long as the device stays in service.
Learn more →Product Penetration Testing
The device on the bench — hardware, firmware, debug interfaces and credentials — its wireless and telemetry links, the companion app, the cloud and update infrastructure behind it, and the clinical interfaces it speaks. Reported to the elements FDA names for penetration test reports, including the testers’ independence and expertise.
Learn more →Built for clinical devices, not adapted from IT
Two buyers, two shapes
Manufacturers get premarket evidence on a unit they can fix. Hospitals get segmentation, compensating controls and procurement leverage over a fleet they cannot patch — not a list of device flaws nobody on site is able to fix. The wider clinical estate is covered on our Healthcare page.
Primary sources only
We quote regulations and guidance from their primary text, and we do not quote clause text from paywalled standards we have not licensed. Your submission should not rest on someone else’s summary.
Legacy measured, not assumed
A legacy device is one that cannot be reasonably protected against current threats — whatever its age, so one bought today can qualify. We measure that across your estate rather than quoting industry statistics no one can source.
Patient-harm findings escalate now
Any finding with a plausible path to patient harm goes to you the moment we find it, not at report time — with the clinical and regulatory context your teams need to act on it.
Where the rules stand, market by market
Binding requirements differ sharply between markets — and in some, there are none yet. Current as of October 2026.
| Market | Instrument | What it means for you |
|---|---|---|
| United States | FD&C Act §524B (21 USC 360n-2) | Applies to “cyber devices” — devices with software the sponsor validated, installed or authorised that can connect to the internet and could be vulnerable to cybersecurity threats — in submissions since 29 March 2023. The section requires a plan to monitor and address vulnerabilities, including coordinated disclosure; processes that keep the device and related systems cybersecure, with updates and patches; and a software bill of materials. It never mentions penetration testing. FDA’s guidance reads “connect to the internet” broadly: by any means, intended or not, including Bluetooth, USB, ethernet and serial ports. |
| United States | FDA premarket cybersecurity guidance (February 2026) | Sets out what a submission should contain, and was reissued to match the Quality Management System Regulation in force since 2 February 2026. Penetration test reports should state the testers’ independence and technical expertise, scope, duration, methods and results. Independent internal testers can qualify, though FDA notes that a third party may sometimes be needed for enough independence; where a third party tests, FDA asks for the original report. |
| European Union | MDR Annex I 17.2, 17.4, 18.8 IVDR Annex I 16.2, 16.4 Guidance: MDCG 2019-16 rev.1 (July 2020) | Software developed to the state of the art, including information security; minimum IT-security requirements; protection against unauthorised access. No software or security standard is harmonised under either regulation, so conformity is argued to your notified body. The IVDR has no equivalent of MDR 18.8. |
| European Union (proposed) | MDR/IVDR revision — COM(2025) 1023 | Would name cybersecurity explicitly in Annex I, add reporting of actively exploited vulnerabilities and severe incidents, and take AI in devices out of the AI Act’s directly applicable high-risk requirements. Proposed December 2025; still at first reading in the European Parliament and not adopted. |
| European Union | NIS2 — Directive (EU) 2022/2555 Cyber Resilience Act — Reg (EU) 2024/2847 | NIS2, which applies through national transposition laws, covers medium-sized and larger device manufacturers and healthcare providers, and smaller ones only where a Member State identifies them; whether an organisation is essential or important depends on its sector and size. The CRA excludes MDR and IVDR devices, but not the products around them that are not devices themselves — a wellness app or a hospital network gateway. For those, reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, with full application from 11 December 2027. |
| European Union | AI Act — Reg (EU) 2024/1689, as amended by Reg (EU) 2026/1744 | AI in devices that need notified-body assessment is high-risk. After the Digital Omnibus on AI, Reg (EU) 2026/1744, those obligations apply from 2 August 2028. |
| United Kingdom (GB) | UK MDR 2002 | No pre-market cybersecurity requirement yet. Draft Medical Devices (Amendment) Regulations 2026, published in May 2026 to align GB essential requirements with international practice, have not been made and are not in force. |
| International | IMDRF N60 (2020), N70 (2023) | The shared reference across regulators: cybersecurity across the whole product lifecycle, and a definition of a legacy device as one that cannot be reasonably protected against current threats — whatever its age. |
| Post-quantum | No device-specific requirement | Neither FDA’s guidance nor IMDRF mentions post-quantum cryptography yet, though FDA asks for cryptography expected to stay strong throughout the device’s service life. The general timelines on our PQC page still reach devices — through procurement, and through service lives that outlast today’s algorithms. |
What you get
- Premarket test evidence — a penetration test report built to the elements FDA names — independence and expertise of the testers, scope, duration, methods, and results — with your disposition of every finding
- Fleet assessment — for providers: device inventory, segmentation and compensating controls, legacy exposure, and the questions to put to vendors at procurement
- Cryptographic bill of materials — device and ecosystem cryptography in CycloneDX format, with a post-quantum roadmap that fits your release and service-life plans
- AI bill of materials — the models, data sources and tools behind your AI-enabled functions, delivered as a CycloneDX ML-BOM
- Retest of fixes — evidence that remediation landed, for your file and your release gates
Evidence your reviewer can work with.
A medical device engagement starts with your device, its intended use, and the markets you are submitting to.
Get in Touch