How should security teams handle cloud functions that allow access by all authenticated users?

Why “All Authenticated Users” Is Usually Too Broad for Cloud Functions

A function that is open to every authenticated user is still exposed to a wide population of principals, not just the small set that truly needs the capability. That matters because cloud functions often sit close to data, APIs, and automation paths. If the action is sensitive, the policy should be treated as an access-control decision with real blast-radius consequences, not as a default convenience setting.

In practice, the danger is not only external abuse. Broad authenticated access can create accidental lateral movement between teams, applications, and environments, especially when the same identity provider, group membership, or inherited policy applies across workloads. If the function can modify records, trigger downstream jobs, or reveal secrets, the access boundary should be narrower than “any signed-in user.”

What Security Teams Should Check Before Allowing It

The first question is whether the function is genuinely low risk. If it is read-only, non-sensitive, and designed for broad internal use, wider access may be acceptable with monitoring. If it handles privileged actions, customer data, admin workflows, or automation hooks, the default should be explicit allowlisting of the required roles, groups, or service identities. IAM and IGA Basics is useful here because it frames access as entitlement design, not just authentication.

Teams should also check whether the policy is broader than intended because of inheritance, inherited project settings, wildcard bindings, or shared roles. In cloud environments, “authenticated” can mask a great deal of hidden reach, so the control review should confirm who can invoke the function, from where, and under which conditions. Where the function is part of cloud workload access, Cloud Workload Identity Guide and Cloud PAM and CIEM Guide help separate intended access from effective permissions.

For externally facing or cross-boundary access, security teams should verify that the function is not relying on “authenticated” as a proxy for trust. Stronger patterns use least privilege, clear audience restrictions, and explicit authorization checks at the function or API layer. Where access depends on tokens or delegated access paths, NIST SP 800-63 Digital Identity Guidelines provides a useful baseline for identity assurance and authenticated-session thinking.

How to Reduce Exposure Without Breaking Legitimate Use

Reduce the policy to the smallest set of identities that truly need it, then separate human use from automation use where possible. That usually means assigning specific roles or groups to invoke the function, rather than trusting the entire authenticated population. If the function is used by a workload or integration, a dedicated workload identity is usually safer than reusing broad human access. Cloud Workload Identity Guide is the better pattern for that design.

Security teams should also pair the policy with reviewable controls, such as access logs, usage telemetry, and periodic entitlement review. If the function is meant to stay broadly reachable, then visibility matters even more, because accidental overreach is harder to spot once the feature becomes normal. Access Reviews and Certification Guide is a good fit for the governance side of that problem, while Remote Access Identity Guide reinforces the broader zero-trust principle that access should be explicit at each entry point.

Risk and Threat Considerations

A broad “all authenticated users” rule increases the chance that a compromised account, over-permissioned group, or poorly understood inheritance path can reach the function. That creates a practical attack path for abuse, privilege creep, and unexpected lateral movement, especially when the function can call internal systems or expose sensitive data.

Failure mechanism: The policy expands the reachable principal set beyond business need, so any stolen, reused, or overbroad authenticated session can invoke the function and abuse its capabilities.

Impact: Attackers or insider threats can trigger unintended actions, access protected data, or use the function as a stepping stone into downstream systems and automation chains.

Practitioner Guidance

What to verify: Confirm whether the function is genuinely safe for every authenticated principal, or whether access should be scoped to a smaller role, group, or workload identity. If the answer depends on the data it touches or the action it performs, treat that as a sign the default policy is too broad.

Common mistake: Teams often stop at authentication and forget authorization. “Authenticated” is not the same as “approved for this function,” and that shortcut becomes dangerous when policies are inherited across projects, tenants, or environments.

Practitioner takeaway: The right test is not whether users can sign in, but whether they should be able to invoke that specific function at all. If the function can materially affect data, systems, or privileges, scope access narrowly and make the exception process explicit.

Related resources from NHI Mgmt Group

• How should security teams handle OAuth file-sharing permissions that grant broader cloud access than users expect?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?