Most organizations have far more non-human identities than human ones, and they get a fraction of the attention. Every scheduled job, deployment pipeline, integration, and background worker authenticates as something, and that something is usually a service account holding a secret: an API key, a token, a certificate, a signing key. These identities do not log in at nine and out at five, they do not get walked to the door when someone leaves, and they rarely have a person actively watching what they do. That combination — powerful, persistent, and unattended — is exactly what makes them attractive to defend well and easy to neglect.
The defining trait of a service account is that its credential is a bearer of trust that lives somewhere other than a person’s head. A password can be phished; a service secret can simply be copied. Once it exists, the questions that matter are how long it lives, how many systems accept it, and who would notice if it were used from somewhere unexpected. Those three questions — lifetime, reach, and observability — are the whole subject of this guide, and each of them is something you can inspect rather than assume.
Where blast radius really comes from
Blast radius is the honest measure of a service account’s risk: if this one credential were misused, what could it reach, and how far could that reach cascade? A key that can read a single storage prefix is a small blast radius. A key that can assume broader roles, create new identities, or touch production data across several systems is a large one, and the danger is that broad permissions accumulate quietly. An account is created for one task, then reused for a second because it “already had access,” then granted a wildcard permission during a late-night fix that nobody narrowed afterward. No single step feels reckless, but the sum is an identity that can do far more than any of its jobs require.
The way to shrink blast radius is the same least-privilege discipline that applies to people, scoped to the specific action, resource, and workflow the account actually performs. A backup job needs write, not delete or read; a metrics collector needs read on one dataset, not administrative rights on the account. This is the identity practice described in IAM Roles and Least Privilege , and it pairs with segmentation so that even a misused credential is confined. When you can say in one sentence exactly what an account is allowed to touch, you can also say what the damage would be if it were abused, and that sentence is worth writing down before you need it.
Why long-lived secrets are the quiet problem
A secret that never changes is a secret that only grows more dangerous. Every deploy that bakes it into an image, every developer laptop that caches it, every log line that accidentally prints it, and every backup that captures it adds another place it might leak from — and because it never rotates, a copy taken today still works next year. Long-lived static secrets are the credential equivalent of a door key that has been copied so many times nobody knows who holds one.
Rotation is the countermeasure, and its real purpose is to bound exposure in time: if a secret is replaced regularly, a copy that leaks has a limited useful life. The stronger move, where a platform supports it, is to avoid holding a durable secret at all and instead have the workload obtain a short-lived credential from its runtime identity, so there is little to steal and nothing to rotate by hand. Keeping secrets out of source code and configuration in the first place is closely related and covered in Secrets in Source Repositories ; the same short-lived, workload-bound identities also underpin the signing discussed in SBOMs, Signatures, and Attestations . The defensive goal is not ceremony for its own sake but a smaller window in which any single leaked credential is useful.
Toy example
Picture a fictional design studio, Loomcraft, whose nightly export job runs as a service account called svc-nightly-export. A defender reviewing identities notices that this account’s key was created two years ago and has never been rotated, and that its permissions include broad read access across several data stores rather than the one export bucket the job uses. Separately, the authentication logs show the account signing in at its usual overnight hour — nothing anomalous, just an old, over-privileged, unrotated credential sitting in plain view.
The calm write-up is narrow: “svc-nightly-export holds a static key created two years ago, never rotated; its granted permissions exceed the single bucket its job requires; recent authentication activity matches the expected nightly schedule with no unfamiliar source.” That is not an incident, but it is real risk with a clear shape. The follow-ups are ordered and safe: confirm the owner and the job’s actual needs, narrow the permissions to the one bucket, plan a rotation with the owner so the change does not break the job, and confirm that access logging is on so an off-schedule use would be visible. The whole exercise is about reducing lifetime and reach before anything goes wrong, and nothing in it requires touching a real system or reproducing an attack.
What evidence matters?
The strongest evidence about a service account is its own configuration exported as data: the identity’s granted permissions, the age and type of its credentials, whether those credentials are static or short-lived, and which systems trust them. These facts describe lifetime and reach precisely, and they are the difference between “that account feels risky” and “this account holds a two-year-old key with permissions across four data stores.” The second kind of evidence is usage — the authentication and access logs that show when and from where the account actually acted. A service account has a naturally predictable pattern, so its logs are unusually informative: a batch job that suddenly authenticates at midday, or from an unfamiliar source, or against a system it never normally touches, is a signal precisely because the baseline is so regular. That baseline reasoning connects to Authentication Log Patterns and Valid Accounts .
The third kind of evidence is ownership and lifecycle: who owns this identity, what created it, and whether it is still needed. Orphaned service accounts — ones whose owning team, project, or integration no longer exists — are among the most dangerous, because nobody will notice their misuse and nobody remembers what they are for. As with all evidence work, the notes worth keeping are timestamped, exported, and tied to a named source rather than remembered, the standard described in Evidence-First Triage . If access logging for an account is disabled, that absence is itself a finding: you can prove what it is allowed to do but not what it has done, and you should say so plainly.
Common mistakes and false positives
The most common false positive is a service account behaving exactly as designed. These identities are supposed to act without a human present, at odd hours, in high volume, so “an account authenticated at 3 a.m. with no person logged in” is the normal state, not a red flag. Before escalating unattended activity, compare it against the account’s established pattern; the meaningful signal is deviation from that baseline, not the mere fact of automation. Treating every non-human login as suspicious floods the queue and trains people to ignore it.
The mirror-image mistake is assuming a service account is fine because nothing has alerted. Silence often means the account is simply unwatched — logging off, or nobody reviewing it — rather than safe, and an old static key can be misused for a long time without tripping anything. Two more traps are worth naming. First, rotating a secret while leaving the permissions broad shrinks the leak window but not the blast radius, and narrowing permissions while leaving a decade-old key in place does the reverse; both dimensions need attention. Second, human controls like multi-factor prompts usually do not apply to non-human identities, so assuming an account is protected the way a person’s would be, as MFA, Passkeys, and Recovery Paths discusses for people, is a category error. A stolen service secret is a valid-account problem, and it is often the quiet start of the story told in Initial Access Without Drama .
What to do next
Start by inventorying non-human identities and, for each, writing the one-sentence version of what it is allowed to touch and how old its credential is. Narrow permissions to the specific action, resource, and workflow the account actually performs, and prefer short-lived, workload-bound credentials over durable secrets wherever the platform allows it. Where static secrets must exist, keep them out of source and configuration, store them in a managed secret store, and rotate them on a schedule the owner has agreed will not break the job. Turn on access logging so an off-pattern use is visible, and retire orphaned accounts rather than leaving them as unattended keys.
If a service-account concern turns into a real incident — a leaked secret, or a credential used from an unexpected source — switch modes and do not experiment. Preserve the identity’s configuration and logs as evidence, revoke or rotate the affected credential through the proper process, follow your incident-response plan, communicate through approved channels, and involve qualified responders and legal counsel where warranted. For learning, keep every account and secret fictional and rehearse the calm sequence: name the reach, bound the lifetime, confirm you would see misuse.
How this guide was made
This page is defensive education assembled from public identity and key-management frameworks and openly published secrets-management guidance, illustrated with an invented studio and toy identities. It makes no claim to certification, compliance sign-off, legal advice, or incident-response authority, and it deliberately avoids exploit detail so it stays useful for safe study rather than operational misuse.
Official references
For deeper grounding, the NIST SP 800-63-4 Digital Identity Guidelines frame how identities and their credentials should be reasoned about, including non-human ones, and the CISA Secure Cloud Business Applications Project offers secure-configuration baselines for the services these accounts authenticate to. The CIS Critical Security Controls v8 place account and credential management in a broader control set, while the CISA Known Exploited Vulnerabilities Catalog is a reminder that a compromised identity often follows an unpatched exposure. Use these as orientation, not as certification.
Related guidebooks
Continue with IAM Roles and Least Privilege to shrink blast radius, and Secrets in Source Repositories to keep credentials out of code in the first place. The identities that sign software connect this topic to SBOMs, Signatures, and Attestations , and to see how a misused credential becomes an intrusion, read Initial Access Without Drama .
