Most PAM programmes stall in year one because the team buys a vault, onboards the Domain Admins it already knew about, and never finds the hundreds of privileged accounts, keys and service identities that attackers actually use. Discovery and onboarding are the unglamorous core of privileged access management: finding every account that can change security state, deciding who owns it, getting its credential under management without breaking the services that depend on it, and proving coverage. This guide sets out a practical first year: what counts as privileged, where to look, how to prioritise, how to onboard human and non-human accounts safely, and what to measure. It is for PAM leads, IAM engineers and infrastructure owners. For the overall model and capabilities, start with the Privileged Access Management Guide; this page goes deeper on the first year of delivery.
Key takeaways
- Define privileged by capability, not by name. An account is privileged if it can change identities, credentials, security policy or recovery capability, or read restricted data, whatever it is called and whether a person or a workload uses it.
- Discovery is continuous, not a project phase. Run it from directories, cloud control planes, endpoints, databases, SaaS and secrets stores on a schedule, and reconcile results against the vault every week.
- Onboard by risk wave, not by platform. Tier 0 and cloud control plane identities first, then credentials that unlock many systems, then breadth.
- Service accounts need dependency mapping before rotation. Rotating a credential that is hard-coded in 40 scheduled tasks is how PAM programmes lose the business's trust; map consumers first.
- Coverage is the headline metric. The share of discovered privileged accounts that are vaulted, rotated and monitored tells you more than the number of accounts in the vault.
What counts as a privileged account
NIST's National Cybersecurity Center of Excellence describes privileged accounts as including local and domain administrative accounts, emergency accounts, application management accounts and service accounts. Microsoft's Entra documentation defines a privileged permission as one that can delegate management of directory resources, modify credentials, authentication or authorisation policies, or access restricted data. Combine the two into a working definition and a classification you can apply to discovery results.
| Class | Examples | Typical location | Onboarding wave |
|---|---|---|---|
| Tier 0 directory and identity | Domain Admins, Enterprise Admins, Schema Admins, AD CS admins, Entra Global Administrator, Privileged Role Administrator, IdP super admins | AD, Entra ID, Okta and other IdPs | 1 |
| Cloud control plane | AWS root and IAM users with admin policies, Azure Owner and User Access Administrator, Google Cloud Organization Administrator | Cloud providers | 1 |
| Credentials that unlock many systems | Hypervisor and vCenter admins, backup admins, vault and PAM admins, CI/CD admins, EDR and MDM console admins | Infrastructure consoles | 1 to 2 |
| Local and built-in administrators | Windows built-in Administrator, root, network device enable accounts, database sa or postgres | Every endpoint, server, device and database | 2 |
| Privileged service accounts and NHIs | Service accounts in admin groups, cloud access keys with admin rights, SaaS admin API tokens, automation accounts | Directories, cloud IAM, code, pipelines, secrets stores | 2 to 3 |
| Application and business admins | ERP, HR and finance system admins, SaaS tenant admins | Business applications | 3 |
| Emergency accounts | Break-glass cloud and IdP accounts, DR accounts | IdP, cloud, AD | 1 (special handling) |
Where to look: discovery sources
No single tool sees everything. Combine sources and expect each one to find accounts the others miss.
| Source | What to collect | Specifics |
|---|---|---|
| Active Directory | Members of protected and privileged groups, nested membership, accounts with adminCount set, delegated ACLs, accounts with SPNs | Microsoft lists 15 protected accounts and groups covered by AdminSDHolder, including Account Operators, Backup Operators, Domain Admins, Enterprise Admins, Key Admins, Print Operators, Schema Admins and Server Operators. See the AdminSDHolder, SDProp and Protected Groups Guide. |
| Endpoints and servers | Local Administrators group membership on every server and workstation, expanded for nested domain groups; local accounts; scheduled tasks and services with their run-as accounts | Microsoft warns that large domain groups nested into local Administrators grant control of every system where they are nested. |
| Microsoft Entra ID | Assignments to roles marked PRIVILEGED, eligible and active PIM assignments, service principals with privileged roles or high-impact Graph permissions | The Roles and administrators page has a Privileged column and an Assignments count. Microsoft recommends fewer than five Global Administrators and fewer than ten privileged role assignments. |
| AWS | Root usage, IAM users with console passwords and access keys, policies granting administrative actions, cross-account roles | The IAM credential report (generated at most every four hours) lists password_last_used, mfa_active and access_key_1_last_used_date per user. It covers only the first two access keys, so use ListAccessKeys for completeness. See the IAM Access Analyzer Guide. |
| Azure and Google Cloud | Owner, Contributor and User Access Administrator assignments at management group and subscription scope; Google Cloud basic roles and service account keys | See the Cloud PAM and CIEM Guide. |
| Unix and Linux | sudoers entries, accounts with UID 0, SSH authorized_keys for root and service users | See the Unix and Linux Privileged Access Guide. |
| Databases and applications | DBA roles, built-in admin logins, application super users | Often outside directory control; request exports from application owners. |
| SaaS | Tenant admin roles and admin API tokens in each critical SaaS platform | See the SaaS API Token Security Guide. |
| Code, pipelines and files | Credentials in repositories, CI variables, scripts on file shares, configuration files | Secret scanning finds privileged credentials no directory knows about. See the Git Secret Scanning Guide. |
Attack path analysis: group membership alone misses indirect privilege. Accounts with rights to reset passwords, modify group membership or write to Tier 0 objects are effectively Tier 0. Graph-based tools reveal these paths; see the BloodHound and Active Directory Attack Path Guide. Microsoft's least privilege guidance also flags accounts able to modify attributes such as sAMAccountName and userAccountControl, which can enable certificate spoofing.
Triage and prioritisation
A first discovery run in a mid-sized organisation typically returns far more privileged accounts than anyone expected; Microsoft notes that Domain Admins and similar groups may hold dozens of members in midsized directories and hundreds or thousands in large ones. Triage each account on four questions before deciding what to do:
- Is it needed? Disable accounts with no use in 90 days after owner confirmation; remove standing membership of Enterprise Admins, which Microsoft says should have no day-to-day members.
- Who owns it? Assign a human owner. Accounts nobody claims after a deadline are disabled, with a documented recovery route.
- What does it unlock? Score by tier and by number of systems reachable.
- How is it used? Interactive human admin, shared team account, service or automation, emergency. The answer determines the onboarding pattern.
Removing accounts and privileges is often a bigger risk reduction than vaulting them. Do the clean-up before onboarding so the vault does not inherit the mess.
Onboarding patterns by account type
| Account type | Target state | Onboarding steps | Watch out for |
|---|---|---|---|
| Named human admin accounts | Separate admin account, phishing-resistant MFA, just-in-time elevation, sessions brokered for Tier 0 | Issue admin accounts, remove standing group membership, enable JIT, require use from privileged workstations | Admins keeping a "spare" standing account |
| Built-in and local admins | Unique per device, rotated, retrieved only through the vault or LAPS | Deploy Windows LAPS or vault-managed rotation; apply deny log-on rights Microsoft documents for the local Administrator (network, batch, service, Remote Desktop) | Same local password across the estate, enabling pass-the-hash |
| Shared team accounts | Eliminated, or vaulted with check-out, individual MFA and rotation after use | See the Shared and Generic Accounts Governance Guide | Vaulting without rotation, so everyone still knows the password |
| Privileged service accounts | Least privilege, managed credential (gMSA, vault rotation or workload identity), owner, monitoring | Map every consumer, remove from admin groups, migrate to gMSA where possible, then enable rotation | Rotation outages; Kerberoastable SPNs with old passwords (T1558.003) |
| Cloud keys and tokens | Replaced by roles, federation or short-lived credentials; remaining keys vaulted and rotated | Use last-used data to retire unused keys, then migrate pipelines to federation | Keys copied into many pipelines |
| Emergency accounts | Two or more, excluded from normal policies, credentials split and sealed, every use alerted | See the Break-Glass Account Guide | Vaulting break-glass inside the system it is meant to recover |
Safe service account onboarding
- Inventory consumers: services, scheduled tasks, IIS application pools, scripts, connection strings and third-party tools that use the account. Logon events (Event ID 4624 logon types 4 and 5 for batch and service) show where it authenticates.
- Reduce privilege first: remove the account from Domain Admins and other admin groups. Microsoft warns that running services under privileged groups can break them when deny-logon restrictions are applied, so test.
- Vault without rotation: store the current credential and verify the vault can log on with it (reconciliation).
- Rotate in a maintenance window: rotate, update every consumer through the PAM tool's dependency features or by script, and confirm services restart.
- Roll back if needed: the vault keeps the previous password version; restore it to the account and consumers, then fix the missed dependency before trying again.
- Move to a better credential: where possible, convert to a gMSA or workload identity so rotation is automatic. See the Group Managed Service Accounts (gMSA) Guide.
A first-year plan
| Quarter | Goals | Exit criteria |
|---|---|---|
| Q1: Foundations and Tier 0 | Privileged definition agreed; discovery from AD, Entra and main cloud accounts; PAM platform hardened; Tier 0 humans and break-glass onboarded | All Tier 0 human admins use vaulted or JIT access; Enterprise Admins empty; break-glass tested |
| Q2: Credentials that unlock many systems | Hypervisor, backup, vault, EDR, MDM and CI/CD admins onboarded; Windows LAPS deployed to servers; cloud root and admin IAM users controlled | Unique local admin passwords on all servers; no unused cloud admin keys |
| Q3: Service accounts and NHIs | Dependency mapping and rotation for privileged service accounts; secret scanning findings remediated; cloud keys migrated to roles or federation | Privileged service accounts owned, out of admin groups where possible, rotating |
| Q4: Breadth and business | Workstation LAPS, databases, network devices, critical SaaS admins and business application admins | Coverage metric above target; discovery and reconciliation run automatically |
Smaller organisations can compress this into two phases: Tier 0, cloud and backup admins in the first quarter, then everything else. A business password manager and native tools (LAPS, Entra PIM, cloud federation) can cover a lot before a full PAM suite is justified. Larger organisations should run discovery per business unit with a central definition and metrics, and treat the PAM platform itself as a Tier 0 system: the NCSC notes that a PAM service is an attractive target and must be architecturally restricted, patched, monitored and backed by a protected break-glass process.
Detection and measurement
- New privilege outside the process: alert on additions to privileged groups (Event IDs 4728, 4732 and 4756 for members added to security-enabled global, local and universal groups) and privileged role assignments in Entra and cloud audit logs. Microsoft recommends alerting on any change to Enterprise Admins, Domain Admins and Administrators membership (ATT&CK T1098 Account Manipulation).
- New privileged accounts: account creation followed by privileged group addition (T1136 Create Account).
- Use of vaulted credentials without check-out: logons by managed accounts that do not match a PAM session indicate a copied password.
- Discovery reconnaissance: bulk enumeration of privileged groups (T1069.002 Domain Groups, T1087.002 Domain Account) from unusual hosts.
- Drift: weekly reconciliation of discovery results against the vault, with new unmanaged privileged accounts raised as tickets.
| Metric | Definition | Year-one target |
|---|---|---|
| Privileged account coverage | Discovered privileged accounts that are vaulted or JIT-managed, divided by all discovered privileged accounts | 100% Tier 0, above 90% overall |
| Standing Tier 0 privilege | Accounts with permanent membership of Tier 0 groups or roles | Near zero beyond break-glass |
| Ownerless privileged accounts | Privileged accounts with no named owner | Zero |
| Rotation compliance | Managed credentials rotated within policy | Above 95% |
| Time to onboard a newly discovered privileged account | Discovery to managed | Under 30 days, under 7 for Tier 0 |
| Rotation-caused incidents | Outages caused by credential rotation | Falling each quarter |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2, AC-2(7) Privileged User Accounts, AC-6(5) Privileged Accounts, AC-6(7) Review of User Privileges | Inventory, role-based privileged accounts, review |
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management, AC-6(9) Log Use of Privileged Functions | Vaulting, rotation and logging |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, DE.CM-03 | Identity management, access policy, monitoring personnel activity |
| CIS Controls v8.1 | 5.1 Inventory of Accounts; 5.4 Dedicated Administrator Accounts; 5.5 Inventory of Service Accounts; 6.5 MFA for Administrative Access | Discovery and onboarding baseline |
| ISO/IEC 27001:2022 Annex A | A.8.2 Privileged access rights; A.5.18 Access rights | Allocation, restriction and review |
| MITRE ATT&CK v20 | T1078.002, T1078.003, T1078.004, T1558.003, T1098 | Techniques that exploit undiscovered privileged accounts |
Common failure patterns
- Onboarding what you already knew: the vault holds the Domain Admins but not the local admin passwords, cloud keys and service accounts that attackers find first.
- One-off discovery: a discovery scan in month one is never repeated, so new admin accounts accumulate outside the vault.
- Vault and forget: credentials stored but never rotated, so people who knew them before still do.
- Rotation without dependency mapping: outages from rotating service accounts lead the business to demand exemptions, and the exemptions become permanent.
- The PAM platform as a single point of compromise: PAM admins without PAWs or MFA, and vault backups stored in reachable shares. Microsoft points out that PAM systems hold credentials for most privileged roles.
- Credentials hiding in scripts: admin passwords in scripts on file shares bypass the vault entirely.
Lessons from incidents
- Scripts on shares: in the Uber breach of 2022 the attacker claimed to have found a PowerShell script with hard-coded admin credentials on an internal network share; Uber did not confirm this detail. Whether or not it happened as claimed, credentials in scripts are a standard discovery target and belong in year-one scanning.
- Accounts nobody turned off: the Colonial Pipeline ransomware attack began with a legacy VPN profile that was no longer used, never disabled and had no MFA. Dormancy checks in discovery catch exactly this.
Practitioner checklist
- Agree a written definition of privileged that covers people, service accounts, keys and tokens.
- Run discovery across AD, endpoints, IdPs, cloud, Unix, databases, SaaS and code, and repeat it weekly.
- Expand nested groups and attack paths, not just direct membership.
- Assign an owner to every privileged account and disable those nobody claims.
- Remove standing Tier 0 membership before onboarding; empty Enterprise Admins.
- Onboard in risk waves: Tier 0 and cloud control plane first.
- Map service account dependencies before enabling rotation, and keep a tested rollback.
- Deploy LAPS for unique local administrator passwords.
- Harden and monitor the PAM platform as a Tier 0 system.
- Report coverage, standing privilege, ownership and rotation compliance monthly.
Standards and references
- NIST NCCoE: Privileged Account Management (SP 1800-18)
- NCSC: Use privileged access management
- Microsoft: Implementing least-privilege administrative models
- Microsoft: Protected accounts and groups in Active Directory
- Microsoft: Privileged roles and permissions in Microsoft Entra ID
- AWS: Generate credential reports for your AWS account
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Privileged Access Management Guide · PAM Maturity Model · Service Account Security Guide · Privileged Access Workstations Guide · JIT Access Guide