Google Cloud encryption discussions often mix together three terms that describe different layers of the design. Customer-managed encryption keys, or CMEK, describe an integration in which a supported Google Cloud service uses a key that the customer controls in Cloud KMS. Cloud HSM describes a hardware protection level for key material managed through Cloud KMS. Cloud External Key Manager, or Cloud EKM, lets supported Google Cloud services use keys whose key material remains in an external key-management system.<\/p>\n
For the Professional Cloud Security Engineer<\/a>, the decision is not \u201cwhich encryption product is strongest?\u201d It is which custody, compliance, availability, latency, operational, and separation-of-duties requirements the workload actually has.<\/p>\n Google Cloud services already encrypt data at rest. With CMEK, the customer chooses and manages the key-encryption key that a supported service uses to protect its data-encryption keys. That key can be a software-protected Cloud KMS key, an HSM-protected key, or in some integrations an external key reached through Cloud EKM.<\/p>\n This means CMEK and Cloud HSM are not competing categories. A storage or database service can use an HSM-backed Cloud KMS key as its CMEK if that integration and location combination are supported. Likewise, Cloud EKM can participate in supported CMEK integrations while the key material remains outside Google Cloud.<\/p>\n Start the architecture by asking whether the service needs customer control over key lifecycle and authorization. Only after that should you decide where the key material must live and what assurance boundary is required.<\/p>\n Cloud KMS provides centralized key creation, import, IAM control, rotation, version management, audit logging, and cryptographic operations. Software protection is usually the simplest customer-managed option because Google Cloud operates the underlying key service and the application does not need to manage HSM capacity or an external key-manager dependency.<\/p>\n For many organizations, the most valuable part of CMEK is administrative control rather than hardware residency. A dedicated security project can own the key, application projects can receive only the permissions needed to use it, and key administrators can be separated from resource administrators. Disabling or destroying the key can then become an independent control over access to encrypted data.<\/p>\n That separation still requires care. Granting broad Cloud KMS roles to the same people who administer the protected service can collapse the intended control. Key projects, IAM groups, audit sinks, and break-glass procedures should be designed as part of the application security model.<\/p>\n Cloud HSM uses Cloud KMS as its management interface while cryptographic key material and operations are protected by Google-managed Hardware Security Modules. Google documents multi-tenant Cloud HSM as using FIPS 140-2 Level 3 certified HSMs, and also offers single-tenant HSM options for requirements that need stronger tenancy separation.<\/p>\n HSM protection is appropriate when a policy, regulator, customer contract, or risk assessment requires hardware-backed keys or specific cryptographic assurance. It should not be selected merely because \u201chardware sounds safer.\u201d HSM keys can have location constraints, higher operation cost, and higher latency for some asymmetric operations than software keys.<\/p>\n For CMEK integrations, the protected service location and the HSM key location must match as required by the service. Architecture therefore needs to choose regions and key locations together instead of treating the key as an afterthought.<\/p>\n Cloud EKM is for organizations that need key material to remain in a supported external key-management system. Google Cloud calls the external system during cryptographic operations required by the integration. The customer therefore controls not only key lifecycle but also an off-cloud dependency that can approve or deny access through the availability of the external key.<\/p>\n This can address strict key-custody or sovereignty requirements, but it creates a deliberate reliability tradeoff. If the external key manager, network path, authentication relationship, or external key is unavailable, Google Cloud services that depend on that key can become unable to read or write protected data.<\/p>\n That failure mode must be accepted explicitly. Highly available external key infrastructure, tested failover, monitoring, and operational ownership are part of the data-platform architecture, not just the security architecture.<\/p>\n Some organizations already have key material that must be generated outside Google Cloud but do not require every cryptographic operation to depend on an external key manager. Cloud KMS supports key import, which lets customer-generated key material be imported into a Cloud KMS software or HSM protection level, subject to supported key types and workflows.<\/p>\n After import, the key material is managed by the selected Cloud KMS protection level. That is fundamentally different from Cloud EKM, where the external key material remains outside Google Cloud and the external system stays in the request path for supported operations.<\/p>\n The distinction is useful in compliance reviews. \u201cCustomer generated,\u201d \u201chardware protected,\u201d and \u201cexternally held\u201d are separate requirements. A design should name which one is required rather than using the vague statement that the organization needs to \u201cown the keys.\u201d<\/p>\nCMEK is an integration model, not a hardware tier<\/h2>\n
Software-protected Cloud KMS keys fit many regulated workloads<\/h2>\n
Cloud HSM changes where cryptographic key material is protected<\/h2>\n
Cloud EKM keeps key material outside Google Cloud<\/h2>\n
Imported keys are different from external keys<\/h2>\n
Key algorithms and protection levels solve different problems<\/h2>\n