Join our Newsletter — 33% off our NHI Course
Home› FAQ› Governance, Ownership & Risk› Why do managed serverless runtimes create new identity…
Governance, Ownership & Risk

Why do managed serverless runtimes create new identity governance questions?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 12, 2026 Domain: Governance, Ownership & Risk

Because the function still needs credentials, but those credentials now operate inside a managed instance boundary that operators cannot directly inspect. That raises questions about who or what receives the temporary identity, how long it persists, and whether any host-level path could widen privilege beyond the function's intended scope.

What makes managed serverless runtimes an identity-governance problem?

Managed serverless platforms shift execution into an operator-run boundary, so the organisation no longer sees the full host, process, or instance layer where credentials are used. That changes governance from a simple “who has the secret” question into a control question about issuance, scope, lifetime, and separation of duties. The runtime may be managed, but the identity risk is still yours to account for.

In practice, the governance question is not whether the function needs access, it is how that access is represented and constrained. Temporary role assumption, workload identity, and delegated access can all be valid patterns, but each one changes who can act, what can be reached, and how quickly access can be withdrawn. Cloud Workload Identity Guide is useful here because it frames the move away from static keys toward temporary credentials and federated trust.

At scale, managed runtimes also create an ownership gap. The platform operator controls the infrastructure boundary, while application teams control the code, and platform teams often control the identity broker or deployment pipeline. If those responsibilities are not explicit, the organisation can end up with credentials that are technically temporary but still over-scoped, poorly reviewed, or impossible to attribute after the fact. IAM and IGA Basics helps anchor that split between authentication, authorization, provisioning, and governance.

Why temporary credentials still need lifecycle controls

Temporary access reduces one class of exposure, but it does not remove lifecycle risk. A short-lived token can still be issued to the wrong workload, inherit excessive permissions, or remain usable for longer than intended if revocation, rotation, or session expiry is weakly implemented. The core governance question becomes whether the credential is tied to a specific workload, environment, and time window, or whether it can drift into a reusable entitlement.

That is why lifecycle discipline matters even when the runtime abstracts away the host. You still need to know where credentials originate, how they are provisioned, when they are refreshed, and what happens when the function is deleted, redeployed, or repurposed. NHI Lifecycle Management Guide is the most direct operational lens for this, and the lifecycle section of the Ultimate Guide to NHIs reinforces the same provisioning, rotation, and offboarding discipline.

Function identities also need ownership. If no team can prove who approved the access, who can renew it, and who must remove it, managed serverless becomes a convenient place for access to outlive the workload that justified it. That is especially true when deployment pipelines or platform defaults silently recreate permissions during updates.

Where the real governance failures show up

The most common failure is overprivilege hidden behind convenience. Teams often grant broad execution roles so deployments do not break, then leave those permissions in place because the runtime boundary feels “managed.” Another failure is secret sprawl: even if the platform supports temporary credentials, teams may still embed long-lived secrets in environment variables, build artefacts, or configuration stores. Top 10 NHI Issues captures those recurring patterns, especially visibility gaps, unmanaged credentials, and excessive permissions.

There is also an environment-isolation issue. Serverless functions often share a managed substrate, which makes boundary assumptions easy to overstate. If trust is placed only in the platform label and not in the actual permission model, teams may miss cross-environment access, confused-deputy paths, or privilege that expands during orchestration. the key challenges and risks section of the Ultimate Guide to NHIs is relevant because it focuses on overprivilege and visibility gaps, the two failure modes that most often undermine governed runtime access.

For practitioners, the hard part is usually not creation of access, it is proving bounded use. If you cannot show which workload received which credential, for which environment, under which approval, and for how long, then the identity control is weaker than the platform abstraction suggests.

Risk and Threat Considerations

Managed serverless runtimes concentrate trust in a boundary you do not fully inspect, which makes weak credential governance harder to spot and easier to exploit. The security risk is not just secret exposure, but the possibility that a runtime-issued identity can reach more systems than the function was meant to touch, or can persist longer than the business owner expects.

Failure mechanism: Broad execution roles, reusable credentials, weak revocation, or deployment-driven permission inheritance can allow a function to act outside its intended scope. If the organisation cannot observe the host layer, it may also miss how the identity is being used or whether the same privilege has spread across multiple functions.

Impact: The result can be lateral movement, unintended data access, difficult incident scoping, and governance gaps that only become visible after a compromise or an audit. In managed runtimes, the issue is often not a missing control entirely, but a control that exists without enough visibility, ownership, or lifecycle enforcement to be trustworthy.

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 NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-05 — Overprivileged NHIManaged serverless runtimes can silently widen function permissions.
NHI-07 — Long-Lived SecretsServerless governance often fails when static credentials persist inside functions.
Recommendation — Limit each function to the minimum permissions needed for its execution role. Replace embedded secrets with short-lived, rotated credentials.
NIST SP 800-53 Rev 5IA-9 — Identification and Authentication (Service and Organization Users)Function-to-service authentication is central when runtimes issue temporary access.
AC-6 — Least PrivilegeThe question centers on keeping runtime access narrowly bounded.
IA-5 — Authenticator ManagementTemporary credentials still require lifecycle and revocation control.
Recommendation — Use service identity controls to authenticate workloads with scoped credentials. Constrain each function to the minimum set of resources and actions it requires. Track credential issuance, expiry, rotation, and revocation for every function identity.

Practitioner Guidance

What to verify: Confirm that each function identity is unique to a workload, tied to a clear owner, and limited to the exact environment and resource set it needs. If a role can be reused across services or environments, treat that as a governance defect rather than a convenience.

Decision rule: If the function can operate with temporary, scoped credentials, prefer that pattern over any long-lived secret, but only when revocation and reissuance are actually controllable. If you cannot prove offboarding, expiry, or renewal behaviour, the access model is not yet governed enough for production use.

Practitioner takeaway: Managed serverless does not eliminate identity governance, it compresses it into a smaller, less visible boundary, so the control objective is to keep function access attributable, time-bound, and tightly scoped.

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.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org