The password was never the only problem: Legacy PAM vs. modern PAM

Part 1 of 3 in our Rethinking Privileged Access series.

The privileged access management (PAM) conversation originally centered on one question: how do we protect the password? Vault it. Rotate it. Inject it into sessions so nobody ever sees it. Gate it behind approvals and MFA so only the right person can check it out. Legacy PAM is one of the most mature, widely deployed answers to that question.

Solving the password problem is a big deal, but it's far from the only one. Zero trust, zero standing privilege, and just-in-time access have all matured since legacy PAM was designed, but legacy PAM hasn't kept pace.

That is the fork in the road between legacy PAM and modern PAM with Netwrix Privilege Secure (NPS). Legacy PAM was excellent at what it was built to do, but stopping modern attacks requires a tool built for something else.

Legacy PAM: Protecting the password

Legacy PAM starts from an assumption: privileged accounts exist permanently, and your job is to protect them as well as possible. If an account is a member of Domain Admins today, it’s still a member of Domain Admins tomorrow, next week, and next year, whether anyone is using that privilege or not. Legacy PAM acts as the disciplined gatekeeper in front of that permanent privilege.

In practice, that gatekeeping looks like this:

• A user needs access to a privileged account. First, they need the right permissions inside the PAM tool itself, through role assignments or folder-level access to the secret.
• Depending on policy, they may need to satisfy MFA before going further.
• They request access to the secret (a check-out), which may require approval from one or more designated approvers.
• Once approved, the user typically never sees the password. The tool launches an RDP or SSH session and injects the credential directly into it.
• The check-out has a time limit. When the user finishes or time runs out, the tool checks the secret back in.
• After check-in, the tool rotates the password, so even a credential exposed during use is no longer valid.

This model removes credential exposure, creates a clean audit trail, and enforces approval gates before anyone touches a sensitive account. But no matter how tightly the workflow runs, the underlying account stays a Domain Admin (or a local admin, or a sudoer) between sessions. The privilege is permanent. Only access to the password is temporary. An administrator can also grab a password for a "quick" job outside the tool, bypassing every one of these controls.

Legacy PAM also has a hard boundary in Active Directory. It reads group membership to decide who gets access to secrets, but it doesn't create, delete, or modify AD groups. Group membership, and the standing privilege that comes with it, lives entirely outside its control.

When legacy PAM vendors say "just-in-time" or "zero standing privilege," they’re referring to access to the password, not to the privilege on the account. They'll also tell you true just-in-time requires a separate endpoint privilege management product, which controls local administrator rights on employee computers. And while it's a form of just-in-time, it doesn't cover the accounts behind your critical infrastructure, the ones PAM exists to protect. Netwrix offers a product in that category as well: Netwrix PolicyPak.

Part 2 of this series covers the attacks that bypass password access or never need it, and why just-in-time and zero standing privilege are so powerful.

Modern PAM: Netwrix Privilege Secure eliminates standing privilege

Netwrix Privilege Secure starts from a different premise. Instead of asking "how do we protect a powerful account," it asks, "why does a powerful account need to be powerful all the time?"

NPS centers on the session and on Activities, which run before, during, and after that session to grant privilege exactly when it's needed and strip it away the moment it isn't. NPS supports three account approaches, each handling that lifecycle differently.

1. Requestor accounts

This is the account a user already uses to log in to their computer and email, with no separate privileged account involved. When a session starts, an Activity grants privilege on the fly, for example by adding the user to Domain Admins or another privileged AD group. Because it's the user's own account, the password isn't vaulted, and the user enters it during the session. When the session ends, NPS automatically removes whatever privilege it granted at the start.

This is often the most convenient of the three approaches but offers the least credential protection, since the password isn't rotated or injected. Even so, it eliminates standing privilege, because the account holds elevated rights only for the duration of the session.

2. Managed accounts

This is the closest analog to how legacy PAM works. When a session begins, NPS rotates the account's password and enables the account. Activities grant privilege for that session, such as adding the account to Domain Admins, local Administrators, or a sudo group. The password is injected into the session, so the user never sees it.

The difference shows up at the end, when NPS rotates the password again and vaults it, reverses the granted privilege, and disables the account. The account still exists, but between sessions it has no privilege and cannot authenticate, which makes a stolen password worthless to an attacker.

3. Ephemeral accounts

This model goes a step further by creating a brand-new account at the start of every session. During the session, it behaves like a managed account: privilege is granted and the password is injected. When the session ends, NPS deletes the account entirely, leaving nothing to attack.

Beyond privilege: What else Activities can do

Granting and revoking group membership is the headline feature, but Activities also close attack paths that standing-access models typically leave open:

• Kerberos ticket purging. When an RDP session ends, NPS can purge Kerberos tickets from the resource, cutting off a lateral movement path that doesn't require an account password.
• RDP enable/disable. Most Windows servers leave RDP running by default. NPS can enable RDP only at the start of a session and disable it immediately afterward, removing a large, constantly available piece of attack surface.
• Protection mode. NPS can scan Windows or Linux resources for unapproved local accounts. A malicious insider using your PAM tool correctly might quietly create local admins for later unauthorized use.
• DC replication sync. A privilege change on one domain controller doesn't always propagate instantly to the DC handling a session's authentication. NPS can force a targeted sync so granted privilege is available immediately instead of waiting on normal AD replication timing.

Side by side

Legacy PAM reduced credential risk. Modern PAM removes the target.

Legacy PAM's check-out/check-in model is a mature, well-tested way to reduce credential exposure and add accountability to privileged access. For many organizations, it was a strong step forward from unmanaged shared passwords.

Netwrix Privilege Secure is built for today's attacks. It treats standing privilege itself, along with the password protecting it, as the attack surface to eliminate. Whether that means a user's own account elevated only for the length of a session, a managed account rendered worthless between uses, or an ephemeral account that ceases to exist when the work is done, the logic is the same: if no privilege is sitting there waiting to be used, there is nothing for an attacker to steal.

Up next in this series

Eliminating standing privilege interrupts far more than the check-out/check-in workflow that legacy PAM relies on. Part 2, Beyond the vault: How NPS defeats more than password attacks, walks through the wider Windows and Active Directory credential attack surface (NTLM hashes, Kerberos tickets, Kerberoasting, cached domain credentials, and more) and maps which of those the NPS session model closes off and which it doesn't.

Then Part 3 covers how Bring Your Own Vault lets you add these session-layer protections on top of the vault you already run, without a rip-and-replace migration.