Review IAM policy bindings on the relevant secret or project and identify principals granted the Google Cloud Secret Manager Secret Accessor Role. Confirm each identity still needs secret read access, including service accounts used by applications. Check for broad project-level bindings and remove unused access, because this role allows retrieval of secret payloads.
What to look for in Google Cloud IAM when auditing Secret Accessor
The audit starts with the IAM binding itself, not with the secret payload. Secret Accessor is a read path, so the practical question is which principals can reach that path, whether the grant sits at the secret, folder, or project level, and whether the access was given to a human, a service account, or an inherited group membership. Review the binding source and scope before deciding whether the access is intentional.
A useful first pass is to inventory every secret that matters to the application estate and then trace who can read each one. That includes direct bindings on a secret, broader project-level grants that cascade to many secrets, and delegated access through groups or automated identities. Google Cloud IAM and service-account governance are easiest to understand when you treat secret access as part of the wider permission model, not as a one-off exception. Google Cloud IAM and Service Accounts Guide
For access review, the important evidence is not just that a principal can read secrets, but why that principal still needs the capability. Secret access for application service accounts should be tied to a current workload, deployment, or integration owner. If the owner cannot explain the dependency, the access is already suspect and should be treated as stale until proven otherwise.
Why broad Secret Accessor grants become a governance problem
The role is easy to over-assign because it solves immediate operational needs. That makes it a common source of access creep, especially when teams grant it at the project level to avoid maintaining per-secret bindings. The larger the project, the more likely a single role assignment exposes more secret material than the original requester intended. Guide to the Secret Sprawl Challenge
Broad grants also complicate recertification. A principal may still be valid for one application but no longer required for another, yet the project-level binding keeps both alive. That is why auditors should separate “can access” from “should access” and review access against the consuming system, not against the team that originally requested it.
When the binding belongs to a service account, the real control question is whether the account represents a live workload with a bounded purpose. If the service account has become a shared utility identity, or if multiple apps reuse the same account, the audit should flag the entire access path because revocation becomes harder and blast radius increases. Ultimate Guide to NHIs, What are Non-Human Identities
Google Cloud Secret Manager follows the same operational pattern as other secret stores: the risk is not merely exposure of one secret, but the accumulation of unmanaged read access over time. Secrets Management Guide
How to validate, clean up, and monitor the access path
Work from the policy bindings outward. Confirm the member, the role, the scope, and any inherited path that could reintroduce the permission after a cleanup. Then verify whether the principal is a person, a group, or an application identity, because the remediation decision differs: human access should usually be time-bound and reviewed more aggressively, while application access needs ownership, purpose, and rotation discipline around the associated credentials.
If you find an unused grant, remove it rather than waiting for a future incident to prove it unnecessary. If you find a legitimate grant, document the business or runtime reason, the owning team, and the review cadence. For production workloads, pair the audit with a check on whether the consuming service account has broader project access than the secret read it actually needs. Top 10 NHI Issues
Where the secret access is tied to an external integration or a long-lived credential, verify whether a narrower pattern is possible. Short-lived credentials, workload identity, or a more specific IAM design can reduce the need for persistent secret retrieval. That is especially important when the same principal can reach multiple secrets across environments, because read access in one project can become an unexpected pivot point in another.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Secret Accessor review is an account and access review problem. |
| Recommendation — Review and remove unnecessary secret-reading access on a recurring schedule. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Secret Accessor should be limited to only the principals that need secret reads. |
| AU-2 — Audit Events | Auditing secret-reader roles depends on logging who accessed secret resources. | |
| Recommendation — Limit Secret Accessor grants to the minimum set of principals required. Log and review secret access events for anomalous or unexpected reads. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Service accounts often hold Secret Accessor via excessive privilege. |
| NHI-07 — Long-Lived Secrets | Secret access reviews often expose persistent credentials that outlive their need. | |
| Recommendation — Reduce secret-reader permissions on non-human identities to the narrowest needed scope. Replace long-lived secret access paths with shorter-lived credentials where possible. | ||
Practitioner Guidance
What to verify: Check the IAM binding at both the secret and project level, then trace whether the principal is direct, group-based, or inherited through a larger access structure. A clean audit needs the exact source of authorization, not just the effective permission.
Decision rule: If the principal cannot be tied to an actively owned workload or a documented operational need, remove the grant or reduce its scope before accepting the risk as normal. If the principal is a service account, treat that as an application-access decision and validate the workload dependency, not just the account name.
What practitioners underestimate: Project-level convenience grants often survive long after the original deployment need has passed, and they are easy to miss because the access still “works.” That makes periodic recertification and owner attestation essential for secret-reader roles.
Practitioner takeaway: The safest audit outcome is not “someone can still read the secret,” but “every remaining reader is explicitly justified, scoped as narrowly as possible, and owned by a current system or team.”
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