Skip to content
Futurex Tops ABI Competitive Report as #1 Innovator!
Get the report
  • There are no suggestions because the search field is empty.
Futurex Tops ABI Competitive Report as #1 Innovator!
Get the report

Database TDE

Database Master Key Protection Outside the Database Engine

CryptoHub provides external database key management for SQL Server, MySQL, Oracle, MongoDB, MariaDB, PostgreSQL, and additional database platforms through EKM, KMIP, and PKCS#11, the interfaces that those databases already support, storing database master keys in FIPS 140-3 Level 3 validated HSMs and separating key administration from database administration.

Database TDE Hero Image
Multiple database platforms supported_

Support for SQL Server, Oracle, MySQL, MongoDB, MariaDB, PostgreSQL, and more

No universal emergency decryption key-1

Database master key never exists in plaintext outside the HSM boundary

Audit trails, access controls, and revocation support

Full audit log of every database key access event, by database and administrator

Separation of DBA and key admin roles

Separation of database administrator (DBA) and key admin roles: a documented PCI DSS and HIPAA compliance control

Consistent key governance across all supported database platforms,

Consistent database key governance across all supported database platforms, in a single interface

The Decision You Are Actually Making

If you already have TDE deployed, the question is not whether to encrypt. The question is where the database master key lives, and whether the person who runs the database also controls the keys that protect it.

Database TDE encrypts data at rest at the storage layer without application changes. The database engine generates a data encryption key (DEK) and wraps it with a master key.

By default, that master key lives inside the database engine, on the same system as the data it protects.

External key management moves the database master key out: CryptoHub holds it inside HSM hardware, and the database requests it through a standard interface at startup or key rotation. Nothing changes at the application layer.

The result: the key that protects the database no longer lives with the data it protects, and the person who manages the database no longer controls the keys.

Architecture Diagram for How TDE Works with CryptoHub Database TDE encrypts data at rest at the storage layer. The database engine generates a data encryption key (DEK) to protect stored data with no application changes required. That DEK is wrapped by a master key before storage, and by default, the master key resides inside the database engine on the same system and within the same administrative boundary as the data it protects. CryptoHub moves the master key out of the database. It stores the key inside HSM hardware, and the database retrieves it through a standard interface during startup or key rotation. The application remains unchanged. What changes is where the key resides and who can access it. Key Separation as a Control When the master key resides inside the database engine, the database administrator also controls the keys protecting the data. That co-location is a recognized control gap under PCI DSS 4.0, NIST SP 800-57, and HIPAA audit frameworks, and a common finding in PCI, HIPAA, and SOC 2 assessments. CryptoHub establishes a documented separation of duties. Master keys are stored inside FIPS 140-3 Level 3 HSMs and never leave that boundary in plaintext. Database and key administrators operate in separate systems with separate credentials, and every key access request is logged with a timestamp, requesting system, and administrator identity. Database administrators never have direct access to the master keys, and the audit trail proves it. Backups and Key Continuity Backup and snapshot management is one of the most overlooked aspects of TDE. Backups encrypted under TDE rely on the same master key as the live database. If that key is unavailable during a restore, the backup cannot be recovered, making key continuity one of the most common production failure points. CryptoHub manages master key availability, access control, and lifecycle for both production and backup environments from a single platform. Key rotation is designed to preserve backup compatibility, preventing existing backup sets from being silently invalidated. Restore-path key access procedures should be documented during the initial CryptoHub integration, not after the first failed restore test.

How Does CryptoHub Connect to Each Database?

CryptoHub uses the native key management interfaces built into each database platform, no additional agents, no proprietary connectors beyond what each database already supports.

SQL Server

SQL Server

FXCL EKM (Extensible Key Management) provider. FXCL is the Futurex Cryptographic Library. The EKM provider installs as a SQL Server plugin and connects SQL Server's database TDE master key to CryptoHub. No changes to SQL Server configuration beyond the EKM provider installation.

MySQL Enterprise TDE -

MySQL Enterprise TDE

KMIP client via the keyring_okv plugin. MySQL Enterprise's TDE keyring architecture supports KMIP-based external HSM-backed key stores natively. CryptoHub acts as the KMIP server. 

Oracle Database TDE

Oracle Database TDE

PKCS#11 interface. CryptoHub replaces the Oracle software wallet as the master key store through the standard PKCS#11 cryptographic interface. The Oracle DBA manages database operations; the key administrator manages CryptoHub.

MongoDB Encrypted Storage Engine

MongoDB Encrypted Storage Engine

KMIP. MongoDB's encrypted storage engine supports KMIP for master key management. CryptoHub manages MongoDB master keys in the same platform as the rest of the organization's key inventory.

MariaDB and PostgreSQL

MariaDB and PostgreSQL

Transparent Data Protection (TDP) agent or column-level encryption. CryptoHub extends database key management to platforms without native EKM or KMIP support through TDP integration.

Additional database platforms can be supported through integration engineering - contact Futurex to discuss your environment.

CryptoHub Benefits for Multi-Database Key Management

Organizations running mixed database environments face a consistency problem with native database TDE key management: each platform stores database keys differently, rotates on a different schedule, and logs access in a separate location. Unified reporting across SQL Server, Oracle, and MySQL native key stores does not exist.

CryptoHub provides consistent database key governance across all supported databases. Database master keys for SQL Server, MySQL, Oracle, MongoDB, MariaDB, and PostgreSQL are managed under a single key lifecycle policy - consistent access controls, consistent rotation schedules, and a single audit log across all database platforms. The same platform also manages keys for application-layer encryption, tokenization, and file encryption, eliminating per-application key management silos for organizations that need to consolidate key governance broadly.

Deployment models

Database Transparent Data Encryption relies on secure, reliable access to master keys throughout the database lifecycle. CryptoHub provides centralized, HSM-backed database key management across on-premises, virtual, hybrid, and cloud deployments, enabling consistent key separation, lifecycle control, and policy enforcement while preserving native TDE operations.

cryptohub appliance_icon

On-Premises Appliance

Keep database master keys inside your own data center with dedicated HSM-backed protection. CryptoHub stores and manages TDE master keys on Futurex hardware, providing physical key separation, centralized governance, and low-latency access for databases running in regulated or air-gapped environments.

cryptohub virtual appliance_icon

Virtual / Hybrid Appliance

Centralize TDE key management across virtualized and hybrid infrastructure. CryptoHub runs as a virtual appliance while maintaining a consistent interface for databases deployed across VMware, KVM, private cloud, and mixed on-premises environments, allowing master keys to remain centrally governed as workloads move.

cryptohub cloud_icon

CryptoHub Cloud (SaaS)

Move TDE master key management to a Futurex-managed HSM-backed service without changing database encryption workflows. Databases continue using Transparent Data Encryption while CryptoHub Cloud provides centralized key custody, lifecycle management, and hardware-backed protection, eliminating the need to operate on-premises key infrastructure.

Supported Databases and Interfaces 

Database Interface Protocol
SQL Server FXCL EKM Provider Microsoft Extensible Key Management
MySQL Enterprise TDE keyring_okv plugin KMIP
Oracle Database TDE Oracle PKCS#11 interface PKCS#11
MongoDB Encrypted Storage Native KMIP client KMIP
MariaDB TDP agent Transparent Data Protection
PostgreSQL TDP agent or column-level Transparent Data Protection
Additional platforms Integration engineering Contact Futurex →

Key Capabilities

Separation of database administration from key administration

Separation of database administration from key administration - documented, logged, and auditable

Key rotation, versioning, access control, and lifecycle management for database master keys

Key rotation, versioning, access control, and lifecycle management for database master keys

Comprehensive audit logging

Comprehensive audit logging: key access events, rotation events, administrative actions

Backup and snapshot encryption key lifecycle management

Backup and snapshot encryption key lifecycle management - including restore-path procedures

Consistent key governance across multiple database platforms in a single administrative interface

Consistent key governance across multiple database platforms in a single administrative interface

RBAC for key administrator roles with per-key and per-application access policy

RBAC for key administrator roles with per-key and per-application access policy

Use Cases

SQL Server in a PCI DSS cardholder data environment

SQL Server in a PCI DSS cardholder data environment

The FXCL EKM provider connects SQL Server TDE to CryptoHub, moving master key protection to FIPS 140-3 Level 3 hardware and establishing documented DBA/key admin role separation for PCI DSS 4.0 Requirement 3.7 compliance.

Oracle Database migration off local software wallet.

Oracle Database migration off local software wallet

Replace Oracle's software wallet with CryptoHub external HSM-backed key management through PKCS#11. Satisfies audit requirements for key-data separation; retains full Oracle DBA workflow with no application changes. Supports multi-cloud and hybrid environments where local wallet creates key custody complexity.

MySQL Enterprise TDE in a HIPAA-regulated environment.

MySQL Enterprise TDE in a HIPAA-regulated environment

Connect MySQL Enterprise TDE to CryptoHub via KMIP and the keyring_okv plugin, establishing HSM-backed database master key protection and full key access audit logging for ePHI data stores.

MongoDB encrypted storage in multi-cloud or hybrid deployments.

MongoDB encrypted storage in multi-cloud or hybrid deployments

Manage MongoDB database master keys in CryptoHub rather than relying on environment-specific key stores, maintaining consistent key policy and audit continuity across cloud and on-premises MongoDB instances.

Mixed-database environments requiring unified key governance.

Mixed-database environments requiring unified key governance

SQL Server, Oracle, and MySQL running in the same environment? CryptoHub manages database master keys for all three under a single key lifecycle policy, with one audit log, one rotation schedule, and one administrative interface.

Database integrations (EKM, KMIP, PKCS#11) work identically across all deployment models.

Frequently Asked Questions

Does CryptoHub replace the database TDE implementation?

No. CryptoHub provides external key management for the database TDE master key. The database engine continues to handle TDE encryption and decryption. CryptoHub manages the master key that the database uses to protect its data encryption key.

Does external key management add latency to database queries?

No. Database key access requests to CryptoHub occur at database startup and during key rotation - not on individual queries. The database engine caches the key material it needs for normal operation. Query performance is not affected.

Which databases does CryptoHub support for external key management?

SQL Server (FXCL EKM), MySQL Enterprise TDE (KMIP/keyring_okv), Oracle Database TDE (PKCS#11), MongoDB (KMIP), MariaDB, and PostgreSQL (TDP or column-level encryption). Additional database platforms can be supported through integration engineering.

What is the FXCL EKM provider?

FXCL is the Futurex Cryptographic Library. The EKM provider is a SQL Server plugin that connects SQL Server's Extensible Key Management interface to CryptoHub, replacing SQL Server's local database key store with HSM-backed external key management.

How does CryptoHub support key rotation for database TDE?

Key rotation for database master keys is managed in CryptoHub. Rotation procedures are database-specific; Futurex documentation covers the process for each supported platform. All rotation events are logged with a full audit trail.

Can CryptoHub manage backup and snapshot encryption keys?

Yes. Database backups encrypted with TDE use the same database master key as the live database. CryptoHub manages the database master key's lifecycle, including access for backup and restore operations. Backup key management procedures should be documented as part of the initial integration design.

Does CryptoHub work in cloud, on-premises, and hybrid environments?

Yes. CryptoHub is available as an on-premises HSM appliance, as the VirtuCrypt cloud HSM service, or in hybrid configurations. The EKM, KMIP, and PKCS#11 integrations work identically across all deployment models.

Why does key co-location create an audit finding?

Storing the master key in the same system as the encrypted data is a recognized control gap. PCI DSS 4.0 Requirement 3.7.6 requires that key-encrypting keys be stored separately from data-encrypting keys and protected by FIPS 140-3 Level 3 validated hardware where possible. NIST SP 800-57 Part 1 specifies HSM-based protection for key-encrypting keys. HIPAA audit controls require documented access separation and key management auditability for ePHI environments.

The deeper issue is role separation. When a database administrator can access both the encrypted data and the keys that protect it, the encryption provides limited assurance. Auditors in PCI, HIPAA, and SOC 2 engagements treat this as a material finding. CryptoHub establishes a documented boundary: master keys held in FIPS 140-3 Level 3 HSM hardware, database and key administrators operating in separate systems with separate credentials, and every key access event logged with timestamp, requesting system, and administrator identity. The DBA does not have access to the keys, and the access record proves it.

What happens to database backups and snapshots?

Backup and snapshot management is the most commonly underplanned aspect of database TDE. Backups encrypted with TDE use the same master key as the live database - if that key is unavailable at restore time, the backup is unrestorable. This is the most common production failure mode for TDE deployments that lose key continuity.

CryptoHub manages master key availability, access control, and key lifecycle for both live database environments and backup scenarios through the same platform. Key rotation procedures account for backup compatibility; rotating the master key does not silently invalidate existing backup sets. Organizations should document restore-path key access procedures as part of the initial CryptoHub integration design, not after the first failed restore test.

Does external key management add latency?

No. Key access requests to CryptoHub occur at database startup and during key rotation events - not during individual read or write operations. The database engine caches the key material it needs for normal operation after the initial fetch. Per-query latency is not affected. Key rotation procedures vary by database platform; Futurex provides platform-specific rotation guides, and all rotation events are logged in CryptoHub.

 

Featured Resources

“Our electronic invoicing solution allowed us to expand our business and increase our service offerings, while continuing to provide our customers with the highest level of security for their sensitive data.”

 

- Jorge Cordova, IT/ Project Manager 

Mis e-Folios

Move Master Keys Outside the Database

Build Your HSM, Your Way.

If your next audit requires documented database key-data separation, a DBA who cannot access the keys, and HSM-backed database master key protection, CryptoHub is how you get there. It connects to the database platforms you already run, through the interfaces those platforms already support, without changes to the application layer.

 

Talk to a database encryption architect about your environment. We will walk through the integration path for your specific database stack, the compliance controls CryptoHub establishes, and what the deployment looks like for your infrastructure. Start for Free.