Penetration testing for medical devices and IVDs
Penetration testing for medical devices, filed as evidence
A reference for regulatory affairs and product security leads. Which requirements and guidance may be relevant to a connected device, what testing can demonstrate, and where the evidence belongs in technical documentation or a premarket submission.
- MDR Annex I 17.2
- IVDR Annex I 16.2
- MDCG 2019-16 §3.7
- FD&C 524B
- ANSI/ISA 62443-4-1
- ENISA GENERAL-11.01
Part 01 Scope and definitions
What a medical device penetration test is
A time-boxed, manual attack on one device build, the software that ships with it and the services it talks to, carried out by people who did not design it.
A medical device penetration test starts from a defined build: a firmware version, a companion application version, a backend release and the accounts and interfaces a real user or a real attacker can reach. Testers work through those interfaces the way an adversary would, chain what they find, and record what the device does about it. The output is a report with a scope, a duration, a method and a set of findings, each with the evidence needed to reproduce it.
The regulatory frame is short. MDR Annex I, point 17.2 requires software in a device to be “developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation”. IVDR Annex I point 16.2 is the same sentence. Two lines of law import whatever the state of the art happens to be, and MDCG 2019-16 rev.1 is where the Medical Device Coordination Group writes down what that means in practice.
Chapter 3.7 of that guidance is the sentence to know: “The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing.” A footnote defines penetration testing, via ENISA, as “the assessment of the security of a system against different types of attacks performed by an authorised security expert”. Chapter 4.1 then files it: Annex II documentation “shall comprise a justification, validation and verification of the solutions adopted to meet those requirements (e.g. methods and results of security testing described in Chapter 3.7 of this guidance)”.
On the US side the requirement is statutory rather than interpretive. Section 524B of the FD&C Act, added by the Food and Drug Omnibus Reform Act of 2022 and effective 29 March 2023, makes cybersecurity information part of the content of any 510(k), PMA, PDP, De Novo or HDE for a cyber device. The FDA guidance issued on 3 February 2026 says penetration test reports “should be provided”, lists the five elements they must contain, and puts tester independence first on that list.
Part 02 Requirements and guidance
The requirements behind test evidence
Eleven entries drawn from regulations and guidance. Their legal effect and applicability differ; each identifies its source.
- MDR I · 17.2
State-of-the-art software development, including information security
“For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.” Regulation (EU) 2017/745, consolidated 10 January 2025. IVDR Annex I point 16.2 is the mirror text.
- MDR I · 17.4
Minimum hardware, IT network and IT security requirements
“Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.” The same words appear at IVDR Annex I point 16.4. MDCG 2019-16 §3.6 adds that these requirements are the manufacturer’s to determine, and that they must not become a way of compensating for the device’s own weaknesses.
- MDCG §3.7
Testing as the primary means of security verification and validation
“The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing.” MDCG 2019-16 rev.1, chapter 3.7. The accompanying footnote takes the ENISA definition of penetration testing.
- MDCG §4.1
Security testing results belong in the Annex II documentation
Documentation “shall comprise a justification, validation and verification of the solutions adopted to meet those requirements (e.g. methods and results of security testing described in Chapter 3.7 of this guidance)”, and “needs to be updated with information raised through the manufacturers post market surveillance system related to handling and remediation of cybersecurity incidents and vulnerabilities”.
- MDR II · 6
Results and critical analyses of all verification and validation tests
Annex II section 6: “The documentation shall contain the results and critical analyses of all verifications and validation tests and/or studies undertaken to demonstrate conformity of the device with the requirements of this Regulation.” Section 6.1(b) names software verification and validation specifically, including all hardware configurations and operating systems the manufacturer identifies.
- MDR Art. 83(3)
The file is kept current from post-market surveillance
Article 83(1) makes post-market surveillance part of the quality management system. Article 83(3) lists what the data are used for and closes with the sentence that governs a security file: “The technical documentation shall be updated accordingly.”
- 524B(a)
Cybersecurity information is part of the submission
A person who submits a 510(k), PMA, PDP, De Novo or HDE for a device meeting the section 524B(c) definition of a cyber device must submit information to ensure the device meets the requirements in 524B(b). The definition has three limbs: software validated, installed or authorised by the sponsor; the ability to connect to the internet; and technological characteristics that could be vulnerable to cybersecurity threats.
- 524B(b)(3)
An SBOM, including commercial, open-source and off-the-shelf components
The FDA recommends machine-readable SBOMs consistent with the minimum elements identified in the October 2021 NTIA “Framing Software Component Transparency” document, plus, for each component, the level of support provided through monitoring and maintenance and the component’s end-of-support date.
- FDA V.C
A penetration test report with five named elements
“Penetration test reports should be provided and include the following elements: Independence and technical expertise of testers; Scope of testing; Duration of testing; Testing methods employed; and Test results, findings, and observations.” Cybersecurity in Medical Devices, FDA, 3 February 2026.
- FDA V.C
Post-release testing at regular intervals, for example annually
“After release, cybersecurity testing should be performed at regular intervals commensurate with the risk (e.g., annually) to ensure that potential vulnerabilities are identified and able to be addressed prior to their ability to be exploited.”
- ENISA 11.01
Hospitals now ask for the evidence at procurement
Control GENERAL-11.01 in ENISA’s procurement guidelines for hospitals and healthcare providers (July 2026), marked Level 1 and applying to all procurement service types: “Confirm that security validation (e.g., penetration testing, audits, independent assessments) is performed on procured products or services before deployment.” The party who produces that evidence is the vendor.
The MDR and IVDR entries are quoted from the consolidated texts of 10 January 2025 (02017R0745 and 02017R0746, revision 005.001). Guidance entries are quoted from MDCG 2019-16 rev.1 (December 2019, July 2020 rev.1) and the FDA guidance issued 3 February 2026. This is a description of published requirements, not legal advice on your device.
Part 03 Interactive · rules from the cited instruments
Build the cybersecurity evidence file for your device
Set the markets and device characteristics. The panel suggests requirements to assess, test evidence to prepare, and where to file it. Confirm legal scope and device classification before treating an entry as applicable.
Interactive mode is not available. You can read the full reference content below. No answers are assessed and no result is calculated.
- Placing the device on the EU market. MDR Annex I points 17.2 and 17.4 apply, with IVDR points 16.2 and 16.4 as the mirror text. MDCG 2019-16 rev.1 §3.7 names penetration testing among the methods of security verification and validation, and §4.1 files the methods and results in the Annex II technical documentation. MDR Annex II section 6 requires the results and critical analyses of all verification and validation tests, and Article 83(3) requires the documentation to be updated as post-market surveillance produces new information.
- Submitting to the FDA. Section 524B of the FD&C Act applies to any 510(k), PMA, PDP, De Novo or HDE covering a cyber device. The submission carries a vulnerability plan under 524B(b)(1), processes under 524B(b)(2) and an SBOM under 524B(b)(3). The February 2026 guidance asks for a penetration test report containing the independence and technical expertise of testers, the scope, the duration, the methods employed, and the results, findings and observations, and for the original third-party report where one exists.
- Wireless, wired or cloud connectivity. Radio and network interfaces bring pairing, key exchange, replay, unauthenticated commands and listening services into scope, and make the FDA’s multi-patient harm view substantive. A manufacturer-hosted backend brings related systems in as well: the FDA counts update servers and connections to healthcare facility networks among them.
- A field update mechanism. The updateability and patchability view has to describe the end-to-end deployment path, including technology the manufacturer does not control. Testing covers signature and version verification, rollback and downgrade behaviour, and the server-to-device path.
- Patient data on the device. MDCG 2019-16 Table 3 lists personal data storage confidentiality, personal data integrity and authenticity, and de-identification among the indicative security capabilities. Testing covers protection at rest, key storage, factory reset and what can be recovered from a decommissioned unit.
- Selling into an EU hospital. ENISA’s July 2026 procurement guidelines make independent security validation before deployment a Level 1 control for all procurement service types, and ask buyers to request an MDS2 form from device suppliers.
- After release. The FDA expects testing at regular intervals commensurate with the risk, for example annually. In the EU the trigger is significant change plus whatever post-market surveillance produces, because the technical documentation has to be updated accordingly.
Markets you place the device on
Device characteristics
No market selected. Add the European Union, the United States, or both to see the requirements covered by this reference.
Section 524B applies to covered premarket submissions for a cyber device meeting all three statutory criteria: sponsor-authorized software, internet connectivity, and characteristics potentially vulnerable to cyber threats. These interface choices do not establish that classification. Confirm it using the FDA definition before applying the 524B entries.
You selected the US market without a network, wireless or cloud interface. The 524B entries are conditional: they apply only to covered submissions for a device meeting all three cyber-device criteria, including the ability to connect to the internet. The tool does not establish that classification.
With no connectivity, no update path and no stored patient data, the FDA expects the documentation to scale down: a device with a single hardware connection “will likely only need to have single architecture view for each of the global system, multi-patient harm, and updateability/patchability views”.
Requirements to assess
- MDR I · 17.2 State-of-the-art software development, including information security Development life cycle, risk management, verification and validation. IVDR Annex I point 16.2 is identical.
- MDR I · 17.4 Minimum hardware, IT network and IT security requirements Set by you, published in the instructions for use, and not a way of compensating for weaknesses in the device.
- MDCG §3.7 Security verification and validation by testing Penetration testing is one of the named methods, alongside security feature testing, fuzz testing and vulnerability scanning.
- MDCG §4.1 Methods and results of security testing in the documentation Filed with the justification, validation and verification of the solutions adopted, and kept updated from post-market surveillance.
- MDR II · 6 Results and critical analyses of all verification and validation tests Including software verification and validation across every hardware configuration and operating system you identify.
- MDR Art. 83(3) Technical documentation updated from post-market surveillance A finding after release is a reason to revise the file, not only the product.
- NIS2 21(2)(e) Security in acquisition, development and maintenance Device and IVD manufacturing is listed in NIS2 Annex II point 5(a). Applicability also depends on Article 2 scope rules and national implementation; placing a device on the EU market alone does not establish it. In-scope entities must assess Article 21 measures, including vulnerability handling and supply-chain security.
- ENISA 11.01 Independent security validation before deployment An ENISA Level 1 procurement recommendation covering all procurement service types. It may become a buyer requirement when adopted in a tender; the guidance alone does not impose a legal duty on every hospital or supplier.
- 524B(a) Cybersecurity information in the premarket submission Required for a 510(k), PMA, PDP, De Novo or HDE covering a cyber device, and for modifications submitted through those pathways.
- 524B(b)(1) A plan to monitor, identify and address postmarket vulnerabilities Including coordinated disclosure and a justified regular update cycle, with out-of-cycle patches for critical vulnerabilities that could cause uncontrolled risks.
- 524B(b)(2) Processes providing a reasonable assurance of cybersecurity Covering the device and its related systems, and demonstrated through the documentation summarised in Appendix 4 of the guidance.
- 524B(b)(3) A software bill of materials Commercial, open-source and off-the-shelf components, machine-readable, with support level and end-of-support date per component.
- FDA V.C A penetration test report with five named elements Independence and technical expertise of testers, scope, duration, methods employed, and results, findings and observations.
- FDA V.B Security architecture views Global system, multi-patient harm, updateability and patchability, and security use case views, each with diagrams and explanatory text.
- FDA V.C Post-release testing at regular intervals, for example annually Commensurate with the risk, so that vulnerabilities are found before they can be exploited.
- FDA VII.C.2 Related systems inside the assurance boundary The FDA counts manufacturer-controlled elements such as software and firmware update servers and connections to healthcare facility networks as related systems.
Test evidence to prepare
- TEST Independent penetration test of the defined build One report covering the device, its companion software and the services it talks to, with the tester’s independence from the development team stated on the front page.
- TEST · RF Radio interface testing Pairing and bonding, key exchange, replay and injection on the air interface, unauthenticated commands, and what the device accepts while unpaired or in service mode.
- TEST · NET Network service testing Every listening port and service, authentication on each, transport protection, and what a device on the same hospital segment can reach without credentials.
- TEST · UPD End-to-end update path testing Signature and version verification on the device, rollback and downgrade behaviour, and the whole path from the update server to the device, including technology you do not control.
- TEST · DATA Stored data and recovery testing Protection of patient data at rest, key storage, what survives a factory reset, and what can be recovered from removable media or a decommissioned unit.
- TEST · API Backend and API testing Device-to-cloud authentication, tenant and account isolation, object-level authorization on clinician and patient data, and administrative interfaces.
- ANALYSIS Multi-patient harm analysis The FDA asks how the device and the systems it operates in defend against attacks with the potential to harm multiple patients at once, for example a fleet of bedside monitors restarting together.
- TEST · 62443 Vulnerability testing described in ANSI/ISA 62443-4-1 Abuse and misuse cases with malformed and unexpected inputs, robustness and fuzz testing, attack surface analysis, vulnerability chaining, closed-box known-vulnerability scanning, software composition analysis of binaries, and static and dynamic analysis including hardcoded and default credentials.
- ARTIFACT Machine-readable SBOM with support metadata NTIA baseline attributes plus, for each component, the level of support provided through monitoring and maintenance and the end-of-support date.
- TEST · CODE Secure code analysis and open-source component scanning MDCG 2019-16 §3.7: “Additional security testing can be done by using tools for secure code analysis and tools that scan for open source code and libraries used in the product, to identify components with known issues.”
- ANALYSIS Security risk management output the test can be traced to MDCG 2019-16 §3.2 keeps security risk analysis, evaluation, control and residual-risk evaluation inside the device risk management process. Findings have to land back in it.
- ANALYSIS Verification of the minimum IT requirements you publish The operating-environment assumptions you state under 17.4 are testable claims. MDCG §3.6 says reliance on the environment should be kept to a minimum and documented where it exists.
- CADENCE Retest on significant change, and whenever surveillance says so Article 83(3) makes the technical documentation follow the post-market surveillance data, so a new attack path against your component stack is a file event.
- CADENCE Post-release testing at regular intervals, for example annually Plan the cadence in the cybersecurity management plan and justify it against the risk of the device.
Where the evidence is filed
- FILE · EU Annex II technical documentation, section 6 Results and critical analyses of all verification and validation tests, with the security testing methods and results from MDCG §3.7.
- FILE · EU Instructions for use The minimum hardware, IT network characteristics and IT security measures needed to run the software as intended, under MDR 23.4(ab) and IVDR 20.4.1(ah).
- FILE · EU Post-market surveillance file Handling and remediation of cybersecurity incidents and vulnerabilities, feeding revisions back into the technical documentation.
- FILE · EU Tender pack for hospital buyers Current independent security validation for ENISA GENERAL-11.01, and an MDS2 form, which PLAN-02.01 names as the best-practice request at procurement.
- FILE · US Premarket submission documentation Appendix 4, Table 1: cybersecurity risk management report with threat model, risk assessment, SBOM, vulnerability assessment and software support, unresolved anomalies, traceability; measures and metrics; architecture views; testing; labeling; cybersecurity management plans.
- FILE · US The original third-party report “For any third-party test reports, manufacturers should provide the original third-party report”, together with your assessment of every finding and the rationale for anything deferred.
- FILE · US Cybersecurity management plan Carries the justification for the regular update cycle and the schedule for periodic security testing after release.
- FILE · BOTH One test campaign, two reporting packs The technical work is the same. Write the evidence once and format it twice: methods and results into Annex II, the five named elements plus the original report into the submission.
This panel reproduces published requirements and links each source. It is not a regulatory determination: device classification, the conformity assessment route and the submission pathway are for you and your notified body or reviewer to establish.
Part 04 EU conformity file · US premarket submission
One test campaign, two evidence packs
The technical work behind a CE-marking file and an FDA submission is largely the same. What differs is what has to be written down, and how strictly independence is treated.
| Evidence | EU · notified body | US · FDA 524B |
|---|---|---|
| Penetration test report | MDCG 2019-16 §3.7 names penetration testing as a method of security verification and validation; §4.1 files the methods and results in Annex II | “Penetration test reports should be provided” with five named elements (guidance section V.C) |
| Tester independence | Not stated as a requirement in the MDR or in MDCG 2019-16 | The first required report element; third parties may be necessary, and the original third-party report must be provided |
| Scope, duration, methods, results | Annex II section 6: results and critical analyses of all verification and validation tests | Named individually as report elements |
| Threat model and architecture | Security risk management under MDCG §3.2 and §3.4; no prescribed set of views | Global system, multi-patient harm, updateability and patchability, and security use case views |
| SBOM | Not an Annex I requirement; component control sits inside state of the art and supplier management | Statutory under section 524B(b)(3), machine-readable, with support level and end-of-support date |
| Detailed vulnerability testing | MDCG §3.7 mentions fuzz testing, vulnerability scanning, secure code analysis and open-source component scanning | Enumerated against ANSI/ISA 62443-4-1, from abuse cases to binary composition analysis |
| Operating environment | MDR 17.4 minimum IT requirements, plus the MDCG §3.6 rule against compensating for device weaknesses in the environment | Carried by the security use case views and the labeling |
| Retest cadence | Significant change, plus whatever post-market surveillance produces: “The technical documentation shall be updated accordingly” | “At regular intervals commensurate with the risk (e.g., annually)” |
Only one side of this table has a hard rule on who runs the test. The FDA guidance says manufacturers “should indicate in the test reports by whom the testing was performed (e.g., independent internal testers, external testers) and what level of independence those responsible for testing devices have from the developers responsible for designing devices”, and adds that “in some cases, it may be necessary to use third parties to ensure an appropriate level of independence between the two groups”. Where a third party is used, “manufacturers should provide the original third-party report”.
The MDR says nothing about who performs the test. In practice a notified body reads an internal report against MDCG 2019-16 §3.7 and asks the same questions the FDA writes down: what was in scope, how long it ran, what methods were used, and who could have been marking their own homework. Commissioning one independent campaign and reporting it twice costs less than doing the work once for Europe and again for a submission.
Sequence matters more than volume. Run the campaign against a release candidate, close the findings you intend to close, retest the fixes, then freeze the report. A report that lists open critical findings with no assessment is worse than no report at all: the FDA asks for “your assessment of any findings including rationales for not implementing or deferring any findings to future releases”, and the same expectation reaches a notified body through the risk file.
Part 05 Scope of a connected-device campaign
What actually gets tested
A device is not one target. These are the surfaces a campaign is scoped across, and the capability from MDCG 2019-16 Table 3 that each one is there to exercise.
- SURFACE 1
The radio interface
Bluetooth Low Energy, Wi-Fi, cellular or a proprietary protocol. Pairing and bonding, key derivation and storage, replay and injection, what the device accepts while unpaired, and whether a service or engineering mode is reachable over the air. Node authentication, transmission confidentiality, transmission integrity.
- SURFACE 2
Wired network services
Every listening port on the device, the authentication on each, transport protection, and the DICOM, HL7 or vendor protocols in between. ENISA control GENERAL-06.02 asks hospital buyers to confirm that device networks are isolated or on dedicated segments, so testing from a shared segment reflects what they will ask about. Node authentication, system and OS hardening.
- SURFACE 3
The update path, end to end
Signature and version verification on the device, rollback and downgrade behaviour, and the whole route from the update server to the unit. The FDA is explicit that this path “will likely include traversing technology that the device manufacturer does not control”. Cybersecurity product upgrades, configuration of security features.
- SURFACE 4
Data at rest and the decommissioned unit
Storage of patient data and of keys, what a factory reset actually removes, what a service technician can extract, and what remains on removable media or a returned device. Personal data storage confidentiality, personal data integrity and authenticity, personal data de-identification.
- SURFACE 5
The companion application
Mobile or desktop software that ships with the device: local storage, credential handling, certificate validation, the pairing flow, and the protocol it speaks to the device. MDCG 2019-16 §3.6 treats anything you did not supply as the operating environment, which makes the boundary a documentation decision as much as a technical one. Person authentication, automatic logoff, emergency access.
- SURFACE 6
The manufacturer backend
Clinician portal, device-management service, telemetry ingestion and the update server. Device-to-cloud authentication, tenant and account isolation, object-level authorization, and administrative interfaces. The FDA treats update servers and healthcare-facility network connections as related systems under 524B(b)(2). Authorization, audit controls, data backup and disaster recovery.
- SURFACE 7
Service and maintenance access
Debug headers, service menus, maintenance accounts, remote support tooling and the credentials that go with them. ENISA control GENERAL-06.08 puts strictly controlled remote maintenance access to medical devices on the buyer’s checklist. Physical locks, configuration of security features, audit controls.
The capability names in italics are quoted from Table 3, “Indicative list of security Capabilities for MD”, in MDCG 2019-16 rev.1 §3.3. The table is indicative, not a checklist: which capabilities apply is an output of your security risk management.
Part 06 FDA guidance section V.C · MDR Annex II section 6
What has to be in the report
Five elements are named by the FDA. Two more are what a notified body needs in order to accept the report as verification and validation evidence.
- ELEMENT 1
Independence and technical expertise of testers
Named first. The guidance asks manufacturers to state “by whom the testing was performed (e.g., independent internal testers, external testers) and what level of independence those responsible for testing devices have from the developers responsible for designing devices”, and notes that “in some cases, it may be necessary to use third parties to ensure an appropriate level of independence between the two groups”.
- ELEMENT 2
Scope of testing
Which build, which interfaces, which accounts and roles, which backend environment, and what was excluded and why. The scope statement is what a reviewer compares against your own architecture views.
- ELEMENT 3
Duration of testing
Calendar window and tester effort. A three-day review of a networked infusion platform reads differently from a three-week campaign against the same device, and the report should let a reviewer see which one happened.
- ELEMENT 4
Testing methods employed
The techniques actually used, including tooling. Footnote 47 of the guidance asks for “the name of the tool, version information as applicable, and any settings or configuration options for the tools used”.
- ELEMENT 5
Test results, findings and observations
Every finding with the evidence to reproduce it, plus, separately, “your assessment of any findings including rationales for not implementing or deferring any findings to future releases”. Deferred issues need a release plan: which vulnerabilities, when, whether interim devices receive the update and how long it takes to reach them.
- EU · A
A traceable link back to the security risk file
MDCG 2019-16 §3.2 keeps security risk analysis, evaluation and control inside the device risk management process. A report that cannot be traced to the risk controls it exercised is hard to file as verification of those controls under Annex II section 6.
- EU · B
The original report, unedited
The FDA requires the original third-party report where a third party performed the work. Keeping the same document in the EU technical file, rather than a summary written afterwards, means one artifact answers both reviewers.
The five named elements are quoted verbatim from Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, FDA, 3 February 2026, section V.C. The document is marked “Contains Nonbinding Recommendations” on every page; section 524B of the FD&C Act is the binding requirement it supports.
Part 07 ENISA · health sector
Why the buyer side is asking
Hospital procurement did not tighten in the abstract. These are the figures ENISA publishes for the sector your devices are sold into.
- of analysed health-sector incidents were ransomware
- 54%
- Jan 2021 – Mar 2023
- of analysed incidents affected healthcare providers, in particular hospitals
- 53%
- Jan 2021 – Mar 2023
- of health-related incidents in the 2024 threat landscape were ransomware
- 45%
- ENISA Threat Landscape 2024
- of those health-related incidents were data breaches
- 28%
- ENISA Threat Landscape 2024
Figures as published by ENISA on its health sector page, with the periods it states. ENISA also records that health is the most affected sector for four years in a row (2020-2023) in significant NIS incidents reported through CIRAS. Source: ENISA, Health
Part 08 Four guides · primary sources only
Read the requirement, not the summary
Each guide quotes the instrument or guidance it describes, links the document it was checked against, and says where the evidence is filed.
- 01 MDR Annex I point 17: the cybersecurity requirement in full Two paragraphs of law create the entire EU device cybersecurity file. Here is the text, what “state of the art” imports, and how MDCG 2019-16 turns it into evidence. Read
- 02 The penetration test report FDA asks for under section 524B Five named elements, an independence question the guidance answers directly, and a requirement to hand over the original third-party report. What a 524B submission expects from a test. Read
- 03 One test campaign, two evidence packs: EU and US together The technical work behind a CE marking file and an FDA submission is largely the same. How to scope, run and report a single campaign so it serves both without being rewritten. Read
- 04 What an EU hospital asks a device vendor for before it buys ENISA published procurement guidelines for hospitals in July 2026. One baseline control asks buyers to confirm independent security validation before deployment. The vendor produces that evidence. Read
Part 09 Frequently asked
Questions manufacturers ask first
Short answers with the citation attached. Where a source does not settle a question, the answer says so.
Does the MDR require a penetration test?
Not by name. MDR Annex I point 17.2 requires software to be developed in accordance with the state of the art including information security, verification and validation, and Annex II section 6 requires the results and critical analyses of all verification and validation tests in the technical documentation. MDCG 2019-16 rev.1 §3.7 is where penetration testing is named, as one method among security feature testing, fuzz testing and vulnerability scanning, and §4.1 places the methods and results of that testing in the Annex II documentation. Guidance is not law, but it is what a notified body works from.
Does the FDA require an external tester?
It requires the report to state the independence and technical expertise of the testers, and says that “in some cases, it may be necessary to use third parties to ensure an appropriate level of independence between the two groups”. Where a third party is used, the original third-party report must be provided. So the rule is not “external always”; it is that you declare the level of independence, and that a low one has to be defensible for a device of that risk.
How often do we have to retest?
For the US market the guidance is explicit: “After release, cybersecurity testing should be performed at regular intervals commensurate with the risk (e.g., annually).” For the EU there is no stated interval. The trigger is significant change plus post-market surveillance, because MDR Article 83(3) ends with “The technical documentation shall be updated accordingly.” In practice most manufacturers selling into both markets run one annual campaign and use it for both.
Is our device a “cyber device” under section 524B?
Section 524B(c) defines it as a device that “(1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats”. All three limbs, in the statutory wording. Internet capability is the one that most often decides it, and it is capability rather than intended use.
Does the Cyber Resilience Act apply to our device?
No. Article 2(2) of Regulation (EU) 2024/2847 states that the regulation “does not apply to products with digital elements to which the following Union legal acts apply: (a) Regulation (EU) 2017/745; (b) Regulation (EU) 2017/746; (c) Regulation (EU) 2019/2144.” Devices and IVDs are out. Two things still reach you: products in your catalogue that are not devices, and the CRA-grade expectations your own suppliers will start meeting. Article 2(5) also lets the Commission adjust the boundary by delegated act, so it is worth rechecking rather than assuming it is settled forever.
Is EN IEC 81001-5-1 mandatory?
It is not cited in the Official Journal as a harmonised standard under Regulation (EU) 2017/745, so it carries no presumption of conformity. We checked that against Commission Implementing Decision (EU) 2021/1182 and all eleven amendments published to date, the most recent on 11 June 2026: none of them references 81001. That does not make secure-lifecycle evidence optional, because Annex I point 17.2 imports the state of the art regardless of what has been cited.
Are device manufacturers essential or important entities under NIS2?
Manufacturers of medical devices and IVDs are listed in Annex II point 5(a) of Directive (EU) 2022/2555, which is the “other critical sectors” annex, with an exception for makers of devices considered critical during a public health emergency, who sit in Annex I. Most commentary gets this backwards. Article 21(2)(d) and (e) are the measures that touch a product security programme directly: supply chain security, and security in acquisition, development and maintenance including vulnerability handling and disclosure.
What will a hospital ask us for before it buys?
ENISA’s procurement guidelines for hospitals and healthcare providers, published in July 2026, make GENERAL-11.01 a Level 1 control for all procurement service types: confirm that security validation, expressly including penetration testing, audits and independent assessments, is performed on procured products before deployment. Alongside it, PLAN-02.01 names the MDS2 form as best practice to request from device suppliers, PLAN-02.02 asks for evidence of following accepted guidelines and standards, and SOURCE-06.01 asks for contract clauses on timely vulnerability disclosure and patching.
What does a device penetration test cost?
This site does not publish a price, because a number without a scope is not information. The cost drivers are countable: the number of physical and radio interfaces, whether firmware has to be extracted and analysed, how many roles and tenants exist in the backend, whether a companion application is in scope, how many device units and spare parts you can supply, and how much retest is needed after remediation. A scoping call that walks those seven items produces a defensible figure; a rate card does not.
Can we reuse last year’s report for a new submission?
Only if the build has not moved. The guidance is clear that a modification submitted through one of the enumerated pathways also has to meet section 524B, and that changes which may impact cybersecurity “could include changes to authentication or encryption algorithms, new connectivity features, or changing software update process/mechanisms”. A report against a superseded firmware version is evidence about a device you no longer sell.