Enforce separation of duties by making sure no single principal can both use a service account and administer the key management permissions that protect its secrets or encrypted data. Split the roles across different people or groups, review bindings regularly, and use approvals for sensitive changes. Monitor for privilege combinations that let one identity create, decrypt, and impersonate without oversight.
What separation of duties means for Google Cloud service accounts and KMS roles
Separation of duties here means splitting control over the service account from control over the key management permissions that protect its secrets or encrypted data. The practical goal is to prevent one principal from both using the workload identity path and changing the cryptographic controls around it, so a single mistake or compromise cannot silently expand into full access.
That division matters because Google Cloud access often becomes powerful through combinations, not isolated permissions. A user who can impersonate a service account and also administer KMS bindings, key rings, or key access can bypass the normal oversight that would otherwise exist between application operators, security admins, and platform owners.
Use different groups or roles for each function, and make the boundary explicit in policy and review. The service account side should cover the minimum operational access needed by the workload, while the KMS side should be owned by a separate control plane with its own approvals and audit trail.
How to design the boundary so it cannot be crossed casually
The cleanest design is to treat service account use, key administration, and secret exposure as separate authority domains. The team that deploys or runs the workload should not be the same team that can grant itself new impersonation rights, edit KMS IAM bindings, or weaken the protection of the underlying data.
That usually means constraining who can bind roles such as service account user or token creator, who can change KMS policy, and who can approve exceptional access. Keep those permissions in different administrative paths, and avoid shared owner groups that can approve both sides of the same control.
Where possible, prefer narrow predefined or custom roles over broad admin roles, and verify that inherited access does not reintroduce the conflict through folder, project, or organization bindings. A role split only works if the effective permissions are split as well.
For deeper role design and related controls, see Google Cloud IAM and Service Accounts Guide.
For the broader identity control pattern behind this separation, Segregation of Duties (SoD) Guide explains how to define toxic combinations and govern them consistently.
What to review when you are checking for toxic combinations
The main thing to look for is whether any principal can create, use, and reconfigure the same trust chain. That includes service account impersonation, key administration, secret access, and any ability to change who is allowed to decrypt or sign. If one identity can do all of those, the separation is too weak.
Review both direct bindings and indirect paths. A user may not hold KMS admin explicitly, but could still inherit it through a group, custom role, project-level grant, or an automation path that lets them alter policy. The same is true for service account access, where a seemingly harmless role can become dangerous when combined with token creation or workload permissions.
It also helps to review the environment from the key outward, not only from the workload inward. If a person can modify the key policy that protects a service account's secrets or encrypted output, they may be able to undermine the workload without touching the workload itself.
Use the guidance in Cryptographic Key Management Guide to align KMS ownership, access reviews, and rotation discipline with the role split.
Service Account Security Guide is useful when you need to validate whether the service account side is already over-privileged or exposed through weak lifecycle controls.
Risk and Threat Considerations
Separation fails when one privileged principal can chain impersonation with key administration. That creates a single point of abuse for decryption, signing, and access persistence, especially if the same account can also approve its own changes or hide activity inside routine administrative workflows.
Failure mechanism: A user or automation path with both service account use and KMS control can escalate from normal operational access to full data access, policy tampering, or covert credential exposure without needing another person to intervene.
Impact: The result can be unauthorized decryption, unauthorized signing, silent privilege expansion, and a much larger blast radius if the principal is compromised or misused.
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 | AC-6 — Least Privilege | Separates service account use from KMS administration by limiting effective permissions. |
| AC-5 — Separation of Duties | Directly governs the toxic-combination problem between service account and KMS control. | |
| IA-5 — Authenticator Management | KMS and service account protection rely on controlled credential and secret lifecycle management. | |
| Recommendation — Restrict each principal to only the permissions needed for its assigned function. Assign conflicting service account and KMS duties to different roles or groups. Control issuance, rotation, and revocation for credentials tied to service account and KMS access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Requires access restrictions that keep administrative authority over identities and keys separated. |
| A.8.24 — Use of cryptography | Covers governance of cryptographic protection and the permissions around it. | |
| Recommendation — Define and enforce access rules that prevent one principal from holding conflicting privileges. Limit who can administer cryptographic controls and who can use the protected material. | ||
Practitioner Guidance
What to verify: Confirm that no single human, group, or automation path can both impersonate the service account and change the KMS permissions protecting its secrets or data. Test the effective permissions, not just the intended role design.
Escalation / exception: If an operational need requires temporary cross-over access, treat it as an exception with time bounds, approval, and post-change review. Do not leave the exception in place as a standing admin pattern.
Common mistake: Teams often split named roles but forget inherited bindings, delegated group membership, or project-wide grants that recreate the same toxic combination through another route.
Practitioner takeaway: The control objective is not just least privilege, it is preventing any one principal from owning both the execution path and the cryptographic authority behind it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org