Who Holds the Key in Customer Controlled Encryption

Most cloud services encrypt customer data. The more useful question is who controls the key path and under which conditions information can be decrypted. For regulated records, legal material, financial information, or intellectual property, this separation of authority can matter as much as the algorithm.

Customer-controlled encryption changes that boundary by placing a higher-level key and its access policy under infrastructure selected by the organization. It can reduce dependence on a collaboration provider, but it also makes identity, key availability, and recovery part of the customer's operating responsibility.

The collaboration provider stores protected content while the external service controls key release.

Envelope Encryption Separates Data Keys from Control Keys

At scale, systems commonly encrypt each object or limited group of objects with a data encryption key. That data key is then wrapped by a separate key encryption key. The encrypted object and wrapped data key can be stored together without placing the higher-level key in the same location.

This separation makes key management more practical. Higher-level keys can be versioned or rotated, policy can be applied to wrap and unwrap operations, and exposure can be contained more clearly than with one key for a large data set.

Envelope encryption is not automatically customer controlled. Control depends on who operates the key service, who can authorize an unwrap request, how identity and context are validated, and whether the storage provider can obtain a usable key without the customer's approval.

Google Workspace CSE Uses an External Key Service

Google Workspace Client-side encryption connects supported Workspace services to an external encryption key service, also called a Key Access Control List Service or KACLS. In the documented flow, a data encryption key protects the content and the external service wraps or unwraps that key according to identity and policy.

The collaboration platform continues to provide document, email, calendar, and meeting functions for supported content. The organization controls the external key path. This can create a clearer separation of authority for data sovereignty, contractual obligations, and regulated workflows.

The boundary is specific rather than absolute. Google documents which editions, applications, data types, clients, and sharing scenarios support CSE. File titles and some metadata may remain outside the encrypted content boundary. Mobile behavior and supported formats can also differ from the browser experience. A deployment decision should use the current support matrix rather than a general statement about Workspace as a whole.

Control Creates Operational Responsibility

An external key service becomes critical infrastructure. If identity verification, authorization policy, routing, or key availability fails, authorized users may be unable to reach protected content. The design needs the same operational discipline as any other service on the access path.

• Availability Define redundancy, capacity, monitoring, recovery objectives, and behavior during a regional or provider outage.
• Authorization Document who can change key policy, approve access, rotate keys, disable a version, or modify Workspace routing.
• Recovery Test restoration after configuration error, credential loss, service failure, and accidental key disablement without adding an uncontrolled bypass.
• Auditability Retain enough evidence to reconstruct key operations, policy decisions, administrative changes, and failed requests.
• Lifecycle Align key creation, rotation, retention, disablement, backup, and destruction with legal and business requirements.

Where OXU KMS Fits

OXU KMS is designed to provide the external key layer for Google Workspace CSE. Oten's product documentation describes Google Drive flows in which OXU KMS wraps a document data key with a customer-managed key, verifies identity and authorization for unwrap requests, and records the key relationship used for protected files.

The same documentation covers key versions and rotation, lifecycle policies, usage history, audit logs, routing rules, and CSE key selection. These controls give an organization practical places to express and review the key boundary.

A production assessment should still confirm the Workspace services in scope, identity-provider dependencies, the exact administrative roles available to Oten and the customer, high-availability design, backup and re-wrap procedures, propagation time, and the content or metadata that remains outside CSE.

Ask Which Parties Can Authorize Decryption

For each sensitive workload, ask which parties can technically authorize decryption without the organization's approval. The answer may be acceptable. If it is not, customer-controlled encryption can provide a clearer separation of authority when the organization is prepared to operate the key boundary responsibly.

The strongest decision includes both sides of that sentence: the provider cannot unilaterally release usable keys for protected content, and the customer has tested the identity, availability, audit, and recovery processes that keep legitimate access dependable.

Discuss Your Security Priorities

If your team is reviewing Google Workspace CSE or customer-controlled key management, Oten can help you map the control boundary, identify the dependencies that need testing, and define a practical evaluation path. Book a consultation to discuss your systems and assurance requirements.

Further Reading

1. Google Workspace About Client Side Encryption
2. Oten KMS Google Drive Encryption and Decryption Flow
3. Oten KMS View Google CSE Files Wrapped by Workspace Key

About Oten

Oten Switzerland GmbH develops OXU, a connected security ecosystem for organizations that value clarity, privacy, and control. OXU brings identity, encrypted storage, and key management into a foundation designed for everyday work.