In brief
For connected software or a medical device under the MDR, cybersecurity must be built into the product lifecycle, not added at the end of development. The MDR sets the requirements ; IEC 81001-5-1 helps translate them into development and maintenance activities, without today conferring a presumption of conformity. The point is not a parallel “cyber file”, but an SDLC where security decisions produce requirements, tests, evidence and traceable post-market actions.
Cybersecurity is not something you handle at the end of development
A medical software product can be functional, validated and clinically relevant… and still be fragile when a vulnerability is discovered after it is placed on the market.
That is precisely what makes cybersecurity different from a simple final check : threats evolve, third-party components change and new vulnerabilities appear throughout the device lifetime.
What the MDR actually requires for cybersecurity
The MDR does not contain a procedure titled “cybersecurity”. It imposes several requirements which, combined, require the manufacturer to control IT-security risks.
Annex I in particular requires that devices incorporating programmable electronic systems, or software that is itself a device, be developed and manufactured in accordance with the state of the art, taking into account the life cycle, risk management (including information security) as well as verification and validation.
The manufacturer must also define the minimum requirements concerning hardware, IT network characteristics and the security measures needed for the software to run as intended, including protection against unauthorised access.
And cybersecurity does not stop at CE marking.
MDCG 2019-16 Rev.1 provides that vulnerabilities, security incidents and changes in the threat landscape be taken into account during the device lifetime. They may lead to re-evaluating risks, deploying patches, performing further verification or updating the technical documentation.
Demonstrating conformity therefore does not consist in showing that a pentest was performed once. You must demonstrate that cybersecurity is controlled as a lifecycle process.
IEC 81001-5-1 : what the standard is actually for
IEC 81001-5-1:2021 defines lifecycle requirements for the secure development and maintenance of health software. It aims in particular to support conformity to the principles of IEC 62443-4-1 while taking account of the specificities of the health sector.
It therefore complements particularly well a software lifecycle already structured around IEC 62304.
Where IEC 62304 structures the development and maintenance of medical software, IEC 81001-5-1 provides a security-centred framework : organising cyber activities, security requirements, secure design and implementation, verification, vulnerability handling or maintenance.
But one regulatory point must be perfectly clear.
At the time of writing, IEC 81001-5-1 is not a harmonised standard under the MDR.
The European Commission included it in its standardisation request M/575 among the new harmonised standards to be developed, with an adoption deadline currently set at 27 May 2028. Its reference is however not published in the Official Journal of the European Union and it therefore does not today confer a presumption of conformity to the MDR.
That does not reduce its value.
It is a particularly relevant technical framework for structuring a secure development lifecycle. But two shortcuts must be avoided : applying IEC 81001-5-1 is not today an MDR regulatory obligation ; and applying it does not automatically demonstrate MDR conformity.
The real challenge : fold cyber into the SDLC, do not add a documentation layer
The classic trap is to treat cybersecurity as a parallel workstream.
The team develops the product. Then, shortly before a submission, an audit or a release, a threat analysis, a few scans and a pentest are added to the file.
The problem is not only documentary. If a threat identified late forces changes to architecture, authentication, encryption, logging or update management, the cost of change can become considerable.
Cybersecurity must therefore enter the same design loops as other product requirements.
Understand the product before choosing controls
Architecture, processed data, interfaces, users, use environment, dependencies and third-party components must be known.
From that context, threat analysis and security risk analysis make it possible to derive testable requirements : authentication, authorisation, encryption, integrity, availability, logging, secure update or interface protection.
The technical control comes after understanding the risk, not before.
Link cyber risks to patient-safety risks
Not every cybersecurity risk automatically becomes a patient-safety risk.
The MDCG explicitly distinguishes security risks with an impact on safety from those without.
Both dimensions must therefore be managed and linked when a compromise of confidentiality, integrity or availability can change device performance or contribute to harm.
Cyber risk management must therefore neither be absorbed entirely into ISO 14971, nor operate in a silo with no connection to the product risk management file.
Verify security as a product requirement
A cybersecurity requirement that is not verified remains an intention.
Implemented controls must be associated with proportionate verification methods : security functional tests, fuzz testing, vulnerability scans, code analysis or penetration testing when relevant. These are in particular the approaches identified by the MDCG for security verification and validation.
The goal is not to accumulate reports. It is to be able to link : threat → risk → requirement → control → test → release decision.
Cybersecurity starts before release, but a large part of its control is played afterwards : detect new vulnerabilities, assess their impact and decide whether a correction is needed, with which priority, which verifications and which communication. A controlled inventory of software components, often materialised by a Software Bill of Materials (SBOM), facilitates that monitoring. But a SBOM is not a cybersecurity strategy. Without monitoring, analysis and a remediation process, it remains an inventory.
Which evidence belongs in the technical documentation?
The technical documentation must make it possible to demonstrate how the applicable general safety and performance requirements are met and provide the justification, verification and validation of the solutions chosen. The MDCG explicitly links these expectations to cybersecurity.
There is therefore no single cybersecurity document that would be enough to answer the MDR.
Depending on the product, its architecture and its risks, evidence may in particular include:
- a cybersecurity management strategy or plan;
- a description of the architecture and security context;
- threat analysis and risk analyses;
- security requirements and controls;
- traceability between risks, requirements and verifications;
- test results and other verification activities;
- the software component inventory and control of third-party components;
- the vulnerability management process;
- update and patch modalities;
- security information communicated to users;
- evidence from post-market surveillance.
The MDCG also explicitly cites the SBOM among the security information that may be communicated for certain products, alongside implemented controls, user roles, logging or securing of updates.
The strength of the file comes, however, less from the number of documents than from their coherence. An identified vulnerability must be able to lead to an analysis, a decision, a modification if needed, a verification then evidence retained in the system.
Cybersecurity is also a QMS topic
IEC 81001-5-1 therefore does not concern only the technical team.
Vulnerability management touches change control. Third-party components touch supplier management. A cyber incident may feed PMS or vigilance. A patch touches design, validation and release management.
Cybersecurity cuts across the quality system.
For digital MedTech, the real objective is therefore to maintain the links between requirements, risks, tests, anomalies, components, versions and evidence as the product evolves.
That is also the value of an eQMS integrated with team tools : avoiding a cyber file maintained manually in a space separate from development.
The PULSE programme makes it possible to build this compliance architecture between QMS, software development and technical documentation, while Qapsule aims to strengthen orchestration and evidence traceability across the different tools.
Action plan
Are you already developing medical software and is cybersecurity not yet fully integrated into your lifecycle?
- Map the architecture and use environment : interfaces, flows, data, users, external systems and third-party components.
- Perform a gap analysis between your practices, applicable MDR requirements, MDCG 2019-16 Rev.1 and IEC 81001-5-1.
- Formalise your threat and security-risk analysis, then identify the links with patient-safety risks.
- Turn security measures into testable requirements integrated into the requirements management system or the product backlog.
- Build traceability between threats, risks, requirements, controls, tests and releases.
- Control third-party components and maintain an inventory usable for vulnerability monitoring.
- Define before placing on the market how a new vulnerability will be received, assessed, corrected, verified and communicated.
- Connect cybersecurity to the QMS : change control, suppliers, CAPA, PMS, vigilance and document control.
- Test the system on a real release, for example during an internal audit, rather than only checking that procedures exist.
The most revealing test is simple : take a potential vulnerability and try to follow its full path, from detection through to proof of control.
Conclusion
The useful question is not only “Which cyber documents should we produce?”, but: “Is our development cycle able to detect a threat, measure the risk, derive a requirement, verify the control and maintain that control after release?” When that system works, documentation becomes the natural evidence of what teams actually do, not a reconstruction the night before an audit.
FAQ
Is IEC 81001-5-1 mandatory under the MDR?
No. The MDR requires the manufacturer to demonstrate conformity to the applicable general safety and performance requirements. Use of standards remains voluntary.
IEC 81001-5-1 can be an excellent way to structure the cybersecurity lifecycle, but applying it is not in itself a regulatory obligation.
Is IEC 81001-5-1 harmonised under the MDR?
No, not at the time of writing.
The standard appears in Commission standardisation request M/575, with an adoption deadline currently set at 27 May 2028 for the requested harmonised standard. Its reference is not yet published in the Official Journal of the European Union.
You should therefore not claim MDR presumption of conformity on that basis today.
What is the difference between IEC 62304 and IEC 81001-5-1?
The two standards are complementary.
IEC 62304 structures the processes of the medical software lifecycle.
IEC 81001-5-1 focuses on the activities needed to secure the development and maintenance of health software and draws in particular on the principles of IEC 62443-4-1.
The goal is therefore not to choose one or the other, but to integrate their relevant activities into the same development cycle.
Does the MDR require a SBOM?
The MDR does not explicitly require, in Annex I, a deliverable named “SBOM”.
MDCG 2019-16 Rev.1 nevertheless cites the Software Bill of Materials among the security information that may be provided depending on the product.
In software relying on many third-party or open-source components, having a usable inventory becomes especially essential to identify quickly whether a new vulnerability concerns the product.
Is a penetration test enough to demonstrate the cybersecurity of a medical device?
No. A pentest is one possible verification technique, but it does not replace risk analysis, security requirements, secure design activities, or vulnerability management after placing on the market.
The MDCG also cites several possible verification techniques, including tests of security functions, fuzz testing, vulnerability scanning or penetration testing.
How should cybersecurity be linked to ISO 14971?
You must distinguish IT-security risk from patient-safety risk, then create the links when one can lead to the other.
A vulnerability that allows access to information with no impact on device performance will not necessarily have the same consequences as an attack that can change a clinical result or make a function unavailable.
The MDCG explicitly distinguishes security risks with and without an impact on safety.
What should be monitored after placing on the market?
Surveillance should in particular make it possible to detect new security incidents, vulnerabilities affecting the product or its third-party components, and changes in the threat landscape.
That information must be assessed to determine whether measures are needed : communication, configuration change, software patch, component update or further verification.
Where should we start if the software is already in development?
Do not start by producing every missing document.
Start with a gap analysis : MDR requirements → current practices → IEC 81001-5-1 → available evidence.
Then identify the gaps that may affect architecture or an upcoming release. Those should be addressed before purely documentary gaps.
This article offers a pedagogical and operational reading of the cybersecurity requirements applicable to medical devices and of the use of IEC 81001-5-1 in an MDR context. The regulatory information and standardisation status presented were verified at the time of writing, in particular from Regulation (EU) 2017/745, MDCG 2019-16 Rev.1, European Commission publications and the IEC.
It does not constitute regulatory, legal or cybersecurity advice applicable to a particular device. The measures needed depend in particular on architecture, intended use, use environment, interfaces, third-party components and product-specific risks. Before any conformity decision, check the texts, guidance, standards and references published in the Official Journal of the European Union in their version in force.