The European Union’s (EU) Digital Operational Resiliency Act, known as DORA, goes into effect January 17, 2025, and is the first major regulation to specifically mandate data encryption at rest, in transit and in use. For many, this regulation has slipped in under the radar. DORA is an EU regulation and is specifically designed to govern the financial sector, so you may be wondering if it applies to your organization. The short answer is, most likely.
Much like GDPR, the “it doesn’t apply to me” debate will be a topic of discussion around DORA for the foreseeable future. There is no question that any financial institution that does business within the EU, or has EU citizens as clients, will be held accountable to DORA. Also, if you do business with or support an EU financial institution, you will fall within DORA regulations. And the fines related to being out of compliance with DORA can be substantial.
Understanding Encryption of Data in Use
The best way to understand DORA is to take the time to review the regulations and consult your legal team to help mold your strategy. That said, there is one critically important piece that addresses a major gap in data operations today: encryption of private, or critical data. Specifically, Article 9, Paragraph 2 which directly mandates encryption of data in use in addition to data at rest and data in transit. This means that by January 17th, 2025, all financial sector organizations who meet the EU designation must actively be implementing encryption of data in use. And right now, global adoption is of encryption of data in use is less than 1%–so your organization is likely not compliant with this regulation right now.
DORA is the first regulation to require encryption-in-use, but it will not be the last. Leaving data-in-use in plaintext is one of the most obvious attack vectors for cyber criminals—and has long been a pain point for organizations. For those not familiar with data in use, it is not the same as data in motion or in transit. Data in use is the active operationalized private, sensitive, or controlled data currently in use to process business transactions.
To put it into context, data at rest is data that is static. Think archives, backups, or any data that is not being searched, processed, or manipulated. Data in transit (or motion) is data that has been put in a container to be transmitted from one point to another. Again, like with data at rest, data in transit is static, not being searched, processed or manipulated while being transmitted. Both data at rest and data in transit are easily encrypted while in those states.
Unfortunately, encryption of data at rest or data in transit is only encrypted within those static states. In order to perform an operation upon that data (e-discovery, audit, query, maintenance, or manipulation), that data must be decrypted into plaintext. This is where the data is most at risk—and what DORA is aiming to crack down on.
Private and critical data is also more fluid today than at any point in history. Data is rarely “at rest” or in a static state. Even data archives, once referred to as “cold storage”, require the ability to perform e-discovery, audit, and maintenance upon the dataset at any given time. This is in direct conflict with the ability to effectively utilize encryption at rest technologies upon archived databases. The only way to truly secure data archives is with encryption of data in use technology.
Financial Institution Example
To better understand these regulations let’s look at a particular use case. Given that DORA is a financial sector regulation, let’s use lending as the use case. When a consumer fills out a loan application they enter private data as part of the standard process. That application is submitted for review, often entering several different review steps. Because the data collected is fluid, it is not encrypted throughout most of the process.
Now, let’s say that the consumer calls the financial institution’s lending officer to update information or check on the status. The lending officer is going to go into their application and run a query for the consumer record. When the lending officer hits enter, the query runs upon an unencrypted, plaintext dataset. This operation requires that a large pool of data remains unencrypted in plaintext to support on-demand requests. In short, there is always a large, active, highly valuable dataset sitting in plaintext to support day-to-day lending operations. As you can imagine, the data has to be available all the time because no one knows who’s going to call for support at any given time.
So, your organization doesn’t offer loan services. Do you handle inquiries from customers related to billing? What about account status? How about selling life insurance products? Almost every aspect of a financial institution’s core operations runs on private, sensitive, and/or controlled data that needs to be readily available. The key is to have this data available while maintaining encryption—which is where encryption of data in use comes in.
From a threat actor perspective, they are hoping you aren’t ready to implement encryption upon data in use because they have been taking advantage of this operational weakness for decades. Look at the largest breaches 2023 and 2024: Latitude Financial, 14 million customers; MOVEit Breach, millions of financial services records compromised; NCR Corporation, disrupted services and exposed sensitive data; AT&T, 73 million customer records; UnitedHealth, unencrypted data; Ticketmaster, millions of customer records.
All the data compromised in these breaches was in plaintext because all the data was in use. This resulted in billions of dollars of damage to the business and an untold amount of damage to consumers. Are you ready for encryption of data in use? If not, it is time to get ready in order to comply with DORA.
DORA Implications for Other Organizations
Perhaps your organization is not an EU financial institution and doesn’t have any accountability to one or to a EU citizen. Why should you care about DORA?
Compliance requirements for encryption of data in use are coming to a law near you. For context, the recent American Privacy Rights Act—a bill that didn’t make it through the U.S. Congress during the last session—included wording related to requiring implementation of privacy enhancing technology (PET) such as encryption of data in use. The Cybersecurity and Infrastructure Security Agency (CISA) specifically called out encryption of data in use under its most recent zero trust maturity model.
We have also learned from our experience with GDPR, once a major compliance body introduces new data security mandates, others will quickly follow. If you rely on compliance to build your critical data strategy, you may not be required to encrypt data in use at this time. But it’s likely only a matter of time before another regulation will require your organization to encrypt data in use.
And if you are at all concerned about your operations’ contribution to the projected 2025 $10.5 trillion cybercrime costs, you may see the threat as being a mandate in itself. To better put that number into context, the global population is around 8.5 billion people, therefore cybercrime will cost each human $1,235.29 per year by 2025. Cybercrime is a key contributor to global inflation.
It’s clear, whether your organization must comply with DORA or now, we need encryption of data in use.
You may not have thought much about encryption of data in use until now, but data security innovators have. There are a few factors to consider when considering the adoption of an encryption solution.
-
-
- Implementation: Do you have the resources to implement the technology?
- Complexity: Does it require a rearchitecting of my environment and/or key operational applications?
- Speed: Is the technology going to add unacceptable latency to my operations?
- Cost: Is the cost of the technology something my organization can justify? More importantly, can you afford to not encrypt your most valuable data?
-
Now that the hard questions are on the table, let’s look at the technology. There are two primary technologies that have been specifically identified to address encryption of data in use:
-
-
- Homomorphic Encryption (HE): HE is often referred to in two flavors, Fully Homomorphic Encryption (FHE) or Partial Homomorphic Encryption (PHE).. FHE offers some hope for addressing data in use, but there are many challenges, the result of which makes it hard to implement for on-demand, practical use cases. The primary challenges reside in the amount of computational power required to run the extremely complex computations. Even with the appropriate hardware, FHE is too slow for on-demand operations such as account management, transaction processing, and client services. PHE is noticeably faster. Unfortunately to get closer to near-real-time processing, security is sacrificed.
-
-
-
- Confidential Computing: Confidential computing is based upon a trusted execution environment (TEE) comprised of several validated hardware and software components. The computation on the data is all done within a certified confidential computing enclave known as the TEE. The data is still in a plaintext format, but the query (or operation) must be completed within the designated TEE which includes chip level encryption. The primary challenges to implementing a confidential computing environment is complexity and cost. The TEE is very complex and will require specifically certified experts to implement and manage. It will also require rearchitecting the data security environment, and applications will need to be modified to run within the TEE. Cost is an obvious concern related to talent and technical resources. Lastly, the TEE will require an annual certification to assure that it meets the minimal standards to be considered as a secure confidential computing TEE.
-
There is a third option for encryption in use that does not face the same challenges as these other options: Paperclip SAFE Searchable Encryption. Paperclip has invested over eight years developing an encryption of data-in-use technology called SAFE®. The innovators at Paperclip built SAFE for one specific purpose: to secure the data its clients trust Paperclip with. As a content supply chain company providing critical backend operations for many recognizable enterprise financial services, Paperclip realized that they needed to do more to secure the data passing through their operations on behalf of their clients.
After exploring and ruling out technologies like PHE, confidential computing, format preserving encryption, and tokenization because they didn’t meet basic operational requirements, Paperclip elected to build its own technology. After exhaustive research (much like EU financial organizations are conducting right now), Paperclip landed on Searchable Symmetric Encryption (SSE) as the only practical foundation. SSE was developed and proven by Song, Wagner, and Perrig in 2000 as part of a joint DARPA and Berkley project.
By combining SSE with patented Paperclip technologies, Paperclip was able to build SAFE as a SaaS-based encryption of data-in-use technology that simply implements at the API layer. SAFE requires no disruption to the end user (no training), no redesigning network or database architecture, and near real-time performance that is virtually unnoticeable to the end user. Other than API expertise and basic database knowledge, SAFE doesn’t require a client to hold any specialized certifications. To cap it all off, the data is shredded, deduplicated, salted, hashed, then fully encrypted with highly secure AES 256 encryption keys (dual keys – data holder and data owner).And SAFE is sold as an affordable SaaS solution that sits at a lower price point than the other encryption –in use options listed above.
Yes, there is a practical way to meet DORA’s encryption of data-in-use mandates and prevent data ransom and theft of private, sensitive, and controlled data. The technology resides within Paperclip SAFE and is available for easy implementation today.
Visit www.paperclip.com/SAFE to learn more or contact Paperclip to schedule a demonstration.