What are the relative merits / deficiencies of a Privileged Access Management (PAM) service compared with a strict policy of named users (no account sharing)?

By PAM, I'm specifically referring to devices which act as proxies, identifying the end-user and substituting shared credentials to access a target account, e.g. CyberArk, and NOT applications which merely provide managed access to a set of usernames and passwords.

More specifically, how do the approaches compare for

  • auditability
  • resistance to external threat
  • long term costs (PAM is an obvious quick fix if you're migrating away from using shared accounts)

2 Answers 2


I don't think it's reasonable to limit the response to a single commercial product. Looking at the question more generally:

  • There are a few basic strategies to control access to high-privileged access (root, Administrator and the like) on systems:

    • Create a personal admin account for every human that may ever need one. Users may know the passwords to these or they may be asked to sign into these via a PAM solution.
    • Have one or a few shared high-privilege accounts and control access to those with a product such as Cyber-Ark, Hitachi ID PAM or similar.
    • Create accounts dynamically and delete them after each use.
    • Have users sign in with normally unprivileged accounts but at runtime assign them additional group memberships / privileges.
  • Personal, named accounts with elevated privileges make sense if:

    • You only have a limited number of systems and people who need elevated access. Imagine a larger IT team with 100 administrators who need access to 10,000 systems, where systems are onboarded and retired at a rate of hundreds per day and staff come and go at least weekly. The pace of creating/deleting high privilege personal accounts and managing passwords to those would be cost prohibitive.

    • You are OK with password-only authentication. Most systems either do not support 2FA or require very complex and possibly fragile configuration to support login with more than just a password.

    • Built-in audit logs are adequate. You don't need to play back a video of user interaction with a privileged login, for example.

  • PAM systems can secure personal, named admin accounts by removing user knowledge of passwords, by randomizing and vaulting passwords, by introducing 2FA and with good authorization models and audit logs. They don't eliminate the administrative burden of personal admin accounts, however.

    Some people talk about "Privileged Identity Management" but this is a really dumb label because these products don't generally create or delete accounts, they control access to existing accounts, hence PAM not PIM.

  • Some PAM products let users request temporary group membership or temporary SSH trust. This is true of Hitachi ID PAM, for example. This is a nice alternative to password randomization/vaulting but is mutually exclusive with mandatory session recording.

  • All PAM products should support some form of 2FA. The nice thing here is that you can configure 2FA once - into the PAM system itself, and from there just launch user logins into the end system. Which 2FA technologies are supported should matter less to any given organization than whether the PAM system supports the 2FA system that they use or plan on. Some PAM systems also bundle a 2FA, in case you don't already have one (again, Hitachi ID comes to mind, but this is likely going to be increasingly common).

  • All PAM products should support some form of session recording. With some, this will be an extra cost item, and with others it's built-in. Figure out whether you need this, what kinds of data streams you care about (keylogging? video capture? copy buffer integration? etc.) and what it will cost before investing in a PAM product.

  • How PAM products launch logins to privileged sessions varies. There are a few approaches, each with its own pros and cons, which can be combined to suit your needs:

    • Launch an admin tool (MSTSC, PuTTY, vSphere, whatever) on the authenticated+authorized user's PC, and inject target address and credentials into it. This is most flexible and scalable, but it implies a certain client OS, a network path from the user's device to the managed endopint and the temporary existence of target account credentials on the user's device. Users gain single sign-on across multiple privileged sessions (just sign into the PAM portal once) and runtime performance.

    • VDI to a proxy and then do the above. This eliminates many connectivity and OS compatibility problems.

    • Proxy the connection protocol, and authenticate in-line. This means that the range of both authentication options and session protocols is limited to what the proxy can handle. Usually you can support PIN-type authentication with things like RSA tokens and protocols such as SSH and RDP. You also tend to concentrate connections in a few choke-point proxy servers, which can create performance problems (reduced per-session bandwidth, in some cases high latency for the full network path). You also force users to re-authenticate for every session - a major nuisance. The upside is that users continue to sign in with whatever tools they are used to and credentials never exist on the user's PC. Caution: some PAM products only support this model, which is quite restrictive (Cyber-Ark may be limited in this way).

    • Proxy the display, not the connection protocol. Basically launch an SSH or RDP session from a proxy server to the managed system and display the session in a browser tab for the user. Very convenient for remote access or vendor access scenarios, but has similar limitations to protocol proxies as above.

    • Never mind proxies or single sign-on -- either tell the user the current password value (display or copy buffer integration) or assign temporary entitlements to the user's existing account. Note that if the session is not launched by PAM, it may not be possible to enforce session recording.

  • The previous poster correctly pointed out that PAM systems offer additional benefits, including:

    • Replacing static passwords with regularly changing ones.

    • Replacing weak password storage (paper, spreadsheets) with something encrypted, replicated, access controlled, etc.

    • Replacing embedded passwords used to launch programs or connect to services with regularly changing passwords, hopefully no longer stored in plaintext anywhere.


As OP mentioned CyberArk, this would answer part of query.

CyberArk can be set to

  • 2FA logon to CyberArk before view the list of target device account
  • change password with password history on device like Windows or service like Facebook or CyberArk logon itself
    • automatically
    • regularly (limit password sharing)
    • after use (ensure one time use)
    • randomly
  • lock password retrieval when one is using (ensure exclusive use)
  • connect to target device without knowing password (e.g. connect is similar to RDP, SSH)
  • record session video to monitor activity
    • store keystroke
    • has live monitoring
  • API for application to access target device (eliminate password hardcode)

Target device can be configured

  • only allow logon access from CyberArk server

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.