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.