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

Transparent Data Protection

File Encryption with No Persistent Keys on the Endpoint

CryptoHub Transparent Data Protection provides transparent file encryption for files and directories at the OS file system layer on Windows and Linux, derives file-specific encryption keys in volatile memory only, and enforces access policy through centralized CryptoHub management, without changing how applications read and write files.

Transparent Data Hero Image
AES-256-CBC with ESSIV -

AES-256-CBC with ESSIV: file content encryption with per-file IV derivation 

NIST SP 800-108 KDF (Counter Mode) -

NIST SP 800-108 KDF (Counter Mode): each file gets a distinct derived encryption key, never a shared key

Kerberos and Active Directory integration

Kerberos and Active Directory integration: access policy tied to your existing identity infrastructure

No universal emergency decryption key

No universal emergency decryption key: deliberate design that eliminates single-credential compromise risk

Windows and Linux

Windows and Linux: signed driver with Microsoft CNG on Windows; agent-based on Linux

How Transparent File Encryption Works

Transparent Data Protection operates at the OS file system layer through a signed driver on Windows and an agent on Linux. When a user or application opens a file in a protected directory, the TDP component intercepts the file system request and validates the user's identity against policy stored in CryptoHub. If access is permitted, a file-specific encryption key is derived in volatile memory using NIST SP 800-108 KDF in Counter Mode and the file is decrypted for that access event. When the user writes to a protected directory, the component encrypts the file before it reaches disk.

The file on disk is always encrypted. The key used to decrypt it never persists on the endpoint. Root key material is generated and held in FIPS 140-3 Level 3 validated HSMs within CryptoHub. The endpoint derives session encryption keys from that root material at access time and stores nothing locally between events.

Transparent Data Protection Architecture

The Architecture Is the Differentiator

Most transparent file encryption implementations maintain a local encryption key agent that caches key material on the endpoint or in a local store. That cached material is a target. If the endpoint is compromised, the key material can be extracted and used to decrypt protected files offline.

CryptoHub TDP is designed so that the endpoint never holds key material between access events. File-specific encryption keys are derived in volatile memory at the moment of access and discarded when the session ends. There is no local key store to extract.

This architecture also means there is no universal emergency decryption key, a deliberate security decision. A single compromised administrator credential cannot decrypt all protected files. Access is controlled by identity-based access policy - Kerberos and Active Directory - and policy managed in CryptoHub. For organizations with strong identity governance, this is a feature. For organizations that rely on break-glass recovery paths, it's an architecture conversation to have before deployment.

One Platform, One Audit Log, One Policy Interface

Policy for Transparent Data Protection is managed in CryptoHub, the same platform used for database TDE key management, application encryption via PKCS#11 and KMIP, and enterprise key lifecycle management. TDP doesn't add a new management plane; it extends the one you already have.

One centralized cryptographic audit log across TDP file access events, database TDE operations, and application encryption activity. One interface for policy changes. One key lifecycle workflow covering rotation, expiration, and access revocation across all workloads. When a compliance audit asks for evidence of key management controls, you pull from one system.

Policy updates take effect without redeploying the TDP agent. Cryptographic algorithm changes and key rotation happen at the CryptoHub level. Endpoint management tooling can be integrated for agent deployment and lifecycle operations; supported platforms include enterprise endpoint management systems and additional tools supported through integration engineering.

Deployment Models

TDP supports three primary deployment patterns:

File server deployment

Install the TDP agent on Windows or Linux file servers. Protect specific file system directories containing regulated data. Access policy is enforced at the server for all users and applications accessing those directories over the network or locally.

Endpoint deployment

Protect sensitive file system directories on Windows and Linux workstations and laptops. Suitable for PCI DSS, HIPAA, or CMMC compliance requirements that include endpoint data-at-rest protection. Policy is centrally managed in CryptoHub regardless of the number of endpoints deployed.

Application data directory

Protect directories used by applications to store sensitive output, logs, or transaction data. The application reads and writes files normally; TDP handles encryption at the file system layer without requiring application changes.

Architecture Decisions

Windows and Linux endpoints and file servers.

TDP operates as a transparent file system layer component on Windows and Linux. It is not designed for containerized workloads, cloud object storage, or environments where the file system abstraction doesn't apply. For those workloads, CryptoHub provides application-layer encryption via PKCS#11 and KMIP.

No universal emergency decryption key - by design.

There is no single credential that decrypts all TDP-protected files. This eliminates a class of credential-compromise attacks. Recovery for deprovisioned users is handled through CryptoHub access management. Organizations should assess whether this aligns with their incident response and recovery procedures before deployment.

Identity-bound access - Kerberos and Active Directory.

Access policy is built on Kerberos and Active Directory identity. Organizations without AD infrastructure or with federated identity configurations should validate compatibility with their identity architecture before deployment.

Transparent to applications - with a caveat

Applications that access files through normal OS file system interfaces work without modification. Applications that access storage at the block level or bypass the OS file system layer may not benefit from TDP protection.

Compliance Coverage

CryptoHub TDP supports data-at-rest encryption requirements across major compliance frameworks:

  • PCI DSS - Requirement 3.5.1 (encryption of stored account data); AES-256 algorithm and FIPS 140-3 Level 3 key management satisfy algorithm and key protection controls
  • HIPAA - 164.312(a)(2)(iv) (encryption and decryption); addressable specification for encryption of data at rest under 164.312(e)(2)(ii) context
  • NIST SP 800-171 - Control 3.13.16 (protect the confidentiality of CUI at rest)
  • CMMC Level 2 - SC.3.177 (employ FIPS-validated cryptography to protect the confidentiality of CUI)

Centralized cryptographic audit logging in CryptoHub records file access events, including user identity, timestamp, and access outcome. Logs are available for compliance review and forensic investigation across both Windows and Linux deployments.

Use Cases

Windows and Linux file server protection

Windows and Linux file server protection

Encrypt sensitive directories on Windows or Linux file servers so that data at rest is protected if storage media is removed, the server is accessed outside normal authentication paths, or an insider accesses files outside their normal workflow.

Regulated endpoint file protection

Regulated endpoint file protection

Encrypt sensitive files and directories on Windows and Linux workstations and laptops for PCI DSS, HIPAA, or CMMC compliance. Policy is centrally managed in CryptoHub regardless of the number of endpoints deployed.

Application data directory encryption

Application data directory encryption

Encrypt directories used by applications to store sensitive output, logs, or transaction data without requiring application modifications. The application reads and writes files normally; TDP handles transparent file encryption at the file system layer.

Shared storage access control

Shared storage access control                                     

Protect shared directories on Windows or Linux-based storage systems with identity-based per-user and per-group access policies managed in CryptoHub.

Multi-framework compliance for file-based data stores

Multi-framework compliance for file-based data stores

Address data-at-rest encryption requirements across PCI DSS, HIPAA, and NIST SP 800-171 for Windows and Linux file-based workloads through a single deployment with centralized audit logging.

Frequently Asked Questions

Does Transparent Data Protection require application changes?

No. TDP operates at the file system layer. Applications read and write files normally. The driver or agent handles transparent file encryption and decryption transparently, with no changes required to the application code or configuration.

Does TDP support Linux?

Yes. TDP supports both Windows (signed driver with CNG integration) and Linux (agent-based). Transparent file encryption policy for both platforms is managed centrally in CryptoHub.

What happens if a user's account is deprovisioned?

Access is controlled by CryptoHub policy. Removing a user from the policy prevents them from accessing protected files going forward. There is no universal emergency decryption key, this is a deliberate security architecture decision. Recovery for deprovisioned users is handled through access management procedures in CryptoHub.

How does key derivation work?

Root key material is held in FIPS 140-3 Level 3 validated HSMs in CryptoHub. When a file access event occurs, the TDP component derives a file-specific encryption key using NIST SP 800-108 KDF in Counter Mode from that root material. The derived encryption key exists in volatile memory only for the duration of the access event and is discarded when the event ends. The endpoint holds no persistent key material.

Can Policies Target Specific Directories?

Yes. Transparent file encryption policy is configured at the directory level. Administrators define which directories are protected and which users or groups have access through centralized management in CryptoHub.

Does TDP Work with Active Directory?

Yes. TDP uses Kerberos and Active Directory for identity-based access control. Network-based and time-based access controls are available for additional policy granularity. No changes to existing AD configuration are required.

Featured Resources

"Futurex allows us to securely and cost effectively offer the most rigorous protection of our customers’ information.”

 

- John Stevenson, Vice President of Information Security and Compliance

First American Payment Systems

Scope File Encryption for Regulated Workloads

CryptoHub Transparent Data Protection provides transparent file encryption for Windows and Linux files and directories at the file system layer with file-specific key derivation, FIPS 140-3 Level 3 HSM-backed root key management, and centralized access policy, without requiring application changes or leaving key material on endpoints. If you're evaluating transparent file encryption for regulated file stores or working toward PCI DSS, HIPAA, or CMMC compliance, a CryptoHub architect can scope a deployment for your environment.

Deploy Where You Need It

CryptoHub runs where your data lives. Choose the deployment model that fits your environment:

  • On-premises hardware appliance -- dedicated Futurex HSM hardware in your data center, air-gapped or network-connected as your policy requires
  • Virtual appliance -- CryptoHub deployed as a VM in private cloud, VMware, Hyper-V, or other virtualized infrastructure
  • CryptoHub Cloud (SaaS) -- HSM-backed cryptographic services delivered as a managed cloud service, with no hardware to provision or maintain

All three models share the same management interface, integration layer, and compliance posture. Organizations running hybrid environments can span deployment models from a single CryptoHub instance.