Privileged access management: the control that matters most and gets implemented worst

Privileged access is the common denominator in most serious security incidents. Ransomware operators who gain initial access through phishing or a vulnerable service aren't done when they land on one workstation. They're done when they reach a privileged account (domain admin, a cloud infrastructure credential, a backup system account) that lets them move laterally, establish persistence, and deploy their payload at scale.

The path from initial access to privileged access is well-documented and heavily automated. Tools like Mimikatz, BloodHound, and their commercial equivalents can map a route from a compromised workstation to domain admin in minutes against a typical Active Directory environment. The attacker's job is to find and exploit your privileged access gaps, and most organizations have gaps they aren't fully aware of.

What PAM is actually protecting against

Privileged access management is about two things: limiting who has standing access to powerful credentials, and monitoring what happens when those credentials are used. The threat model has three components.

Credential theft

Attackers extract credentials from memory, from files, from browser storage, or from poorly secured password managers. Any credential stored in plaintext anywhere an attacker can reach is at risk. Privileged credentials in plaintext are catastrophic, because they give the attacker access to everything those credentials touch.

Lateral movement

Once an attacker has any credential, they'll use it to probe what else they can reach. Shared admin passwords across multiple systems mean compromising one credential compromises every system that shares it. Overly broad role assignments mean a credential intended for a narrow purpose provides access far beyond it.

Privilege escalation

Even starting with a low-privilege account, an attacker looks for ways to acquire higher privileges. Misconfigured group policies, unpatched local privilege escalation vulnerabilities, and Kerberoastable service accounts are all escalation paths common in real environments.

The inventory problem

Most organizations don't have an accurate count of their privileged accounts. This is the first problem to solve, because you can't manage what you haven't found.

A privileged account, for this purpose, is any account with elevated access: domain and local admins, service accounts with elevated privileges, cloud infrastructure accounts with admin or owner roles, database accounts with DBA privileges, network device accounts, and backup and recovery system accounts.

When organizations run their first serious privileged account inventory, they almost always find more than they expected. Service accounts created for a project years ago and never decommissioned. Application integrations handed domain admin rights because it was easier than working out the minimum necessary permissions. Personal admin accounts created by IT staff and never documented. Cloud accounts created outside the standard provisioning process. The inventory itself is valuable beyond finding accounts: it surfaces access that wasn't intentionally granted and can't currently be explained. Those unexplained accounts deserve immediate investigation.

The controls that close the highest-risk gaps

No shared privileged credentials

Shared admin passwords are the single highest-risk identity pattern. When multiple people or systems share a credential, you lose attribution (you can't tell who did what), you lose the ability to revoke access selectively, and the credential inevitably ends up stored insecurely somewhere. Every privileged account should be individually assigned to a specific person or automated system with a documented purpose.

Password vaulting for every privileged account

Privileged credentials belong in a vault, checked out when needed, not stored in someone's head or on a sticky note. Modern PAM platforms (CyberArk, Delinea, BeyondTrust, and lighter options like 1Password Business for smaller environments) handle this. The vault also enforces rotation, provides audit trails, and integrates with your SIEM. At minimum this applies to your domain admin accounts, your cloud infrastructure accounts, and your backup system credentials.

MFA on all privileged access

This is not optional. An attacker who has stolen or guessed a privileged credential should still hit an MFA challenge before they can use it. This single control eliminates the most common credential exploitation path.

Least privilege assignment

Audit what each privileged account actually needs to do and trim access to the minimum. A service account that reads from one database table does not need domain admin rights. The common objection, "it was easier to just give it admin," is exactly the pattern attackers rely on. Least privilege remediation is tedious, and it directly reduces blast radius.

Just-in-time access for admin tasks

For human admin accounts, the best practice is to have no standing privileged access at all. Admins work in standard user accounts day to day and request elevated access for specific tasks with time-limited grants. That eliminates the scenario where an admin's everyday workstation, the one used for email and browsing, is the machine that gets compromised and happens to have domain admin credentials in memory.

Session recording for privileged access

Knowing that privileged access happened is different from knowing what was done. Session recording captures the full activity of privileged sessions, which is valuable for incident investigation, for insider threat detection, and as a deterrent. Most PAM platforms include it. Organizations without a platform can implement privileged session recording through jump server or bastion host architectures.

What most SMB and mid-market programs are missing

Full-featured enterprise PAM platforms (CyberArk, Delinea) are expensive, complex to implement, and built for environments with dedicated IAM teams. Most mid-market organizations don't need the enterprise stack. They do need the underlying controls. A mid-market PAM program running without an enterprise platform should have:

• A password manager with admin vault capability (1Password Business, Keeper, or similar) deployed for all IT staff, with privileged credentials stored there rather than in spreadsheets or personal vaults
• MFA enforced on all Active Directory admin accounts via Conditional Access (if you're on Entra ID) or an equivalent for on-premises environments
• A quarterly review of privileged accounts: who has them, what they're for, whether the access is still needed, and whether the last rotation was recent enough
• A network policy that blocks domain admin accounts from email, web browsing, and other non-administrative tasks
• Documentation of every service account with its purpose, owner, and access scope

Those five cover most of the attack surface enterprise PAM is designed to address, without the enterprise budget or implementation complexity.

KRIs for privileged access

The signals that tell you whether your PAM program is working, and the ones worth watching for drift as part of your KRI program:

• Privileged account count trend: growing, stable, or declining. Growth without a matching review is a sprawl indicator.
• Standing versus just-in-time ratio: of your human admin accounts, what share have standing elevated access rather than time-limited grants. Movement toward JIT is a maturity signal.
• Privileged account review completion rate: the share of accounts reviewed on schedule this cycle. Slippage is how accounts accumulate without oversight.
• Credential rotation compliance: the share of privileged credentials rotated within your policy period. Service accounts are the most common failure category.
• Shared credential count: ideally zero, otherwise declining.
• MFA coverage on privileged accounts: should be 100%. Any gap is a coverage problem worth tracking explicitly.

The one thing to do first

If you're starting from scratch or rebuilding, the single highest-value first action is a complete privileged account inventory. Before you buy a tool, before you write a policy, before you run a review, find every account with elevated access, document what it is and what it does, and identify the ones that can't be explained.

The accounts you can't explain are the most urgent risk. They're either legacy accounts that should have been decommissioned, accounts created for purposes nobody documented, or accounts created by someone who shouldn't have created them. All three are worth investigating before anything else. Everything else in PAM, vaulting, rotation, JIT access, session recording, builds on an accurate inventory. Without it, you're managing an incomplete picture.