Module 7 – Cyber Resilience, Financial Resilience, and Interoperable Public Services

1. From the Digital Rulebook to Sectoral Resilience

In earlier modules, you saw how the Digital Services Act (DSA), Digital Markets Act (DMA), and the AI Act create a modern EU digital rulebook.

This module zooms in on three sectoral regulations that add resilience and interoperability to that picture:

• Cyber Resilience Act (CRA) – Regulation (EU) 2024/2847
• Digital Operational Resilience Act (DORA) – Regulation (EU) 2022/2554
• Interoperable Europe Act (IEA) – Regulation (EU) 2024/903

All three:

• Use regulation (directly applicable in all Member States)
• Build on ideas you know from the New Legislative Framework (NLF): essential requirements, conformity assessment, CE marking (for CRA), and standards
• Are horizontal within their sectors: they set baseline rules for many different actors

Why they matter now (late 2025):

• CRA was adopted in 2024 and is in its staged application phase, reshaping how products with digital elements handle cybersecurity.
• DORA entered into application in January 2025, transforming how EU financial entities manage ICT risk.
• The Interoperable Europe Act was adopted in 2024 and is being rolled out as the new backbone for cross-border digital public services.

In the next steps, you’ll learn:

1. What each regulation does in practice
2. How they connect to existing product, financial, and public-sector rules
3. How to apply their logic to concrete scenarios

> Tip for this module: Think of CRA as about secure products, DORA as about resilient financial operations, and the Interoperable Europe Act as about public administrations that can talk to each other digitally.

2. Cyber Resilience Act – Core Idea and Scope

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, is the EU’s horizontal cybersecurity law for products with digital elements.

2.1 Core idea

If a product is connected or can be updated, it must:

• Be secure by design and by default
• Be supported with security updates for a defined period
• Provide transparent information about cybersecurity features and vulnerabilities

2.2 Scope – “Products with digital elements”

The CRA covers hardware and software that:

• Has at least one direct or indirect logical or physical data connection to a device or network, and
• Is placed on the market in the EU.

This includes, for example:

• Consumer IoT: smart thermostats, smart locks, wearables
• Industrial/enterprise: routers, firewalls, PLCs, industrial sensors
• General software: operating systems, office suites, certain developer tools

Excluded or separately regulated examples (to avoid overlap):

• Medical devices (already covered by MDR/IVDR cybersecurity rules)
• Aviation and some automotive products (covered by sectoral safety rules)
• Certain open-source software developed outside commercial activity

2.3 Link to the NLF

CRA mirrors the NLF structure you saw in earlier modules:

• Essential cybersecurity requirements in the Regulation
• Harmonised standards to show presumption of conformity
• Conformity assessment procedures (self-assessment vs third-party)
• CE marking to show compliance

So if you understand how the Low Voltage Directive or Radio Equipment Directive work, the CRA feels structurally familiar—but applied to cybersecurity rather than just safety or EMC.

3. CRA in Practice – A Smart Home Device

Let’s walk through a practical CRA scenario.

Scenario: Launching a smart door lock in the EU

You are a manufacturer of a Wi‑Fi-connected smart door lock that users control via a mobile app.

Under the CRA, you must:

1. Analyze cybersecurity risks

• Identify threats: brute-force attacks, credential stuffing, replay attacks, physical tampering
• Consider impacts: unauthorized entry, privacy breach, reputational damage

1. Design security by default

• No default password like `admin/admin`
• Enforce strong authentication and secure password policy
• Use encrypted communication (e.g., TLS) between lock, app, and cloud
• Limit exposed services/ports

1. Plan for vulnerability handling

• Create a vulnerability handling process, including:
• A contact channel for security researchers
• Procedures to receive, assess, and remediate vulnerabilities
• Deadlines for issuing patches

1. Provide security updates

• Offer timely security patches for a minimum support period defined by CRA
• Ensure secure update mechanisms (signed updates, rollback protection where relevant)

1. Inform users

• In the instructions and online, clearly state:
• Security features (encryption, 2FA, etc.)
• Minimum supported period for security updates
• Recommended secure configuration (e.g., enable 2FA, change default settings)

1. Conformity assessment and CE marking

• For many products, you may use internal control (self-assessment) if you apply harmonised standards.
• For higher-risk classes (e.g., critical products), you may need a notified body.
• Once compliant, you affix the CE mark and keep technical documentation.

Key takeaway: Under CRA, cybersecurity is no longer a “nice to have” feature; it is a legal requirement embedded in the product lifecycle—design, production, updates, and end-of-support.

4. DORA – Digital Operational Resilience for Finance

The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, focuses on financial-sector ICT risk. It entered into application in January 2025, so it is fully in force now.

4.1 What is “digital operational resilience”?

It means a financial entity can withstand, respond to, and recover from ICT-related disruptions, such as:

• Ransomware attacks
• Cloud provider outages
• Data corruption incidents
• Distributed Denial of Service (DDoS) attacks

4.2 Who is covered?

DORA applies to a wide range of financial entities, including:

• Banks and credit institutions
• Investment firms, trading venues
• Payment institutions, e-money institutions
• Insurance and reinsurance undertakings
• Crypto-asset service providers (where covered by EU financial rules)
• Critical third-party ICT service providers (e.g., major cloud platforms serving many financial entities)

4.3 Main pillars of DORA

DORA is structured around five main areas:

1. ICT risk management

• Governance and internal controls
• ICT risk strategy approved by management
• Asset inventories, protection, and monitoring

1. ICT-related incident reporting

• Classify incidents (e.g., major, significant)
• Report major incidents to competent authorities under harmonised timelines

1. Digital operational resilience testing

• Regular testing (vulnerability assessments, scenario tests)
• Advanced threat-led penetration testing (TLPT) for certain significant entities

1. ICT third-party risk management

• Contracts with ICT providers must include specific clauses (e.g., access, audit, exit strategies)
• Oversight of critical third-party providers at EU level

1. Information sharing

• Encourage sharing of cyber threat information and intelligence among financial entities, under safeguards.

4.4 How DORA fits with existing rules

DORA complements, rather than replaces:

• CRD/CRR (banking prudential rules)
• MiFID II, Solvency II, etc.

Those rules focus on capital and financial risks; DORA adds a harmonised layer for ICT and cyber resilience, so that financial services remain available and trustworthy even under digital stress.

5. DORA in Practice – A Ransomware Attack on a Bank

Consider a mid-sized EU bank hit by a ransomware attack that encrypts part of its internal systems.

Under DORA, the bank must be prepared to:

1. Before the incident – ICT risk management

• Maintain an up-to-date inventory of critical systems (core banking, payment processing, online banking portal).
• Implement segmentation so an attack on office PCs does not easily spread to core banking.
• Have backups that are isolated and regularly tested.
• Train staff in phishing awareness and incident procedures.

1. During the incident – Response and communication

• Activate its ICT Business Continuity Plan and Disaster Recovery Plan.
• Switch to backup systems or manual procedures where possible.
• Notify relevant internal teams and senior management.
• For a major incident, report to the competent authority within the DORA deadlines.

1. After the incident – Recovery and learning

• Restore systems from clean backups.
• Perform a post-incident review: root cause analysis, what worked, what failed.
• Update controls, training, and testing scenarios based on lessons learned.

1. Third-party angle

• If the attack exploited a vulnerability in a cloud provider or IT vendor, the bank must:
• Review contractual clauses (e.g., notification obligations, support, exit strategies).
• Reassess the provider’s criticality and its own concentration risk.

Key contrast with CRA:

• CRA: focuses on product manufacturers and software publishers and the security of the product itself.
• DORA: focuses on financial institutions and their ICT operations, including how they use third-party ICT providers.

Together, they cover secure products (CRA) and resilient financial operations (DORA).

6. Interoperable Europe Act – Making Public Services Work Across Borders

The Interoperable Europe Act (IEA), Regulation (EU) 2024/903, is about interoperable digital public services across the EU.

Instead of cybersecurity or finance, it targets public administrations and their ability to exchange data and services smoothly.

6.1 What does “interoperable” mean here?

Interoperability is the ability of different systems and organisations to work together. The IEA follows the traditional EU view of interoperability with four layers:

• Legal – laws and policies allow data exchange
• Organisational – processes and responsibilities align
• Semantic – data has the same meaning across systems
• Technical – systems can connect (APIs, formats, protocols)

6.2 Main goals of the Interoperable Europe Act

The Act aims to:

• Create a cooperation framework for Member States, EU institutions, and other public bodies
• Promote reusable solutions (software, data models, building blocks)
• Support cross-border digital public services, such as:
• Online business registration valid across borders
• Cross-border e-prescriptions and e-health records
• Recognition of electronic IDs and diplomas

6.3 Key instruments

While details are still being implemented, the IEA provides for:

• An Interoperable Europe Board to coordinate decisions
• Interoperable Europe Portal as a hub for solutions, guidelines, and documentation
• Common interoperability solutions (e.g., reference architectures, open standards)
• Support for open-source software and open specifications in public administration

6.4 How it links to other laws

• Works alongside the Single Digital Gateway (for access to information and procedures)
• Complements the eIDAS framework (electronic identification and trust services)
• Supports implementation of sectoral digitalisation (e.g., in health, justice, transport)

Big picture: the IEA is about governance and cooperation, not just technology. It tries to avoid each administration building isolated solutions that cannot talk to each other.

7. Connecting CRA, DORA, and the Interoperable Europe Act

Use this thought exercise to connect the three regulations.

7.1 Scenario

Imagine a cross-border digital public service that lets citizens:

• Open a bank account online in another EU country
• Use their national eID to authenticate
• Interact via a web portal that runs on cloud infrastructure
• Access their data via a mobile app using a smart device

7.2 Your task

For each regulation, identify what it mainly cares about in this scenario.

1. Cyber Resilience Act (CRA)

• Which products with digital elements are in scope here?
• Think about: the mobile app, the smartphone OS, the router at home, security modules.

1. DORA

• Where does digital operational resilience come in?
• Think about: the bank’s ICT systems, cloud providers, incident reporting.

1. Interoperable Europe Act (IEA)

• Where do public administrations and interoperability show up?
• Think about: cross-border identity verification, data exchange between national registers, public portals.

7.3 Reflect

Write short bullet points (for yourself) under three headings:

• CRA:
• …
• DORA:
• …
• IEA:
• …

Then check your reasoning:

• If you focused on devices, apps, and embedded software, you’re in CRA territory.
• If you focused on banks’ and financial entities’ ICT systems and third-party providers, that’s DORA.
• If you focused on public authorities coordinating and exchanging data across borders, that’s the Interoperable Europe Act.

> Optional extension: How does the AI Act (from Module 6) interact with these? For example, if the bank uses an AI-based credit-scoring system, which rules apply in parallel?

8. Quick Check – Matching Regulation to Focus Area

Test your understanding by matching each regulation to its primary focus.

9. CRA vs DORA – Who Is Responsible?

Consider who carries the main legal obligations in each regulation.

10. Flashcards – Key Terms and Concepts

Flip these cards (mentally or with a partner) to reinforce key concepts from this module.

11. Apply It – Mini Case Study

Use this mini case to practice applying all three regulations.

Case

A public employment agency in one Member State launches a cross-border online job-matching platform. Features:

• Jobseekers can log in using their national eID.
• Employers include banks and insurance companies.
• The platform runs on a cloud infrastructure and offers a mobile app.

Your task

Answer these questions in bullet points (no need to write full essays):

1. CRA angle

• Which components of this system are likely to fall under the CRA’s definition of products with digital elements?
• What kind of security-by-design measures would you expect from the app developer?

1. DORA angle

• How might banks using this platform need to consider it in their ICT risk management under DORA?
• What would you expect in their contracts with the platform operator or cloud provider?

1. Interoperable Europe Act angle

• Where do you see public-sector interoperability issues (e.g., data exchange with other national employment agencies, social security, tax authorities)?
• What kind of common standards or solutions might the Interoperable Europe framework encourage here?

Reflect on how one real-world service can trigger multiple regulatory layers: product cybersecurity (CRA), financial resilience (DORA, for banks using it), and public-sector interoperability (IEA).