Discovering All Privileged Accounts in Your Environment

You cannot protect what you cannot see. The first and most critical step in any Privileged Access Management programme is discovery — building a complete, accurate inventory of every account in your environment that holds elevated privileges. Most organisations that attempt this exercise are surprised by the result. The number is almost always higher than expected, often by a factor of three or more.

Privileged account discovery is not a one-time project. It is an ongoing discipline, because new privileged accounts are created regularly — through system deployments, application installations, cloud service provisioning, and even shadow IT.

Where Privileged Accounts Hide

The accounts your IT team knows about — the named Domain Admin accounts, the Global Administrator in Microsoft 365 — are only the visible portion. Beneath them lies a much larger population of privileged accounts that are often unmanaged and unmonitored.

Common hiding places for undiscovered privileged accounts include:

• Local administrator accounts — every Windows workstation ships with a built-in Administrator account. In many environments, these all share the same password.
• Service accounts — created for applications, scheduled tasks, and system integrations. They often have passwords that have not changed in years.
• Nested group memberships — a user who is a member of Group A, which is a member of Group B, which is a member of Domain Admins. The user effectively has Domain Admin rights, but it doesn’t appear that way at first glance.
• Cloud service principals and managed identities — non-human accounts in Azure, AWS, or GCP that can have sweeping permissions.
• Legacy system accounts — credentials embedded in old scripts, configuration files, or applications that nobody has touched in years but that still run nightly.
• Third-party vendor accounts — remote access accounts given to support providers, often with admin-level access and no expiry date.

The Discovery Process

Effective privileged account discovery combines automated scanning with manual investigation. Neither alone is sufficient.

Phase 1: Automated Scanning. Use built-in tools and, where available, PAM discovery tools to enumerate:

• Members of privileged Active Directory groups (Domain Admins, Enterprise Admins, Administrators, Account Operators, Backup Operators)
• Azure AD / Entra ID directory roles (Global Administrator, Privileged Role Administrator, Exchange Administrator)
• Local administrator group members on all endpoints
• Cloud IAM roles with elevated permissions (AWS root, IAM admin policies; Azure Subscription Owner/Contributor)

Phase 2: Manual Investigation. Automated tools miss accounts that don’t fit standard patterns. Investigate:

• Service accounts running scheduled tasks, Windows services, and application pools
• Credentials embedded in scripts, configuration files, and connection strings
• Third-party vendor and contractor accounts with remote access
• Accounts in legacy or standalone systems not connected to central directories

Phase 3: Classification. For each discovered privileged account, record:

• Account name and type (human admin, service account, emergency account)
• What system or resource it has access to
• Who owns it or is responsible for it
• Whether there is a current business justification for the access
• When the password was last changed
• Whether MFA is enabled (for human accounts)

Phase 4: Ongoing Monitoring. Discovery is not a one-time activity. Implement alerting for:

• New members added to privileged groups
• New service accounts created with elevated permissions
• New cloud IAM role assignments with administrative access

Tools for Discovery

You do not need to purchase an enterprise PAM product to begin discovery. Many free or built-in tools can provide immediate value:

• PowerShell + Active Directory module — enumerate privileged group members, service accounts, and accounts with non-expiring passwords
• Azure AD / Entra ID portal — review directory role assignments and privileged identity management status
• Microsoft LAPS (Local Administrator Password Solution) — identifies and manages local admin accounts on Windows endpoints
• BloodHound (open source) — maps Active Directory attack paths and reveals hidden privilege escalation routes
• Cloud-native tools — AWS IAM Access Analyzer, Azure Privileged Identity Management reports, GCP IAM Recommender

Why This Matters

You cannot manage risk you haven’t identified. Every unmanaged privileged account is an unmonitored door into your most sensitive systems. In post-breach forensics, one of the most common findings is that the compromised account “wasn’t on anyone’s radar” — it was a service account, a nested group member, or a forgotten vendor credential.

Regulators and auditors specifically look for evidence that you know what privileged accounts exist and that you review them regularly. “We didn’t know about that account” is not an acceptable response during an audit or investigation.

What to Do Now

• Run a basic discovery of all members of Domain Admins, Enterprise Admins, and Global Administrators — this week
• Ask IT to enumerate all service accounts and identify which ones have administrative privileges
• Check for local admin accounts on workstations — are they managed centrally or independently?
• Review third-party vendor accounts — do any have persistent admin access?
• Create a simple spreadsheet as your initial privileged account inventory if no tool is in place

Evidence to Collect

• A dated inventory of all known privileged accounts across on-premises and cloud environments
• Documentation showing the owner and business justification for each privileged account
• Evidence of nested group membership analysis (especially in Active Directory)
• Records of third-party vendor access review
• A plan for ongoing privileged account discovery (even if it is a manual quarterly review)

Common Mistakes

• Only counting human admin accounts. Service accounts, application identities, and cloud service principals often outnumber human admins and carry equal or greater risk.
• Trusting the directory alone. Active Directory group membership is a starting point, not a complete picture. Local admin accounts, cloud roles, and application-level admin access all live outside the directory.
• Treating discovery as a one-off project. Environments change constantly. A discovery exercise that is six months old is already incomplete.
• Not assigning ownership. Every privileged account must have a named human owner accountable for its existence and use. “IT” is not an owner — a named individual is.

---

Knowledge Check

---