Zero Standing Privileges for Service Accounts in Cloud Workloads

An employee resigns on a Friday. By Monday morning, IT has turned off the account, pulled the badge access, and killed the VPN session. This is routine, almost boring in its reliability. Now ask what happens to the service account that employee spun up eighteen months ago to automate a data migration, or the API key sitting in a CI/CD pipeline that they generated and forgot about. In most environments, nothing happens to it. It keeps working, indefinitely, because nobody built a process to notice it exists.

That asymmetry is the subject of this piece: service account credentials in cloud workloads, which carry a structural design flaw that has nothing to do with sloppy administration and everything to do with how cloud identity systems were built. A service account is provisioned to do a task, but the API key, token, or IAM role binding behind it carries no expiration tied to that task's completion. The access outlives the job it was created for, by months or years, and nobody is checking.

Cloud IAM systems bind permissions to an identity, not to an intent or a time window. That's the whole mechanism. It means accumulation isn't a bug introduced by careless engineers, but the default behavior of the system doing what it was built to do. A break-glass role gets provisioned during an incident and never gets torn down once the fire is out. A CI/CD service account gets broad permissions for a one-time migration, and it keeps those permissions for the next three years. Pipeline credentials get baked into image layers, so they ride along with every container built from that image, forever, or until someone finally notices and feels slightly embarrassed.

The scale of this problem is larger than most security teams account for. Non-human identities already outnumber human users in most enterprise environments, yet most privileged access management tools were built to solve a human-admin problem: approve the request, log the session, rotate the password. Machine accounts don't fit that model, so they sit outside it, under-governed because the tooling was never built with them in mind.

AI agents are about to make this worse because they inherit the old risk and run it at a different speed. 1Password surveyed developers and found that most of them give their agents standing access to systems and credentials. Agentic workloads pick up that same always-on access pattern, but an agent can act on standing credentials far faster than a human operator can, and it won't pause to second-guess itself first.

Standing Service Account Credentials as the Attacker's Preferred Path

Privilege escalation is a lot of work. Attackers would rather skip it. When a service account already carries standing, always-on permissions, there's nothing left to escalate, there's just a credential sitting there waiting to be taken, and the moment someone takes it, the access is already live.

Wiz's Cloud Threat Highlights report for the first half of 2026 tracks a group called JINX-0163, and it got in through a single GCP service account. From that one foothold, the group moved laterally, and it pulled thousands of secrets out of multiple GCP projects, including customer credentials. None of that would have been possible without one condition: that single service account had standing access reaching across projects it had no ongoing reason to touch. The account wasn't the vulnerability. The permissions it was allowed to keep were.

A separate case shows you the same structural flaw, but from a supply chain angle instead of a direct breach. In March 2026, a threat actor group known as TeamPCP published malicious versions of the LiteLLM package, numbered 1.82.7 and 1.82.8, to PyPI. If you installed those versions during their short window of availability, you had your cloud keys, SSH keys, and Kubernetes secrets harvested straight out of your environment. The attackers never touched the target systems directly. They didn't need to. The credentials were sitting in pipelines and container environments, persistent and portable, and installing a poisoned package was enough to hand them over.

Put these two cases side by side: a compromised identity doesn't look like an intrusion, it looks like a workload doing its job. Traffic from a stolen service account matches what the account generates normally, because it's using the same permissions it always had, calling the same APIs it always calls. Detection tools built to flag anomalies have nothing to flag. The credential is behaving exactly as designed, which is the whole problem.

What zero standing privileges means for service accounts

Zero standing privileges, ZSP, is a different architecture built on a simple separation: eligibility for access and active possession of access are two different states, and a credential should only occupy the second state for as long as a task is actually running.

CrowdStrike's definition of ZSP captures this cleanly. An identity can be eligible for elevated access without that access being live. The access becomes active only when requested, gets evaluated against policy, is granted for the exact duration of the task, and is automatically revoked the moment the task ends. The credential exists for the length of the job and not one second longer.

The distinction that matters most here is about what happens after approval, not before it. An approval workflow that grants access and lets it sit there indefinitely has not stopped standing privilege, it has just added a checkpoint in front of it. The privilege still has to expire on its own, automatically, without a human remembering to revoke it, because humans forget and systems don't.

Password rotation looks like a security control, but it leaves the actual vulnerability untouched. Vault-centric tools rotate credentials on a schedule, which sounds responsible, but between rotations the standing account is still sitting there, fully valid, a stationary target. A stolen credential stays usable until the next scheduled rotation, and if that rotation cycle runs on a 30-day clock, an attacker has a 30-day runway. Netwrix's definition of ZSP draws the same line CrowdStrike does: the shift that matters is eliminating standing accounts entirely, not rotating them more often, and replacing them with temporary credentials scoped to one task at a time.

The data on where most organizations actually stand is not encouraging. The Netwrix 2026 Data and Identity Security Report found that 76% of organizations cannot immediately revoke standing access when it's no longer needed. So before you can even get to building ephemeral credentials or scoped task-based access, three out of four organizations are stuck on a simpler step: turning an old permission off on demand.

Just-in-time access and zero standing privileges get used interchangeably, and that's a mistake. JIT is a mechanism: it evaluates a workload's rights at the moment it tries to touch a resource, replacing a stored key with a per-request decision. ZSP is the outcome that mechanism is supposed to produce. JIT only gets there if the access it grants also expires automatically and is scoped down to the minimum the task actually requires. If it doesn't meet both conditions, JIT is just a fancier approval gate in front of the same old standing-privilege problem.

The clearest way to hold this model in mind: standing privilege is the credential that still exists in the gap between one task and the next. Zero standing privilege closes that gap completely, so nothing sits idle for an attacker to find.

The three mechanisms that make ZSP work for automated workloads

You can't get to zero standing privilege for service accounts by flipping a single switch. Three mechanisms have to work together, and each one solves a different way standing credentials fail.

The first is dynamic credentialing, which replaces stored secrets with tokens that expire the moment the job is done. When a CI/CD job needs to connect to a database, it proves who it is through cryptographic attestation, using something like a cloud-signed token or a container service account token, and a credential provider issues a token in response that expires automatically when the task finishes. No secret ever lives in the pipeline, the image layer, or an environment variable waiting to be scraped. It exists only in the window between issuance and completion, and then it's gone. Netwrix Privilege Secure builds this through what it calls Activity Token login accounts: credentials generated on demand, scoped to one specific task, with the rights automatically revoked once the session ends.

The second is conditional access evaluation, and it checks more than identity before it grants access. A traditional credential gets validated once, at issuance, and then trusted for however long it remains valid. Conditional access instead evaluates real-time signals, security posture, environment compliance, even time of day, every time access is requested. A credential that was fine yesterday isn't automatically fine today if the posture of the workload requesting it has changed in the meantime. This closes a specific gap: static credentials get checked once and trusted indefinitely, while conditional evaluation turns every single access request into its own fresh decision. For machine workloads that can't complete an MFA prompt the way a human can, cryptographic proof of environment identity stands in for multi-factor authentication. That's not a workaround bolted on to cover a gap. Machines can't answer a push notification, so this is a deliberate design choice, not a workaround.

The third mechanism is workload identity attestation, most commonly implemented through SPIFFE and SPIRE. This issues cryptographically verifiable identities, called SVIDs, directly to workloads that spin up and disappear constantly, containers scheduled and rescheduled by the hour. A workload authenticates using its SVID instead of a long-lived secret sitting in a config file somewhere. Production deployments at Uber, Square, and GitHub show this approach holding up at real scale, inside genuinely complicated cloud environments.

One honest caveat belongs here. The SPIRE server that issues these identities becomes a target worth treating like a crown jewel in its own right. A compromised SPIRE node can mint SVIDs for every workload registration entry mapped to it. The thing built to eliminate standing credential risk introduces a new concentration of risk if it isn't protected as carefully as the credentials it replaces.

A fourth piece ties the technical mechanisms to human operators. Engineers request access through an integrated workflow, often a Slack bot tied into a PAM system, where low-risk operations get auto-approved and sensitive actions like IAM policy changes or encryption key management get routed to a human reviewer. Standing privileged access stays at zero the entire time, because the human reviews it before access gets granted, not after it's already live.

Vendors are starting to build toward this model directly. 1Password launched Privileged Access on July 28, 2026, provisioning access at the moment it's requested, scoping it to what the work actually requires, and removing it when the work is finished, covering both human and AI identities under one Unified Access platform. Alongside it, 1Password Credential Broker for GitHub Actions entered public preview the same day, and it delivers credentials to CI/CD pipelines at runtime instead of storing them there permanently. Netwrix Privilege Secure integrates natively with a directory service, an identity provider, privileged access management, local admin password management, and device management through agentless discovery, and supports bring-your-own-vault setups, though its connector depth is strongest in environments centered on one major platform vendor, so teams running stacks centered on other cloud providers should check that coverage carefully before committing. CyberArk, BeyondTrust, and Delinea show up regularly in enterprise evaluations too, each arriving from a different starting point, vault-centric, converged remote access, usability-first, with uneven depth on non-human identity coverage. The evaluation question that actually matters is how deep the JIT capability goes and how well it covers non-human identities.

Where ZSP implementations break down

The strongest objection to zero standing privilege is that it's not fully achievable for machine identities. That objection has some truth in it. Near-zero standing privilege is achievable and is a substantial improvement over the status quo, and the objection gets used far more often to justify doing nothing than to describe a genuine technical limit.

Legacy automation is the first place this breaks down. Plenty of automated workflows were built around an always-on service account, with no clean point in the process where a just-in-time approval step could be inserted without breaking the pipeline. For machine-to-machine integrations that can't tolerate an interactive approval step, the better pattern is ephemeral credential exchange between trusted workloads, scoped narrowly and issued with short time-to-live windows. The ephemeral credential exchange is a middle path, short of a permanent secret sitting in a runner and short of interactive JIT, that cuts the exposure window dramatically without requiring a human in the loop. If you can't eliminate some standing accounts, short-lived credentials with automated rotation and tight scope can still shrink the blast radius, even without reaching zero standing privilege in the strict sense.

Coverage gaps are the second failure mode, and they're common. An organization rolls out JIT access across cloud infrastructure and the SaaS tools connected through a standard provisioning protocol, and declares victory, while project management tools, collaboration platforms, design software, and code review tools stay on standing access because the identity governance platform can't reach them. The fix isn't to wait for full coverage before starting. Start with the identities that carry the most risk, CI/CD service accounts with production access, database connectors, cross-account admin roles, and extend coverage from there. A related trap sits inside vendor claims: plenty of tools say they offer JIT access while long-lived service accounts keep running in the background the entire time. In any evaluation, what matters is whether the tool actually removes persistent access or just rotates it and logs the rotation.

Operational brittleness is the third failure mode, occurring when approval workflows add friction to processes that used to run without any human involvement. A pipeline that ran unattended for three years suddenly has a dependency on an approval step, and if that step fails or the approver is on vacation, the pipeline stalls. When this happens, the fix is to route low-risk, repetitive operations through automated approval logic and reserve human review for the genuinely sensitive actions, so the friction lands only where it should.

None of this adds up to a claim that zero standing privilege is simple to roll out across a real enterprise, with its decade of legacy pipelines and half-documented service accounts. It adds up to a much narrower, firmer claim: the credential that sits idle between tasks is the thing attackers are actually after, and every mechanism described here, dynamic credentialing, conditional access, workload attestation, scoped workflow automation, exists to make sure that idle credential stops existing.