Your company has a hiring process. Somebody writes a job description, an interviewer probes for fit, HR runs a background check, IT provisions accounts against a role, a manager owns the person, and when they leave, a process takes the access back.
Now think about the last service you deployed. It came with credentials: an API key, a service account, a certificate, a token in a config map. That identity got created in seconds, by an engineer under deadline, with whatever permissions made the pipeline go green. Nobody wrote its job description. No manager owns it. Nothing will take its access back, because nothing is watching for the day it stops being needed.
You didn't deploy a service. You hired someone, and skipped every step of your own process.
I've spent fifteen years running identity programs, and this is the gap I'd put in front of any CTO first. We built serious governance for the smaller half of the workforce and almost none for the larger half. My argument here is that machine identity is a workforce management problem, which is why buying another certificate manager rarely fixes it. Until the larger half of the workforce has owners, scopes, reviews and an exit process, the number of unmanaged workers in your estate will keep compounding.
The workforce you never hired
Palo Alto Networks, which now owns CyberArk, puts the ratio at 109 machine identities for every human identity in the enterprise, up from 82 to 1 a year earlier, in its 2026 Identity Security Landscape survey of more than 2,900 cybersecurity decision makers. 77% of organizations expect that number to keep climbing.
The growth rate matters more than the ratio. Going from 82 to 109 in a year is an increase of roughly a third, and that isn't a trend you get ahead of by adding headcount to the identity team. That curve comes from how software is built now: microservices that authenticate to each other, pipelines that authenticate to clouds, functions that wake up, get a token, and vanish. Each of those is a worker with credentials and a scope of access.
Then there are the new arrivals. In the same survey, 99% of organizations reported adopting AI agents, and 40% of those agents already have access to organizational data. An agent is an employee with initiative. It decides what to do next, it calls tools, and increasingly it hires its own help by spawning sub-agents, each of which needs credentials of its own.
The word "identity" is doing real work in that sentence. These aren't integrations or configuration. They authenticate, they hold permissions, they act, and someone should be accountable for each of them. Your business runs on identity, and most of the identities running it were never issued by anyone you can name.
Machines are now the way in
For years the security story had a human at its center: someone clicked a link, someone reused a password. Attackers have followed the numbers.
SpyCloud's 2026 Identity Threat Report, based on a survey of 750 cybersecurity leaders and practitioners, found that compromised non-human identities were the primary entry point in 31% of breaches, nearly twice the rate of phishing and social engineering at 17%. Sophos surveyed 5,000 IT and security leaders across 17 countries in the first quarter of 2026 and found that 71% of organizations had suffered at least one identity-related breach in the previous year, with weak management of non-human identities cited in 41% of them: API keys in code, static credentials, orphaned service accounts. The mean recovery cost was $1.64 million, with a median of $750,000.
Two things make a machine identity an attractive target. It usually has more access than a person doing similar work, and it operates without anyone watching. A human's stolen credential eventually behaves oddly: logins at the wrong hour, from the wrong country. A service account's credential behaves exactly as expected, because nobody knows what to expect from it in the first place.
The monitoring numbers say as much. In the SpyCloud research, 95% of organizations believed they had adequate visibility into AI and non-human identity exposure, while only 36% monitored it. Sophos found that just one in three organizations regularly rotates or audits service accounts and non-human identities, and only 11% do it continuously.
Run those against the workforce analogy. Two thirds of your staff have never had a performance review, most have never had their access revisited since their first day, and no manager would notice if one of them started working for someone else.
Why secrets sprawl is inevitable
Here is where I'd push back on how most organizations think about this. They treat the credential as the identity. Issue an API key, store it in a vault, call it managed.
An API key is a bearer token. Whoever holds it's the identity, and copies are indistinguishable from the original. That property is what makes secrets sprawl inevitable rather than sloppy.
GitGuardian's State of Secrets Sprawl 2026, published in March, found 28.65 million new hardcoded secrets pushed to public GitHub during 2025, a 34% increase year over year. Secrets tied to AI services reached 1,275,105, up 81%. Internal repositories, the ones teams assume are safe, were roughly six times more likely to contain a hardcoded secret than public ones. Commits written with AI coding assistants leaked secrets at about twice the baseline rate, 3.2% against 1.5% across all public commits.
The detail I find most damning is the longevity. GitGuardian reports that above 64% of the credentials it confirmed valid in 2022 were still valid in January 2026. Four years after being exposed to the internet, most of those keys still work. Nothing rotated them, because nothing owned them.
A credential that never expires and can be copied freely isn't an identity. It's a key under the doormat, and the doormat is in a public repository.
The alternative has existed for years. Workload identity systems issue a short-lived, cryptographically verifiable credential to a workload after attesting what that workload actually is. SPIFFE and SPIRE, the standard and its implementation, graduated from the Cloud Native Computing Foundation in September 2022, with production users including Netflix, Uber and GitHub. The cloud providers have their own versions. The technology is settled. What makes adoption slow is that it changes how engineers get access to things, which makes it an organizational decision with a tooling component, and those move at the speed of the organization.
The math is about to end manual rotation
If none of the above moves your roadmap, a deadline should.
In April 2025 the CA/Browser Forum adopted Ballot SC-081v3 with 25 votes in favor and none against among certificate issuers. It sets a schedule for the maximum lifetime of a publicly trusted TLS certificate:
- Before 15 March 2026: 398 days
- From 15 March 2026: 200 days
- From 15 March 2027: 100 days
- From 15 March 2029: 47 days
The first cut is already in force. Domain validation data reuse shrinks on the same schedule, down to 10 days by 2029, so the revalidation that goes with each renewal gets more frequent too.
Work out what that does to a calendar. A certificate you renewed once a year in 2025 needs renewing roughly eight times a year by 2029. Multiply by however many certificates your organization actually has, then add the ones nobody has counted, the ones on internal services, appliances, load balancers, and that one integration a vendor set up in 2019.
Every organization I can think of falls into one of two positions here. Either certificate renewal is already automated end to end, in which case the schedule is a non-event, or renewal still depends on a human remembering, in which case the next three years will produce a steady supply of outages. The second group tends to discover the problem the way it's always discovered: a payment service stops responding on a Saturday morning.
I'd treat the 2029 date as the useful gift in this story. It converts an argument about good practice into an engineering deadline, and deadlines get funded.
An agent is a contractor, not a service account
The agent wave breaks the last assumption holding the old model together: that a machine identity is static, long-lived, and does one predictable thing.
An agent's whole value is deciding what to do next. It reads a ticket, queries a database, calls three APIs, and writes to a system you didn't anticipate when you issued its credentials. Give it a standing key with broad permissions and you've handed an improviser a master key.
The control numbers in the Palo Alto research are the ones I'd read aloud in a steering committee. Only 37% of organizations can revoke an AI agent's credentials. Only 30% have immutable audit logging of what their agents do. Sophos adds that agents can spin up sub-agents autonomously, each generating new credentials with broad, persistent access and inconsistent oversight.
Most organizations running agents today can't fire one and can't prove what it did, which is a strange position to occupy while expanding their use.
The contractor comparison is the one I'd design against, and this is my framing rather than anyone's published guidance. A contractor gets a scope of work, an end date, an access badge that stops working when the engagement ends, and a named person inside the company who's accountable for them. None of that's exotic. It's what every procurement department already does for humans, and it maps cleanly onto agents: a defined task boundary, credentials that expire by default, permissions scoped to the task rather than the platform, and a log that survives the agent that wrote it.
The timing matters too. Palo Alto's Unit 42, reporting on more than 750 incidents it investigated across more than 50 countries, found that in the fastest cases attackers moved from initial access to data exfiltration in 72 minutes, 4x faster than the year before. It also found that identity weaknesses played a material role in nearly 90% of those investigations. A quarterly access review isn't a control at that speed.
Run it like a workforce
The reframe I'd take to an executive team is that machine identity needs the same five things your HR process already provides for people. Nothing here requires a new category of product.
Every identity gets created against a requisition. No credential exists without a named human owner and a stated purpose. If an engineer can mint a service account with no owner attached, your inventory is fiction from its first day. Most cloud platforms can enforce this at creation time through tagging policy, which turns a governance wish into a build-time error.
Every identity gets a job description. Scope the permissions to the task instead of the platform. The lazy version is the wildcard policy that made the deploy work at 11pm; the honest version takes another hour and is the difference between an incident and an inconvenience. This is also where the agent question gets decided, because an agent with platform-wide permissions will eventually use them.
Every identity gets an end date. Credentials should expire by default and renew automatically, which is the same capability the certificate schedule is forcing on you anyway. Anything that can't rotate automatically becomes a standing exception with an owner and a review date, not a permanent arrangement that quietly outlives the person who created it.
Every identity gets reviewed. Certification campaigns at most organizations cover employees and contractors and stop there. Machine identities belong in the same cycle, reviewed by their owner, with "is this still needed?" as the first question and "does it still need this much access?" as the second. Owners who can't answer either question are telling you something useful about that identity.
Every identity can be terminated. This is the test I'd run first, because it's quick and the answer is usually uncomfortable. Pick one production service account and one AI agent. Time how long it takes to revoke their access completely and confirm it's gone. An hour is a reasonable bar. If you can't clear it, you don't have a control, and everything built on top of it's paperwork.
Who owns this
The question that decides whether any of the above happens is one nobody enjoys: which team owns machine identity?
In most organizations the answer is that it's split, which means it's nobody's. Security owns the policy but doesn't touch the pipelines. Platform engineering owns the pipelines and treats credentials as configuration. Application teams own the services and inherit whatever pattern the last team used. The result is a workforce with three part-time managers and no accountable one.
My view, and it's a view rather than a finding, is that the identity program should own the standard and the platform team should own the paved road. The identity program defines what a machine identity must have: an owner, a scope, a maximum lifetime, an audit trail. The platform team makes the compliant path the easiest one to take, so that getting a scoped, short-lived, automatically rotating credential is less work than hardcoding a key. Every organization that has made real progress on secrets, in my reading of how these programs go, has made the secure path the convenient one rather than policing the convenient one.
That division also settles the funding argument. The standard costs a policy document and some review time. The paved road is engineering work with a deadline attached to it, which is exactly the shape of the certificate schedule above.
Run the workforce this way and the security case makes itself. What I find more interesting is the speed case. When identity for a workload is issued automatically, scoped to its job, and expires on its own, engineers stop waiting on tickets to get access to things. Provisioning a new service stops being a negotiation and becomes a property of the platform. That's what access as an accelerator looks like at machine scale, and it's the same time-to-yes argument I'd make about human access, with three orders of magnitude more identities riding on it.
Recognize your digital workforce
Start with a headcount, because every other decision depends on it.
- Count them, by type. Service accounts, API keys, TLS certificates, cloud roles, CI/CD tokens, agents. One number per category, from the systems of record rather than from memory. If the count takes more than a week to assemble, that's your first finding.
- Name an owner for each. Not a team mailbox. A person. Identities with no owner go on a list that gets shorter every month.
- Find the ones that never expire. Sort by credential age. The oldest entries are your highest risk and usually your easiest wins, because a key nobody has rotated in four years is frequently a key nobody needs.
- Run the revocation drill. One service account, one agent, timed, in production. Write down the number.
- Check your certificate position against the schedule. How many publicly trusted certificates do you hold, and what share renew without a human? The 200-day cap is already in force; the 47-day cap arrives in 2029.
- Put agents under the same governance as contractors, with a scope, an expiry, an owner, and a log you can read after the fact.
That's a headcount, an org chart, and an offboarding process for the larger half of your workforce. None of it's novel. The novelty is applying it to workers made of code.
Your machines outnumber your people 109 to 1, they hold more access than your people do, and attackers now prefer them as a way in. Recognize your digital workforce, and manage it like one.