Skip to main content
News & Insights

The Update for
Digital Health.

Technical depth, regulatory updates, and insights into the future of health identities.

7 min read

The EU Cyber Resilience Act (CRA) for Digital Health: Obligations, Deadlines, and What Applies to DiGAs and Health Software

azuma Team
azuma Team
Core Team

The Cyber Resilience Act (CRA) is no longer a future concern – it's applicable EU law. The first hard obligations kick in on September 11, 2026, and the regulation applies in full from December 11, 2027. For digital health providers, this raises a question many still underestimate: where exactly does the CRA apply to me – and what about my software supply chain?

This article explains what the CRA requires, which deadlines apply, how it relates to medical device regulation (MDR), and what this means in practice for DiGAs, health apps, and their suppliers.

What is the Cyber Resilience Act?​

The CRA (Regulation (EU) 2024/2847) is the first horizontal EU regulation to set uniform cybersecurity requirements for "products with digital elements" (PDE) – covering nearly all hardware and software made available on the EU market. The goal is a consistent security level across the entire product lifecycle, evidenced through the familiar CE marking.

Two things are important to understand:

  • The CRA has global reach: what matters isn't where a product is manufactured, but whether it's made available on the EU market.
  • It is directly applicable in all member states – unlike a directive, it requires no national transposition.

Cyber Resilience Act: Timeline & Scope for Digital Health

The timeline: What applies when​

The CRA entered into force on December 10, 2024, and becomes applicable in stages:

  • June 11, 2026: The rules on notifying conformity assessment bodies apply.
  • September 11, 2026: Reporting obligations for actively exploited vulnerabilities and severe security incidents take effect – to be reported via the central Single Reporting Platform at ENISA and the responsible national CSIRT.
  • December 11, 2027: Full application of all remaining requirements – essential security requirements, conformity assessment, CE marking, and technical documentation.

After December 11, 2027, products without CE-compliant CRA evidence may no longer be placed on the EU market.

The core obligations for manufacturers​

The CRA demands far more than a one-time security audit. Central obligations include:

  • Security by design based on a documented risk assessment.
  • Software Bill of Materials (SBOM): a machine-readable list of at least the top-level dependencies, kept up to date and made available to market surveillance authorities on request.
  • Vulnerability management & security updates throughout the entire support period, including coordinated vulnerability disclosure.
  • Reporting obligations with tight deadlines: an early warning within 24 hours, a full report within 72 hours, and a final report no later than 14 days after a remediation becomes available (or one month for severe incidents).
  • Conformity evidence: technical documentation, an EU declaration of conformity, and CE marking.

Products are classified into risk classes (standard, "important," and "critical"), with stricter assessment procedures for the higher classes. Violations of the essential requirements can incur fines of up to €15 million or 2.5% of global annual turnover – whichever amount is higher.

CRA and digital health: Where it applies to DiGAs and health apps​

This is the decisive and often misunderstood point. The CRA exempts products that are already subject to their own sectoral rules – medical devices under the MDR (Regulation (EU) 2017/745) and in-vitro diagnostics under the IVDR are exempt from the CRA to avoid double regulation.

This does not, however, mean digital health is off the hook. The exemption applies at the product level, and the CRA remains relevant in several places:

  • Non-medical-device software: Many health applications (or parts of them) aren't medical devices in the regulatory sense – think portals, companion apps, administrative, or infrastructure software. These fall under the CRA.
  • Remote data processing and infrastructure: Backend services and outsourced processing solutions can fall within the CRA's scope.
  • The software supply chain: Even if your main product is regulated as a medical device under the MDR, the individually placed-on-the-market software components from your suppliers are frequently CRA-obligated – and you need corresponding evidence from them.

In short: the CRA rarely applies to digital health providers "not at all" or "completely" – it applies specifically at the edges of the medical device scope, and throughout the supply chain.

What this means for your software supply chain​

The CRA turns cybersecurity into a matter of supply chain due diligence. Anyone integrating third-party components needs to be able to rely on – and document – their CRA conformity. In practice, this means suppliers need to provide CRA conformity evidence (or credible compliance roadmaps), SBOMs, and technical documentation so you can meet your own due diligence obligations.

One building block present in nearly every digital health application is identity and access management. If this is covered by a service that's already been developed CRA-compliant, a security-critical part of your supply chain evidence is taken care of. The security-related requirements here also overlap with BSI TR-03161, which already applies to DiGAs regardless.

Putting CRA compliance into practice​

The real effort isn't in understanding the regulation, but in its operational implementation: generating and maintaining SBOMs, continuously monitoring for vulnerabilities, setting up reporting workflows with 24/72-hour deadlines, shipping security updates throughout the support period, and documenting conformity evidence in an audit-ready way. For teams building their product in parallel, that's a substantial, ongoing effort.

How azuma nori helps with CRA compliance​

This is exactly the operational effort azuma nori addresses: an agentic compliance workstation that runs locally on the developer's machine and automatically checks source code against pre-defined compliance matrices – without the code ever leaving the device. For the Cyber Resilience Act, nori already offers 31 pre-defined controls today that automatically trace typical CRA-relevant requirements for products with digital elements in your code.

This extends nori's existing BSI TR-03161 coverage to the horizontal EU product security layer – particularly for teams that need to keep an eye on both their main product and their software supply chain. As with every nori analysis, your source code stays entirely local; evaluation runs through LLM Sub-Agents that you configure yourself (Claude, OpenAI, Gemini, or your own on-premise model).

CRA checking is currently available in nori as a Beta — you can try it via the free self-service Test Access with a curated set of controls.

Frequently asked questions​

Does the Cyber Resilience Act also apply to DiGAs?​

It depends. If the DiGA is a medical device under the MDR, it's exempt from the CRA (no double regulation). Non-medical-device software, remote data processing, and the software supply chain, however, can very much fall under the CRA.

From when do I need to comply with the CRA?​

The reporting obligations for actively exploited vulnerabilities and severe incidents apply from September 11, 2026. All remaining requirements – including CE marking and conformity assessment – apply from December 11, 2027.

What is an SBOM, and do I need one?​

A Software Bill of Materials is a machine-readable list of a product's software components. The CRA requires, at minimum, capturing the top-level dependencies, keeping them up to date, and making them available to market surveillance authorities on request.

How does the CRA relate to BSI TR-03161?​

Both address product security, from different angles: BSI TR-03161 is the health-specific security guideline (among other things, for DiGAs), while the CRA is horizontal EU product cybersecurity. In practice, many measures overlap – for example, vulnerability management and secure update processes.

What happens if I don't comply?​

Violations of the essential security requirements can incur fines of up to €15 million or 2.5% of global annual turnover.

Want to know how much CRA coverage your code already has today? Get free Test Access to azuma nori or schedule a call with our team.

As of: July 2026. The CRA continues to be specified further through implementing and delegated acts as well as harmonized standards – please double-check the current status of deadlines and detailed requirements before publishing.