The Guide to Service Account Security and Governance

You can probably name every person with admin rights to production. Can you name the service account that's held the same rights since your last reorg, and the person who'd answer for it if it started reading data it has never touched?

Service account security is the practice of controlling which non-human accounts exist, what each one can reach, who's accountable for it, and how it proves its identity. Most programs start with the last of those, the password, and never get to the first. The incidents below share that gap. In each one, nobody had settled whether the account should exist or how much it should be allowed to reach.

Closing that gap takes answers to a handful of practical questions. Where do service accounts hide across Active Directory, cloud, and SaaS apps, and why should rotation wait? Who owns each account, what order do the fixes go in, and how do you stop engineers from borrowing service account credentials? The sections that follow answer each one, ending with how to audit service accounts and which ones to fix first.

How do you find service accounts in Active Directory, cloud, and SaaS?

If your service account inventory starts at your identity provider, it starts in the wrong place. Service accounts get created in three homes, and an inventory built from SSO and the HR feed misses most of what lives in two of them.

The directory holds domain service accounts, group managed service accounts (gMSAs), and accounts with service principal names (SPNs), the identifiers Kerberoasting attacks use to request tickets they can crack offline. The cloud holds IAM users with access keys, service principals and app registrations, and Google Cloud service accounts. SaaS apps hold integration users, bots, and the OAuth grants that let one app read another.

Cloud and SaaS accounts get created inside the console or the app, usually by an engineer or an integration installer. They never pass through SSO and never show up in the HR feed. The one exception is a cloud whose directory doubles as your IdP, where service principals appear natively.

Without a label, you identify service accounts by how they behave. Look for no matching HR record, no interactive sign-ins, API-only authentication, and names like svc_ or integration_.

Lumos closes this gap from the app side. It connects to apps directly through more than 300 integrations, so it captures the local accounts that never touch the IdP and maps them in one access graph next to your employees. When an incident responder asks what a given account can reach, the answer comes from one place.

Skipping this step costs you later. Each control that follows covers only the accounts on your list, so the missing ones stay unreviewed indefinitely. Treat the list as the foundation of your broader non-human identity program.

Why service account password rotation belongs last

Credential rotation matters, and it's the wrong place to start. Rotation efforts, scheduled or emergency, tend to skip the accounts people believe are unused, and those are the accounts attackers find.

Cloudflare's own postmortem shows the pattern. After credentials leaked in an October 2023 breach at a third-party vendor, Cloudflare rotated them. It missed one service token and three service account credentials out of thousands, because the team believed those accounts were unused. In November an attacker used them to reach Cloudflare's Atlassian environment, including through a SaaS integration's service account with admin rights in Jira.

Rotating those four credentials would have stopped this attack. The team skipped them for the same reason they should have been gone: everyone believed they were unused. A retired account can't be missed in an emergency rotation.

Old credentials pile up because nothing forces them out. Datadog's State of Cloud Security 2025 found that 59% of AWS IAM users, 55% of Google Cloud service accounts, and 40% of Microsoft Entra ID applications had access keys more than a year old. AWS access keys and Google Cloud service account keys stay valid until someone rotates or deletes them, so a key without an owner ages in place.

Hunting for dormant credentials by hand turns NHI security into a project that never finishes. Lumos's NHI Owner Hunter Agent monitors service accounts, keys, and tokens continuously and shuts down the ones that go dormant or carry more scope than they use.

Rotation stays in the program, but it belongs last. The question that comes first is simpler and harder to answer: should this account exist, and who says so?

Service account governance starts with an owner and a workload

A service account earns its place by staying attached to two things: the workload it serves and the person who answers for it. Lose either one, and the account should land in review automatically.

The workload anchor is the application, pipeline, or integration that uses the account. When that workload is decommissioned, the account has lost its reason to exist, even if it's still sitting in the directory. The human anchor is a named person, with a named backup, who can say what breaks if the account is revoked.

The test is binary, and it's the core of service account governance. An account with both anchors is governed, and an account missing either one is a finding. Findings are common. In customer environments Lumos has analyzed, 95% or more of non-human identities have no human owner.

No owner means no one to call at review time and no leaver event to catch the account when someone departs. Lumos's Agent Ownership Finder assigns a human owner to each NHI and AI agent it catalogs, and new agents get an owner before they get to work. That owner record is where AI agent access management begins, since no one can review an agent's grants until someone answers for them.

CIS Controls Safeguard 5.5 sets the external bar. It calls for a service account inventory that records a department owner, a review date, and a purpose for each account, with reviews at least quarterly. Go one level further. A department never leaves the company or answers an on-call page, so it never triggers the leaver event your user access management relies on to surface the account.

Ownership stays true only if something checks it. Wire four events to open a review automatically: the owner leaves or changes teams, the workload is decommissioned, the account goes unused past a set window, or it picks up new privileges. Those triggers turn ownership from a spreadsheet field into part of the account's lifecycle.

The cheapest place to set both anchors is at creation. Require a workload and an owner in whatever request or pipeline creates the account, and don't issue credentials until both are filled in. Apply the same gate to the AI agents your teams deploy, since an agent is a service account that picks its own next action.

How to secure service accounts in the right order

Run every service account through four questions in order. A yes at step 1 ends the review, because the account goes away. Everything else works down the whole list, since the other three steps can all apply to the same account.

‍

An account whose owner left but whose workload still runs isn't a retirement candidate yet. It needs a new owner, and it reaches step 1 only if it's still unclaimed at the deadline.

Take a nightly reporting job on a cloud VM that authenticates with a years-old access key. The key can write to every bucket in your data lake, though the job reads only two, so the account passes step 1 and drops to read access on those two buckets at step 2. At step 3 it switches to the identity the cloud attaches to the VM, which hands out short-lived tokens. That leaves no stored key for step 4.

A data-export account built for a dashboard someone retired last year stops at step 1. Disable it during business hours and keep the change reversible while you watch authentication failures through its longest job cycle. If something breaks, whoever reports it is the owner you were missing.

The platforms themselves are pushing step 3. Google Cloud now blocks service account key creation and key upload by default for organizations created on or after May 3, 2024. Windows Server 2025 adds delegated managed service accounts (dMSAs), which replace a legacy service account's password with managed, fully randomized keys.

Klue's response to its June 2026 breach heads the same direction. According to the CrowdStrike investigation summary Klue published, an attacker used a previously compromised GitHub personal access token to push code into Klue's integration service and collect customers' Salesforce OAuth tokens. Klue then blocked personal access tokens across its GitHub organization. Its workflows now authenticate through GitHub Apps or short-lived, automatically expiring credentials.

A better credential type doesn't settle the governance question, though. Akamai's BadSuccessor research showed the new dMSA type could be abused to take over any account in the domain, and Microsoft patched the direct escalation path in August 2025 (CVE-2025-53779). The right to create and modify service accounts is privileged access in its own right, so review it alongside the accounts themselves.

How much access should a service account have?

A service account's blast radius is everything it's allowed to do that its job doesn't require. That excess is where a compromise turns into a breach, which makes cutting it the core of non-human identity breach prevention.

Dropbox Sign shows how. In April 2024 an attacker compromised a back-end service account tied to an automated configuration tool. Dropbox said the account held privileges to take a variety of actions in production, and the attacker used them to reach the customer database. No configuration job needs the customer database, and this account could reach it anyway.

Over-grant rarely comes from one bad decision. Accounts get cloned from older, broader ones. Admins grant rights "to make it work" during a deploy, and integration installers request OAuth scopes that get approved by default. None of those grants gets undone later.

The fix is to let usage set the scope. Compare what each account is granted against what it used, and cut what's untouched. For SaaS integrations, compare granted OAuth scopes with the API calls the integration makes.

Usage data at this scale needs automation. Albus, Lumos's AI identity agent, analyzes usage patterns to flag service accounts that hold more access than they use. Netskope applied the same principle across its broader access program, and usage-driven least privilege with just-in-time grants cut its standing access by 80%.

Measure across the account's longest job cycle, since quarterly and year-end jobs look dormant in a short window. Confirm with the human anchor before you cut, and start with accounts holding admin or production-write access, where excess access costs the most.

Right-sizing never finishes, because permissions drift back up with each new feature. Keep the comparison running and feed it into your privilege creep detection.

How to block service account interactive logon without slowing engineers down

When a person signs in as a service account, check first how hard it is for that person to get access as themselves. Blocking interactive logon sticks only after engineers have a fast, legitimate path of their own.

The pattern is familiar. An incident hits at 2 a.m., the on-call engineer needs database access now, and the approval path takes hours. The service account's password is sitting in a config file. Borrowing it once becomes a habit, and from then on nobody can attribute what that account did.

If you're in PCI scope, this is already an audit item. PCI DSS v4.0.1 Requirement 8.6.1 treats interactive use of the accounts that applications and services run under as an exception. That exception has to be time-limited, approved, and attributable to an individual. Requirement 8.6.2 bars hard-coding passwords for any of those accounts that can sign in interactively (PCI SSC document library).

The fix is to make the legitimate path faster than the borrowed one. Code42 set up pre-approved on-call groups in Lumos, so verified engineers reach sensitive databases within seconds during an incident. Lumos removes that access within a few hours. With time-based access on its most critical applications, Code42 also cut privileged access by 67% across its stack.

Once that path exists, close the old one. Deny interactive logon for service accounts at the platform level, through Group Policy, conditional access, or the session policies in your IAM tools, and treat each interactive attempt as a high-severity alert.

Exceptions will still happen. Check the credential out to a named person and record the session, then rotate it as soon as the work is done. MFA on the service account won't solve the underlying problem, since it breaks automation and leaves the reason for borrowing untouched.

How do you audit service accounts without rubber-stamping them?

Nobody can meaningfully re-approve four thousand unchanged service account entitlements, so stop asking anyone to. A review works when it shows the right person only what changed, in words they can read.

Most service account reviews fail the same way. The campaign lands with an IT generalist who can't parse an entitlement like NS_FIN_ADMIN_7. Nothing has changed since last quarter, so everything gets certified by default.

Three changes fix it:

1. Route each account to its human anchor, who knows what the account is for.
2. Review only the deltas: new grants, new privileges, a changed owner, or behavior that shifted.
3. Translate each entitlement into plain language before anyone approves it.

Lumos handles the last two directly. Its delta access reviews show reviewers only what changed since the last cycle. Its Entitlement Analyst translates permissions into plain English, so NS_FIN_ADMIN_7 becomes write access to every invoice in NetSuite. App owners review human and machine access side by side in the same campaign, so service accounts don't need their own user access review software.

ChargePoint shows what that review engine does under audit pressure. It runs access reviews for SOC 2, SOX, PCI, FedRAMP, and ISO 27001, and it completed twice as many reviews after moving data collection and reviewer routing into Lumos.

Once reviews carry only changes, the quarterly campaign gets small enough to mean something, and the anchor triggers handle whatever can't wait a quarter. An owner who sees one new admin grant on one integration account, described in plain language, can approve or revoke it in a minute.

Which service accounts should you fix first?

Fix privileged service accounts first, meaning the ones with admin rights, production write access, or broad OAuth scopes, starting with the types below. Pull them from all three homes, give owners a deadline, and disable anything still unclaimed when the window closes. Track one number as you go: the count of privileged service accounts missing an anchor, which should fall every month.

Accounts whose workload is gone

The workload these accounts served has been decommissioned, but their credentials still work. With no legitimate traffic left to protect, they're the lowest-risk retirements on the list. Disable them now and delete them after a quiet period that covers their longest job cycle.

Accounts with no human owner

The workload still runs, but the owner left or changed teams, so no one can say what breaks if the account is revoked. Assign a new owner from the team that deploys or maintains that workload. If no one claims it by the deadline, it moves to retirement.

Dormant accounts that still authenticate

Accounts everyone believes are unused get skipped during rotation and ignored by monitoring, which makes them the easiest credentials for an attacker to use quietly. Pull last-authentication dates across each account's longest job cycle. Anything with no activity in that window goes to its owner for a retire-or-keep decision this month.

Accounts with admin access they don't use

Admin and production-write permissions an account never exercises are blast radius you can cut without touching its job. Compare granted permissions with observed use and drop the excess, starting with accounts that can reach customer data. That shrinks the damage from every account you can't retire yet.

Service accounts people sign in to

Any service account with interactive sign-ins is being borrowed, so you can't attribute what it does. Find these accounts in your sign-in logs, give the people using them their own time-bound access, and then block interactive logon.

SaaS integrations with broad OAuth scopes

Integration accounts often keep every scope the installer requested, including write access the integration never uses. Compare granted scopes with the API calls the integration makes, and revoke tokens for integrations whose app is no longer in use. A stolen integration token reaches every record those scopes allow, which is how one vendor's breach becomes yours. The same scope check belongs in AI agent access management, since agents connect to SaaS apps through the same OAuth grants.

Unowned service accounts are the ones attackers find first

Non-human identity threats now move at machine speed: attackers use AI agents to hunt for credentials and test them faster than any human team can investigate. A quarterly spreadsheet review gives a dormant credential three months to be found and used.

Every control covered here rests on two questions: whether an account should exist, and who's accountable for it. Discovery across the directory, cloud, and SaaS tells you what you have. The two anchors decide what stays, and the four decisions settle the rest, from cutting unused access to giving engineers a fast path of their own. Delta reviews and the fix-first list keep those answers true as people, workloads, and agents change.

So go back to the opening question. Name the service account with admin rights to production, the workload it serves, and the person who answers for it. If that takes a week of spreadsheets and Slack threads, an attacker's agent can get there first.

Lumos keeps that answer current around the clock. It discovers service accounts in all three homes through more than 300 integrations, assigns a human owner to each NHI and AI agent it catalogs, and puts its agents to work shutting down dormant credentials and flagging access that accounts don't use. Albus runs alongside the IGA and ITSM tools you already use, so you can start with your riskiest service accounts without a rip-and-replace project. Book a demo to see how Lumos finds the service accounts that fail both anchors and gets each one owned, right-sized, or retired.

‍