Most privileged access management programmes fail not because the vault is weak but because privilege keeps leaking around it: standing admin rights, credentials in scripts, shared local passwords and service accounts nobody onboarded. Attackers who reach a privileged account rarely need anything else, so a PAM tool that covers only half the privileged accounts gives a false sense of control. This page ranks the ten PAM mistakes we see most often, with what goes wrong, an incident where it played a part, how to detect it and the fix. It is for identity, infrastructure and security operations teams running or rescuing a PAM programme, and for leaders deciding where the next budget goes. For a staged view of capability, use the PAM Maturity Model; this page is the list of what most often goes wrong on the way.
The Top 10 at a glance
- Standing privileged access instead of just-in-time
- Too many privileged accounts and over-broad roles
- Onboarding only the privileged accounts you already know about
- Privileged credentials hard-coded in scripts and files
- Shared or identical local administrator passwords
- Phishable MFA, or none, on privileged access
- Administering from everyday workstations
- Not treating the PAM platform itself as tier 0
- Not rotating credentials after an incident
- Break-glass accounts that are untested or unmonitored
| # | Mistake | How attackers use it | First fix |
|---|---|---|---|
| 1 | Standing privilege | Any compromised admin session has full rights immediately | Eligible, time-bound, approved activation |
| 2 | Too many admins | More accounts to phish, spray or socially engineer | Reduce counts, use scoped roles |
| 3 | Partial discovery | Target the unvaulted accounts, especially service accounts | Continuous discovery across directory, cloud and SaaS |
| 4 | Hard-coded credentials | Search file shares and repositories for admin passwords | Retrieve secrets at run time; scan for leaks |
| 5 | Shared local admin passwords | Pass the hash across every machine with the same password | Unique, rotated local passwords (LAPS) |
| 6 | Phishable admin MFA | Push fatigue, help desk resets, adversary-in-the-middle | Phishing-resistant MFA for all privileged roles |
| 7 | Admin from daily devices | Infostealer or phishing on the admin's laptop takes the session | Privileged access workstations or hardened admin paths |
| 8 | PAM platform not tier 0 | Compromise the PAM tool or its API keys to reach everything | Protect, monitor and scope the PAM platform itself |
| 9 | No rotation after incidents | Reuse credentials taken in an earlier breach | Rotate everything the attacker could have seen |
| 10 | Neglected break-glass | Unmonitored super-admin accounts, or lock-out during a crisis | Two tested, monitored emergency accounts |
1. Standing privileged access instead of just-in-time
The mistake: administrators hold permanent admin rights in the directory, cloud and SaaS consoles, used for a few minutes a week and exposed every hour of every day.
Why it matters: a phished session, stolen token or infostealer log is immediately an admin compromise. NIST SP 800-53 AC-6(5) restricts privileged accounts to defined personnel and roles, and AC-2(2) covers automatic removal of temporary and emergency accounts. Microsoft's guidance for Entra roles is to grant just-in-time access through Privileged Identity Management (PIM), where an "eligible" assignment has to be activated (with MFA, justification or approval) for a limited period, as opposed to an "active" assignment that is always on.
The fix: convert standing assignments to eligible ones for every tier 0 and tier 1 role, set activation windows in hours, require approval for the most powerful roles, and alert on any new permanent active assignment. Keep a short, documented list of exceptions (break-glass accounts, some automation). Equivalent just-in-time features exist in most PAM platforms and cloud providers; the principle, zero standing privilege for humans, is the same.
2. Too many privileged accounts and over-broad roles
The mistake: the highest roles (Domain Admins, Global Administrator, cloud organisation owner) are handed out because they are easy, and nobody removes them.
Why it matters: every extra privileged account is another target for password spray, phishing and help desk social engineering. Microsoft recommends assigning Global Administrator to fewer than five people and keeping privileged role assignments below ten, and shows an alert card in the Entra admin center when the Global Administrator count reaches five or more. NIST SP 800-53 AC-6(7) requires periodic review of user privileges.
The fix: count privileged accounts per platform and publish the number. Replace top-level roles with scoped built-in or custom roles (for example, a help desk role limited to one administrative unit or organisational unit), and run quarterly access reviews on every privileged role, with removal as the default when nobody justifies the access. See the Least Privilege Techniques Guide.
3. Onboarding only the privileged accounts you already know about
The mistake: the PAM project vaults the domain admins and the root accounts on day one and stalls there. Service accounts, cloud access keys, SaaS admin accounts, database accounts, network device logins and CI/CD credentials stay outside.
Why it matters: attackers go where the controls are not. Privileged non-human identities usually outnumber privileged humans, cannot use MFA, and often hold standing access to production. ATT&CK tracks the use of valid domain, local and cloud accounts as T1078.002, T1078.003 and T1078.004, and Kerberoasting of service account credentials as T1558.003.
The fix: run discovery continuously, not once: directory group memberships, local administrators groups, cloud IAM role bindings, SaaS admin roles, database grants and secrets in code. Give every privileged account an owner and an onboarding status, and track the percentage onboarded as the programme's headline metric. See the Privileged Account Discovery and Onboarding Guide and the Service Account Security Guide.
4. Privileged credentials hard-coded in scripts and files
The mistake: automation scripts, scheduled tasks, configuration files and repositories hold admin passwords in plain text, sometimes including the credentials for the PAM platform itself.
Why it matters: an attacker inside the network searches file shares first. In the Uber breach of 2022, the attacker claimed to have found a PowerShell script with hard-coded admin credentials on an internal share; Uber did not confirm that detail, but it is the pattern defenders find most often. ATT&CK tracks this as T1552.001 (Unsecured Credentials: Credentials In Files), and NIST SP 800-53 IA-5(7) prohibits embedded unencrypted static authenticators in applications and scripts.
The fix: scripts retrieve credentials from the vault or secrets manager at run time under their own scoped identity; better still, use managed identities or workload identity federation so there is no secret to store. Scan file shares, repositories and CI logs for credentials, and treat every hit on a privileged credential as an incident: rotate, then find out who could read it. See the Secrets Management Guide.
5. Shared or identical local administrator passwords
The mistake: the built-in local administrator account has the same password on every workstation or server, set in a gold image years ago.
Why it matters: one credential dump (ATT&CK T1003) on one machine gives access to all of them through pass the hash (T1550.002). Microsoft's documentation for Windows LAPS describes exactly this: local administrator accounts often share the same password across devices, which attackers exploit to move laterally.
The fix: deploy Windows LAPS, which rotates each device's local administrator password and backs it up to Microsoft Entra ID or Active Directory (one or the other, not both), with password encryption and history available in Active Directory. Legacy LAPS emulation mode stores passwords in clear text in Active Directory, so treat it as a temporary step. Restrict who can read LAPS passwords, alert on reads, and enforce rotation after use. Apply the same principle to Linux root, network devices and hypervisors. See the Local Administrator Password Solution (LAPS) Guide.
6. Phishable MFA, or none, on privileged access
The mistake: administrators sign in to the PAM portal, cloud consoles and remote access with push notifications, one-time codes or SMS, and the help desk can reset an admin's MFA over the phone.
Why it matters: attackers target admins with push bombing (ATT&CK T1621), adversary-in-the-middle phishing and help desk impersonation. In the MGM Resorts breach, by the attackers' own account, a call to the IT help desk impersonating an employee led to administrator access to Okta and Azure. NIST SP 800-53 IA-2(1) requires MFA for privileged accounts; phishing resistance is what makes it hold against current attacks.
The fix: require phishing-resistant methods (FIDO2 security keys, device-bound passkeys, Windows Hello for Business or certificate-based authentication) for every privileged role and for PAM activation, enforced through policy rather than user choice. Make admin MFA resets a high-assurance process with identity verification and a second approver. See the Hardware Security Keys Guide and the Top 10 MFA Mistakes.
7. Administering from everyday workstations
The mistake: admins check email, browse the web and run privileged sessions from the same laptop, often with the same account.
Why it matters: malware on that laptop can capture credentials and session tokens or ride the live session, bypassing the vault and MFA entirely. NIST SP 800-53 AC-6(2) requires privileged users to use non-privileged accounts for non-security functions.
The fix: separate admin accounts from daily accounts, and run tier 0 administration from privileged access workstations or a hardened jump path with no email or general browsing. Block privileged accounts from signing in to standard workstations, and do not let higher-tier credentials touch lower-tier machines. See the Privileged Access Workstations Guide.
8. Not treating the PAM platform itself as tier 0
The mistake: the PAM platform, remote support tool or jump server is managed like any other application: broad API keys, ordinary admin accounts, internet-facing components patched on the normal cycle, and nobody watching its own logs.
Why it matters: whoever controls the PAM platform controls everything it protects. In the BeyondTrust breach of December 2024, a stolen API key for the Remote Support SaaS infrastructure, able to reset passwords for local application accounts, was used to reach US Treasury Departmental Offices workstations, which Treasury classed as a major incident. Remote access and PAM vendors are tier 0 suppliers.
The fix: protect the PAM platform as tier 0: dedicated admin accounts with phishing-resistant MFA, scoped and expiring API keys, network restrictions on management interfaces, emergency patching for its components, and its own logs sent to a SIEM it cannot alter. Ask SaaS PAM vendors how they protect your tenant's keys. See Remote access and PAM vendors as tier-zero suppliers.
9. Not rotating credentials after an incident
The mistake: after a breach at your organisation or a supplier, the team rotates the credentials it knows were stolen and leaves the rest.
Why it matters: in the Cloudflare breach of November 2023, a nation-state attacker used credentials stolen in the earlier Okta support system breach that had not been rotated: Cloudflare had rotated thousands of exposed credentials but left one service token and three service account credentials because it mistakenly believed they were unused. The attacker needed only those four.
The fix: after any compromise, rotate every credential the attacker could have seen, not only those you can prove were taken, and track rotation to 100% with an owner per credential. Automated rotation through the PAM platform makes this a job of hours, not weeks. See Credential Rotation at Scale.
10. Break-glass accounts that are untested or unmonitored
The mistake: emergency accounts either do not exist, are synchronised from the same on-premises directory that might be down, share the admins' normal MFA, or sit unmonitored with a password in a safe nobody has opened in years.
Why it matters: break-glass accounts are the most powerful accounts you have and the least used, so misuse is easy to miss and a lock-out during an outage is costly. Microsoft recommends two or more cloud-only emergency access accounts on the onmicrosoft.com domain, not federated or synchronised, protected by phishing-resistant methods that differ from normal admin accounts, excluded from Conditional Access policies that block sign-in, monitored with alerts on every sign-in, and validated at least every 90 days.
The fix: follow that pattern on every critical platform, not just your identity provider, store credentials in physically separate secure locations, and test quarterly as a drill with the authorised-user list reviewed each time. See the Break-Glass Account Guide.
Detecting PAM failures
| Signal | Example source | Mistakes it catches |
|---|---|---|
| Member added to a privileged group (Windows events 4728, 4732, 4756) | Domain controller security logs | 1, 2, 3 |
| Special privileges assigned at logon (event 4672) for an account not in the PAM inventory | Windows security logs | 3 |
| New permanent active privileged role assignment | Entra or cloud provider audit logs | 1, 2 |
| Privileged sign-in from a non-PAW device or new location | Identity provider sign-in logs | 6, 7 |
| Vault checkout or LAPS password read outside a ticket | PAM and directory audit logs | 5, 8 |
| Credential hit in a file share, repository or CI log | Secret scanning | 4 |
| Any break-glass sign-in | Identity provider sign-in logs | 10 |
| PAM platform admin or API key change | PAM platform logs forwarded to SIEM | 8 |
Track five numbers monthly: percentage of discovered privileged accounts onboarded (human and non-human), number of standing privileged assignments (trend to near zero), privileged accounts on phishing-resistant MFA (target 100%), devices with unique managed local admin passwords (target 100%), and days since the last successful break-glass test (under 90). NIST SP 800-53 AC-6(9) requires logging the use of privileged functions, which is the raw material for all of these.
Mapping to OWASP
PAM is mostly an infrastructure discipline, so the OWASP mapping is narrow: privileged non-human identities are covered by the OWASP Non-Human Identities Top 10, and the rest maps better to NIST and ATT&CK.
| Mistake | OWASP NHI Top 10 (2025) | MITRE ATT&CK v20 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| 1. Standing privilege | Not applicable | T1078.002, T1078.004 | AC-6(5), AC-2(2) |
| 2. Too many admins | NHI5 Overprivileged NHI | T1098 | AC-6(7), AC-2(7) |
| 3. Partial discovery | NHI1 Improper Offboarding, NHI5 | T1078.002, T1558.003 | AC-2 |
| 4. Hard-coded credentials | NHI2 Secret Leakage | T1552.001 | IA-5(7) |
| 5. Shared local admin passwords | Not applicable | T1003, T1550.002, T1078.003 | IA-5 |
| 6. Phishable admin MFA | Not applicable | T1621 | IA-2(1) |
| 7. Admin from daily devices | Not applicable | T1078.002 | AC-6(2) |
| 8. PAM platform not tier 0 | NHI3 Vulnerable Third-Party NHI | T1078.004 | AC-6(5), SC-7 |
| 9. No rotation after incidents | NHI7 Long-Lived Secrets | T1078 | IA-5 |
| 10. Neglected break-glass | Not applicable | T1078.004 | AC-2(2), AC-6(9) |
In NIST CSF 2.0, the programme sits mainly under PR.AA-05 (access permissions follow least privilege and are reviewed) and PR.AA-01 (identities and credentials, including for services, are managed). See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide for the non-human side.
Where to start
If you can do only three things this quarter: put phishing-resistant MFA on every privileged role and harden admin MFA resets (mistake 6); run a full discovery pass and publish the onboarded percentage, including service accounts (mistake 3); and deploy LAPS or its equivalent everywhere (mistake 5). Then convert standing assignments to just-in-time (mistake 1) and move tier 0 administration onto privileged access workstations (mistake 7).
Small organisations can get far with built-in features: separate admin accounts, PIM-style just-in-time roles from their identity provider, LAPS, security keys for admins and two tested break-glass accounts, before buying a dedicated PAM platform. Larger organisations need continuous discovery, session management for high-risk systems, automated rotation and secrets management for non-human accounts, and should treat the PAM platform as a tier 0 system with its own threat model. If you are selecting a platform, see the PAM RFP Template.
Practitioner checklist
- Inventory every privileged account across directory, cloud, SaaS, databases, network devices and CI/CD, with an owner each.
- Convert permanent privileged role assignments to eligible, time-bound activation with MFA and justification.
- Reduce Global Administrator and Domain Admins membership to the minimum and review privileged roles quarterly.
- Require phishing-resistant MFA for all privileged roles and for PAM activation.
- Deploy LAPS or equivalent unique, rotated local admin passwords on all endpoints and servers.
- Scan file shares, repositories and CI logs for privileged credentials and move them to the vault.
- Separate admin and daily accounts; run tier 0 administration from hardened workstations.
- Protect the PAM platform as tier 0: scoped API keys, network restrictions, emergency patching and external logging.
- Keep a post-incident rotation runbook that covers every credential an attacker could have seen.
- Maintain two monitored, cloud-only break-glass accounts and test them at least every 90 days.
Standards and references
- NIST: SP 800-53 Rev. 5
- Microsoft Learn: Best practices for Microsoft Entra roles
- Microsoft Learn: What is Microsoft Entra Privileged Identity Management?
- Microsoft Learn: Manage emergency access admin accounts
- Microsoft Learn: Windows LAPS overview
- MITRE ATT&CK: Valid Accounts
- MITRE ATT&CK: Unsecured Credentials: Credentials In Files
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: PAM Maturity Model · Privileged Remote Access Buyers Guide · Vendor Privileged Access Management (VPAM) Guide · Unix and Linux Privileged Access Guide