The Accounts Your Access Review Never Sees

Key Takeaways
Service accounts run much of the business yet often hold more privilege than any executive or administrator.
Machine identities now outnumber human ones many times over, far beyond what access reviews were built for.
They are an attacker’s ideal target: high privilege, no MFA, passwords that rarely change, and credentials sitting in scripts.
Reviews that cover only human access certify half the estate, leaving a real assurance gap auditors and boards never see.
Dormant or orphaned service accounts get rubber-stamped each cycle because no one owns them or dares switch them off.
Fix it with four moves: inventory non-human identities, assign named owners, ask usage and privilege questions, and block new orphans at creation.
Service accounts often hold the most powerful access in the enterprise, yet they sit outside the review that tells your auditors, and your board, that access is under control.
Every quarter, your organisation certifies that access is under control. Managers sign off, evidence is filed, and the auditor ticks the box. But one category of account is routinely left out of that exercise, and it happens to be the category attackers go after first.
These are service accounts: the non-human identities used by applications, scheduled jobs, databases, integrations and bots. Nobody logs in with them in the morning, and nobody thinks about them during the day. They quietly run a large part of the business, and they frequently hold more privilege than any executive or administrator in the company. Depending on how they are counted, recent studies put machine identities at anywhere from 17 to 109 for every human one [1][2]. Either way, they dwarf the population your review was designed for.

Why this belongs on the board agenda
It is an attacker’s ideal target. A service account typically has high privilege, no multi-factor authentication (a machine cannot answer an OTP), a password that rarely changes, and credentials sitting in scripts or configuration files. No human is behind it to notice anything unusual. Attackers know this, which is why service accounts are so often used to move sideways through a network and to stay inside it, unnoticed, for a long time.
Identity is where the pressure is. In CyberArk’s 2026 survey of 2,930 security leaders, nine in ten organisations reported a successful identity-related breach in the previous twelve months [1]. And in the 2026 IBM and Ponemon study of 602 breaches, it took organisations an average of 247 days to identify and contain a breach [3]. An account that nobody watches is well placed to stay unnoticed for that long.
[[Quote]]
It is an assurance gap. Ask your team whether all privileged access was reviewed last quarter. In many organisations the accurate answer is: all privileged human access. On paper the control looks complete, and the evidence folder looks complete. In reality, a whole population of powerful accounts never came under review. The gap does not show up in the evidence folder, but it is very real. When leadership tells the audit committee, a regulator or a customer that access is reviewed, it is relying on a statement that is only half true.
It is a risk you cannot fix by simply switching things off. The reviewer who finally looks at an account called svc_batch_01 has no documentation and no owner to ask, and no one wants to be the person who brought down a production job on a Friday evening. So the account is approved, review after review, not because anyone checked it, but because everyone was afraid to touch it.
Why service accounts keep slipping through
Access reviews were designed around people: pull a list of users, map each one to a manager, and ask the manager to certify. Non-human accounts break every assumption in that design.

What good looks like: four moves
- Put non-human identities in scope, and inventory them. You cannot review what you have not listed. Look for directory accounts that never log in interactively, accounts whose passwords never expire, accounts carrying service principal names, and the cloud IAM roles, API keys and tokens that rarely come near a normal review.
- Make ownership non-negotiable. Every service account gets a named person or team who answers for it at review time. An orphan account should not be allowed to exist, and if nobody is willing to own it, that is a strong signal it should not be there at all.
- Ask different questions. For a person, the question is whether they still need the access. For a service account, ask: is it still being used or has it gone dormant, why does it hold this level of privilege, when was its credential last rotated and where is it stored, and should interactive logon be blocked altogether?
- Fix it at the source. No service account is created without a named owner, a stated purpose and an end date or review date. Cleaning up is hard, but stopping new orphans from being created is cheap.
Five questions to put to your CISO
- How many non-human accounts do we have, and how many of them have a named owner?
- How many hold domain admin, database admin or standing access to production?
- When were their credentials last rotated, and where are those credentials stored?
- Were these accounts in scope of the last access review our auditors saw? If not, what did we tell them?
- If one of them were abused tonight, how quickly would we know?
The bottom line
An access review that covers only people certifies half the estate, and usually not the riskier half. The question for leadership is not whether the review was completed on time. It is whether the review included the accounts that nobody ever logs in with. Those are the ones to look at the hardest.
Sources and notes
[1] CyberArk, 2026 Identity Security Landscape. Survey of 2,930 global cybersecurity leaders. https://www.paloaltonetworks.com/idira/identity-security-landscape-report
[2] Veza, 2026 State of Identity & Access Report, released 11 December 2025. Analysis of millions of identities across large enterprises. https://veza.com/company/press-room/veza-identity-access-research-report-reveals-identity-permissions-sprawl-has-reached-critical-levels-amid-explosion-of-machine-and-ai-agent-identities-across-the-enterprise/
[3] IBM and Ponemon Institute, Cost of a Data Breach Report 2026. 602 breaches across 17 industries, March 2025 to February 2026. https://www.ibm.com/reports/data-breach (figures as summarised at https://www.bakerdonelson.com/ten-takeaways-from-ibms-2026-cost-of-a-data-breach-report)
Veza and CyberArk are identity-security vendors, and their figures come from their own customer data and surveys. Definitions differ between studies (for example, CyberArk’s count includes AI agents), which is why the machine-to-human ratio is shown as a range. Treat these as indicative of the scale of the problem, not as a measure of any single organisation.
Keep Reading
.webp)

















