Transparent Data Encryption (TDE) is an Oracle Database security feature designed to protect data at rest. It does this by encrypting database files and, in some cases, database objects, while remaining completely transparent to applications and authorised users.
If you work with Oracle databases, you’ve likely encountered Transparent Data Encryption (TDE)—especially during security reviews, compliance audits, or cloud migrations.
In this blog I explain:
Blog #1 - Oracle TDE and Hybrid Disaster Recovery: Why It Breaks & How to Fix It
Blog #3 - TDE licensing - when you're allowed to use it
Blog #4 - Best practice TDE wallet creation & management
Transparent Data Encryption (TDE) is an Oracle Database security feature designed to protect data at rest. It does this by encrypting database files and, in some cases, database objects, while remaining completely transparent to applications and authorised users.
From an operational perspective, applications continue to read and write data as normal. From a security perspective, if someone gains access to database files, storage snapshots, or backups without authorisation, the data is unreadable.
This makes TDE a key tool in security, compliance, and cloud security.
Oracle TDE is widely used to meet:
It protects against scenarios such as:
TDE is therefore a critical control for securing data at rest, particularly in cloud and hybrid environments.
Oracle TDE uses a two-layer encryption model:
This process is completely transparent to applications—no schema changes or query modifications are required.
Oracle TDE supports encryption at two levels:
- encrypts all objects stored within the tablespace, including:
This is the default and recommended approach in most environments, particularly in Oracle Cloud Infrastructure (OCI). Encrypting at the tablespace level provides broad protection without requiring teams to identify individual sensitive columns.
An important note, for Oracle Standard Edition 2 (SE2) on OCI Base Database Service, tablespace encryption is the only supported option. While this removes the ability to encrypt individual columns, it simplifies security design and avoids the operational complexity of managing column-level encryption.
- allows individual columns to be encrypted selectively. This approach can be useful in highly targeted use cases but introduces additional design and operational overhead.
Beyond data files, TDE also protects:
This ensures that data is protected not only at rest, but also throughout common database operations.
A core principle of Oracle TDE is that encryption keys are not stored in the database itself. This separation is critical for security and compliance.
Oracle uses a two-tier key architecture:
The master key is used to encrypt and decrypt the lower-level keys, which in turn protect the data.
A TDE wallet is a secure container used to store encryption keys. It stores only encryption-related material and is typically managed at the database host level.
Wallet-based key management is commonly used in on-premises environments and remains a practical requirement in hybrid architectures, even when OCI Key Management Service is used on the cloud side.
Oracle also supports external key management services, including:
These services enable centralised management of encryption keys across multiple databases and environments. In OCI, databases can be configured to use OCI KMS instead of local wallets.
For in-depth information on TDE wallets READ : Blog #4 - Best practice TDE wallet creation & management
In multitenant databases, keystores can be configured in one of two modes:
A single keystore and master encryption key are shared across the container database (CDB) and all associated pluggable databases (PDBs). This is the most common configuration and simplifies key management.
Separate keystores and master keys are managed for the CDB and individual PDBs. This provides stronger isolation but adds operational complexity.
Important limitation: OCI KMS does not support isolated PDB keystores. Applies to Oracle Exadata Cloud@Customer, Autonomous Database Cloud@Customer, and Oracle Exadata Database Service (as of 2025).
By default, TDE tablespace encryption uses the Advanced Encryption Standard (AES) with a 128-bit key (AES128). This provides strong protection and meets the requirements of most security and compliance frameworks.
Where policy or regulation requires it, stronger algorithms such as AES192 and AES256 can be specified when creating encrypted tablespaces.
Oracle also supports additional algorithms for specific use cases. These are typically relevant for environments with explicit cryptographic requirements.
Oracle TDE is designed to minimise performance impact:
While TDE works well within a single environment, it introduces complexity in hybrid DR architectures.
Key challenges include:
This means:
Hybrid DR designs can appear to work—
but fail after switchover when encryption states don’t match.
This is especially common in:
For more in-depth information READ : Blog #1 Oracle TDE and Hybrid Disaster Recovery: Why It Breaks & How to Fix It
TDE is essential for security—but must be carefully designed in disaster recovery architectures.
Blog #2 - What is Oracle TDE?
Blog #3 - TDE licensing - when you're allowed to use it
Blog #4 - Best practice TDE wallet creation & management
Oracle Transparent Data Encryption (TDE) is a database security feature that encrypts data at rest, including database files, backups, and redo logs, without requiring changes to applications.
Oracle TDE encrypts data files (tablespaces), redo logs generated from encrypted data, RMAN backups, and temporary data created during database operations.
Oracle TDE works using a two-layer encryption model: a master encryption key stored outside the database and data encryption keys stored inside the database, encrypted by the master key. Data is encrypted before being written to disk and decrypted automatically when read.
Oracle TDE encryption keys are stored outside the database in a secure keystore, such as a TDE wallet, Oracle Key Vault, or Oracle Cloud Infrastructure (OCI) Key Management Service (KMS).
Oracle TDE can break hybrid disaster recovery because encrypted redo logs generated in one environment cannot be applied to a database that is not configured with compatible encryption and key management, causing replication failure after switchover.