IEC 81001-5-1 specifies the cybersecurity activities that belong in the health software development lifecycle. Published in 2021, it maps onto the IEC 62304 process structure and adds the security work — threat modelling, secure design and coding, verification, and vulnerability handling after release — that 62304 itself does not cover.
In the EU this is the standard that gives practical shape to the cybersecurity requirements in MDR Annex I, which are otherwise stated too generally to build against. MDCG 2019-16 is the accompanying guidance.
Its most useful contribution to a small team is the insistence that vulnerability handling is a lifecycle obligation. A device shipped with a clean scan and no route to deliver a patch eighteen months later does not meet the intent. In practice that means a software bill of materials you actually regenerate, a monitored disclosure channel, and a validated update path designed before launch rather than improvised during an incident.
Safety risk assumes random failure; security risk assumes an adversary who picks the worst moment. Probability means something different in each. Keep the analyses linked but separate, and feed security findings with safety consequences into the 14971 file explicitly.
A test at the end verifies; it does not design. The weight of the standard sits in threat modelling and in secure design decisions made early enough to change the architecture.
The regulatory question after a disclosed vulnerability is not whether you can write the patch. It is whether you can validate and deliver it to fielded devices under change control.
The standard itself is not law. EU MDR Annex I does impose cybersecurity requirements, but states them too generally to build against, and 81001-5-1 has become the practical route to demonstrating them — increasingly what notified bodies expect to see. Meeting it is voluntary; meeting the underlying requirement is not.
Effectively yes. The standard requires you to identify third-party components and monitor their vulnerabilities, which is not achievable without a maintained inventory. FDA also expects an SBOM for cyber devices in premarket submissions. The test is whether you regenerate it as the product changes, not whether one exists.
It maps onto the same lifecycle structure and extends it with security activities, including widening the SOUP process to cover known vulnerabilities rather than only functional anomalies. They are meant to run as one process, not two parallel ones — the documentation overlaps heavily and separating them duplicates work.
Working out how IEC 81001-5-1 applies to what you are building is usually the first conversation.
Get in touch →