Join our Newsletter — 33% off our NHI Course
Home› Guides› PAM Maturity Model: Assessing Privileged Access Management Maturity
Maturity Model Privileged Access (PAM)

PAM Maturity Model: Assessing Privileged Access Management Maturity

← All guides
By Lalit Choda, NHI Mgmt Group Updated 18 October 2026 15 min read
On this page

Most organisations own a privileged access management tool, yet attackers still find standing domain admins, shared root passwords and service accounts with rights nobody can explain. Buying a vault is not the same as being mature: Microsoft's privileged access strategy states that "There is no single 'silver bullet' technical solution that will magically mitigate privileged access risk." This model scores PAM maturity across eight dimensions on the five-level Ad hoc to Optimised scale used by the NHI Mgmt Group NHI Governance Maturity Model, aligns it with CISA's Zero Trust Maturity Model, NIST SP 800-53, CIS Controls v8.1 and NIST CSF 2.0, and shows what cyber insurers ask about privileged access. It is for CISOs, PAM programme owners and infrastructure leads who need an honest baseline and a staged roadmap. For maturity across all identity types, use the Identity Security Maturity Model; this page goes deeper on privileged access only.

Key takeaways

  • Score eight dimensions separately: discovery and inventory, standing privilege and just-in-time access, credential vaulting and rotation, privileged authentication, access pathways and tiering, session control and monitoring, privileged non-human identities, and governance and review.
  • Standing privilege is the clearest single indicator. Count the accounts that hold administrative rights right now without asking for them; mature programmes drive that number towards break-glass accounts only.
  • Level 3 (Defined) is the right first target: a complete privileged account inventory with owners, dedicated admin accounts with phishing-resistant MFA, just-in-time elevation for the most powerful roles and recorded Tier 0 sessions.
  • Non-human privilege is where most programmes stall. Service accounts, automation and AI agents often hold more standing rights than the humans the PAM programme was built for.
  • Insurers ask concrete questions. Published ransomware supplemental applications ask how privileged accounts are secured, whether admins have separate accounts and how many people hold persistent privileged access; answer from evidence, not intent.

The five levels

LevelNameDescription
1Ad hocAdministrative rights are granted on request and rarely removed. Shared and default admin passwords are common, administrators use one account for email and administration, there is no inventory of privileged accounts and nobody can say who changed what on a server.
2DevelopingA PAM vault holds some shared administrator passwords and some IT staff have separate admin accounts. MFA protects remote access and a few consoles. Domain admin membership is reviewed once a year. Service account passwords are mostly unmanaged.
3DefinedEvery privileged account (human, service, local, cloud and SaaS) is inventoried with an owner and a tier. Admins use dedicated accounts with phishing-resistant MFA, the most powerful roles use just-in-time elevation, shared and break-glass credentials rotate after use, Tier 0 administration runs from privileged access workstations and Tier 0 and third-party sessions are recorded.
4ManagedJust-in-time elevation with approval covers most administrative roles on premises, in cloud platforms and in SaaS. Privileged non-human identities use managed identities or vaulted, automatically rotated secrets. Privileged sessions are brokered and monitored centrally, detections for privileged misuse run in the SOC and metrics are reported monthly.
5OptimisedZero standing privilege is the default for people and workloads. Elevation is per task and context aware, discovery feeds the inventory continuously, high-confidence detections revoke sessions and rotate credentials automatically, and control evidence is produced from the platform for auditors and insurers.

The eight dimensions

Levels 2 and 4 sit between the descriptions shown; the roadmap below lists what moves you from each level to the next.

DimensionLevel 1 Ad hocLevel 3 DefinedLevel 5 Optimised
Discovery and inventoryNo list of who holds admin rightsInventory of privileged accounts across directory, servers, databases, network, cloud and SaaS, each with owner, tier and purposeContinuous discovery of new privileged accounts, roles and permission paths; unknown privilege raises an alert
Standing privilege and just-in-time accessPermanent membership of every admin groupHighest-impact roles (Domain Admins, Global Administrator, cloud owner roles) eligible only, activated just in time with MFA and justificationNo standing privilege outside break-glass; elevation scoped to the task and resource and expires automatically
Credential vaulting and rotationShared passwords in spreadsheets; same local admin password everywhereShared, break-glass and local admin credentials vaulted or managed by Windows LAPS; rotation after use and on staff departureCredentials issued per session and never seen by the administrator; static privileged passwords rare
Privileged authenticationPasswords only, or MFA on VPN onlyPhishing-resistant MFA for every privileged account; legacy authentication blocked for adminsContinuous validation of the admin, device and session, not just at sign-in
Access pathways and tieringAdmins work from everyday laptops and browse while privilegedDedicated admin accounts (CIS Safeguard 5.4); Tier 0 managed only from privileged access workstations; admin interfaces not reachable from user networksAll privileged access passes through a few hardened, monitored pathways; lateral paths to Tier 0 measured and closed
Session control and monitoringNo record of privileged activityTier 0 and third-party sessions brokered and recorded; use of privileged functions logged (NIST AC-6(9))Behavioural detections on privileged sessions; automated session termination and credential rotation on high-confidence alerts
Privileged non-human identitiesService accounts in Domain Admins with passwords that never changePrivileged service accounts inventoried with owners; gMSA or vaulted, rotated secrets; no interactive logonWorkloads, pipelines and AI agents use short-lived, scoped credentials issued at runtime
Governance and reviewNo PAM policy; reviews only when auditors askPAM policy and standard; quarterly review of privileged role holders that removes access; break-glass testedEvent-driven reviews when roles, risk or behaviour change; outcome metrics reported to the board

How this model relates to other frameworks

The five levels align with, but do not replace, the frameworks auditors and regulators use. CISA's Zero Trust Maturity Model describes the Identity pillar's access management function moving from access that "expires with automated review" (Initial) to the Optimal stage, where the enterprise "uses automation to authorize just-in-time and just-enough access tailored to individual actions and individual resource needs". Its automation function is telling for PAM: at the Initial and Advanced stages the enterprise still "manually orchestrates privileged user identities". NIST CSF 2.0 Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe how rigorously risk is governed rather than how strong the controls are, and NIST says they "should complement an organization's cybersecurity risk management methodology rather than replace it". NIST SP 800-207 adds the principle behind just-in-time access: no implicit trust is granted to user accounts based on network location or ownership.

DimensionNIST SP 800-53 Rev. 5CIS Controls v8.1CISA ZTMM identity functionNCSC secure system administration
Discovery and inventoryAC-2(7) Privileged User Accounts5.1, 5.5, 6.6Visibility and AnalyticsUse privileged access management
Standing privilege and JITAC-6(5) Privileged Accounts; AC-2(2) Automated Temporary and Emergency Account Management6.8Access ManagementUse privileged access management
Vaulting and rotationAC-2(9) Restrictions on Use of Shared and Group Accounts; AC-2 item k5.2Identity StoresProtect your administration interfaces
Privileged authenticationIA-2(1) Multi-factor Authentication to Privileged Accounts; AC-17(4) Privileged Commands and Access6.5AuthenticationProtect your administration interfaces
Pathways and tieringAC-6(2) Non-privileged Access for Nonsecurity Functions; AC-6(3)5.4Access ManagementGain trust in your management devices; Risk manage administration using tiers
Session control and monitoringAC-6(9) Log Use of Privileged Functions; AC-2(12)Not covered in Controls 5 and 6Visibility and AnalyticsLog and audit administration activities
Privileged NHIsAC-6(5); AC-2 item a5.5Automation and OrchestrationUse privileged access management
Governance and reviewAC-6(7) Review of User Privileges; AC-2 item j5.1, 6.8GovernanceRisk manage administration using tiers

As a rough guide, Level 1 resembles the ZTMM Traditional stage and CSF Tier 1, Level 2 the Initial stage and Tier 2, Levels 3 and 4 the Advanced stage and Tier 3, and Level 5 the Optimal stage and Tier 4. That alignment is NHI Mgmt Group's judgement, not an official crosswalk. Microsoft's Rapid Modernization Plan (RAMP) for privileged access is a useful Level 2 to Level 3 sequence for Microsoft estates: it "prioritizes stopping the accumulation of new security risks first", starting with emergency access accounts, just-in-time roles through Entra Privileged Identity Management, separate admin accounts and admin workstations.

PAM maturity for cyber insurance

Insurers assess privileged access before they quote, and some publish their application forms. The Corvus Insurance ransomware supplemental application asks "How are privileged accounts secured and managed?" and defines privileged accounts as those with administrator permissions, which "commonly includes local administrator, domain administrator, and service accounts". Its answer options include separate administrative accounts, no admin rights for standard users, unique local administrator passwords, a password vault and "MFA required for internal use of privileged accounts". The Admiral ransomware supplemental application (form 182APP0323) asks about MFA for "Administrator and privileged user accounts", whether workstations are prohibited from local admin rights, whether privileged accounts are managed with tooling, "How many users have persistent privileged accounts for endpoints" and what compensating controls protect them.

What insurers askLevel that answers yes with evidenceEvidence to keep
Separate admin and day-to-day accounts3Export of admin accounts mapped to owners; no mailbox on admin accounts
MFA for privileged accounts, including internal use3Sign-in logs showing MFA method for every privileged sign-in, internal RDP included
No local admin rights for standard users; unique local admin passwords3Endpoint group membership report; LAPS coverage report
Privileged accounts managed in a vault or PAM tool2 to 3Vault onboarding coverage against the privileged inventory, not just a licence
Number of persistent privileged accounts and compensating controls4Monthly count of standing privileged accounts; JIT activation logs
Rapid account termination for leavers3Measured time from HR leave date to privileged access removed

Two warnings from the NCSC's cyber insurance guidance apply. First, "Do not limit yourself to meeting the minimum cyber security requirements specified by an insurer", since an insurer's minimum may not protect what matters to you. Second, "If you're claiming that security measures are in place when they're not, the insurer may not be obliged to pay any claims". Most policies are re-assessed every 12 months, so time the PAM self-assessment to feed renewal. See the Cyber Insurance Guide.

Self-assessment questions

Score each dimension from 1 to 5 using evidence, not intent. Your overall level is the lowest score among the dimensions that protect Tier 0 and your most critical systems, not the average.

  • Inventory: how many accounts are members of Domain Admins, Enterprise Admins, Global Administrator and cloud owner roles today, and does your inventory match a fresh export?
  • Standing privilege: of those accounts, how many hold the role permanently, and how many of the permanent ones are break-glass accounts?
  • Vaulting: when a shared or break-glass password is checked out, how many minutes pass before it is rotated, and when was each break-glass account last tested?
  • Authentication: what percentage of privileged sign-ins in the last 30 days used a phishing-resistant method, and can any admin still use legacy authentication?
  • Pathways: from which devices did Tier 0 sign-ins come last month, and were they all privileged access workstations?
  • Sessions: could you show exactly what a third-party administrator did on a production server last Tuesday?
  • Non-human privilege: how many service accounts hold administrative rights, and how many have a password older than 12 months?
  • Governance: how many privileged entitlements did the last quarterly review remove, and how long did it take to revoke all access for the last administrator who left?

Moving up a level

Scale changes the route, not the destination. A small organisation with one directory and one cloud tenant can usually reach Level 3 with built-in features: just-in-time roles in Entra Privileged Identity Management, Windows LAPS, the Protected Users group and dedicated admin accounts. A large organisation with many server, database, network and SaaS platforms will need a dedicated PAM platform with a vault and session broker, and should decide per platform whether native cloud just-in-time roles or the broker is the enforcement point, so that every privileged path has exactly one.

From Ad hoc to Developing

  1. Export every privileged group and role from directories, servers, databases, network devices, cloud platforms and SaaS admin consoles into one list. See the Privileged Access Management Guide.
  2. Give every administrator a dedicated admin account with no mailbox and no internet browsing.
  3. Create two break-glass accounts per directory, vault their credentials and alert on every use. See the Break-Glass Account Guide.
  4. Vault shared administrator passwords and deploy Windows LAPS for local administrator accounts.

From Developing to Defined

  1. Add an owner, tier and purpose to every inventoried privileged account and remove the ones nobody claims after a disable-then-delete period.
  2. Enforce phishing-resistant MFA for all privileged accounts, piloting with the identity team first and keeping a tested break-glass path as the rollback.
  3. Convert the highest-impact roles to eligible, just-in-time assignments with MFA and justification at activation. Microsoft's RAMP target for Entra is "100% of applicable privileged access roles are using Microsoft Entra PIM". See the JIT Access Guide.
  4. Move Tier 0 administration to privileged access workstations and block Tier 0 accounts from lower-tier hosts. See the Tiered Administration and Enterprise Access Model Guide.
  5. Record Tier 0 and third-party sessions, starting in record-only mode before adding blocking policies. See the Privileged Session Management Guide.

From Defined to Managed

  1. Extend just-in-time elevation with approval to server, database, cloud and SaaS admin roles, using a short default activation window and a documented emergency path. See the Cloud PAM and CIEM Guide.
  2. Move privileged service accounts to gMSAs or managed identities, or vault and rotate their secrets automatically. See the Service Account Security Guide.
  3. Send PAM, directory and session logs to the SOC and build detections for privileged activity outside approved pathways, out of hours or without a matching activation.
  4. Measure attack paths to Tier 0 and close the ones that bypass the PAM pathway.

From Managed to Optimised

  1. Remove remaining standing privilege so that only break-glass accounts hold permanent admin rights.
  2. Issue privileged credentials per session and scope elevation to the task and resource.
  3. Automate containment for high-confidence detections (end the session, rotate the credential, disable the account), with a reviewed release process.
  4. Generate audit and insurer evidence from the platform rather than by hand.

Metrics that show maturity

  • Standing privileged accounts: accounts holding admin rights without activation (target: break-glass only).
  • Just-in-time coverage: percentage of privileged roles that are eligible rather than active.
  • Phishing-resistant MFA coverage: percentage of privileged sign-ins using a phishing-resistant method (target 100%).
  • Inventory ownership: percentage of privileged human and non-human accounts with a current owner and tier.
  • Rotation compliance: privileged credentials rotated within policy, including after every break-glass use.
  • Time to revoke: hours from an administrator leaving to all privileged access removed, measured on real leavers.

See the Identity Security Metrics Guide for how to report them.

Common failure patterns

  • Not treating the PAM system as Tier 0: in the Uber breach, attackers found scripts with hard-coded administrator credentials for the privileged access system, which gave them control over the secrets it held.
  • Standing admin with mass-action rights: in the Stryker Intune wiper attack, one hijacked admin account was enough to wipe tens of thousands of devices. Just-in-time elevation and approval for bulk destructive actions limit that blast radius.
  • Help desk resets that bypass PAM: the MGM Resorts breach began with a help desk call that led to identity provider admin access. Privileged accounts need stronger recovery than standard users.
  • Vault without rotation: passwords are stored but never changed, so anyone who once checked one out still knows it.
  • Humans only: the programme covers administrators while service accounts, pipelines and agents keep permanent domain or cloud admin rights.
  • Auto-approved elevation: just-in-time roles with eight-hour default windows and no approval look mature in reports but behave like standing privilege.

Practitioner checklist

  • Set Level 3 as the 12-month target, with Level 4 for Tier 0 and systems that hold regulated data.
  • Build the privileged inventory, human and non-human, before buying or expanding tooling. See the PAM Buyer's Guide.
  • Count standing privileged accounts monthly and report the trend.
  • Require phishing-resistant MFA and dedicated accounts for every administrator.
  • Treat the PAM platform, its database and its administrators as Tier 0.
  • Test break-glass accounts at least every 90 days, as RAMP recommends for emergency access.
  • Bring privileged service accounts and automation into scope in the same year as human admins.
  • Reassess every 12 months, timed to feed your cyber insurance renewal.

Standards and references

Related NHI Mgmt Group resources: Identity Security Maturity Model · Privileged Access Management Guide · JIT Access Guide · Privileged Identity Management (PIM) Guide · NHI Governance Maturity Model

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Written and reviewed by Lalit Choda, NHI Mgmt Group. Last updated 18 October 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org