Key Takeaways
- “State of the art” in EU MDR cybersecurity is not about using the latest technology. It is about using what is currently accepted, proven, and defensible during review
- Cybersecurity is directly tied to Annex I, which means it impacts both patient safety and CE certification outcomes
- Standards help structure your approach, but they do not guarantee compliance. What matters is how they are applied to your device
- Notified bodies focus on evidence, traceability, and clear justification, not just implementation claims
- Gaps usually appear in documentation, weak risk linkage, or unclear security decisions, rather than missing controls
- Post-market activities, such as vulnerability handling and updates, carry the same weight as design phase controls
Introduction
Medical devices have changed fast. What used to be standalone equipment is now part of a connected environment where software, cloud systems, and real-time data all work together. That shift has improved how you deliver care, but it has also made security a much bigger concern than before. Manufacturers must now demonstrate MDR state of the art cybersecurity by aligning their security measures with current standards and evolving threats.
You have probably seen what can go wrong. The WannaCry ransomware attack impacted over 200,000 systems across 150 countries, bringing parts of the UK’s National Health Service to a standstill, forcing hospitals to cancel appointments and delay treatment. Since then, attacks on healthcare have only increased, with European agencies like ENISA repeatedly flagging the sector as a prime target.
This is why Cybersecurity state-of-the-art MDR matters more than most teams expect. In 2026, it will include alignment with the EU AI Act for AI device use.
The challenge is that no one clearly defines it, yet you still need to prove it.
What “State of the Art” Actually Means
Under EU MDR, when you see MDR state of the art cybersecurity, it is not about chasing the newest technology. Article 2(24) describes it as a level of technical capability based on what is currently known and used. In real terms, industry experts expect you to follow practices that they already trust.
That usually means you should stick with controls and methods that have been proven to work. Not experimental ideas. Your setup should also reflect how attacks actually happen today, not how they looked five years ago.
People often compare your implementations with what others in your space are doing and what assessors typically see. For example, when properly configured, they still widely accept TLS 1.2, while organisations that adopt TLS 1.3 demonstrate alignment with more current security practices.
Why “State of the Art” Matters in EU MDR Compliance
Under EU MDR compliance, “state of the art” sits inside Annex I. So it is not something extra. It directly affects how your device is looked at from a safety perspective.
When security is off, the problem shows up in real use. A device can return the wrong result, someone might change the data without noticing, or users can experience access drops at the worst time. In connected systems, one issue can quickly affect everything around it.
A lot of teams run into trouble here. Something that worked a few years ago may not hold up anymore. During assessment, that gap becomes visible pretty quickly, and that is where delays start.
You will hear this linked back to Cybersecurity state of the art MDR when you are asked to explain your decisions. The focus remains on what you have implemented and whether it aligns with what is used across the industry today. Also, it defends against modern threat vectors like ransomware-as-a-service.
Where Cybersecurity is Required in EU MDR
Instead of going clause by clause, it is easier to look at Annex I in terms of what you actually need to have in place and show during a cybersecurity assessment:
| Area | What Needs to Be in Place | What Reviewers Expect to See |
| Access Control | Role-based access with clearly defined permissions and authentication that fits the risk level. This may include stronger controls where needed | Access control matrix and authentication design documentation |
| Data Protection | Encryption applied to stored data and data in transit using current and accepted methods such as AES-256 for data at rest and TLS 1.2 or above for data in transit | Encryption architecture diagrams and key management policies |
| Software Integrity and Updates | Secure update process that prevents unauthorised changes, along with mechanisms to ensure only trusted software runs on the device | Code signing approach and secure boot or equivalent protection |
| Instructions for Use (IFU) | Clear guidance on security settings, how updates should be handled, and what risks remain, along with how to manage them | Documented instructions that reflect real-world usage and user responsibilities |
Access Control: Permissions that are too broad or not clearly mapped tend to flag early during review.
Data Protection: Encryption alone is not enough if key handling is weak or poorly documented.
Software Integrity and Updates: If updates can be modified or installed without verification, it raises immediate concern. The lack of an SBOM is seen as a major regulatory hindrance.
Instructions for Use: If users are expected to take security-related actions, the team must clearly explain these, not assume them.
Role of MDCG 2019 16 in Defining Cybersecurity Expectations
MDR sets the requirement, but it rarely tells you what “good” looks like in practice. That is where MDCG 2019 16 comes in. It is what most teams end up relying on when they need to justify their cybersecurity approach.
One thing it makes clear early on is that security cannot be added later. It has to be part of the design. That is where threat modelling comes in. If this step is missing or too generic, reviewers usually notice it during the review.
It also pushes a layered setup. Relying on a single control is not enough. You are expected to cover the network, the application, and the device itself. Gaps between these layers are easily visible.
Vulnerability handling is another area where expectations have shifted. Fixing issues is not enough anymore. You need to show how you track them, how you receive reports, and how you roll out updates without creating new risks.
What reviewers often look for is a clear link between MDR, MDCG, and what you actually implemented:
| MDR Requirement | MDCG Guidance | Practical Implementation |
| Protection against unauthorised access | Authentication and authorisation | Role-based access, multi-factor authentication, and session control |
| Risk management | Security across the lifecycle | Threat modelling during design and regular updates |
| Protection against manipulation | Software integrity and authenticity | Code signing and controlled update process |
This kind of mapping answers most questions early, because it shows how your decisions connect back to both MDR and MDCG.
Book a Meeting to Identify Gaps in Your Current Cybersecurity Approach Under MDCG 2019-16.
Book a Meeting for Compliance Readiness
What Qualifies as “State of the Art” Cybersecurity in Practice?
At a practical level, “state of the art” is less about adding more controls and more about how well everything fits together. Reviewers tend to look at how security is handled across development, risk management, technical controls, and what happens after release.
1. Risk Management Integration
Cybersecurity is not treated separately. It is expected to sit inside your ISO 14971 process.
- Cyber risks should be identified alongside safety risks
- Risk-benefit analysis should include security-related scenarios
- Residual risk needs to be clearly justified, especially where full mitigation is not possible
This is where many gaps arise, especially when organisations document cyber risks but do not properly link them to overall risk decisions.
2. Secure Development
This usually shows up early in the review. If security was not considered during development, it becomes obvious.
- Threat modelling is expected at the design stage. Methods like STRIDE or attack trees are commonly used
- Secure coding practices should address known issues, such as those listed in OWASP Top 10 and CWE guidelines.
- Code reviews and static analysis (SAST/DAST) help catch problems before release
If these steps are missing or too high-level, it often leads to deeper questioning.
3. Technical Security Controls
Controls need to reflect current practice, and not just basic coverage.
- Encryption should follow accepted methods such as AES 256 for storage and TLS 1.2 or above for communication
- Strong authentication providers expect it in higher-risk scenarios, including multi-factor authentication, where relevant.
- Logging and monitoring should include audit trails and, where applicable, mechanisms for anomaly or intrusion detection to support timely response.
What matters here is consistency. Is security applied across the system or only in parts?
4. Post Market Security
Security does not stop after release, and this is where expectations have shifted the most.
- Ongoing monitoring of vulnerabilities through sources like CVE databases
- A defined patch management process, not ad hoc updates
- A clear incident response plan that can be followed when something goes wrong
If post-market handling is weak or unclear, it raises concerns quickly.
What Reviewers Compare in Practice
| Level | What It Looks Like |
| Outdated | Hardcoded passwords, no encryption, limited visibility into system activity |
| Acceptable | Basic encryption in place, updates released when needed, and some level of monitoring |
| State of the art | Continuous monitoring, structured patching process, regularly tested security controls, including methods like penetration testing |
Mapping EU MDR Requirements to Cybersecurity Standards
When you are building your case around cybersecurity, standards usually sit in the background as support. They help show that your approach follows what the industry already accepts, but they are not a shortcut to EU MDR compliance.
This is how things line up in practice:
| MDR Requirement | Standard | Purpose | What It Looks Like in Practice |
| Risk Management | ISO 14971 | Identify and assess risks | Organisations handle cyber risks alongside safety risks, not as a separate exercise. |
| Software Lifecycle | IEC 62304 | Control how software is developed | Security checks are part of development, not added at the end |
| Cybersecurity | IEC 81001-5-1 | Guide security across the product | Designers apply controls from design through to updates after release. |
| Information Security | ISO 27001 | Set up organisational controls | Internal policies, access rules, and governance are clearly defined. |
What this really does is give you something to point to. Instead of saying your approach is “secure”, you are showing that it lines up with how others are doing it and what regulators are familiar with.
But this is where many teams get caught out. Following a standard on paper does not mean much if the actual product does not reflect it. Reviewers will still look at what you built, not just what compliance standard you referenced.
How Notified Bodies Assess “State of the Art” Cybersecurity
Technical Documentation Review
Notified bodies begin with a detailed review of technical documentation to evaluate alignment with cybersecurity standards and MDR compliance. The following elements are examined:
- Cybersecurity risk management file, including identification, evaluation, and control of cyber risks within the overall risk framework
- Software architects document where and how security controls are implemented.
- Security requirements specification aligned with identified threats and the intended use of the device
Any lack of alignment between these documents can lead to further scrutiny.
Evidence They Expect
Implementation must be supported with verifiable evidence. High-level descriptions are not sufficient. Typical evidence includes:
- Threat modelling documentation with defined threats, attack paths, and mitigation measures
- Secure development lifecycle records demonstrating integration of security activities during development
- Security testing evidence, such as VAPT reports and validation results
Common Audit Questions
Notified bodies assess how organisations handle cybersecurity in practice through targeted questions:
- Who identifies, tracks, and resolves vulnerabilities after release
- What controls ensure the integrity and authenticity of software updates
- Which standards or guidance frameworks do we follow, and how do we apply them
Responses are evaluated based on clarity, completeness, and supporting evidence.
Key Insight
Assessment is based on objective proof aligned with MDR cybersecurity guidance. Notified bodies evaluate:
- Evidence supporting implemented controls
- Traceability between identified risks, applied controls, and residual risks
- Justification demonstrating that the approach aligns with current industry practices
Claims without supporting documentation or traceability do not meet the sufficient criteria.
Download a Sample Pentest Report Aligned with “State of the Art” Cybersecurity Expectations.
Get a Free Sample Pentest Report
How to Demonstrate “State of the Art” Compliance (Step-by-Step Workflow)
To meet regulatory expectations for cybersecurity MDR, your approach needs to follow a clear and traceable path from design to post-market activities. The steps below show how practitioners typically structure this in practice.
1. Start with Threat Modelling
Begin at the design stage. Identify possible threats, how they could exploit them, and what the impact would be. This sets the foundation for all security decisions that follow.
2. Align Development with Secure Practices
Your development process should follow IEC 62304, with security built into each phase. This includes secure coding practices, code reviews, and validation activities.
3. Integrate Cybersecurity into Risk Management
Cyber risks should be part of your ISO 14971 process. They need assessors, controllers, and linkers to assess them, control them, and link them to overall risk decisions, including benefit-risk evaluation and residual risk justification.
4. Implement Security Controls
Apply controls based on identified risks. This typically includes:
- Encryption for data protection
- Authentication mechanisms based on risk level
- Logging to track system activity and detect issues
Controls should apply consistently across the system.
5. Perform Security Testing
Before submission, validate your setup through security testing. This may include different methods, such as penetration testing, to identify weaknesses and confirm that controls are working as intended.
6. Set Up Vulnerability Monitoring and Patch Management
Define how vulnerabilities will be tracked and handled. This includes monitoring sources such as public databases, assessing impact, and deploying updates in a controlled manner.
7. Maintain Post Market Surveillance
After release, continue monitoring device performance and security. This includes PMS activities and PSUR reports, where applicable, to track ongoing risks and actions taken.
8. Document Everything
You should clearly document all of the above in your technical file. Reviewers rely on this to understand what they did, why they did it, and how it meets current expectations.
How Qualysec Supports EU MDR Cybersecurity Compliance
Qualysec helps you move from having security controls in place to actually proving they hold up during review. The focus stays on medical devices, APIs, cloud, and connected systems, using a mix of manual and automated testing with real-world attack scenarios.
This becomes useful before the notified body assessment. You can identify vulnerabilities early and strengthen your technical documentation with evidence that is easier to defend.
What you get:
- Detailed VAPT reports with severity levels
- Clear reproduction steps and remediation guidance
- Post-testing support and retesting
With experience across 2000 plus assets in 40 plus countries, Qualysec supports alignment with OWASP, ISO 27001, NIST, HIPAA, and MDR expectations.
Conclusion
MDR state of the art cybersecurity is not a one-time requirement. It keeps evolving and remains directly linked to both patient safety and regulatory approval.
Relying on checkbox compliance is no longer enough. What works in practice is following medical device security best practices and supporting them with clear, evidence-driven documentation across the entire lifecycle.
Teams that align early with standards, penetration testing, SBOM management and structured documentation usually face fewer delays during CE certification and handle audits with more confidence.
For a smoother path to compliance, you can rely on Qualysec to strengthen your security posture with practical, audit-ready validation.
Speak directly with Qualysec’s certified professionals to identify vulnerabilities before attackers do.
FAQs
1. What does “state of the art” mean in EU MDR cybersecurity?
It signifies what the industry currently accepts and uses, not what is newest. If your setup looks outdated or does not reflect how threats work today, it will be questioned.
2. Which standards demonstrate state of the art security?
Standards like ISO 14971, IEC 62304, IEC 81001- 5-1, and ISO 27001 are commonly used. They help structure your approach, but on their own, they are not enough. What matters is how you apply them to your device.
3. How do notified bodies evaluate cybersecurity maturity?
They go through your documentation and look for gaps. Risk management, architecture, testing, and lifecycle handling all need to connect. If something feels disconnected or unclear, someone picks it up quickly.
4. Does MDR require penetration testing?
MDR does not explicitly mandate penetration testing, but organisations expect security validation, and they commonly use penetration testing to demonstrate the effectiveness of controls.
5. How often should security practices be updated?
There is no fixed timeline. Updates usually follow changes in vulnerabilities, threats, or technology. If nothing changes for long, that itself can raise concern during review.
0 Comments