Organizations moving critical workloads to the cloud often need more than encryption at rest. They need direct control over where encryption keys are created, stored, governed, rotated, and audited. This is especially important for regulated industries, multicloud environments, and customers with data sovereignty or separation-of-duties requirements.
Oracle Cloud Infrastructure External Key Management Service, or OCI EKMS, helps meet these requirements by allowing OCI services to use encryption keys that are created and managed outside OCI, by integrating with third-party key manager systems (KMS). With this integration, customers can keep key material in a third-party KMS, while OCI KMS routes supported cryptographic operations to this third-party through a secure integration pattern.
Currently, OCI EKMS can be integrated with Thales CipherTrust Manager and Fortanix Data Security Manager (DSM). This blog is focused on the integration with Fortanix DSM.
Why Fortanix DSM with OCI EKMS?
OCI KMS already provides native cloud key management backed by Oracle-managed HSMs. For some customers, however, policy or regulatory requirements call for external custody of master encryption keys. OCI EKMS is designed for these scenarios.
With OCI EKMS and Fortanix DSM:
- Key material remains outside OCI in Fortanix DSM.
- OCI stores key references, not the actual key material.
- Encrypt and decrypt operations are performed by Fortanix DSM.
- OCI services continue to use OCI-native workflows through OCI KMS.
- Security teams can centralize key management across hybrid and multicloud environments.
This gives customers a clean separation between encrypted data in OCI and externally controlled encryption keys.
How the Integration Works
At a high level, OCI External KMS is configured with an external Vault backed by Fortanix DSM. OCI integrated services continue to use the OCI Vault interface as they normally would. When a cryptographic operation is required, OCI External KMS routes the request to Fortanix DSM over a private endpoint.
The sequence flow includes the following:
- OCI service requests encryption or decryption through OCI External KMS, which uses an external Vault.
- The external Vault authenticates with OCI Identity Domains using the confidential client application credentials and obtains an OAuth2 JWT access token (issued by OCI Identity Domains) containing the required audience and scope.
- OCI External KMS sends the request, along with the token, through a private endpoint in a VCN, to OCI API Gateway. The OCI API Gateway acts as the secure entry point for OCI EKMS requests.
- The OCI API Gateway validates incoming requests and forwards them to Fortanix DSM over HTTPS.
- Fortanix DSM validates token issuer, audience and scope by using OCI’s JWKS endpoint and OCI Identity Domain public signing keys, and confirms that the request is authorized to use the target key.
- Fortanix DSM locates the configured security object (AES-256 key) and performs the cryptographic operation internally and returns the result (only the result of the operation is returned through the API Gateway to OCI External Vault and then back to the requesting OCI service; the key material remains securely within Fortanix DSM).
The important point: The key material never leaves Fortanix DSM. OCI External Vault uses an external key reference mapped to a Fortanix DSM security object.
You can see below the OCI EKMS and Fortanix DSM request flow corresponding to the previous sequence.
Notes:
- (Optional, recommended) FastConnect co-location can be created in OCI. This is required to have direct connectivity between the OCI VCN and the Fortanix DSM.
- A Fully Qualified Domain Name (FQDN) is used for TLS certificate, instead of an IP address. Configuration using FQDN requires a private API Gateway in a private subnet. If using different networks for the private endpoint and the API Gateway, then the private subnet must have a NAT Gateway to route requests from the API Gateway to OCI External KMS. If both are using the same network, it is only needed to allow the access via security list.
Here you have an architecture according to the previous description:
Core Configuration Flow
A typical implementation includes these major steps:
- Prepare OCI networking with a VCN, private subnet, routing, and security rules.
- Configure TLS for secure communication between OCI EKMS, API Gateway, and Fortanix DSM.
- Create an OCI API Gateway deployment that forwards OCI EKMS requests to the Fortanix DSM endpoint.
- Configure OCI Identity Domains with confidential applications, audience values, and the right scope.
- Enable access to the Identity Domain signing keys so Fortanix DSM can validate JWTs.
- Create a private endpoint for access in OCI.
- Create an external Vault in OCI EKMS.
- Configure Fortanix DSM with a group, application, JWT authentication, and signing key URL.
- Create an AES-256 security object in Fortanix DSM with encrypt and decrypt permissions.
- Create an OCI key reference that maps to the Fortanix DSM security object.
The OCI key reference acts as the logical OCI-side representation of the key. The actual key remains in Fortanix DSM.
Operational Considerations
The external key ID is treated as a durable contract. In the Fortanix integration, OCI maps the key reference to the Fortanix DSM security object name. After the key reference is created, renaming the corresponding security object in Fortanix DSM needs to be avoided because cryptographic operations can fail if OCI can no longer resolve the referenced key.
It is crucial to plan for availability and latency. OCI EKMS depends on timely responses from the external key manager. The timeout limits for External KMS operations are: 1 second for read timeout and 500 milliseconds for connection timeout, so the Fortanix DSM endpoint, API Gateway, private connectivity, DNS, TLS, and identity configuration should be designed and tested as production-critical infrastructure.
Also it is needed to establish an operational model for key rotation, audit review, access approval, break-glass access, and incident response. External key management gives security teams powerful control, but that control must be paired with reliable runbooks.
OCI Services That Can Use EKMS
OCI External Key Management provides support across several services, including Block Volume, Compute boot volume encryption, File Storage, Object Storage, Oracle Kubernetes Engine, Streaming, and multiple Oracle Database services. This allows customers to apply externally managed keys to a broad set of cloud workloads while continuing to use OCI-native service integrations.
Conclusion
Fortanix DSM with OCI External Key Management gives customers a strong model for key sovereignty, centralized governance, and separation of duties. OCI services continue to operate through familiar Vault integrations, while Fortanix DSM remains the system of record for key material and cryptographic operations.
For customers in regulated, hybrid, or multicloud environments, this architecture offers a practical path to protect data in OCI while retaining external control of the keys that protect it.
As next step, you can read more about OCI External KMS in Oracle documentation. You can also give it a try: visit our OCI KMS website to learn more about Oracle Cloud Infrastructure Security products and sign up for a Free Tier account to take a closer look.
For more information, you can see the following resources: