In nearly every penetration test we conduct, the path from initial access to full environment compromise runs through a privileged account. A developer's laptop gets phished, and the attacker finds cached admin credentials. A service account with domain admin privileges is using the same password it was created with three years ago. An API key with production database access is sitting in a public GitHub repository.
Privileged accounts are the keys to the kingdom, and most organizations manage them with the same rigor they apply to regular user accounts: which is to say, not enough. Passwords get stored in shared spreadsheets, admin access is granted permanently "because it's easier," and service accounts proliferate without inventory or oversight.
Privileged Access Management (PAM) is the discipline of fixing this. But PAM is not just about password vaults. Modern PAM encompasses just-in-time access provisioning, session recording and monitoring, service account governance, and the policies that tie them all together. This guide covers what actually works.
Why Privileged Accounts Are the Primary Target
To understand why PAM matters, you need to understand how attackers think about privileged access. In a typical attack chain, initial access gives an attacker a foothold, usually as a regular user. From there, the immediate priority is privilege escalation: finding a way to gain admin, root, or other elevated access.
Once an attacker has privileged access, they can:
- Access any data in the environment. Admin accounts typically have unrestricted access to databases, file shares, and customer data
- Disable security controls. Turn off EDR, delete logs, modify firewall rules, and blind the security team
- Create persistence. Add new admin accounts, install backdoors, and establish access that survives password resets and system restarts
- Move laterally. Pivot from one system to another using privileged credentials, expanding the blast radius from a single compromised workstation to the entire network
- Deploy ransomware. Enterprise-wide ransomware deployment typically requires domain admin or equivalent access. Without privileged access, the attacker is limited to individual machines
This is not theoretical. In our Active Directory penetration testing engagements, we routinely escalate from a standard user account to domain admin within hours. The paths are almost always the same: cached credentials on workstations, service accounts with excessive privileges, and Kerberoastable accounts with weak passwords.
From our testing data: In over 75% of internal network penetration tests, we achieve domain admin access within the first 48 hours. The most common privilege escalation path involves compromising a service account, which typically has a weak or never-rotated password and permissions far beyond what the service actually needs.
The Core Components of Modern PAM
Effective PAM is built on several interconnected components. Implementing just one without the others leaves significant gaps. Here is what a complete PAM program includes:
Privileged account discovery and inventory
You cannot manage what you do not know about. The first step is identifying every privileged account in your environment: human admin accounts, service accounts, application accounts, root and built-in administrator accounts, cloud IAM roles with elevated permissions, database admin accounts, and network device admin accounts.
Most organizations are surprised by the number of privileged accounts they find. We commonly see environments where the number of service accounts with admin-level permissions exceeds the number of human admin accounts by a factor of five or more.
Credential vaulting and rotation
Privileged credentials should be stored in a centralized vault (CyberArk, HashiCorp Vault, 1Password Business, etc.) rather than in spreadsheets, config files, or people's heads. The vault provides encrypted storage, access logging, and automated rotation.
Rotation is critical. A password that never changes is a password that can be compromised without detection. Automated rotation means that even if a credential is stolen, it becomes invalid within hours or days rather than remaining valid indefinitely.
Just-in-time (JIT) access
This is the most impactful PAM control for reducing risk. Instead of granting permanent admin access, users request elevated access when they need it, receive approval, and the access automatically expires after a defined period (typically 1-4 hours).
JIT access eliminates the concept of standing privileged access. If there are no always-on admin accounts, there are no always-on admin accounts to compromise. An attacker who compromises a user's workstation finds a standard user account, not an admin credential.
Session recording and monitoring
When privileged access is used, the session should be recorded and monitored. This means capturing the commands executed, files accessed, and changes made during the privileged session. Session recording provides accountability (who did what and when), forensic evidence (what happened during an incident), deterrence (people behave differently when they know they are being recorded), and compliance evidence for auditors.
Least privilege enforcement
Every account should have the minimum permissions required for its function. This applies to human accounts (a developer does not need production database admin access for daily work) and to service accounts (a monitoring agent does not need write access to the systems it monitors). Implementing least privilege requires understanding what each account actually needs, which is why discovery and inventory come first.
Service Account Management
Service accounts are the most neglected category of privileged accounts and, consequently, the most frequently exploited. They deserve special attention in any PAM program.
The service account problem
Service accounts are created to run applications, scheduled tasks, integrations, and automated processes. They typically need elevated permissions to function. And they have several properties that make them attractive to attackers:
- Passwords are rarely rotated. Nobody wants to break a production integration by rotating the service account password, so it stays the same for years
- Permissions are excessive. Service accounts are often created with admin-level access "to make sure it works" during initial setup, and the permissions are never scoped down
- There is no accountability. Service accounts are not tied to individuals, so their use is rarely monitored or questioned
- They are not covered by MFA. Service accounts authenticate programmatically, which typically means password-only or key-based authentication without multi-factor
- Nobody knows they exist. Service accounts accumulate over years of projects, integrations, and configuration changes. Many environments have service accounts for systems that no longer exist
Managing service accounts properly
Effective service account management requires:
- Complete inventory. Identify every service account, what it does, what systems it accesses, what permissions it has, and who owns it
- Scoped permissions. Reduce each service account's permissions to the minimum required for its function. If a monitoring service only needs read access, remove write and admin permissions
- Automated rotation. Rotate service account passwords on a defined cadence (every 30-90 days). Use a vault that can handle the rotation and automatically update the dependent systems
- Ownership assignment. Every service account should have a named human owner who is responsible for its security and who participates in access reviews
- Decommissioning process. When a system or integration is retired, its service accounts should be disabled and eventually deleted. This requires maintaining the inventory and checking it against active systems
PAM for Cloud Environments
Cloud environments introduce PAM challenges that traditional on-premises solutions were not designed for. IAM roles, temporary credentials, cross-account access, and infrastructure-as-code all require a modern approach to privileged access.
AWS IAM best practices
- Never use the root account for daily operations. Lock it with MFA and monitor it for any usage
- Use IAM roles with temporary credentials rather than long-lived access keys
- Implement AWS Organizations with SCPs (Service Control Policies) to enforce permission boundaries
- Use AWS SSO for human access, eliminating the need for IAM users with permanent credentials
- Monitor CloudTrail for privileged API calls and set up alerts for anomalous activity
Multi-cloud considerations
Organizations using multiple cloud providers face the additional challenge of maintaining consistent PAM policies across AWS, GCP, Azure, and any other platforms in use. Federated identity (using a single IdP across all cloud providers) provides a foundation, but each cloud's IAM model has unique quirks that require provider-specific knowledge. This is an area where cloud security assessments provide significant value.
What Penetration Testers Look For
Understanding how pentesters target privileged accounts helps you prioritize your PAM investments. Here are the specific techniques we use and what they exploit:
| Technique | What It Exploits | PAM Control That Prevents It |
|---|---|---|
| Kerberoasting | Service accounts with SPNs and weak passwords | Strong password policy, managed service accounts, rotation |
| Credential Harvesting | Cached admin credentials on workstations | JIT access (no standing admin credentials to cache) |
| Pass-the-Hash | Reusable NTLM hashes from privileged sessions | Credential guard, admin tiering, LAPS |
| Golden Ticket | Compromised KRBTGT account hash | KRBTGT password rotation, admin tiering |
| Cloud IAM Abuse | Over-permissioned IAM roles and policies | Least privilege, regular IAM access reviews |
| Service Account Pivot | Service accounts with domain admin on multiple systems | Scoped permissions, credential vaulting |
| Config File Credentials | Passwords stored in plaintext config files | Credential vaulting, secrets management |
Each of these techniques is well-documented and widely used by both penetration testers and real-world attackers. The PAM controls that prevent them are also well-understood. The gap is usually not knowledge but implementation.
Implementing PAM: A Practical Roadmap
PAM implementation does not have to be a massive, multi-year project. Here is a phased approach that delivers value incrementally:
Phase 1: Foundation (Month 1-2)
- Complete an inventory of all privileged accounts (human and service)
- Deploy a credential vault and migrate the highest-risk credentials into it
- Enable MFA on all admin accounts that do not already have it
- Implement local admin password management (LAPS or equivalent) for workstations
Phase 2: Control (Month 3-4)
- Implement JIT access for the most sensitive admin roles
- Begin automated rotation for service account passwords
- Set up monitoring and alerting for privileged account usage
- Conduct a penetration test to validate control effectiveness
Phase 3: Maturity (Month 5-6)
- Enable session recording for all privileged access
- Implement admin tiering to prevent credential exposure across tiers
- Extend PAM controls to cloud environments and SaaS admin accounts
- Establish quarterly access reviews for all privileged accounts
Phase 4: Optimization (Ongoing)
- Continuously reduce standing privileged access through expanded JIT
- Integrate PAM data into your SIEM for behavioral analytics
- Regular testing and validation through ongoing penetration testing
- Refine policies based on actual usage patterns and audit findings
PAM and Compliance
PAM controls map directly to requirements in every major compliance framework:
- SOC 2 CC6.1 / CC6.3: Logical access controls and management of privileged access. PAM provides the controls and evidence that satisfy these criteria
- ISO 27001 A.9.2: User access management, including privileged access management. ISO explicitly calls out privileged access as a distinct control area
- PCI-DSS Requirement 7 and 8: Restrict access by business need to know and identify users. PAM is essential for meeting these requirements in environments that handle cardholder data
- NIST CSF PR.AC: Access control, including privileged account management. NIST provides detailed guidance on PAM as part of the Protect function
Organizations with mature PAM programs consistently have smoother audits because the controls, monitoring, and evidence are built into the system rather than assembled manually before each audit cycle.
The bottom line: Privileged access management is not optional for any organization that takes security seriously. Every major breach, every successful ransomware attack, and every significant penetration test finding involves privileged access at some point in the chain. Investing in PAM reduces your attack surface, improves your compliance posture, and directly addresses the techniques that real attackers use against real environments.
Find out how attackers exploit your privileged accounts
Our penetration testing specifically targets the privilege escalation paths that lead to full environment compromise. We show you exactly how an attacker would move from initial access to domain admin, and how to stop them.
