The PAM Deployment Is Live. Here Is What It Does Not Cover.
The privileged access management project closed two quarters ago. The vendor reported 83 percent of privileged accounts enrolled. Leadership considers the control active. The red team that tested the environment found domain admin in four hours using credentials that had never touched the vault.
This is not a vendor failure. It is a coverage problem that almost every PAM deployment produces, because the definition of "privileged" that gets used during enrollment is narrower than the actual attack surface.
What Gets Enrolled First
PAM rollouts follow a predictable sequence. Named administrative accounts in Active Directory, tier zero accounts with domain controller access, local administrator passwords on servers, and a few shared root credentials that had been sitting in a spreadsheet since the migration. These are the accounts security auditors ask about, the ones compliance frameworks flag, and the ones most visible to whoever scoped the project.
By the end of the rollout, those accounts are in the vault. Password rotation is running. Session recording is configured. The project is declared a success.
What is not enrolled: the service desk administrator accounts used for daily operations that were excluded because enrolling them would require retraining a hundred people before the project deadline. The developer accounts with production database access that predate the privilege review. The shared accounts on legacy systems that cannot support the PAM agent. The third-party vendor accounts managed by an MSP and therefore, in someone's mental model, someone else's problem to enroll.
In other words, the convenient accounts got enrolled. The operationally difficult ones did not - which means the ones most likely to have accumulated excessive access over time are exactly the ones sitting outside the vault.
The Coverage Number Is Not the Coverage
When a PAM program reports that 83 percent of privileged accounts are enrolled, the useful question is not about the 17 percent that were missed. It is about what "privileged" means in the scope that generated that number.
If the scope was defined as accounts with Domain Admin or equivalent, then accounts with Write access to Group Policy objects, accounts that can modify service configurations on domain controllers, and accounts with sufficient rights to create new admin-level accounts were probably not counted. None of them have the specific right that defines privileged in the compliance documentation, and all of them represent paths to full domain compromise.
A penetration tester who finds a Tier 1 account with the right combination of delegated permissions can reach domain admin without ever touching an account the PAM program thought it needed to protect. The coverage number reflects the program's definition of privileged. Not the attacker's.
Automation That Predates the Vault
PAM handles interactive sessions well. An administrator who needs to work on a server authenticates through the PAM portal, the session is recorded, the credential is checked out from the vault and checked back in. This is the workflow the vendor demonstrated and the one everyone practiced.
Then there is the automation. The scheduled tasks that run as local administrator on fifty servers because that is how the monitoring agent was deployed in 2019. The scripts that authenticate directly to Active Directory with hardcoded credentials because they were written before the PAM project started. The CI/CD pipelines that use a service account with infrastructure access because retrofitting those credentials through the PAM API was too complex to prioritize.
These automation paths represent a substantial fraction of actual privileged access in most environments, and they bypass the vault entirely. The administrator logging in interactively is going through the checkpoint. The script running at 3 AM against the same system is not, and neither the PAM team nor the SOC has visibility into what it does.
Cloud IAM Does Not Fit the Vault Model
The vault model - store credentials, check them out on demand, rotate after use - was designed for accounts with persistent passwords. AWS IAM roles, Azure service principals, and GCP service accounts generate temporary credentials on demand through the cloud provider's own mechanisms. There is no static password to vault.
This creates a structural gap in PAM programs designed around Active Directory. The architecture that protects privileged access in on-premises environments has limited applicability to the environments where most new privileged access is being created. Cloud-native PAM solutions exist, but they are separate products with separate enrollment processes, and most organizations are running two parallel programs with gaps between them.
The IAM role that an EC2 instance uses to manage other EC2 instances, read from S3, or call cross-account APIs: none of these show up in the enterprise PAM enrollment report, because the enterprise PAM was never designed to know they exist.
What Actual Coverage Requires
Discovery has to precede enrollment, and discovery has to be adversarial. Running a standard IAM enumeration query to find accounts with admin rights will find the accounts that administrative policy created with admin rights. A BloodHound analysis of Active Directory shows which paths lead to privilege, including the paths built from combinations of delegated rights that nobody audited individually.
For cloud environments, IAM Access Analyzer and equivalent tools surface over-permissioned identities and roles that have not been used recently. The starting inventory for cloud PAM coverage should come from that analysis, not from a list of accounts that someone's team owns.
Automation paths need their own treatment, separate from the interactive access program. Identify every scheduled task, service, and script that runs with elevated credentials. For each one, determine whether the access is still appropriate and whether it can be replaced by shorter-lived credentials or role-based access that does not require a static password. The ones that cannot be changed immediately should be documented and explicitly accepted as exceptions rather than treated as invisible.
Monitor for PAM bypass attempts. If the program is operating correctly, privileged accounts should almost never be used directly without a PAM checkout. Authentication events from privileged accounts that did not originate from a PAM session are either a gap in the program or an active intrusion. Either one is worth an alert.
The 83 percent enrollment is real work that reduced real risk. The 17 percent is not the problem. The problem is the additional surface that was never in the denominator, because the scope was defined by what was convenient to audit rather than by what an attacker would actually use.