The Converging Compliance Horizon: How MDR, AI Act, CRA and EHDS Are Reshaping MedTech Strategy

For nearly three decades, the CE mark has served as the passport for medical devices entering the European market. Introduced with the Medical Device Directive (93/42/EEC) in 1993, this regulatory framework evolved through the 2007 amendment (Directive 2007/47/EC) that brought standalone software with medical purpose under its umbrella. The current Medical Device Regulation (MDR 2017/745) and In Vitro Diagnostic Regulation (IVDR 2017/746) have further strengthened these requirements, introducing rigorous cybersecurity mandates, interoperability standards, and comprehensive verification and validation protocols.

Yet the regulatory landscape is undergoing a transformation that extends far beyond traditional medical device boundaries. The European Commission, Parliament, and Council have enacted three landmark pieces of legislation—the Artificial Intelligence Act (AI Act 2024/1689), the Cyber Resilience Act (CRA 2024/2847), and the European Health Data Space (EHDS 2025/327)—that collectively reshape how health software systems must demonstrate conformity. For MedTech leaders, this convergence presents both unprecedented complexity and strategic opportunity.

This article examines how these frameworks interact, what timelines demand attention, and how forward-thinking organizations can transform regulatory compliance from a cost center into a competitive differentiator.

The Strategic Context: Why Regulatory Convergence Matters Now

The traditional approach to health software architecture has relied on careful modularization. Under MDCG 2019-11 (rev. 1), manufacturers could position software modules strategically: those contributing directly to medical intended purpose fell within MDR scope, while auxiliary functions—data orchestration, user interface components, connectivity layers—could operate outside the regulated boundary. This approach accelerated development, reduced certification costs, and maintained focus on patient safety-critical elements.

This modular strategy remains valid, but its boundary conditions have fundamentally shifted. What once existed as "unregulated" software territory now falls under multiple overlapping regimes. The clinical module may still answer to MDR, but the artificial intelligence component likely qualifies as high-risk under the AI Act. The electronic health record handling triggers EHDS requirements. The network-connected infrastructure falls under CRA jurisdiction.

The implication is profound: instead of a single conformity assessment, many health software systems now require multi-framework compliance. The organization that treats this as merely additive burden will struggle. The organization that recognizes the convergence patterns and builds integrated compliance systems will thrive.

Understanding the Four Frameworks

The Medical Device Regulation (MDR 2017/745)

The MDR represents the foundational requirement for any software qualifying as a medical device. Its scope covers software intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. The regulation mandates comprehensive quality management systems, clinical evaluation, post-market surveillance, and technical documentation aligned with harmonized standards.

For software manufacturers, MDR compliance has become increasingly demanding. The MDCG guidance on clinical evaluation of software (MDCG 2020-1) requires systematic demonstration of clinical validity, technical performance, and clinical benefit. Cybersecurity requirements under MDR Annex I, Chapter I.17 demand systematic risk management addressing confidentiality, integrity, and availability of both device and data.

The Artificial Intelligence Act (2024/1689)

The AI Act introduces a risk-based approach to AI system regulation. Its Annex III lists high-risk AI applications, including AI systems intended for use as safety components of regulated products—including medical devices. The regulation works in two directions simultaneously: as standalone product legislation for listed use cases, and as horizontal legislation integrating into sectoral CE regimes through Annex I.

For MedTech applications, the implications are substantial. AI components embedded in medical devices must comply with both MDR requirements and AI Act obligations. These include data governance requirements (training, validation, and testing datasets must meet quality criteria), technical documentation standards, record-keeping obligations, transparency and provision of information to users, human oversight measures, and robustness, accuracy, and cybersecurity requirements.

The Digital Omnibus on AI (Regulation (EU) 2026/1744) has adjusted timelines, pushing high-risk AI system obligations to December 2, 2027 for Annex III standalone systems, and to August 2, 2028 for AI integrated into regulated products such as medical devices. EN 18286, providing harmonized standards for AI Act quality management, has now been officially published.

The Cyber Resilience Act (2024/2847)

The CRA addresses a critical gap in product safety regulation: cybersecurity for products with digital elements. Unlike the cybersecurity requirements embedded in MDR Annex I, which apply specifically to medical devices, the CRA creates horizontal obligations for all products with digital elements placed on the EU market.

The CRA explicitly excludes medical devices from its scope (Article 2(2)), recognizing that sectoral legislation already addresses these products. However, the exclusion is narrower than it first appears. Electronic health record systems, regulated under EHDS, fall within CRA scope. Software offered as a service (SaaS) with no product placed on the market escapes CRA requirements, but SaaS EHR modules remain caught by EHDS, and AI functionality may still qualify as high-risk under AI Act.

Key CRA obligations include vulnerability handling processes, security update delivery, incident reporting for actively exploited vulnerabilities and severe incidents (effective September 11, 2026), and CE marking for hardware and software products (effective December 2027). The CRA and EHDS interact through Article 32(5a), which specifies that CRA conformity for EHR systems is demonstrated through the EHDS procedure.

The European Health Data Space (2025/327)

The EHDS creates a dual regulatory structure. As vertical product legislation, it establishes specific requirements for electronic health record systems placed on the EU market. As horizontal legislation, it imposes interoperability and data handling obligations on medical devices that process electronic health records.

The EHDS introduces concepts of "priority categories" of personal electronic health data, mandatory semantic and technical interoperability standards, and digital testing environment requirements for conformity assessment. For medical device manufacturers whose products exchange data with EHR systems, understanding these interoperability requirements becomes essential for maintaining market access.

Mapping Your Software Architecture Against Regulatory Requirements

Determining which frameworks apply to which components requires systematic analysis. The following decision framework provides a starting point for this assessment:

Question 1: Does the software module have a medical intended purpose?

If yes, the module falls under MDR (or IVDR for in vitro diagnostics). This determination follows MDCG 2019-11 guidance, considering whether the software directly contributes to diagnosis, treatment, or monitoring functions.

Question 2: Does the module incorporate artificial intelligence?

If yes, and if the AI performs functions listed in AI Act Annex III (including safety components of regulated products), the module triggers AI Act requirements. The integration provisions (Article 6) mean AI in medical devices follows the AI Act high-risk pathway.

Question 3: Does the module process electronic health record data?

If yes, EHDS interoperability requirements apply. If the module itself constitutes an EHR system component, additional product legislation requirements follow.

Question 4: Is the module a product with digital elements placed on the market?

If yes, and if it is not excluded as a medical device, CRA obligations apply. This primarily affects non-medical components such as general connectivity infrastructure, user interface frameworks, or data orchestration layers.

The intersection of these questions determines the compliance matrix for each software module. A clinical decision support module with AI components processing EHR data might trigger MDR, AI Act, and EHDS simultaneously. A connectivity layer without medical purpose or AI might fall under CRA alone.

Critical Timelines and Implementation Windows

The regulatory convergence creates a compressed implementation window that demands immediate attention. The following timeline outlines key obligations:

September 11, 2026 — CRA vulnerability and incident reporting obligations become effective. Manufacturers must have processes in place to monitor for actively exploited vulnerabilities, report severe incidents to ENISA, and deliver security updates. This applies even before CE marking requirements take effect.

December 2, 2027 — CE marking becomes mandatory for products with digital elements under CRA, and for high-risk AI systems under AI Act Annex III. Products without CE marking cannot be placed on the EU market after this date.

August 2, 2028 — AI Act requirements for AI systems integrated into regulated products (including medical devices under MDR) become effective. This represents the deadline for ensuring AI components in medical devices meet AI Act obligations.

2029 — EHDS CE marking requirements for electronic health record systems take effect.

This timeline reveals a strategic insight: the most demanding deadlines cluster in late 2027 and 2028. Organizations that delay preparation until 2027 will face a compliance fire drill. Organizations that begin now can spread implementation costs, integrate requirements into normal development cycles, and potentially capture market share as competitors struggle to adapt.

Building an Integrated Compliance Architecture

The good news amid this complexity is that the frameworks are explicitly designed for integration. The AI Act (Article 47(3)), CRA (Article 28(3)), and EHDS (Article 39(2)) all provide for single EU declarations of conformity covering multiple applicable acts. One CE mark can attest compliance with all relevant frameworks.

Similarly, quality management systems can be integrated. The AI Act expressly permits integration of its quality management requirements into existing systems (Article 17(3)), and EN 18286 provides harmonized standards supporting this integration. A medical device manufacturer already operating an ISO 13485-compliant quality management system can extend that system to cover AI Act, CRA, and EHDS requirements rather than building parallel structures.

Technical documentation also overlaps substantially. Each framework requires:

• System description and architecture documentation
• Risk management file addressing safety and security
• Requirements traceability matrix
• Verification and validation evidence
• Standards conformity evidence
• Post-market monitoring procedures
• Declaration of conformity

The AI Act (Article 11(2)) explicitly requires a single combined set of documentation for regulated products falling under multiple acts. Rather than maintaining separate technical files for MDR, AI Act, CRA, and EHDS, manufacturers can structure one comprehensive dossier with act-specific annexes.

Act-Specific Documentation Supplements

While core documentation converges, each framework requires specific supplements:

AI Act additions: Data governance documentation describing training, validation, and testing datasets; bias detection and mitigation measures; human oversight interface specifications; and accuracy, robustness, and cybersecurity testing protocols specific to AI systems.

CRA additions: Software bill of materials (SBOM) documenting components and dependencies; vulnerability disclosure policy; security update delivery mechanisms; and evidence of secure development lifecycle implementation.

EHDS additions: Interoperability testing results in digital testing environments; semantic mapping documentation for priority health data categories; and evidence of conformance with European electronic health record exchange format specifications.

Strategic Recommendations for MedTech Leaders

1. Conduct a Comprehensive Regulatory Mapping

Begin with a systematic analysis of your software architecture against the four-question framework described above. Document which modules trigger which requirements. Identify gaps where current compliance activities may not cover newly applicable frameworks.

This mapping should involve cross-functional teams including regulatory affairs, engineering, quality assurance, and product management. The goal is not merely compliance identification but strategic insight: understanding which product capabilities create regulatory obligations and which architectural decisions minimize compliance burden while maintaining functionality.

2. Integrate Compliance into Development Lifecycle

The most cost-effective compliance approach embeds requirements into normal development processes rather than adding them as post-development activities. This means:

• Including cybersecurity requirements in initial design specifications
• Building data governance into AI training pipelines from the start
• Documenting design decisions as they occur rather than retrospectively
• Conducting risk analysis continuously rather than as a pre-submission activity

The organizations that thrive in this environment will be those where regulatory awareness permeates engineering culture, not those where regulatory affairs operates as an isolated checkpoint.

3. Invest in Quality Management System Enhancement

If your organization operates under ISO 13485, extend that system to incorporate AI Act, CRA, and EHDS requirements. The harmonized standards (particularly EN 18286 for AI Act) provide concrete guidance for these extensions.

Consider engaging notified bodies early for conformity assessment planning. The limited pool of AI Act and CRA notified bodies may create bottlenecks as deadlines approach. Early engagement secures assessment slots and identifies potential compliance gaps while there is still time to address them.

4. Treat Compliance as Market Opportunity

Regulatory compliance can be a competitive moat. Organizations that achieve early compliance with AI Act, CRA, and EHDS can market their products as fully compliant while competitors scramble to catch up. Healthcare procurement increasingly considers cybersecurity and AI governance in purchasing decisions—compliance becomes a sales enabler.

Furthermore, the standardization these frameworks create may actually reduce market fragmentation. A unified approach to AI safety, cybersecurity, and data interoperability across the EU creates a larger addressable market for compliant products.

5. Monitor Regulatory Evolution

These frameworks will evolve. MDCG guidance documents continue to clarify AI Act and MDR intersections. Harmonized standards will be updated. Implementation experiences will reveal gaps and ambiguities. Establish processes to monitor regulatory developments and assess their implications for your products.

The Path Forward: From Compliance Burden to Strategic Advantage

The convergence of MDR, AI Act, CRA, and EHDS represents a fundamental shift in how health software is regulated in Europe. The era of positioning software modules outside regulatory scope is ending—not through elimination of modular strategies, but through expansion of regulatory boundaries to cover previously unregulated components.

This shift creates immediate implementation challenges. The timelines demand action: vulnerability reporting by September 2026, CE marking by late 2027, AI-in-device compliance by August 2028. Organizations that delay preparation risk market exclusion.

Yet within this challenge lies opportunity. The frameworks are designed for integration: one CE mark, one declaration of conformity, one integrated quality management system, one unified technical documentation structure. The manufacturer that approaches this systematically can achieve compliance more efficiently than those treating each framework as an isolated requirement.

More importantly, regulatory compliance and commercial success increasingly align. Healthcare systems demand cybersecurity assurance. Clinicians require confidence in AI-driven recommendations. Patients expect their health data to be handled responsibly. The regulations codify these expectations into binding requirements—but the underlying market dynamics would push toward similar standards even without regulatory mandates.

The strategic MedTech leader will view this convergence not as an obstacle but as a catalyst for organizational excellence. By building integrated compliance systems, embedding regulatory awareness into development culture, and treating conformity as a market differentiator, organizations can turn regulatory complexity into sustainable competitive advantage.

The compliance horizon is converging. The question is not whether your organization will meet these requirements, but whether you will meet them as a follower struggling to catch up, or as a leader setting the standard for your market.