What is privileged access management (PAM)?

Key takeaways

• Privileged accounts are the high-impact attack target. A compromised standard user has limited blast radius; a compromised admin account can deploy ransomware, exfiltrate data, or modify access for the entire environment.
• PAM has four disciplines: credential vaulting, session management, just-in-time elevation, and secrets management. A complete program addresses all four.
• Most mid-market manufacturers run with documented privilege creep, shared admin passwords, dormant service accounts, and unmanaged vendor access.
• A PAM program can start with processes and modest tooling (password manager, conditional access, documented procedures) and add a dedicated PAM tool as scale justifies.
• ARG tests privileged access boundaries during assumed-breach simulation to identify the specific paths that produce real risk.

What does privileged access management actually cover?

Privileged access management addresses six categories of account, each with its own attack profile.

1. Domain admins. Active Directory or Entra accounts with the highest privilege level. Full control over identity, devices, and (via Group Policy or equivalent) configuration. Compromise of a single domain admin account is generally equivalent to compromise of the entire environment.

2. Server admins. Local administrator accounts on servers (Windows or Linux). Used for system maintenance, application deployment, troubleshooting. Often shared across the IT team; often not centrally managed.

3. Workstation admins. Local administrator on user workstations. Used for software installation, troubleshooting, and (in some configurations) by users themselves. Privilege escalation from a phishing landing typically targets the workstation admin level first.

4. Application admins. Privileged roles inside applications: ERP admin, SaaS tenant admin, Microsoft 365 global admin, database admin. Often the most consequential category because application admins have direct access to business-critical data and workflows.

5. Service accounts. Non-human accounts used by applications, scripts, and integrations. Often have high privilege because they need to perform automated tasks. Frequently created without lifecycle management; dormant service accounts accumulate over years.

6. Vendor and contractor accounts. Outside parties with elevated access for support, integration, or maintenance. Often the most exposed category because the manufacturer does not control the vendor's authentication, device, or operational security. See What is third-party risk for manufacturers?.

PAM scope covers all six categories. A program that addresses domain admins but ignores service accounts has a gap; a program that addresses humans but ignores vendor access has a gap. The complete program runs across all six.

The four PAM disciplines

PAM organizes around four operational disciplines. Each addresses a specific aspect of privileged-account control.

1. Credential vaulting. Privileged passwords and keys stored in a controlled vault rather than on individual machines or in shared documents. Vault access is itself authenticated (with phishing-resistant MFA) and logged. The vault rotates passwords on a schedule. Common tools: CyberArk, BeyondTrust, Delinea, HashiCorp Vault for secrets, Bitwarden Business or 1Password Business for smaller deployments.

2. Session management. Privileged sessions are mediated by a controlled jump server or session-recording proxy. The user authenticates to the jump server; the jump server connects to the target system on the user's behalf using vault-held credentials. The session is recorded; commands are logged. The user never sees the privileged credentials directly.

3. Just-in-time (JIT) elevation. Rather than holding privileged rights all the time, users request elevation when they need it. The request is approved (automatically based on policy, or by a human), the elevation lasts for a defined window, and the elevation is revoked after. The standing-privilege surface shrinks to zero (or near-zero); the time-bounded surface is monitored.

4. Secrets management. Application-level secrets (API keys, database connection strings, cryptographic keys) stored in a secrets vault rather than in code, configuration files, or environment variables. Secrets are rotated automatically; access is logged; expired secrets are removed. Common tools: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager.

The four disciplines together produce a complete PAM program. Most mid-market manufacturers start with credential vaulting and add the others as the program matures.

Why most mid-market manufacturers run with shared admin passwords

Mid-market manufacturers typically inherit a PAM posture that has accumulated over years. The recurring patterns:

1. Shared admin passwords for servers and applications. The IT team uses common "admin" or "administrator" credentials. The password is documented in a shared OneNote, a printed sheet, or memory. Activity is not attributable to specific people.
2. Service accounts with long-lived passwords. Created during initial system deployment; the password has not changed in three to seven years. Documented in the same shared OneNote.
3. Workstation local admin rights. Some users have local admin on their workstations because they "need it for their job"; the rights were granted ad-hoc and have never been reviewed.
4. Vendor accounts with shared credentials. A vendor's "support" account used by multiple vendor employees, with credentials that have not rotated in years.
5. Application admin accounts shared across the IT team. Microsoft 365 global admin, ERP admin, network admin all use shared credentials.
6. No MFA on admin paths. External-facing accounts have MFA; admin-only paths (server consoles, internal admin portals) often do not.

Each pattern is fixable. The patterns persist because changing them produces operational disruption: shared passwords are convenient, service accounts are sensitive to rotation, local admin removal produces help-desk tickets. The work is real and worth doing.

Examples of incidents enabled by absent PAM controls

What ARG sees during assumed-breach engagements at mid-market manufacturers:

• Spear-phished user reaches domain admin through cached credentials. Standard user workstation is compromised; the workstation has a cached domain admin credential from a prior helpdesk visit; the attacker uses Mimikatz to extract the credential and authenticates as domain admin.
• Shared admin password discovered in OneNote. Standard user account compromised; the user has access to the shared IT OneNote (because they were briefly part of IT); the admin passwords are documented there; the attacker has full access in minutes.
• Service account with broad rights used for lateral movement. A service account used by the backup software has read access to most file servers; the credential is harvested from the backup server; the attacker uses it to enumerate and exfiltrate file shares.
• Old vendor account survives password rotation. Vendor "support" account has not been touched since the original integration in 2019; the password is the original; the attacker discovers the account in a routine credential check and authenticates.
• Workstation local admin used to disable EDR. Compromised user has local admin on their workstation; the attacker disables EDR through local admin; subsequent attack proceeds without detection.
• Microsoft 365 global admin without MFA. Tenant-wide policies require MFA but exclude break-glass admin accounts; the break-glass account's credentials are discovered in old documentation; the attacker authenticates without MFA.
• OAuth grant to admin app survives password rotation. Phishing-acquired OAuth grant from earlier incident retains access; password rotation does not revoke the grant; the attacker reads admin mailbox without re-authentication.

Each example is preventable with specific PAM controls. The remediation is finite and well-understood; the gap is execution.

How to start a PAM program without buying enterprise software

For a mid-market manufacturer building PAM from baseline:

1. Inventory privileged accounts. All domain admins, server admins, application admins, service accounts, and vendor accounts. Each one named, owner identified, MFA state documented, last password rotation noted.
2. Eliminate shared accounts where possible. Replace shared admin accounts with named admin accounts. A login as "admin" becomes a login as "alice-admin" or "bob-admin". Activity becomes attributable.
3. Implement MFA on all admin accounts. Phishing-resistant MFA (FIDO2 hardware keys for admins) on every privileged login. The conditional access policy requires it; no exceptions for "break-glass" without compensating controls.
4. Separate admin accounts from daily-use accounts. Admin tasks performed from an account with elevated rights; daily work (email, web, productivity) performed from a separate standard account. The separation contains the blast radius of a compromised daily account.
5. Vault privileged credentials. A password manager with team features (Bitwarden Business, 1Password Business) holds privileged credentials. Access is logged; sharing is controlled; offboarding revokes access.
6. Document service account ownership and rotation. Each service account has a named owner; password rotation cadence is defined; dormant accounts are reviewed and removed.
7. Implement conditional access for admin paths. Privileged operations require specific authentication context: managed device, phishing-resistant MFA, low-risk session, named admin account.
8. Log privileged activity. Audit logs capture admin actions; review cadence ensures the logs are examined. Anomalies surface to human attention.

The starting program does not require an enterprise PAM tool. The transition to a dedicated tool (CyberArk, BeyondTrust, Delinea) happens when scale or specific requirements (session recording, just-in-time elevation, secrets-management integration) justify the investment.

Best practices for credential rotation and break-glass accounts

Two specific PAM topics warrant their own discipline.

Credential rotation. Privileged passwords rotate on a documented cadence: at minimum quarterly for highest-privilege accounts, on a defined schedule for service accounts, immediately after personnel changes or suspected compromise. Rotation that is not automated rarely happens on schedule; tooling that automates rotation is worth the integration effort.

Break-glass accounts. Emergency accounts that bypass normal authentication for use during incidents (when MFA is unavailable, when the identity provider is down, when conditional access is locking everyone out). Break-glass accounts have specific characteristics:

• Stored in a physical safe or sealed envelope, not in normal credential storage.
• Used exclusively for emergencies; any use generates an alert.
• Rotated after every use; the password in the safe is replaced.
• MFA configured with a hardware factor that cannot be lost during the emergency.
• Logged extensively; the audit trail of break-glass use is reviewed.

Break-glass accounts are a real operational requirement; they exist because identity systems can fail. The discipline is in handling them as exceptional, not normal.

PAM FAQs

Is PAM the same as IAM?

No. Identity and access management (IAM) covers user identity and access in general. PAM is the subset specifically focused on privileged accounts (administrators, service accounts, vendor accounts with elevated rights). PAM has tighter controls than general IAM because privileged accounts have higher impact when compromised.

Do I need a PAM tool, or are processes enough?

Processes plus modest tooling work for small environments. A 50 to 200 person manufacturer can run effective PAM with a password manager, documented procedures, conditional access policy, and disciplined logging. Above 200 to 300 endpoints with multiple privilege tiers and many service accounts, a dedicated PAM tool starts paying back. The process is the substance; the tool is the scale support.

How is PAM evaluated by cyber insurance underwriters?

Underwriters increasingly ask about PAM specifically: named administrative accounts, MFA on admin access, separation of admin accounts from daily-use accounts, monitoring of privileged sessions, and management of service accounts and vendor access. Absence of PAM is a premium driver; presence of mature PAM is a premium reducer. See What is cyber insurance underwriting?.

What is the difference between PAM and zero-standing-privilege?

Standing privilege means an account has its elevated rights all the time. Zero-standing-privilege means no account has elevated rights by default; rights are granted just-in-time when needed and revoked after use. PAM tools and processes implement standing privilege with monitoring; zero-standing-privilege is a tighter model that eliminates the always-available admin account entirely. Zero-standing-privilege is the more mature target; standing-with-controls is the practical starting point.

How ARG tests privileged access boundaries during simulation

Privileged access testing is part of assumed-breach simulation in every ARG engagement. The work is operated by James Wall on infrastructure ARG controls.

The simulation starts from a defined assumed-breach position (a phished user, a compromised workstation, a stolen credential) and exercises the path to privileged access:

• Local privilege escalation. Whether the starting position can be elevated to local admin on the compromised system. Techniques include UAC bypass, vulnerable services, kernel exploits, and credential extraction.
• Lateral movement to privileged systems. Whether the elevated foothold can reach systems holding privileged credentials. SQL servers, file shares with admin OneNotes, backup servers with service-account credentials, jump servers with cached credentials.
• Credential extraction. Mimikatz-equivalent extraction of LSASS, DPAPI, browser-stored credentials, SSH keys, and cloud-credential caches.
• Privileged session abuse. Whether the extracted credentials allow access to privileged sessions and operations.
• Persistence through PAM gaps. Whether the attacker can establish persistent privileged access through service-account abuse, OAuth grants, or scheduled tasks.

Findings consolidate into the monthly operational packet alongside the rest of the engagement. The remediation backlog includes specific PAM items: shared accounts to replace, service accounts to vault, MFA gaps to close, conditional access policies to tighten. Re-tests in subsequent rounds confirm that the closed paths stay closed.

The output supports insurance underwriting evidence and CMMC / NIST SP 800-171 compliance for the Access Control family.

For founding clients, PAM testing is part of the standard engagement. The expected outcome is a measurable reduction in privileged-access exposure over the engagement's first year.

Apply as a founding client or see how the engagement works for the full delivery cycle.