DORA and data in use: the role of Confidential Computing

DORA has applied since 17 January 2025, yet its demanding requirements continue to pose challenges for the financial sector, and some of the more detailed obligations are still being overlooked. Protecting data while it is being processed is one example. It is an important step towards sovereign cloud and AI architectures, but the necessary safeguards are far from universally implemented. This article looks at how Confidential Computing can help.

‍

Like most regulations, DORA primarily defines security objectives and control requirements rather than prescribing specific technologies. In some cases, however, the connection between a regulatory requirement and a technical approach is relatively direct. Data in Use and Confidential Computing are a case in point.

Two regulatory provisions illustrate this particularly well: one in DORA itself and the other in the supplementary Commission Delegated Regulation (EU) 2024/1774.

‍

Article 9(2) DORA

‍

Financial entities shall design, procure and implement ICT security policies, procedures, protocols and tools that aim to ensure the resilience, continuity and availability of ICT systems, in particular for those supporting critical or important functions, and to maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit.

‍

Article 6(2) of Commission Delegated Regulation (EU) 2024/1774
‍

(2) […] That policy shall contain rules for all of the following:
‍

• the encryption of data at rest and in transit;
• the encryption of data in use, where necessary;
• the encryption of internal network connections and traffic with external parties;
• the cryptographic key management referred to in Article 7, laying down rules on the correct use, protection, and lifecycle of cryptographic keys.
  ‍

For the purposes of point (b), where encryption of data in use is not possible, financial entities shall process data in use in a separated and protected environment, or take equivalent measures to ensure the confidentiality, integrity, authenticity, and availability of data.
‍

The protection of Data in Use – in other words, data while it is being processed – is therefore an explicit part of the DORA framework. Whether encryption is required or whether a separated and protected environment or an equivalent measure is sufficient must be determined on a risk basis. Confidential Computing provides a particularly robust technical approach for meeting this requirement.

‍

‍

Why Confidential Computing?

‍

Confidential Computing protects data during processing inside Trusted Execution Environments (TEEs) – hardware-isolated, encrypted and attestable execution environments. It therefore addresses key DORA security objectives: protecting the confidentiality and integrity of data in use and providing the type of separated and protected environment described in Article 6(2) of Delegated Regulation 2024/1774.
‍

Other approaches to encrypting Data in Use do exist, but their practical applicability remains very limited. Fully homomorphic encryption, for example, involves substantial computational overhead for many workloads. Confidential Computing, by contrast, incurs significantly lower performance overhead, usually only a few per cent. Actual figures depend on the hardware, architecture and workload.
‍

Confidential Computing also provides a capability that is particularly relevant to audits and evidence requirements: Remote Attestation. It allows organisations to verify the identity, configuration and integrity of TEEs and the workloads running inside them. The execution environment generates cryptographically signed measurements containing information about the hardware, its configuration and the workload being executed.
‍

These measurements can serve two purposes. They can be checked against defined security policies before sensitive data or keys are released, and they can provide technical evidence for compliance and audit processes. Attestation alone, however, is not evidence of compliance. Robust technical evidence only emerges when attestation is combined with defined policies, independent verification, tamper-resistant logging and integration into existing control and audit processes.
‍

But Data in Use encryption is not the only area where Confidential Computing can support DORA requirements.

‍

‍

How does Confidential Computing support DORA?

‍

DORA covers five main areas: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing on cyber threats. Confidential Computing is particularly relevant to the first and the fourth, and can contribute to meeting the corresponding DORA requirements.
‍

Some examples:
‍

• ICT risk management framework (Article 6(1)–(3) DORA) and protection of ICT assets (Article 9(1)–(2) DORA):
  DORA requires a documented ICT risk management framework and appropriate technical measures to limit ICT risk. By protecting Data in Use, Confidential Computing adds another layer to existing security controls. This can also extend to AI workloads, as models can run inside TEEs.
  ‍
• Protection against unauthorised and privileged access (Article 6(2) and Article 9(4)(c) DORA; Article 21 Delegated Regulation 2024/1774):
  Access to data and ICT assets should be restricted to the minimum required. TEEs can significantly reduce the risk of access by the host system, hypervisor or privileged infrastructure administrators while providing a technically verifiable form of isolation.
  ‍
• Authenticity, integrity and confidentiality during processing (Article 9(2) DORA):
  TEE isolation protects data and code against unauthorised access and modification, with Attestation allowing the execution environment’s integrity to be verified. Availability – another requirement under DORA – can also be supported through a self-healing, container-based Confidential Kubernetes architecture that automatically replaces failed instances.
  ‍
• ICT third-party risk management (Articles 28 and 30 DORA):
  Financial entities remain responsible for meeting DORA requirements even when they use cloud providers or other ICT third-party service providers. Confidential Computing reduces the level of trust that has to be placed in the provider: the provider can operate the infrastructure without gaining access to the plaintext data being processed. This does not, however, remove the need for contractual provisions on control, audit and exit.
  ‍
• Documentation, review and auditability (Article 6(5)–(7) DORA and Article 12 Delegated Regulation 2024/1774):
  DORA requires the ICT risk management framework to be documented, regularly reviewed and subject to appropriate audit processes. Attestation results can provide additional technical evidence for these processes, provided that they are logged and integrated into existing control and audit procedures.
  ‍

Confidential Computing can therefore support more than one specific DORA requirement and contribute to compliance at several levels. The key is to understand both its potential and its limits. Its primary contribution is technical, and like other security mechanisms it must be integrated into the organisation’s broader governance and control processes.
‍

The effectiveness of Confidential Computing also depends on several architectural details.
‍

What financial entities need to consider when implementing Confidential Computing?

‍

Confidential Computing closes a fundamental security gap, particularly in cloud and AI environments. But as with any technology, its effectiveness depends on how it is implemented. Several aspects that may initially appear secondary become particularly important in the context of DORA compliance:
‍

• Management and control of cryptographic keys:
  To maintain the confidentiality of TEEs, financial entities need to retain control over their secrets rather than handing that control to an external provider. An independent key management system, itself operated inside TEEs, can protect keys and signatures against unauthorised access, disclosure and modification. This aligns with Article 7(2) of Delegated Regulation 2024/1774, which requires controls to protect cryptographic keys throughout their lifecycle against those risks.
  ‍
• Post-quantum security and crypto-agility:
  TEEs are only as secure as the cryptography protecting them. With the future threat posed by quantum computers and current “harvest now, decrypt later” attacks, Post-Quantum Cryptography (PQC) is becoming increasingly relevant. The DORA framework also requires cryptographic technology to be reviewed and, where necessary, updated as cryptanalysis develops and cyber threats evolve. Crypto-agility provides the basis for replacing cryptographic methods in a controlled manner as risks change – including future threats from quantum computers.
  ‍
• Verification of Attestation results:
  This highly specific requirement has no direct equivalent in DORA, but it is crucial to the level of confidentiality that Confidential Computing can provide. It is therefore addressed in another major compliance framework: the BSI’s C5 catalogue. OPS-33 of C5:2026 distinguishes between four Attestation trust levels. Levels 1 and 2 are classified as “very strong attestation”: in both scenarios, the cloud customer can verify the Attestation evidence in an environment it fully trusts. Level 3, where evidence is checked by a trusted verification service selected by the customer, is classified as “strong attestation”. If the cloud provider controls the verification and only returns the result to the customer, C5 classifies this as “weak attestation”.
  ‍

These capabilities are not automatically part of every Confidential Computing solution. Financial entities therefore need to assess the market carefully and ensure that their chosen provider supports the required functionality.
‍

The enclaive vHSM (virtual Hardware Security Module) supports customer-controlled management of cryptographic keys. The vHSM is crypto-agile and enables post-quantum-secure algorithms to be integrated into suitable cryptographic processes. enclaive also enables customers to verify Attestation evidence themselves and can therefore – depending on the specific implementation – meet the conditions for very strong attestation at trust level 1 under C5:2026.

‍

‍

Conclusion

‍

Protecting Data in Use is one of the DORA requirements that makes it necessary to strengthen traditional security architectures with additional safeguards. Organisations that adopt Confidential Computing can strengthen both their regulatory compliance and the security and sovereignty of their data.
‍

Confidential Computing is therefore an important building block for DORA-compliant systems, but it is not automatic evidence of compliance. It neither replaces ICT risk management nor existing security measures. Instead, it complements them and must be integrated into the organisation’s wider governance and control framework.

‍

‍