DORA Encryption-in-Use: The Fallback Isn't Free

Data used to be called the new oil. Lately it’s feeling more like uranium — extraordinarily valuable, and just as dangerous in the wrong hands.

That tension is a big part of why 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before, according to S&P Global Market Intelligence. Ask why, and the easy answer is the model: too slow, too expensive, the ROI never showed up. The easy answer is wrong.

The problem isn’t the models. It’s not budget, compute, or capability. The most valuable data an enterprise owns — transaction histories, identity records, patient charts — is also the data nobody is cleared to touch. A model can’t train, an agent can’t infer, and a dashboard can’t generate insight from data it isn’t allowed to see.

That’s not a new problem. It’s an old one, compounding fast: AI-powered attacks are rising, agents are breaking out of their own sandboxes, and the people who built the black box can’t always say what’s happening inside it. Regulators are the ones now scrambling to draw a boundary around it. In January 2025, DORA became the first major regulation to say, in writing, that data has to be protected not just at rest and in transit, but in use.

Two terms this piece leans on. Encryption-in-use means computing on data — searching it, aggregating it, training on it — while it stays encrypted, so the application layer never holds plaintext. Compliance debt is what accumulates when you satisfy today’s regulatory requirement with ever more compensating controls instead of fixing the architecture underneath.

DORA changed the encryption conversation

Financial institutions have spent years protecting data at rest and in transit. But what happens when that data is actively being processed?

That’s where encryption-in-use enters — and where DORA drew a line most institutions haven’t crossed yet.

DORA Article 9 requires financial entities to maintain high standards of confidentiality, integrity and availability for data “at rest, in use or in transit.”

Article 6 of Commission Delegated Regulation (EU) 2024/1774 — the RTS on the ICT risk-management framework — requires financial entities to establish an encryption and cryptographic-controls policy covering data at rest, data in transit, and data in use where necessary. (EUR-Lex)

Date	Milestone	Status
16 Jan 2023	DORA entered into force	Past
17 Jan 2025	DORA became fully applicable	Past
30 Apr 2025	First major Registers of Information submission to the ESAs	Past
July 2025	ESAs notified ICT providers assessed as potentially critical	Past
18 Nov 2025	First Critical ICT Third-Party Providers (CTPPs) formally designated	Past
2026	Ongoing supervisory oversight of CTPPs begins and ramps up	Current
2026 onward	Financial entities begin or continue DORA TLPT (threat-led penetration testing) cycles	Current
2026 onward	Annual, updating Register of Information reporting	Recurring
2026 onward	Ongoing DORA incident reporting, testing, ICT-risk management and third-party oversight	Recurring
2028 onward	First full three-year TLPT cycle comes due for entities subject to the three-year requirement	Upcoming

DORA isn’t only about encrypting databases and network traffic. Data matters just as much while it’s being used as while it’s sitting still or moving.

The problem: encryption-in-use has historically been hard

Protecting data at rest and in transit is relatively straightforward: encrypt the storage and encrypt the connections moving data between systems.

Data in use is different.

Applications traditionally need access to usable data to search, analyze, or process it, creating a fundamental challenge: how do you compute on data without exposing the data itself?

Historically, organizations have written off encryption-in-use as too expensive to run, too complex to integrate, and too hard to retrofit into legacy systems without specialized cryptographic expertise — chief among them fully homomorphic encryption, which most teams don’t actually need.

The result? Many organizations have reasonably concluded that encryption-in-use is too costly or impractical and instead rely on the alternative controls DORA permits.

But “permitted” doesn’t mean “best.” Regulatory expectations keep tightening, and compensating controls that pass today’s audit aren’t guaranteed to pass the next one.

DORA anticipated this problem

The regulation acknowledges the complexity of encrypting data in use and says that where it is not feasible or is too complex, financial entities can protect confidentiality, integrity and availability through other ICT security measures.

Then Article 6 of the RTS makes the alternative explicit:

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.

This is a crucial distinction, and a narrower one than it first reads: the alternative exists for the case where encryption-in-use isn’t possible. It is not a standing choice between two equal options.

The compliance trap: “If the alternative is allowed, why change?”

So, if DORA permits alternative controls, why would a financial institution invest in encryption-in-use?

Start with the word the fallback hangs on. The RTS doesn’t offer segregation as an equal option; it offers it where encryption of data in use is not possible. That is a conditional, and the condition is doing all the work. When the RTS was drafted, encrypting data in use at production speed was a research topic — fully homomorphic encryption took hours to do what a warehouse does in seconds. It isn’t a research topic anymore. Blind Insight trains a model on a million encrypted records in about 50 seconds and runs aggregates, fuzzy match, and free-text search on ciphertext inside the warehouse you already have. Once encryption in use is possible for a workload, “not possible” stops being something you can write in the audit file for that workload.

Two things follow. First, the burden sits with the entity. It is the financial institution, not the supervisor, that has to be able to justify why encryption in use was not possible for a given system, and that justification gets harder every year the technology is commercially available. Second, guidance follows capability. The RTS already tells entities to stay abreast of developments in cryptography and adapt; when a control moves from impossible to ordinary, regulators tend to stop describing it as optional. A control environment built on the fallback today is built on a clause written for a world that has since changed.

Compliance isn’t the same thing as maximum protection

An organization can satisfy a regulatory requirement with compensating controls and still fall short of the strongest security architecture available.

DORA itself requires organizations to consider leading practices and standards and to adopt mitigation and monitoring measures where they cannot use the most reliable techniques.

The regulatory direction is toward stronger protection

Regulatory frameworks keep moving toward stronger protection of data across its lifecycle. The question isn’t whether a control is compliant today — it’s whether the architecture behind it still holds up in three years.

Compensating controls have a cost too

Organizations often think: encryption-in-use = expensive.

But the real comparison is:

Encryption-in-use investment

vs.

Segmentation + isolation + access controls + monitoring + DLP + privileged access + audit evidence + ongoing compliance work + future remediation

In other words: the fallback isn’t free.

The hidden cost of the “fallback”

Today

Organizations may need to maintain:

• Protected processing environments
• Additional infrastructure
• Network segmentation
• Access controls
• Monitoring
• Logging
• Privileged-access controls
• DLP
• Compensating controls
• Risk assessments
• Documentation
• Audit evidence

Tomorrow

Every time regulatory expectations change, the organization has to revisit that entire control environment.

This creates compliance debt

Like technical debt, compliance debt accumulates when organizations solve today’s regulatory requirement with increasingly complex compensating controls rather than addressing the underlying architectural challenge.

Encryption-in-use doesn’t have to mean “rip and replace”

Modern privacy-enhancing technologies can allow organizations to perform useful operations while keeping sensitive information protected, at a fraction of what many organizations once thought it cost. That’s not a claim to take on faith — see what we won’t oversell about where encryption-in-use is still catching up, phrase search speed among them.

Organizations don’t have to choose between useful data or protected data. They can increasingly architect for useful and protected data.

Where Blind Insight fits

This is what “possible now” looks like in one picture. Data is encrypted by the Blind Proxy before it lands in the warehouse you already run, it stays encrypted while it is queried, aggregated, matched, and trained on, and the six workloads along the bottom are the financial-services jobs running on it today.

How to read it:

• Blind Proxy — encrypts in-region on the way in and processes queries on the way out; the application layer never holds plaintext it wasn’t granted. Platform overview.
• Encrypted EDW — the warehouse you already run, holding ciphertext. Aggregates, fuzzy match, free-text, range, and equality all execute with zero decryption. How that compares to FHE, enclaves, and tokenization.
• KMS/KMI and access controls — the analytics side holds query keys only. Decryption keys are placed on a user’s or agent’s keyring only for the fields their grant permits, under ABAC, RBAC, agentic, or algorithmic policy. How grants work for agents.
• Pseudonymized and anonymized data services — two GDPR postures from one encrypted source: limited access for select cases and staff, or a fully anonymized domain. The configurations are documented in the DORA / GDPR / HIPAA compliance playbook.
• The use-case row — model training and inference on BlindML, retrieval and agent workflows on BlindLLM, and KYC/AML scoring, group MI, quant on encrypted tick data, and time-boxed field controls on the platform. Financial services overview.

Protect data in use

Blind Insight enables organizations to work with sensitive data while maintaining encryption rather than routinely exposing plaintext to the application and database layer. The same protection extends to AI agents and LLM inference sitting on top of that data — see how encrypted inference and agent guardrails work.

Reduce compensating-control complexity

Instead of building an ever-growing collection of controls around plaintext processing environments, organizations can move toward a security architecture where the data itself remains protected.

Build for the regulatory future

DORA isn’t just another box to check. It’s a catalyst to build an architecture stronger than the minimum compliance most organizations settle for. For the control-by-control mapping — including where counsel still has to sign off — see the compliance playbook Cameron wrote for GDPR, HIPAA, and DORA.

DORA compliance across the data lifecycle

Data state	DORA concern	Traditional approach	Privacy-preserving approach
At rest	Confidentiality, integrity	Encryption at rest	Encryption
In transit	Confidentiality, integrity	TLS / network encryption	Encryption
In use	Confidentiality, integrity, authenticity, availability	Plaintext processing + compensating controls	Encryption-in-use / privacy-enhancing technology
Keys	Key lifecycle and security	Centralized key management	Cryptographic key controls
Future threats	Resilience	Periodic upgrades	Architecture designed for evolving cryptography

Blind Insight can become one layer of a broader DORA encryption and cryptographic-controls strategy. For how this maps to model training and inference specifically, see the full DORA Art. 9(2) and GDPR walkthrough for AI workloads.

The business case: spend once vs. keep paying

The traditional approach: DORA requirement → compensating controls → audit → remediation → new regulation → additional controls → repeat.

The privacy-preserving approach: DORA requirement → stronger data architecture → reusable security control → adapt as requirements evolve.

Nowhere is the difference sharper than expansion. Every new territory arrives with its own supervisor, its own residency rule, and — on the fallback — its own protected processing environment, with the whole control list above rebuilt for one more jurisdiction. Encryption-in-use inverts that: one encrypted source, encrypted in-region, with a key and grant policy per jurisdiction — a fraud analyst in Germany who decrypts nothing, an analyst in the US who decrypts one risk field — so a new market is a configuration, not a build. That return is not deferred. It lands on the first market you enter after the architecture is in place, and again on every one after it.

The question isn’t simply “What is the cheapest way to comply with DORA today?” It’s “What architecture gives us the lowest total cost of compliance over the next five, ten, or fifteen years?”

Future-proofing financial data

DORA is one piece of a much larger shift toward treating data security as a lifecycle problem rather than a storage problem. Institutions increasingly need architecture that holds up across data minimization, cross-border transfer, third-party processing, AI workloads, and attacks and cryptographic threats that are still evolving.

DORA’s own RTS explicitly says financial entities should remain abreast of developments in cryptanalysis and adapt cryptographic technology as needed. (EUR-Lex)

The bottom line

DORA does not make encryption-in-use universally mandatory. It recognizes that it may not always be feasible and provides a risk-based alternative.

But “permitted” doesn’t mean “optimal.”

For financial institutions, the real opportunity is to stop optimizing for today’s minimum and start building the architecture that protects sensitive data for good.

Encryption-in-use can turn that challenge into an opportunity: stronger security, fewer compensating controls, and an architecture better positioned for whatever comes next.

Blind Insight gives financial institutions a practical path there now — sensitive data stays protected and useful, without trading security for cost.

DORA didn’t invent the choice between compliant and defensible — it just made it visible. The RTS fallback keeps you inside Article 9(2) today, but only for as long as encryption in use is “not possible” for your workload — and that is no longer a claim that ages well. It also doesn’t stop the compensating-control bill from arriving the next time the standard moves. Encryption-in-use is the version that doesn’t need re-litigating in three years — see the compliance FAQ for how this maps against GDPR and HIPAA too.

From demo to production in weeks. Book a demo and we’ll walk the DORA mapping against your schema, then start in the sandbox — nothing to deploy, synthetic data in your shape, live in 72 hours. Or try it on your own schema today.