Encryption at rest

By default, BigQuery encrypts customer content at rest. BigQuery handles encryption for you without any additional actions on your part. This option is calledGoogle default encryption. Google default encryption uses the same hardened key management systems that we use for our own encrypted data. These systems include strict key access controls and auditing. Each BigQuery object's data and metadata is encrypted using theAdvanced Encryption Standard (AES).

If you want to control your encryption keys, then you can use customer-managed encryption keys (CMEKs) inCloud KMS with CMEK-integrated services including BigQuery. Using Cloud KMS keys gives you control over their protection level, location, rotation schedule, usage and access permissions, and cryptographic boundaries. Using Cloud KMS also letsyoutrack key usage, view audit logs, andcontrol key lifecycles. Instead of Google owning and managing the symmetrickey encryption keys (KEKs) that protect your data, you control and manage these keys in Cloud KMS.

After you set up your resources with CMEKs, the experience of accessing your BigQuery resources is similar to using Google default encryption. For more information about your encryption options, see Customer-managed Cloud KMS keys.

CMEK with Cloud KMS Autokey

You can either create CMEKs manually to protect your BigQuery resources or use Cloud KMS Autokey. With Autokey, key rings and keys are generated on demand as part of resource creation in BigQuery. Service agents that use the keys for encrypt and decrypt operations are created if they don't already exist and are granted the required Identity and Access Management (IAM) roles. For more information, seeAutokey overview.

To learn how to usemanually-created CMEKs to protect your BigQuery resources, seeCustomer-managed Cloud KMS keys.

To learn how to use CMEKs created byCloud KMS Autokey to protect your BigQuery resources,seeUsing Autokey with BigQueryresources.

Encryption of individual values in a table

If you want to encrypt individual values within a BigQuery table,use the Authenticated Encryption with Associated Data (AEAD)encryptionfunctions. If you want to keep data for all of your own customers in acommon table, use AEAD functions to encrypt each customers' data using adifferent key. The AEAD encryption functions are based on AES. For moreinformation, seeAEAD Encryption Concepts in GoogleSQL.

Client-side encryption

Client-side encryption is separate from BigQuery encryption atrest. If you choose to use client-side encryption, you are responsible for theclient-side keys and cryptographic operations. You would encrypt data beforewriting it to BigQuery. In this case, your data is encryptedtwice, first with your keys and then with Google's keys. Similarly, data readfrom BigQuery is decrypted twice, first with Google's keys andthen with your keys.

Important: BigQuery does not know if your data has already beenencrypted client-side, nor does BigQuery have any knowledge ofyour client-side encryption keys. If you use client-side encryption, you mustsecurely manage your encryption keys and all aspects of client-side encryptionand decryption.

Data in transit

To protect your data as it travels over the Internet during read and writeoperations, Google Cloud uses Transport Layer Security (TLS). For moreinformation, seeEncryption in transit in Google Cloud.

Within Google data centers, your data is encrypted when it is transferredbetween machines.

What's next

For more information about encryption at rest for BigQuery andother Google Cloud products, seeEncryption at rest in Google Cloud.

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-19 UTC.