What is Oracle Transparent Data Encryption (TDE)?

If you work with Oracle databases, Transparent Data Encryption (TDE) is one of those features you’ve almost certainly heard of, and may already be using, even if you haven’t had to think too deeply about how it works.

TDE often comes up during security reviews, compliance discussions, cloud migrations, or questions around backup and disaster recovery. While encryption at rest isn’t unique to Oracle, it’s particularly important to understand Oracle TDE well because of its licensing implications, its default use within OCI’s Base Database Service, and the architectural complexities it can introduce in hybrid environments (which I covered in a previous blog).

In this post, I’ll walk through what Oracle TDE actually does, what parts of the database it protects, and how Oracle implements it under the covers. The goal is to keep this grounded in real Oracle behaviour, detailed enough for DBAs, but structured so architects and IT decision makers can clearly understand the design implications as well.

What is Oracle Transparent Data Encryption (TDE)?

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.

What problem does TDE solve?

TDE is designed to protect against scenarios such as:

• Lost or stolen database backups.
• Compromised storage or snapshots.
• Unauthorised restores of database files outside a controlled environment.

By encrypting data at the physical file level, TDE ensures that data remains protected even if infrastructure controls fail.

Importantly, encryption and decryption are handled entirely by the Oracle database engine. There is no requirement for application changes, schema redesign, or query modification.

What does Oracle TDE encrypt?

Oracle TDE supports encryption at two levels:

Tablespace encryption

Tablespace encryption encrypts all objects stored within the tablespace, including:

• Data files.
• Associated redo data.
• Segments created within the tablespace.

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. 

Column-level encryption

Column 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.

What else is protected?

Beyond data files, TDE also protects:

• Database backups: Encrypted data remains encrypted in RMAN backups.
• Redo data: Redo data generated for encrypted tablespaces is also encrypted.
• Temporary data: Data written to temporary tablespaces during sort operations remains protected.

This ensures that data is protected not only at rest, but also throughout common database operations.

Where are encryption keys stored?

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:

• A TDE master encryption key, stored externally.
• Tablespace or column encryption keys are stored in the database, but encrypted using the master key.

The master key is used to encrypt and decrypt the lower-level keys, which in turn protect the data.

TDE wallets

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.

External key management

Oracle also supports external key management services, including:

• Oracle Key Vault (on-premises)
• OCI Key Management Service (KMS)

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.

Hybrid Environments & TDE Challenges

One area where TDE design becomes more challenging is in hybrid environments, particularly for teams running Oracle Standard Edition. While TDE works well within a single environment, extending encrypted databases across cloud and on-premises sites introduces key-management and architectural constraints, especially where features such as Data Guard or cloud-native key services are not available. 

In OCI Base Database Service, TDE is enabled by default, but those encryption decisions can complicate hybrid disaster recovery designs when the secondary site operates under different edition, licensing, or key-management limitations. We explore these challenges and practical ways to address them in more detail in our separate blog focused specifically on TDE in hybrid Oracle environments.

TDE in multitenant environments

In multitenant databases, keystores can be configured in one of two modes:

United mode

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.

Isolated mode

Separate keystores and master keys are managed for the CDB and individual PDBs. This provides stronger isolation but adds operational complexity.

It’s important to note that OCI KMS does not support isolated PDB keystores. This limitation applies to services such as Oracle Exadata Cloud@Customer, Autonomous Database Cloud@Customer, and Oracle Exadata Database Service (as of January 2025).

Encryption algorithms and strength

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.

Performance and operational considerations

Oracle TDE is designed to minimise performance impact:

• Tablespace encryption does not interfere with index range scans
• RMAN compression continues to function normally
• Advanced features such as Exadata Hybrid Columnar Compression (HCC) and Advanced Compression are fully supported

In most modern environments, the performance overhead of TDE is negligible compared to the security benefits it provides.

Summary

Oracle Transparent Data Encryption provides strong, transparent protection for data at rest by encrypting database files, backups, and redo data, while keeping encryption keys outside the database itself.

For DBAs, TDE integrates directly into standard database operations. For architects and decision-makers, it provides a critical security control that aligns with cloud and compliance requirements, particularly in the OCI Base Database Service, where TDE is mandatory by default.

Understanding how TDE works, its defaults, and its constraints is essential when designing secure Oracle database architectures, especially in hybrid and cloud-based environments.