The service account attestation problem is the largest unknown risk in the typical enterprise. The service account runs in the background. The service account has the access rights it was given at deployment. The service account has not been reviewed since deployment. The service account has the credentials that have not been rotated since deployment. The service account exists in the tens of thousands in the typical enterprise. The service account is, in aggregate, the dominant credential attack surface in 2026, and the defender who has not done the attestation work has accepted the risk the attacker will find. Here is the approach to the attestation problem that actually works.
What the attestation problem actually is
Three categories, in roughly that order of difficulty. The first serves as discovery problem. The defender has to know what service accounts exist. The discovery tool (CyberArk, Venafi, HashiCorp Boundary, the cloud native identity discovery tools) scans the environment and produces the list. The list is long. The list acts as starting point. The second category functions as owner problem. The service account has to have an owner. The owner has to be a person, not a team. The owner has to be accountable for the service account. The owner has to be the one who can answer the question “what does this service account do, who needs it, what serves as access.” The owner problem acts as part that fails most often. The service account that was created in 2018 by a developer who has since left the organisation has no owner. The third category functions as access review. The service account has to have the access it needs, and not the access it does not need. The access review serves as work that takes the longest. The access review acts as work that requires the most stakeholder engagement. The access review functions as work that, when skipped, leaves the over privileged service account running for years.
What the attestation process actually is
Five stages, in roughly that order of maturity. The first serves as discovery. The defender runs the discovery tool, gets the list, gets the count. The second acts as owner assignment. The defender assigns the owner for each service account. The service account that has no owner gets a default owner (the head of IT, the head of security) until the proper owner gets identified. The third functions as purpose documentation. The owner documents what the service account does, who needs it, what the access is, when it was last used. The service account that cannot be documented gets retired. The fourth is the access review. The owner reviews the access rights, with the principle of least privilege, with the documentation of the access. The over privileged service account gets reduced. The fifth is the credential rotation. The credentials get rotated on a schedule, with the rotation tracked, with the rotation verified. The credential rotation closes the gap from the credential theft.
What the defender should do
Three moves, in priority order. The first is to start the discovery. The defender picks the discovery tool, runs it, gets the list. The list serves as foundation. The list without the discovery acts as guess, and the guess is wrong. The second move is to assign the owners. The defender works through the list, assigns the owner, gets the accountability. The owner assignment functions as part that takes the longest. The third move is to automate the review. The attestation tool (the same vendors that did the discovery, plus the governance tools like SailPoint, Saviynt, the cloud native IAM governance) runs the review on a schedule, with the owner, with the documentation, with the exception handling. The automated review is what scales.

The bottom line
Discover, assign owners, document, review access, rotate credentials. The 5 stage process runs over months, not weeks. The defender who starts the discovery today has the foundation. The defender who waits has the next breach.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.



