Most teams have a number for this. It usually comes from a spreadsheet that was accurate the day someone built it, but the real number has been climbing ever since. New servers get built, vendors create accounts during installs, and people get added to admin groups during an outage and never taken back out. Here are four steps to get a number you can trust.
What's inside
Settle on a definition before you scan anything.
The test we use: if someone holding that account can change security settings, reach data outside their own responsibilities, or create and modify other accounts, it counts as privileged.
If someone holding that account can change security settings, reach data outside their own responsibilities, or create and modify other accounts, it counts as privileged. Write it down and use the same definition every time you count.
Tier 0
Anything that can control your identity systems: domain admins, enterprise admins, the global admins in your identity provider, and the PAM platform itself.
Tier 1
Server and database admins, along with the local administrator accounts on those servers.
Tier 2
Workstation admins and help desk accounts.
Everything else
Service accounts, cloud admin roles, and network device logins land in whichever tier matches what they can reach.
Open Domain Admins and you might see 12 names, but those are only the direct members.
If someone nested a group like IT-Infrastructure inside it, every member of that group is a domain admin too, and that nesting can run several layers deep. I've seen a 12-name group turn into over 60 domain admins once you expand everything underneath it.
Pull the full recursive membership of each privileged group, and don't stop at Domain Admins. Administrators, Account Operators, Backup Operators, and Schema Admins all deserve the same treatment.
Direct membership understates the real count. Expand nested groups recursively before you write the number down.
Active Directory doesn't know anything about local accounts.
Your PAM solution should have a reliable discovery tool, or there are many third-party options that can help you have greater visibility on your privileged account estate. The discovery should scan your Windows and Unix machines for local administrator accounts, along with the service accounts running Windows services, scheduled tasks, and IIS app pools.
This is usually where the built-in local Administrator account turns up with the same password on a few hundred machines. An attacker who gets that credential from one server can log into the rest with it, and once they're local admin on a server, they can start harvesting whatever credentials are cached there.
Local administrators
Local administrator accounts on Windows and Unix machines
Windows services
The service accounts running installed Windows services
Scheduled tasks
Accounts that tasks run as, often undocumented
IIS app pools
Identity each application pool is configured to run as
Your cloud platforms keep their own admins, and they rarely show up in an AD report.
AWS IAM users and roles with AdministratorAccess, and Azure accounts holding Global Administrator or Owner on a subscription.
Don't forget the root user on each AWS account. It can do anything in that account, IAM policies can't restrict it, and it's usually the one credential nobody has touched since the account was set up.
sa on SQL Server, and SYS and SYSTEM on Oracle.
Routers, switches, and firewalls carry admin logins that often don't appear in identity reports at all — and one admin login is frequently shared by the whole team.
Build one inventory with a tier classification and an owner for every account you found, then check it against the vault.
Anything in the inventory that isn't in the vault goes on the onboarding list, with Tier 0 at the top. If you can't say how many privileged accounts you have right now, please reach out; a discovery scan is one of the first things we run in a risk assessment.