Published on October 15, 2026
Security for medical devices is more than just compliance. A medical device can meet all standards and still be vulnerable. Standards such as IEC 81001-5-1 or the requirements of the MDR describe what a manufacturer must demonstrate. They do not guarantee that an attacker will fail. Compliance therefore demonstrates that processes were followed, but it is not the goal. Whether a product is actually secure is determined throughout its entire lifecycle: in design, in development, and on the market. Anyone who takes “security by design” seriously therefore starts early and thinks beyond the checklist. This article shows where false security arises and how manufacturers can avoid it. This article shows where false security arises and how manufacturers can avoid it.
What Does Safety Mean in the Context of Medical Devices? Safety, Security, and Compliance
When you ask about safety, you usually get four answers: no harm to patients, data protection, CE marking, and a successful penetration test. The first two describe an outcome, while the other two are merely proofs. Behind these lie three questions:
Compliance is proof, not the goal. The goal lies where all three converge: safe and verifiable. False security arises on the periphery. Compliance without protection appears safe but isn’t, and protection without proof cannot be demonstrated. Where safety and security converge, an attack results in patient harm: a tampered measurement leads to an incorrect treatment decision.
Security by Design for Medical Devices: Safety Is Built into the Design, Not Through Audits
The later security is incorporated into a project, the more expensive and less effective it becomes. Security by Design therefore begins with the requirements. Security requirements are derived from the intended use, the operating environment, and regulatory requirements, and they form part of an iterative cycle with the cybersecurity risk analysis. The analysis is never complete at the start of the project because it generates new requirements.
The principles are secure defaults, least privilege, defense in depth, and requirements formulated in a way that allows for testing. “The system must be secure” cannot be tested. “Updates are signed and verified before installation” can be tested.
The architecture determines early on what can be protected later. Trust boundaries exist between devices or apps, the cloud backend, and any hospital IT systems. These include segmentation, authentication between components, authorization in the backend, signed updates, cryptoagility, and—in the case of the cloud—a clearly defined shared responsibility model.
One example is the login process. Attackers without access must first find vulnerabilities. Attackers with valid login credentials act like normal users: the controls don’t work, and the logs look normal. Decisions such as “MFA optional,” “password rules are set by the operator,” or “no lockout after failed attempts” often amount to unconscious risk acceptance. Passwords mean memorizing, typing, resetting, phishing, and that Post-it note on the monitor. The secure approach must be the simplest one, and there are many systems available to help with this:
The goal must be to make it easier for users to use a secure login system than to enter a password. This promotes both acceptance and security. And password resets and account recovery must be just as secure.
In Development: Knowledge, Scope, and Tools with Triage
Those who understand attacks develop software differently. This is achieved through product-focused training rather than mandatory e-learning, using examples from their own system, incorporating security into code reviews, using the OWASP Top 10 as a reference, and fostering a culture of openness where findings are welcomed.
A security expert needs a clear mandate. IEC 81001-5-1 belongs in the software development process, and security belongs in the “Definition of Done.” Documentation is created alongside the product and is not written retroactively. Its backbone is traceability—from the threat, through the requirement, to the test.
Tools belong in the CI pipeline: secret scanning on commit, static code analysis (SAST), and dependency scanning (SCA) during the build, fuzzing and dynamic testing (DAST) during testing, and IaC scanning and penetration testing at release. A tool without a triage process offers only a false sense of security.
Dependency scanning, secure defaults, modern login procedures, and a designated security champion yield quick results. Ownership within the team, incorporating security into the “Definition of Done,” and a culture of learning from mistakes have a lasting impact. Mandatory e-learning, documentation written in reverse, and tools without triage offer little benefit.
In the Market: Post-Market Safety of Medical Devices
A Software Bill of Materials (SBOM) without monitoring is a document, not an action. The cycle runs continuously: SBOM in CycloneDX or SPDX format, comparison with the National Vulnerability Database and CSAF advisories, assessment using VEX (is the vulnerability exploitable?), and action: patch, notification, or acceptance.
Post-market surveillance for cybersecurity draws on threat intelligence, BSI and CERT reports, logging and anomaly detection, a policy for coordinated vulnerability disclosure (CVD), and feedback from operators.
When an incident occurs, the incident response process consists of six steps: detect, assess (by the PSIRT), report, patch, recover, and learn. When it comes to reporting requirements, check the MDR vigilance requirements, the GDPR’s 72-hour deadline, and NIS2 if the manufacturer is affected. Recovery includes backup and restore, cloud-based disaster recovery, and communication with operators. Practice before things get serious.
"Accepted" does not mean "forever." A new attack technique, a new CVE, an architectural change, or a fixed interval triggers a reassessment. The end of the product lifecycle is also part of this: When end-of-support is announced and the product is considered legacy in the field, this must be planned and communicated to the operators.
What Manufacturers Can Expect
The threat landscape is shifting in three directions: AI-powered attacks (sophisticated phishing, automated vulnerability scanning, faster exploits), cloud dependency (outages as a supply chain risk, misconfiguration, shared responsibility), and the supply chain (libraries, build pipelines, service providers). Regulatory frameworks are catching up.
Already relevant:
Here it comes:
Conclusion
Frequently Asked Questions About Medical Device Safety
What you'll find on our website
- Cybersecurity – Risk management throughout the product lifecycle, secure software architecture, and documentation in accordance with EU, FDA, and BSI requirements.
- Post-Market Surveillance – We continue to support you even after the product has been placed on the market: monitoring error logs, market updates, and cybersecurity information to identify risks early on.
Sources
- Regulation (EU) 2017/745 (MDR), Consolidated Version
- BfArM, Cybersecurity of Medical Devices
- MDCG 2019-16 Rev. 1, Guidance on Cybersecurity for Medical Devices
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 2026
- Regulation (EU) 2024/2847 (Cyber Resilience Act), in particular Article 2(2), Article 14, Article 69, and Article 71
- Regulation (EU) 2024/1689 (AI Regulation)
- Directive (EU) 2022/2555 (NIS 2 Directive)
- Act on the Federal Office for Information Security (BSIG), New Version
- BSI, Questions and Answers on NIS-2
- Regulation (EU) 2016/679
- ISO 14971, IEC 62304, and IEC 81001-5-1