# Frequently Asked Questions about Client-Side Field Level Encryption

Learn about client-side field level encryption (CSFLE) with these frequently asked questions.

## What is client-side field level encryption?

Client-side field level encryption (CSFLE) encrypts specific fields in your
data at the producer before sending to Kafka, ensuring sensitive data is
never stored in plaintext. Confluent Cloud administrators cannot access
your encrypted data because you control the encryption keys in your
key management service (KMS).

Key characteristics:

* All sensitive data is encrypted on clients such as Kafka producers and consumers.
* Organizations own and manage the encryption keys in their own KMS.
* Confluent does not have access to the encryption keys or data in plaintext.
* CSFLE is based on existing governance capabilities like Schema Registry and tags.

## Why should I use client-side field level encryption?

Use client-side field level encryption to:

* Prevent Confluent employees, including SRE and Engineering, from accessing sensitive
  data, even when they have access to the Confluent Cloud environment and clusters.
* Prevent sensitive data exposure through third-party tools such as
  Amazon S3, Datadog, Splunk, or other tools that integrate with Confluent Cloud.
* Meet important compliance requirements for data privacy and security.

## Which fields should be encrypted?

* Only encrypt fields that contain sensitive data. For example, encrypt
  fields that contain personally identifiable information (PII) such as
  social security numbers, credit card numbers, or other sensitive data.
* Do not encrypt fields that are used for filtering or sorting. For example,
  fields used for filtering or sorting should not be encrypted because
  encrypted data cannot be filtered or sorted.
* Encryption and decryption processes in field-level encryption execute on your
  clients. Sensitive data is encrypted before it is stored or transmitted, and
  then decrypted when it needs to be accessed by authorized users, producers,
  or consumers.
* You can also use self-managed keys for server-side encryption for your
  Kafka clusters in Confluent Cloud. For more information, see [Using Self-Managed
  Keys for Server-Side Encryption](../byok/overview.md#byok-encrypted-clusters).

## What encryption algorithm is used?

By default, the data encryption key uses the Advanced Encryption Standard (AES) algorithm
in Galois/Counter Mode (GCM) with 256-bit keys, also referred to as AES-256-GCM.

## Is Hashicorp Vault supported?

[Hashicorp Vault Transit Secrets Engine](https://developer.hashicorp.com/vault/docs/secrets/transit)
is supported only when the KEK is **not** shared with Confluent. For more information, see
[Encryption as a Service: Transit Secrets Engine](https://developer.hashicorp.com/vault/tutorials/encryption-as-a-service/eaas-transit).

## Where are keys stored?

When you enable **Share key access with Confluent Cloud**, you can create
an encryption key for AWS, Azure, or Google Cloud key management service.

## Can I use multiple key vaults for high availability?

Yes. CSFLE supports accessing encryption keys from multiple key vault instances for
high availability and disaster recovery. It allows you to:

* Configure redundant key vault access to ensure encryption operations continue if
  one key vault becomes unavailable.
* Store identical copies of encryption keys across multiple regions or cloud providers.
* Implement custom proxy services for advanced key vault management and failover logic.
* Support data classification requirements where different types of data use different
  key vaults.

All key vault instances must contain identical copies of the encryption key material.
CSFLE does not provide automatic failover between key vaults. You must implement retry/fallback
in clients or a custom KMS driver/proxy. For more information, see the use of
`encrypt.alternate.kms.key.ids` under `kmsProps` in
[KEK Parameters](manage-keys.md#kek-parameters-csfle).