The password nobody owns: Taking machines to zero standing privilege (ZSP)
CSO Online ·
Ask your infrastructure lead who owns the service account behind the overnight finance batch and notice how long the answer takes. In many of the environments I’ve reviewed, the engineer who set it up left years ago and the password has been sitting in a vault, or sometimes a plain config file, ever since. It usually still carries permissions sized for a migration that wrapped up before anyone on the current team joined, so people leave it alone rather than risk breaking something nobody fully understands. Multiply that across the landscape, and the numbers get uncomfortable quickly. Palo Alto Networks surveyed more than 2,900 security leaders for its 2026 Identity Security Landscape and found an average of 109 machine identities for every human one. I’d treat any single ratio with some caution, since each vendor counts identities differently. The same report’s finding that 61% of privileged access requests are still met with standing privilege, instead of being granted on demand, is much harder to wave away. Entro Labs looked at the age of these identities too. Close to half were more than a year old, and 7.5% had been around for somewhere between five and ten years. Over the past decade, most security programmes have put real effort into controlling human admins through PAM. Machine accounts tended to get a vault and a rotation schedule, and in most of the programmes I’ve worked on, that’s roughly where the effort on them ended. Why rotation only buys you time Vaulting and rotating a service account password beats leaving it hard-coded in a script, and I wouldn’t advise anyone to pull out a vault that’s working. Rotation changes the secret, though it leaves the access exactly as it was. Between one change and the next, the credential stays valid with every permission intact, readable from wherever the application fetches it. If an attacker copies it a few days into a ninety-day cycle, they’ve got close to three months to use it quietly. OAuth integrations make this worse, because a refresh token can keep renewing itself long after anyone remembers granting it. The Salesloft Drift campaign in August 2025 is the clearest recent example I can point to. Google Threat Intelligence Group reported that the actor it tracks as UNC6395 used stolen OAuth and refresh tokens tied to the Drift integration to pull data out of Salesforce customer instances between 8 and 18 August, and more than 700 organisations were caught up in it. Because the tokens were genuine and no person was signing in, there was no MFA prompt to trip and nothing unusual for the authentication layer to notice. I suspect plenty of the affected customers would have struggled to name who in their own team had approved that integration in the first place. I’d want every CIO to look closely at what the attackers were after. Customers were told to search their Salesforce records for secrets such as AWS keys and Snowflake tokens, since support cases are a common place for staff to paste credentials while troubleshooting. In other words, the stolen standing token was being used to hunt for more standing tokens in other systems. Salesloft later linked the initial access to a compromise of its GitHub account back in March, months before the theft began. width="1024" height="469" sizes="auto, (max-width: 1024px) 100vw, 1024px"> Figure 1: Standing credential vs zero standing privilege . Ashish Mishra What zero standing privilege looks like for a machine With zero standing privilege, a machine identity holds no usable access while it sits idle. When it has work to do, it proves who it is to a policy engine and gets back a short-lived credential scoped to that job, which expires on its own once the job finishes. Most of you will already have something like this for people, usually as just-in-time elevation through a PAM platform. Workloads tend to get there through workload identity federation instead. The workload presents a signed token from a platform the target already trusts, such as a Kubernetes cluster or a CI pipeline, and swaps it for temporary access. GitHub Actions deploying into AWS is the easiest case to picture. The pipeline requests an OIDC token from GitHub, AWS checks it against a trust policy tied to that repository, and the job runs under a role whose credentials last around an hour by default. No access key gets stored in the repo at any point. Google’s own authentication action for GitHub recommends federation over exported service account keys on the same grounds, warning that those keys are long-lived and need the same care as a password. Getting there without breaking production Full zero standing privilege across every machine identity isn’t achievable in most enterprises right now, and it’s worth saying so plainly to your board. Older applications that log in to a database with a username and password won’t federate, and plenty of vendor appliances only accept a static API key. Practitioners increasingly describe near-zero standing privilege as the realistic target for machines, which is how I’d frame it too. Everything starts with an inventory. You need every machine credential in one place, including the OAuth grants your SaaS integrations hold, with a named human owner recorded against each. The owner field can look like admin overhead, but an account with no owner tends to survive every clean-up exercise, because nobody has the authority to approve switching it off. Once the list exists, sort it by what an attacker could reach with each credential. CI/CD pipelines and cloud admin roles usually end up near the top, and they also happen to be where federation is most mature, so moving pipelines to OIDC tends to be one of the earliest wins. Connected SaaS apps deserve a separate look. A lot of them were approved years ago with broad scopes, often by a business team rather than security, and nobody has revisited them since. Cut the scopes down to what each integration actually uses. It’s also fair to ask suppliers how they store the refresh tokens they hold on your behalf, and after Drift, a vendor with access to your CRM should have a ready answer. Some systems won’t federate for years. In those cases, you can still shorten how long a credential lives, even if you can’t change what it’s allowed to do. Vault-issued dynamic secrets work well here, with the database account created when the session starts and dropped when it closes, and the application usually needs little or no rewriting. For board reporting, the number I’d track is the share of machine access granted on demand compared with the share held permanently. Expect the first reading to look poor. It’s still worth putting in front of the board early, since the change from one quarter to the next tells them far more about progress than any single snapshot.