When your primary lives on on-premises Exadata and your standby sits in a different region or cloud, the hardest part of Transparent Data Encryption is not the encryption itself. It is deciding where the master key lives, how both sides reach it, and what happens to that key when you fail over. This is the field guide to TDE key management across a hybrid Data Guard estate.

Imagine you are a DBA on-call for a Data Guard failover. The primary opens fine, the standby applies fine, the switchover completes, and then something that was invisible for three years suddenly becomes the single most important object in the environment: the Transparent Data Encryption master key. If the new primary cannot reach it, you have a database that is technically up and operationally useless, because every encrypted tablespace it owns is unreadable without the key that protects it.

That is the whole problem in one sentence, and it is a problem that has quietly gotten more interesting over the last year. Oracle has been steadily expanding the set of places where that master key can live, and the set of topologies where a Data Guard relationship can span them. On-premises Exadata can now anchor its keys in an Oracle Key Vault that you control. The multicloud services -Oracle Database@AWS, Oracle Database@Azure, and Oracle Database@Google Cloud – can each use the key management service of the cloud they run in. And cross-region Data Guard now works with those cloud key management services, which means a primary and a standby in different regions of the same cloud can share the same key lineage, with the key replicated across the regions.

What matters here is that the keystore choice is a topology decision. The cross-region Data Guard capability is documented for the case where the primary and the standby use the same cloud provider’s key management service, and the key is replicated between the regions. The wider hybrid case -an on-premises Exadata primary anchored in OKV, with a multicloud standby using a cloud KMS- is an architecture you build from those individual integrations. That is where the operational discipline this article is about really earns its keep.

This article walks through that decision from the ground up: what the key actually is, the ground rules that 26ai now imposes, how to pick a keystore for a hybrid topology, how each of the cloud and on-premises keystore options works, what cross-region replication of the key really requires, and what changes when you bring your own HSM.

The Key You Are Actually Protecting

Start with the object, because a lot of the confusion in this space comes from the word “key” doing too much work. Transparent Data Encryption encrypts your data files (or selected columns) and then transparently decrypts them for authorized sessions. The value is data at rest: if someone steals the storage media or a data file, they get ciphertext, not credit card numbers. Oracle documents this in the Transparent Data Encryption guide.

The encryption is only as strong as the key that drives it, and that is the master encryption key, or MEK. The MEK is what you are actually protecting, and the database stores it in a security module that is external to the database itself. Oracle uses the generic term keystore to cover the whole family, and there are two branches. The first is the TDE wallet, historically called the software keystore, which is a password-protected file that holds the key. The second is an external keystore, which is a key management system that sits outside the database; either Oracle Key Vault or OCI Vault, plus the cloud-native KMS integrations on the multicloud services.

The 26ai Ground Rules

Before you architect anything, understand the constraints that the current release has consolidated. Oracle has been streamlining how TDE is configured, and the direction is deliberate; fewer ways to do it wrong, and a single recommended path that the tooling understands.

The setup is now driven by two parameters. The static WALLET_ROOT parameter names the directory where keystores live, for example /etc/ORACLE/KEYSTORES/${ORACLE_SID}. The dynamic TDE_CONFIGURATION parameter names the type of keystore you intend to use: FILE for a wallet or OKV for Oracle Key Vault. When you create the keystore, the database builds a directory under WALLET_ROOT for that type: WALLET_ROOT/tde for a wallet, WALLET_ROOT/okv for Key Vault.

There is one detail here that will save you a painful upgrade, and it is worth internalizing. Upgrades of 19c and 21c databases to 26ai will fail if the source databases do not have WALLET_ROOT and TDE_CONFIGURATION set. Oracle is retiring the older sqlnet.ora-based configuration path, and the ENCRYPTION_WALLET_LOCATION parameter is desupported in 26ai. The reason is simpler to explain: one explicit, parameter-driven keystore location that both the cloud tooling and the upgrade path can read, instead of a search order that could resolve to more than one place. If you are planning a move to 26ai, set those two parameters on your 19c DBs now, while the upgrade path still works.

Two related consolidations are worth knowing. TDE public key infrastructure keys are desupported in 26ai, which moves the platform toward the modern keystore model. And the keystore search order is now explicit: first the WALLET_ROOT location when the KEYSTORE_CONFIGURATION attribute of TDE_CONFIGURATION is set (which is the recommended path), then the legacy sqlnet.ora location (which is the desupported one), then the ORACLE_BASE or ORACLE_HOME admin wallet directory.

You can see which mode a database is in at any time from the V$ENCRYPTION_WALLET view:

SELECT KEYSTORE_MODE, CON_ID FROM V$ENCRYPTION_WALLET;

The KEYSTORE_MODE column reports UNITED or ISOLATED. That mode turns out to matter a lot for the multicloud options, so hold that thought.

United Mode for the Cloud

In a multitenant environment you can configure keystores for the whole container database, or for individual pluggable databases. United mode means a common keystore for the CDB and the PDBs that are in united mode. Isolated mode means a keystore per PDB, and an isolated PDB overrides the united mode setting of its CDB.

This matters because the customer-managed key options on the cloud services require united mode. Oracle Key Vault integration for ExaDB-D, and the multicloud key management integrations, operate at the CDB level: the key management solution you choose applies to the entire CDB and all of its PDBs. You cannot pick a different keystore at the PDB level. What you can do is give different PDBs within the same CDB distinct encryption keys, but they all draw from the same keystore.

So if you are standardizing on an external keystore across a hybrid estate, the practical rule is: keep your PDBs in united mode. If a PDB is in isolated mode, the cloud tooling will not manage it, and you will find yourself with a database that the automation cannot see. This is one of those constraints that is invisible until you are three databases deep into a migration and one PDB refuses to join the keystore.

On-Premises: Oracle Key Vault as the Anchor

Oracle Key Vault is a software appliance -a purpose-built application stack that you install on your own hardware. It is not a cloud service that Oracle runs for you, and it is not a physical box that you buy. It is a set of software packages (built on Oracle Linux and Oracle Database) that you deploy onto a server or virtual machine you control. The Oracle Key Vault documentation describes it as “a full-stack, security-hardened software appliance built to centralize the management of keys and security objects within the enterprise.” You are responsible for provisioning it, securing it, backing it up, and keeping it healthy — which is exactly what you want on the primary side of a hybrid topology: the key does not leave a system you control.

OKV can run on bare metal or on a virtual machine. The installation guide states that the process “installs all the required software components onto a dedicated server or virtual machine.” You can deploy it on Oracle Database Appliance hardware, on your own x86 server, or on an OCI compute instance. This last point matters for the hybrid estate: OKV can live in OCI as a VM, which means you can run a fully OKV-based hybrid architecture where your on-premises Exadata, your OCI-hosted OKV, and your multicloud databases all share the same key management plane.

It can also be deployed as a multi-master cluster of up to 16 geographically distributed nodes, giving you fault tolerance and high availability at the key management layer. If one OKV node goes down, the others continue serving keys. The cluster can span data centers, so an OKV cluster with a node in your on-premises DC and another in an OCI region acts as a single, coherent key management fabric.

Oracle Key Vault is not a Hardware Security Module. An HSM is a physical device with tamper-resistant hardware that generates and stores cryptographic keys inside a dedicated, FIPS-validated boundary. OKV is a software appliance: it stores keys in software, running on a general-purpose operating system.

The distinction is not academic. An HSM provides a hardware root of trust; the key material never leaves the physical boundary of the device. OKV provides centralized key lifecycle management with software-based storage. If you need the hardware-backed assurance, you can pair OKV with an HSM: OKV manages the keys and wallets, and the HSM protects the root key that encrypts them. This is the “OKV backed by HSM” pattern. But OKV itself is the key manager, not the hardware vault.

The practical upside of OKV being a software appliance is flexibility. You can deploy it on existing hardware, in a VM, or in a cloud compute instance. You can cluster it across locations. You can back it up with standard Oracle tools. And you can manage the full lifecycle of your encryption objects — creation, rotation, deactivation, archival — through a centralized console or REST API.

OCI Vault: The Native Cloud Keystore

Before we get to the multicloud KMS integrations, there is a third external keystore option that sits between OKV and the cloud-native services: OCI Vault, Oracle Cloud Infrastructure’s own key management service.

OCI Vault is a managed cloud service within OCI that stores and manages encryption keys. It is the native keystore for databases running in OCI regions, and it is also available as a keystore option for the multicloud services: you can point an Oracle Database@Azure, Oracle Database@AWS, or Oracle Database@Google Cloud database at an OCI Vault, and the Exadata infrastructure in that third-party cloud will reach back into OCI to fetch the key. This is documented in the Exadata Database – OCI Vault integration guide: the integration requires an OCI dynamic group, an IAM policy, and network connectivity from the Exadata VM cluster into OCI.

The important implication is that OCI Vault is an OCI-resident service. It is not a local service in AWS, Azure, or Google Cloud; you must connect to OCI to use it. This has a latency and availability consequence: every key operation from your multicloud database crosses the network into OCI. For a cross-region Data Guard configuration using OCI Vault, there is an additional constraint: OCI Vault currently supports key replication to only one remote region, which limits your Data Guard topology to two regions (the primary region and one standby region).

So the real choice is this: with OCI Vault you keep one key management service that covers all your Oracle estates, on-premises included, because on-premises OKV can bridge to it. With a cloud-native KMS (AWS KMS, Azure Key Vault, GCP CMEK) you keep key operations inside the same cloud as the database.

Multicloud: AWS KMS, Azure Key Vault, and GCP CMEK

The multicloud services -Oracle Database@AWS, Oracle Database@Azure, and Oracle Database@Google Cloud- each let the TDE master encryption key live in the key management service of the cloud the database runs in. This section explains what each service is, why it matters for Oracle, and how the integration works. It applies specifically to the Exadata Database Service on Dedicated Infrastructure running in those clouds, not to arbitrary Oracle databases that you install yourself on a cloud VM.

Before we go into the details, it is worth being explicit about why OKV is not the same thing as these cloud KMS integrations. OKV is a customer-provisioned software appliance; you install it, you own it, you manage the backup and the upgrade cycle. The cloud KMS services are fully managed by the cloud provider: you create a key, you define who can use it, and the provider handles the durable storage, replication, and availability. The integration model is also different: OKV uses a direct network connection from the database endpoint to the OKV server, while the cloud KMS integrations use a PKCS#11 driver on the Exadata VM cluster plus a cloud-specific identity connector.

AWS KMS

What it is. AWS Key Management Service is a fully managed service that lets you create and control cryptographic keys used to protect your data across AWS services and your own applications. You define a key, you decide which IAM roles can use it, and AWS handles the durable storage and replication of the key material. A key can be single-region or multi-region; a multi-region key automatically replicates to other AWS regions you select.

The philosophy is clean: the identity of the database is established through OCI, the permission to use the key is granted in AWS IAM, and the key operations stay within AWS’s network boundary. No key material ever leaves AWS.

Key backup and replication. AWS KMS multi-region keys replicate automatically to the chosen regions. For single-region keys, AWS KMS stores the key material redundantly within the region. AWS does not allow the key material to be exported, but you can schedule key deletion with a 7-30 day waiting period, during which the key is in a pending-deletion state and can be recovered.

Azure Key Vault

What it is. Azure Key Vault is a cloud service for securely storing and accessing secrets, encryption keys, and certificates. It comes in three tiers: Standard (software-protected keys in a multi-tenant environment, FIPS 140-2 Level 1), Premium (HSM-protected keys with FIPS 140-2 Level 2 or FIPS 140-3 Level 3 depending on the HSM platform, with Platform 2 the current default), and Managed HSM (single-tenant, fully managed hardware security module, FIPS 140-3 Level 3 validated). The tier you pick determines the compliance floor your keys satisfy.

The operational philosophy differs from AWS in one important way: the identity connector is per-VM (Azure Arc agent on each machine), not per-cluster. And for Managed HSM, which is the compliance-relevant tier, the connectivity must be private;no public endpoint. You set up an Azure Arc Private Link Scope and a Private Endpoint to keep the traffic off the internet.

Key backup and replication. Azure Key Vault supports soft-delete (enabled by default, 90-day retention) and purge protection: a deleted key remains recoverable for the retention period. You can also back up a key to an encrypted file and restore it to another vault in any Azure region. For cross-region Data Guard, you replicate the vault (not individual keys) using the OCI console’s “Replicate Azure key vault” operation. This mirrors the entire vault and its keys to the target region.

GCP CMEK

What it is. Google Cloud’s Customer-Managed Encryption Keys (CMEK) is a feature of Cloud KMS that lets you create and manage encryption keys used by Google Cloud services. You organize keys into key rings (a logical grouping per region), and you control who can use each key through IAM permissions. CMEK is specifically the “bring your own key” variant — you create and control the key, as opposed to Google-managed keys.

This model is architecturally interesting because it is the only one of the three where key resources are first-class objects in OCI. You register a GCP key ring in OCI, and from that point forward the full key lifecycle — provisioning, rotation, revocation, and auditing — is visible from the OCI side. The key still lives in GCP, and key operations still happen in GCP, but the management plane is unified in OCI.

Key backup and replication. GCP CMEK keys are automatically replicated within the chosen region for durability. Cloud KMS also supports multi-region keys, which replicate automatically to the constituent regions defined by the multi-region location. For cross-region Data Guard, you replicate the key ring (not individual keys) using the OCI console’s “Replicate GCP key ring” operation. Keys can be scheduled for destruction with a configurable destruction period (default 30 days), and they are recoverable during that window.

The External Keystore Option: Bring Your Own HSM

There is a fourth path that is newer and conceptually different from the three multicloud integrations. The Manage Keys Using an External Keystore capability lets you store the MEK in an external keystore of your choice on ExaDB-D, available for 26ai and 19c. It is distinct from the multicloud integrations: those are for the multicloud services and use the cloud provider’s own key service, whereas the external keystore option is for ExaDB-D and points at a keystore appliance you choose, including a third-party HSM.

Where we earlier explained the conceptual model of external keystores, this option is the practical realization of it: a PKCS#11 interface that the database talks to, with you owning the keystore appliance on the other side.

The DC Exit Scenario: Keeping Your On-Premises HSM

This is the use case that makes the external keystore option strategically relevant. If you have an on-premises data center with a hardware security module (such as a Thales Luna, Entrust nShield, or Utimaco HSM) that already protects your TDE keys, and you are moving that database to ExaDB-D in the cloud, you have a decision to make.

The external keystore option lets you keep using that same HSM. You install the HSM vendor’s PKCS#11 library on the Exadata VM, configure the network path from the VM to the HSM (or to a cloud-hosted instance of the same HSM), and the database continues to fetch its master key from the same appliance it has always used. The key does not need to be migrated to a cloud KMS. The compliance boundary and the key custody remain unchanged.

You own the end-to-end connectivity, the PKCS#11 driver installation, and the HSM configuration. The cloud automation does not check the connection to the external keystore in advance, so if the key is unreachable, the database returns an error and you find out at the worst moment. But for an industry that has built its audit trail around one specific HSM, keeping that same HSM is a strong reason to use this option.

Key Backup with an External Keystore

Key backup for an external keystore is entirely your responsibility. The HSM or keystore appliance vendor provides its own backup and restore mechanisms. Unlike AWS KMS or Azure Key Vault, where the cloud provider handles durability and replication, the external keystore model puts the backup burden on you. This is consistent with the custody model: if you own the key, you own the backup of the key.

Cross-Region Data Guard: Replicating the Key

This is where the whole architecture comes together. Since April 2026, ExaDB-D supports cross-region Data Guard for databases that use a cloud service provider key management service for their TDE MEKs: Azure Key Vault (Standard, Premium, and Managed HSM), GCP CMEK, and AWS KMS and CloudHSM. The supported operations are the ones you care about in a real DR plan: adding standby databases across regions, switchover and failover, database lifecycle operations, and viewing encryption key details across primary and standby.

What the Cloud Services Automate

The cross-region Data Guard enablement documentation specifies the workflow. The encryption key resource must be replicated from the source region to the destination region before you enable Data Guard. Depending on the service: for Azure, you replicate the vault; for GCP, you replicate the key ring; for AWS, you replicate the key itself.

Once replicated, the standby VM cluster must have its identity connector in place and cloud key management enabled. Before you flip the switch, verify the key management configuration on the primary from the Database Details page, in the Encryption section: for Azure you confirm the vault and key, for GCP the key ring and key, for AWS the key.

After that, Data Guard operations -switchover, failover, reinstate- work with no additional key management steps. The primary and standby both draw on the same key lineage, and the cloud KMS handles the regional availability of the key material.

The Scope of the Capability

This is a cross-region capability within a cloud provider’s key management service: the primary and the standby are in different regions, both use the same provider’s key service, and the key resource is replicated between the regions. It is not a documented Data Guard group that spans AWS on one side and Azure on the other. When you build the wider hybrid case – an on-premises primary anchored in OKV, a multicloud standby on a cloud KMS– you are putting those individually documented integrations together, and making the key reachable by both sides is then your responsibility.

Wrapping up

If your database is encrypted and your disaster recovery site is in a different location -or a different cloud- then the most important security object in that environment is not the data. It is the key that unlocks the data, and the decision of where that key lives is one of the most consequential choices you will make in the design.

For a long time the practical answer was simple: the key lived in a file on the same machine as the database, and that was good enough as long as everything stayed in one place. That model breaks the moment your standby is somewhere else, because a key that is local to the primary cannot be reached by a standby in another region. What has changed is that the platform now gives you a proper set of answers to that problem. You can keep the key in Oracle Key Vault – a software appliance you control, on your own hardware, in your own data center, or in an OCI compute instance, optionally clustered across locations for resilience. You can store it in OCI Vault as a managed cloud service that spans your Oracle estates. You can let it live in the key management service of whichever cloud the database runs in -AWS KMS, Azure Key Vault, or GCP CMEK. And if you have an existing on-premises HSM that you trust, you can keep using it in the cloud through the external keystore option.

The single takeaway is this: treat the key as a first-class part of your high availability plan, not as an afterthought of your encryption plan. Decide deliberately where it lives, make sure both sides of your recovery relationship can reach it, and keep a documented record of its lifecycle. Do that, and the encrypted database that fails over cleanly is the same database that passes the audit.