Skip to content
The Cyber Security Place

Identity

The credential nobody remembers creating

Every control in identity security assumes there is somebody to ask. A service account cannot be trained, phished, promoted or offboarded.

Last reviewed August 31, 2026

The problem is ownership, not scale. About 31% of identity-related breaches trace to a credential that nobody on the current team could identify as theirs, and an identity with no owner is never reviewed, rotated or revoked. The evidence is a number that should be impossible: roughly 64% of secrets leaked in 2022 were still valid four years later. Counts of how many machine identities exist disagree by threefold — 45, 109 or144 per person — and that disagreement is itself the finding, because counting them needs the inventory whose absence is the problem. Around 97% carry more privilege than their function needs, and one dataset counted some 824,000 orphaned identities, up about 40% in a year.

Would you revoke it?

7 credentials found in one estate, with what you would actually know about each. Decide before you see what happens. For 2 of them the honest answer is that nobody knows — and that is not a gap in the exercise, it is the reason they are still live.

  1. A deployment key with write access to every repository

    Found in
    In the continuous integration configuration
    Last used
    Fourteen months ago
    Owner
    Created by an engineer who left in 2023

    Nobody knows

    Nothing observable happens for eleven days, and then a nightly job that nobody knew existed stops producing the file that the finance reconciliation depends on. It is found in March.

    Because the honest answer to what breaks is nobody knows, and the person who would have known was offboarded properly — their account was disabled the same afternoon. This key was not their account.

  2. A service account that runs the nightly backup

    Found in
    In the directory, with a password set in 2019
    Last used
    Last night
    Owner
    Nobody. It appears in a runbook with no author.

    Something breaks

    Backups stop that night and nobody notices for six weeks, because the monitoring for this job was configured to alert an address that no longer routes anywhere.

    This one is genuinely load-bearing, and it is also the clearest example of the problem: a credential doing essential work with no owner, no rotation and a password older than most of the team.

  3. An API token in a public repository commit from 2022

    Found in
    Git history, four commits deep, since removed from the current files
    Last used
    Unknown — the provider does not log reads
    Owner
    Nobody. The repository belongs to a team that was reorganised.

    Nothing breaks

    Nothing breaks. It was superseded two years ago and the replacement is in the secrets manager. The old one simply stayed valid because revoking it was never anybody's task.

    Removing a secret from the current files does not revoke it, and this is the commonest misunderstanding in the whole subject. The commit is still in the history and the token still works.

  4. A supplier's account with access to the customer database

    Found in
    Created during an integration project in 2021
    Last used
    Three weeks ago
    Owner
    The supplier, who was acquired last year

    Nobody knows

    Either nothing, or a data feed that a business team depends on stops. The only way to find out is to do it, and the business team will find out at the same time you do.

    Because the project that created it ended, the contract that governed it was novated to a company nobody has spoken to, and the access review it should appear in lists it under a person who left.

  5. A test account with production database credentials

    Found in
    In a configuration file in a staging environment
    Last used
    Eight months ago
    Owner
    Created for a migration that finished

    Nothing breaks

    Nothing at all. The migration completed in 2024 and this is pure residue — the single most satisfying kind of credential to remove, and the kind that survives longest because nobody is looking.

    Finishing a project produces a celebration, not a cleanup task. Nobody is assigned to remove what the project created, and the credential outlives the reason for it by years.

  6. A read-only token used by a monitoring tool

    Found in
    In the tool's configuration, scope set to full administrator
    Last used
    Continuously
    Owner
    The platform team, who did not create it

    Something breaks

    Monitoring stops, which you will notice within minutes, and the outage is entirely self-inflicted. What is worth doing instead is narrowing the scope, which nobody does because it works as it is.

    It was granted administrator because that was quickest during setup, and it has never been reduced because reducing it means finding out exactly which permissions the tool needs, which is an afternoon nobody has.

  7. A personal access token belonging to a current employee

    Found in
    In an automation that three teams depend on
    Last used
    Hourly
    Owner
    A named person, who does not remember creating it

    Something breaks

    Three teams' automation stops. Worse, it will also stop on the day that person leaves the company, and at that point nobody will connect the outage to the offboarding for several hours.

    Because it works, and because the fix — moving it to an account that belongs to a team rather than a person — is a morning of work with no visible benefit until the day it becomes an incident.

The asymmetry is the whole subject. Breaking the payroll run on a Friday afternoon is a certain cost with your name on it; an unowned credential sitting in a repository is a diffuse risk with nobody's. Every individual decision to leave it alone is defensible, and the aggregate of everybody making that defensible decision for four years is a majority of leaked secrets still working.

Why does none of the identity playbook apply?

Identity security has four load-bearing controls, and all four assume a person. Awareness training, which requires somebody who can be surprised by a deceptive message. A second factor, which requires somebody holding a device. Joiner-mover-leaver processes, which require an employment relationship with a start and an end. And access reviews, in which a manager confirms that a named human still needs what they have.

A deployment key satisfies none of those preconditions. It cannot be trained because it does not decide anything. It cannot hold a second factor because there is nobody to hold it. It never joins and never leaves, so no process fires when the project that created it ends. And it appears in an access review, if it appears at all, as a row that every manager scrolls past because none of them recognises it.

That last failure is the one worth dwelling on, because access review is the control that exists specifically to catch this. It works by asking somebody who knows. When the answer to who knows is nobody, the review does not fail loudly — it passes, with the row approved by whoever was asked to sign the page.

Which suggests where the effort belongs. Not in extending the human controls to machines, which is what most products attempt, but in the two things that work without a person: expiry, so a credential dies unless somebody renews it, and scoping, so the ones that survive can reach less. Both operate on the credential rather than on somebody's attention.

A number that should be impossible

Around 64% of the secrets published to public repositories in 2022 were still valid four years later. Not undiscovered — published, indexed, scanned by anybody who cared to look, and still working.

The volume that produces this is not small. Something like 28.65 million hardcoded secrets were added to public commits in a single recent year, which is roughly one per second, continuously, all year. Most are trivial; a meaningful minority reach production systems, and the platforms that notify owners are notifying somebody who often no longer works there.

The reason for the survival rate is the misunderstanding this subject is built on. Removing the secret from the current file feels like the fix, looks like the fix in a review, and does nothing whatsoever: the value remains in the version history, one command away. The only action that helps is revoking the credential at the service that issued it, and that requires knowing which service, which account, and what depends on it.

There is a second reason, less discussed and more human. Revoking somebody else's leaked key is an act with an unknown blast radius performed on somebody else's system, frequently by a person who found it by accident. The path of least resistance is to report it and move on, and reporting it lands with a team who face exactly the decision the exercise above describes.

How many of them are there?

The published ratios of machine identities to people disagree by a factor of three. One large survey puts it near 45 to one across enterprises; another reports about 109 to one; measurements of cloud-native estates reach roughly 144 to one. All three are quoted confidently, frequently in the same article.

The disagreement is not sloppiness. It comes from what each is willing to count. Does a short-lived container's token count as an identity? A certificate? A row in a database of API keys that a customer created? Every answer is defensible and they produce different worlds, which is why comparing two of these figures is meaningless and quoting one as a fact is worse.

What survives the disagreement is the direction and the order of magnitude: there are far more of these than there are people, and the gap is widening as automation and machine-to-machine integration spread. That is enough to act on. The precise multiple is not a number anybody needs, and treating it as one has produced a decade of slides that say nothing.

The deeper point is circular and worth stating plainly. Counting machine identities accurately requires a complete inventory of them — which is exactly the artefact whose absence causes the problem in the first place. An organisation that could answer the question precisely would not have the condition the question is about.

A decade of identity meaning people

403 entries here concern credentials, keys, certificates or machine accounts. 75 name a key, secret or token, 33 discuss certificates, and 142 concern privileged access more broadly.

82014512015542016422017762018732019472020492021

The solid portion names a key, secret or token specifically: about 25% across the first half of the period and roughly 15% across the second. Coverage peaks in 2018 with 76. Across the whole decade the word identity meant a person, while the count of identities belonging to nobody grew past a hundred to one — which is why the controls designed in those years all assume somebody can be asked. The earliest piece here naming one, Keyboards may be leaking secrets but probably not yours macworld, treats it as a developer mistake rather than an identity.

That framing persisted for years and it shaped the response. A leaked key was a lapse by an individual engineer, addressed with a scanner and a reprimand, rather than an account with permissions that somebody should own. The vocabulary arrived late, and the estate had already been built.

The order the work has to happen in

This subject attracts elaborate programmes and they mostly stall, because they begin with the interesting part. The order that works is dull and it is not negotiable: find them, own them, expire them, then narrow them.

Finding them is the entire difficulty and the step that gets skipped. It means reconciling what each platform will tell you it has issued against what anybody believes exists, and the output is a list that will be longer than expected and immediately out of date. It is worth doing anyway, because every subsequent step is impossible without it and trivial with it.

Ownership comes next and it is a management problem wearing technical clothes. Every credential gets a team — not a person, because people leave, which is the failure mode being fixed. A team that cannot say what a credential does is the answer to a useful question, not a failure: it identifies precisely the ones that should expire first.

Then expiry, which does the work the other controls cannot, and scoping last because it is the most expensive and the least urgent. Doing them in the reverse order — the common approach, because scoping produces a satisfying diagram — spends the budget on the credentials somebody already understood, and leaves the unowned ones exactly as they were.

What about the ones your customers create?

Every organisation that offers an interface for other software to use is issuing credentials it does not control, to people it will never meet, for purposes it cannot see. Those keys sit in somebody else's repository, somebody else's laptop and somebody else's departed employee's password manager, and they authenticate against your systems.

The asymmetry is uncomfortable. You carry the consequence of the leak and the customer carries the decision about how carefully to store it, which is the shape of an incentive problem rather than a technical one. Scanning public repositories for your own key format and notifying the owner is the usual response, and it is worth doing even though the notification frequently reaches nobody.

The controls that survive contact with reality are the ones that do not depend on the customer being careful. Keys with a recognisable prefix, so that automated scanners can find them and providers can revoke them centrally. Short lifetimes, so an old leak stops mattering. And a self-service way to rotate that takes two minutes, because a rotation process requiring a support ticket guarantees the key never rotates.

There is also a decision most providers make badly by default: what a single key can reach. Issuing one credential with the full scope of the account is convenient at signup and turns any customer's leak into a total compromise of their data with you. Scoped keys are more work to design and are the difference between an incident and a catastrophe on somebody else's premises.

The certificate that expires at three in the morning

Certificates are the one machine identity that already dies on its own, which makes them a useful natural experiment: this is what expiry does to an organisation that has not prepared for it. What it does is produce outages, reliably, at hours nobody chose, in systems whose owners had moved on.

The pattern is consistent enough to be a genre. A certificate on an internal service that nobody remembers deploying expires, an unrelated system fails in a way that gives no hint of the cause, and three hours are spent looking somewhere else. The underlying failure is not cryptographic; it is the same ownership gap, showing up on a schedule instead of in a breach.

Lifetimes have been shortening steadily and are heading shorter still, which is a good decision made for reasons that will be unpopular. A shorter life means a compromised certificate is useful for less time and it makes manual renewal impossible, which forces automation. Organisations that automated years ago will not notice; those still renewing by hand and calendar reminder will find the change expensive.

The useful reframing is that expiry is not the problem, it is the control working. An organisation that experiences certificate outages is an organisation discovering its unowned inventory in the least damaging way available — on a date the issuer chose, in daylight somewhere, without an intruder involved. The complaint that renewals are annoying is the complaint that the fire drill was inconvenient.

Which argues for deliberately importing the property elsewhere. A token that expires in ninety days behaves like a certificate: it surfaces its owner, or it surfaces its absence, on a predictable schedule and without an adversary. The objection is always that renewal is toil, and the answer is that the toil is the inventory, arriving in instalments small enough to absorb rather than as a project nobody funds.

There is a threshold worth knowing before adopting that argument wholesale. Below a certain lifetime, renewal stops being a task a human can perform at all, and an organisation that shortens lifetimes without automating first has simply converted a slow problem into a weekly emergency. The sequence matters more than the ambition: automate the renewal, confirm it survives a failure, and only then shorten. Teams that reverse those two steps produce exactly the outage the change was meant to prevent, and conclude from it that short lifetimes are impractical rather than that the order was wrong. The same inversion explains most abandoned programmes in this area: the ambitious step is attempted before the boring one that makes it survivable, and the failure is then blamed on the ambition rather than on the sequence. It is worth saying plainly because the sequencing error is cheap to avoid and expensive to diagnose afterwards, when the only evidence left is a cancelled programme and a team that will not try again.

The newest identity acts on its own

A class of non-human identity has arrived that breaks the assumptions in the previous sections. Software agents that take actions on a person's behalf hold delegated authority, act at times nobody scheduled, and choose sequences of operations that no engineer wrote down in advance.

Every difficulty above gets sharper. A service account does one predictable thing; an agent's legitimate behaviour is defined by its instructions, which change. The principle of least privilege requires knowing in advance what an identity needs, and that is precisely what is not knowable here — so the pressure is towards granting broad access and hoping the constraints hold, which is how the estate got into this condition the first time.

Attribution gets harder too, and it matters more. When an agent acting for a person does something damaging, the logs record the credential, and answering whether the person intended it, whether the instruction was reasonable and whether the agent exceeded it requires evidence most systems do not capture. The insider-risk vocabulary of careless, malicious and exploited does not obviously extend to something that had no intent at all, and stretching it to fit produces investigations that sound conclusive and establish nothing.

The honest position is that nobody has this solved and the sensible precautions are unglamorous and familiar: separate identities per agent rather than reusing a person's, narrow scopes, short lifetimes, and logs detailed enough to reconstruct a sequence afterwards. The organisations that will handle this well are the ones that already did the dull inventory work, which is the same conclusion as everything else on this page.

One further habit is worth borrowing from aviation rather than from software: write down what the thing is allowed to do before granting it anything, in a sentence a colleague could check. Not a permissions matrix, which nobody rereads, but a plain declaration — this agent reconciles invoices and touches no customer record. It costs a minute at creation and it converts the impossible later question, «should this identity be able to do that?», into a comparison anybody can perform.

Common questions

What is a non-human identity?

Anything that authenticates and is not a person: a service account, an API token, a deployment key, a certificate, an automation's credential. They do the same things a user account does and none of the controls designed for people apply to them.

How many are there?

Nobody knows, and the published figures disagree by a factor of three — roughly 45 per human in some surveys, about 109 in others, and near 144 in cloud-native environments. The disagreement is the finding: counting them requires the inventory whose absence is the problem.

Why is this different from password security?

Because every control in identity security assumes somebody can be asked. You cannot train a service account, it will not notice a phishing message, it has no second factor, and it does not leave the company. The playbook was written for people.

What is the actual harm?

Around 31% of identity-related breaches trace back to a credential that nobody on the current team could identify as theirs. It is not that machine identities are inherently weaker; it is that an identity nobody owns is never reviewed, rotated or revoked.

Are leaked secrets actually exploited?

They remain available to be. Around 64% of secrets leaked in 2022 were still valid four years later, which means most exposure is never closed. Whether each one was used is unknowable; whether it could have been is not.

Does deleting the file fix a leaked key?

No, and this is the commonest misunderstanding in the subject. Removing a secret from the current files leaves it in the version history, where it is trivially recoverable. The only fix is revoking the credential itself.

Why do they have so much access?

Because broad permissions are the quickest way to make something work on the day it is built, and narrowing them afterwards requires knowing exactly what it needs. Roughly 97% carry more privilege than their function requires, and almost none of that is deliberate.

Why not just revoke the ones nobody claims?

Because the consequence is unknown, and that asymmetry decides everything. Breaking payroll on a Friday is a certain, attributable cost; an unowned credential is a diffuse one. Every individual decision to leave it is defensible and the aggregate is what the figures describe.

What is an orphaned identity?

One whose owner has left, whose project ended, or whose supplier was acquired — and it survives all three, because none of those events triggers anything. One dataset counted around 824,000 of them, up about 40% in a year.

Where should a team start?

By finding out what exists, which is unglamorous and is the whole job. Everything else — rotation, scoping, expiry — is straightforward once there is a list, and impossible before. Most organisations have no list and no owner for making one.

Does a secrets manager solve it?

It solves storage, which is a real problem and not this one. A secrets manager holds the credentials somebody put in it; the credential that matters is the one nobody remembers creating, and it is not in there.

What single change helps most?

Expiry. A credential that dies on its own converts an unbounded liability into a scheduled interruption, and it forces the ownership question at a moment of your choosing rather than during an incident. It is also the change teams resist hardest, for exactly that reason.

Credentials and keys in the archive

403 entries, peaking in 2018 with 76.