![\"Sebastian](\"https:\/\/www.bayoomed.com\/wp-content\/uploads\/sites\/4\/2026\/09\/Sebastian-Wittor-Senior-Project-Manager-BAYOOMED-295x300.jpg\" "\\"Sebastian")
<\/span><\/div><\/div><\/div><\/div>Sebastian Wittor<\/strong> Julia Schliesch<\/strong> Published on October 15, 2026<\/em><\/p>\n 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 \u201csecurity by design\u201d 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.<\/p>\n<\/div><\/div><\/div><\/div><\/div> 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:<\/p>\n<\/div> Safety:<\/strong> Does the product pose a risk to the patient? ISO 14971 and IEC 62304 address this issue.<\/p>\n<\/div><\/li> Security:<\/strong> Can anyone attack the product? That's what IEC 81001-5-1 addresses.<\/p>\n<\/div><\/li> Compliance:<\/strong> Can we demonstrate compliance with the requirements? These include, for example, MDR and FDA regulations.<\/p>\n<\/div><\/li><\/ul> 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\u2019t, 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.<\/p>\n<\/div><\/div><\/div><\/div><\/div> 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.<\/p>\n The principles are secure defaults, least privilege, defense in depth, and requirements formulated in a way that allows for testing. \u201cThe system must be secure\u201d cannot be tested. \u201cUpdates are signed and verified before installation\u201d can be tested.<\/p>\n 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\u2014in the case of the cloud\u2014a clearly defined shared responsibility model.<\/p>\n 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\u2019t work, and the logs look normal. Decisions such as \u201cMFA optional,\u201d \u201cpassword rules are set by the operator,\u201d or \u201cno lockout after failed attempts\u201d 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:<\/p>\n<\/div> Passkeys (FIDO2), phishing-resistant<\/p>\n<\/div><\/li> On-Device Biometrics<\/p>\n<\/div><\/li> Badge with PIN at the clinical workstation<\/p>\n<\/div><\/li> Single sign-on via the clinic's identity provider<\/p>\n<\/div><\/li> Quick User Switching on Shared Devices<\/p>\n<\/div><\/li> Break-glass for emergencies, with a log<\/p>\n<\/div><\/li><\/ul> 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.<\/p>\n<\/div><\/div><\/div><\/div><\/div> 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.<\/p>\n A security expert needs a clear mandate. IEC 81001-5-1 belongs in the software development process, and security belongs in the \u201cDefinition of Done.\u201d Documentation is created alongside the product and is not written retroactively. Its backbone is traceability\u2014from the threat, through the requirement, to the test.<\/p>\n 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.<\/p>\n Dependency scanning, secure defaults, modern login procedures, and a designated security champion yield quick results. Ownership within the team, incorporating security into the \u201cDefinition of Done,\u201d 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.<\/p>\n<\/div><\/div><\/div><\/div><\/div> 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.<\/p>\n 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.<\/p>\n 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\u2019s 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.<\/p>\n \"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.<\/p>\n<\/div><\/div><\/div><\/div><\/div> 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.<\/p>\n Already relevant:<\/p>\n<\/div> FDA Section 524B:<\/strong> Premarket Guidance, as of February 2026<\/p>\n<\/div><\/li> Cyber Resilience Act:<\/strong> Reporting Requirements Effective September 2026 for Components Not Covered by the MDR<\/p>\n<\/div><\/li> NIS2:<\/strong> In effect in Germany as of December 2025; applies to organizations in certain sectors that meet a specific size threshold<\/p>\n<\/div><\/li> MDCG 2019-16:<\/strong> Guidance on Cybersecurity for Medical Devices (non-binding)<\/p>\n<\/div><\/li><\/ul> Here it comes:<\/p>\n<\/div> Cyber Resilience Act<\/strong> to Take Full Effect in December 2027<\/p>\n<\/div><\/li> EU AI Act:<\/strong> Additional Requirements for AI-Based Medical Devices; read more in our article on AI system classification<\/a><\/p>\n<\/div><\/li><\/ul><\/div><\/div><\/div><\/div> Evidence:<\/strong> Compliance is the evidence, not the goal.<\/p>\n<\/div><\/li> Design:<\/strong> Safety is built into the design, not through an audit.<\/p>\n<\/div><\/li> Decision:<\/strong> Justify, document, and reassess risk acceptance.<\/p>\n<\/div><\/li>
\nSenior Project Manager, Medical Engineering<\/em>
\nSecure Software Engineering & AI
\nLinkedIn<\/a><\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div>![\"Julia](\"https:\/\/www.bayoomed.com\/wp-content\/uploads\/sites\/4\/2026\/05\/Julia-Schliesch-Juni-2021_verkleinert-scaled.jpg\" "\\"Optimized")
<\/span><\/div><\/div><\/div><\/div>
\nEditorial<\/em>
\nComplex technical topics - communicated clearly.
\nLinkedIn<\/a><\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div>What Does Safety Mean in the Context of Medical Devices? Safety, Security, and Compliance<\/h2><\/h2><\/div>
Security by Design for Medical Devices: Safety Is Built into the Design, Not Through Audits<\/h2><\/h2><\/div>
In Development: Knowledge, Scope, and Tools with Triage<\/h2><\/h2><\/div>
In the Market: Post-Market Safety of Medical Devices<\/h2><\/h2><\/div>
What Manufacturers Can Expect<\/h2><\/h2><\/div>
Conclusion<\/h2><\/h2><\/div>