Ask a fintech engineering team how many employees have access to production, and they'll answer in seconds. Ask how many non-human identities have access, and you'll usually get a long pause.
At Arclogiq, we've seen that pause many times, usually in the middle of a PCI DSS audit prep, when someone realizes the spreadsheet of service accounts is a year old and nobody trusts it.
This post is about that pause: why it happens, why it matters more every quarter, and how two ideas, CIEM and Workload Identity Federation, can turn machine identity from a quiet liability into something you actually control.
The identities that outnumber your people
Think about everything in your cloud that authenticates without a human attached. CI/CD pipelines. Lambda functions and Azure Functions. Kubernetes pods. Payment reconciliation jobs. The integration a contractor built two years ago. The script someone wrote at 2 a.m. to fix a production issue and never took down.
Each one has credentials. Each one has permissions. And most of them were created under deadline pressure by someone who just needed the thing to work.
Nobody set out to build a mess. An engineer creates a service account, downloads a key, pastes it into a CI variable, and ships. It's reasonable in the moment. But multiply it across teams, sprints, and three cloud providers, and you end up with an estate where machines outnumber humans many times over, and the machines are the ones with the long-lived, rarely reviewed, over-permissioned access.
Human identities have guardrails: MFA, SSO, offboarding, quarterly reviews. Machine identities mostly have a JSON file and good intentions. That's what attackers go looking for. A leaked static key needs no phishing and no password cracking, and it often carries far more access than its job ever required.
Why this lands hard in regulated environments
If you run payments, lending, or anything touching cardholder data, this isn't just hygiene. It's an audit finding waiting to happen.
PCI DSS 4.0 pays real attention to application and system accounts. It expects least-privilege access, controlled and accountable use of those accounts, no hard-coded credentials lying around in scripts and config files, and proper management of the secrets that do exist. A service account with admin rights that nobody owns doesn't just feel uncomfortable, it's something an assessor will circle in red.
For fast-growing fintechs and NBFCs, this tends to surface at the worst possible moment: when an enterprise deal or a regulator is waiting on a clean report. Cleaning up identity under that kind of pressure is painful. Cleaning it up steadily, in the background, is a lot less so.
CIEM: seeing what your identities can really do
CIEM stands for Cloud Infrastructure Entitlement Management. The name is clunky, but the idea is simple: compare what each identity is allowed to do with what it actually does.
In most environments, that gap is huge. A service account might hold permissions across dozens of services and touch three. Every unused permission is pure risk with zero benefit, because if that identity is ever compromised, the attacker inherits the whole set, not just the slice the workload needs.
A solid CIEM practice gives you four things:
A real inventory. Across AWS, Azure, and GCP, including effective permissions that come from nested groups, inherited roles, and cross-account trusts. Those are almost impossible to reason about by hand, and that's where surprises live.
Right-sizing. Instead of guessing what a role needs, look at what it did over the last 60 or 90 days and trim the rest.
Risk flags. Identities that can escalate their own privileges, trust relationships wider than anyone intended, dormant accounts holding powerful roles.
Ongoing monitoring. Permissions drift. The cleanup you finish in March is half undone by June.
One honest warning: your first CIEM scan will probably return thousands of findings. If you treat all of them as urgent, your team will be exhausted by Friday. Prioritize hard. Start with identities that are internet-facing, hold admin-like power, or can reach cardholder or customer data. Fix those, then work down the list at a sustainable pace.
Workload Identity Federation: removing the secret itself
CIEM shrinks the blast radius. Workload Identity Federation (WIF) goes after the root cause, the long-lived secret.
Here's the idea. Your workload already has an identity where it runs. A GitHub Actions job has one. A Kubernetes pod has one. A VM or function has one. WIF lets your cloud provider trust that identity instead of demanding a separate static key.
The flow looks like this:
The workload gets a short-lived token from the platform it already runs on, usually an OIDC token.
It presents that token to your cloud provider's token service.
The provider checks it against a trust configuration you defined: which issuer, which repo, which branch, which service account.
If everything matches, the workload receives temporary credentials that expire in minutes or an hour.
No key to download. No key to rotate. Nothing sitting in a repo's commit history waiting to be found.
Each cloud has its own flavor: Workload Identity Federation on Google Cloud, OIDC providers and IAM Roles Anywhere on AWS, federated credentials and managed identities on Azure. The branding differs, but the pattern is the same, and it works just as well for Kubernetes workloads as for pipelines.
Take a typical deployment pipeline. The old way is a cloud key stored as a repository secret that everyone forgets about. The federated way is a trust relationship scoped to one repository and one branch. If someone forks the repo or pushes from somewhere unexpected, the conditions don't match and access simply isn't granted.
But here's the catch people miss: federation is only as safe as your trust conditions. A policy that accepts any token from a given issuer hasn't removed the risk, it has just hidden it somewhere harder to audit. Pin it tightly: specific repo, specific branch or environment, specific audience. Treat the trust policy as the new crown jewel, because it is.
Better together
We used to think of these as separate projects: CIEM in the "visibility" bucket, WIF in the "engineering" bucket. In practice, they feed each other.
CIEM tells you what to migrate first. Your inventory shows which accounts still rely on static keys, how old those keys are, and how powerful their roles are. That's a migration backlog, already ranked by risk.
WIF makes CIEM's job easier. When workloads use short-lived, federated access, each one tends to get its own narrow role rather than sharing one overpowered account "that everything uses." Right-sizing a role that has one job is far simpler than right-sizing one that has twenty.
Then CIEM becomes your safety net. It catches the new static key someone creates next month because they were in a hurry, and the trust policy that got loosened "just to test something."
How we'd start
If you're looking at a large, messy estate and wondering where to begin, here's the order we usually suggest. It isn't glamorous, but it works.
Get an honest inventory. Count service accounts, keys, and roles. Note which are static and which are federated. Expect to be a little surprised.
Go after the oldest, loudest keys. Long-lived credentials with broad permissions are the highest-value targets. Anything unused for months can often just be deleted, which is the cheapest security win there is.
Federate one pipeline first. Don't try to boil the ocean. Move a single CI/CD workflow to WIF, learn what breaks, and document the pattern. The second one takes half the time.
Make federation the default for anything new. The most important policy isn't cleaning up the past, it's not making new messes. Provide templates and Terraform modules so the secure way is also the easy way. People follow the path of least resistance, so make that path the safe one.
Assign an owner to every identity. This is the most underrated step. Ownerless identities are the ones that rot. If an account can't be traced to a team, that's a finding in itself.
Review on a schedule. Right-sizing isn't a one-time project. Fold it into the team's rhythm, the same way you handle dependency updates.
The human part
It's tempting to treat all of this as a purely technical problem, but much of it is cultural. Engineers create long-lived keys because they're under pressure and the key works. If the secure alternative is slower or poorly documented, they'll route around it, and honestly, who could blame them?
That's why we care about delivering security as clear, actionable fixes instead of noisy reports. A security team that shows up as a helpful neighbor, with working examples and a ten-minute setup, will get adoption. One that shows up with a 200-page policy document and a clipboard won't. Your engineers aren't careless. They're busy, and the job is to make the right thing the easy thing.
Where this leaves you
Machine identities aren't going away. With more automation, more containers, and now AI agents acting on our behalf, there will be many more of them next year than this year. You can keep managing them from memory and stale spreadsheets, or you can give them the same care you give people: a clear purpose, the least access needed, and a short, well-defined life.
CIEM shows you where you stand. Workload Identity Federation removes the thing attackers want most. Together, they turn an invisible, ever-growing risk into something you can manage, and something you can confidently show an auditor.
And the next time someone asks, "How many service accounts do we have?", there won't be a pause. There'll be an answer.
Want help mapping your non-human identity estate or getting audit-ready? Talk to the Arclogiq team.
Top comments (0)