What should be used instead of the Google Cloud KMS CryptoKey Encrypter/Decrypter Role for least privilege?

Use separate, narrower permissions for encryption or decryption where the workload only needs one direction, or a custom role if predefined roles are still too broad. The combined encrypter/decrypter role gives more capability than many services require, so audit each principal’s actual operation set and remove unnecessary write or read path access.

When the encrypter/decrypter role is too broad for least privilege

The main issue is not the KMS role name itself, but the direction of access it grants. If a workload only encrypts, only decrypts, or only wraps and unwraps keys in one workflow, giving it a combined permission set widens blast radius. Use the narrowest Google Cloud IAM permission set that still lets the workload complete its specific cryptographic operation.

That means separating read-path capability from write-path capability wherever the application design allows it. For some workloads, a predefined narrower role is enough; for others, a custom role is the better fit because it lets you keep only the exact KMS operations the service actually uses. The same least-privilege logic should be applied to surrounding IAM bindings, not just the KMS grant itself, as NHIMG’s Google Cloud IAM and Service Accounts Guide explains.

In practice, this question usually comes up when teams start from convenience and then discover the application never needed symmetric full-duplex access. That is where a custom role or a narrower predefined role is preferable, because it preserves the service’s cryptographic function without granting unnecessary authority over keys, ciphertext handling, or future workflows that may be added later.

How to choose the narrower permission set

Start by mapping the actual operation set for each principal: encrypt only, decrypt only, both, or key management operations that are separate from data-plane usage. Then verify whether the service can be separated by environment, workload, or function so that one component does not inherit capabilities from another. The relevant control question is whether the principal must ever perform both directions, not whether the role makes that easier.

If the workload needs only one direction, use the smallest predefined permission set that supports that direction. If the predefined options still expose more than the workload needs, create a custom role and keep the permissions narrow enough to avoid accidental reuse in adjacent services. NHIMG’s Cryptographic Key Management Guide is useful here because it frames KMS access as part of a broader key lifecycle, including rotation and post-compromise response.

For Google Cloud specifically, the surrounding IAM design matters as much as the key permission choice. A role that is theoretically least privilege can still be effectively overbroad if it is attached to a reusable service account, inherited too widely, or combined with other permissions that let the principal reach the same keys through another path. NHIMG’s IAM and IGA Basics covers the governance side of that decision, including access review and entitlement hygiene.

What to review before you replace the role

Before changing the binding, confirm that no dependent process is silently relying on the broader role for an adjacent function such as key metadata access, rewrapping, or environment promotion. A narrow role can break hidden coupling, so validate the exact API calls in logs or traces rather than assuming the current grant is intentional. If the team cannot explain why both directions are required, that is a strong sign the broader role should be removed.

Also check whether the workload’s secrets, tokens, or service account credentials are already exposed elsewhere. A key permission change reduces future damage, but it does not undo earlier overexposure if the principal has already been able to reach sensitive material. NHIMG’s Privileged Access Management Guide is relevant when you need to right-size standing access and reduce long-lived privilege around production workloads.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	KMS access depends on managing the credentials that authorize the principal.
	AC-6 — Least Privilege	The question is specifically about reducing excess permissions for a KMS principal.
	IA-9 — Service Identification and Authentication	Workloads and service accounts are the usual principals for KMS access in this scenario.
Recommendation — Limit credential scope and rotate any keys or tokens that grant KMS access. Assign only the KMS permissions required for the workload's actual direction of use. Authenticate the workload with a dedicated service identity instead of broad shared access.
ISO/IEC 27001:2022	A.5.15 — Access control	Least-privilege KMS role choice is an access-control decision.
	A.8.5 — Secure authentication	The role is granted through authenticated principals and their credentials.
Recommendation — Define and enforce narrow access rights for each KMS-bound principal. Use strong authentication for the principal before granting KMS permissions.

Practitioner Guidance

What to prioritise: treat directionality as the deciding factor. If the workload only encrypts or only decrypts, remove the unused half of the capability first, then decide whether a custom role is needed for the remaining operations.

What to verify: verify the real KMS call pattern for each principal, not the intended design on paper. If logs show only one direction in steady state, the combined role is usually unjustified.

Common mistake: teams often keep the combined role because it is easier to standardise. That convenience usually becomes latent privilege, especially when the same service account is reused across environments or services.

Practitioner takeaway: least privilege here means matching the role to the cryptographic direction actually used, then auditing for any wider IAM path that could still grant the same capability indirectly.