Privileged access management (PAM) platforms hold the keys to your most powerful accounts, so a poor choice either leaves standing privilege in place or creates a single system an attacker can use to reach everything. PAM has grown from password vaults and session recording into a wider set of controls: just-in-time (JIT) elevation, cloud entitlements, secrets for machines, endpoint privilege and remote access. This vendor-neutral guide is for identity, security and infrastructure teams writing requirements, running an RFP or replacing a platform, and ends with a proof of concept you can run in your own estate. For the underlying concepts, see the Privileged Access Management Guide.
Key takeaways
- Map where privilege lives first. Directories, servers, cloud consoles and IAM, databases, Kubernetes, SaaS admin roles, endpoints and machine identities all hold privilege, and few platforms cover all of them equally well.
- Most organisations need both models. Vault-centred PAM (vaulting, rotation, session brokering) and JIT-centred PAM (ephemeral access, no standing privilege) solve different problems; score how a platform combines them.
- Non-human identities are privileged users too. Service accounts, pipelines, workloads and AI agents often hold more standing privilege than administrators, so test them, not only human workflows.
- Developer experience decides adoption. If access from the command line is slow or awkward, engineers will route around the platform and the standing privilege comes back.
- The PAM platform is a tier-zero system. It stores or brokers the credentials for your most sensitive roles, so its own security, resilience and break-glass design belong in the evaluation.
Define requirements
Start with an inventory of privileged access as it is today, not as the policy says it should be. The NCSC's secure system administration guidance is a useful frame: it defines an administrator as a person or a process with higher permissions than a normal user (a scheduled task's system account counts), and asks you to control "who, where, when, why and how people perform system administration". Microsoft goes further and says organisations "should make securing privileged access the top security priority". MITRE ATT&CK T1078 Valid Accounts describes attackers using existing credentials for initial access, persistence, privilege escalation and defence evasion, often without malware.
- Privileged populations: infrastructure and cloud administrators, database administrators, developers with production access, help desk, third-party suppliers, and non-human identities such as service accounts, CI/CD pipelines, scripts and AI agents. Record counts and owners. See the Service Account Security Guide.
- Targets: Windows and Linux servers, Active Directory and Entra ID, each cloud provider's console and CLI, databases, Kubernetes clusters, network devices, SaaS admin roles and, where relevant, operational technology. See the Active Directory and Entra ID Hardening Guide.
- Access patterns: interactive sessions (RDP, SSH, web consoles), command-line and API access, application-to-application credentials and emergency access. NIST IR 7966 notes that SSH is often used for interactive and automated access "with very high privileges", and that SSH key-based access needs provisioning, termination and monitoring. See the SSH Key Management Guide.
- Deployment and resilience: SaaS, self-hosted or hybrid; data residency; recovery objectives; and how administrators get in when the platform is down. See the Break-Glass Account Guide.
- Integrations: identity provider, IGA, ticketing, SIEM and ITDR, and secrets managers.
Map requirements to the frameworks you report against
| Requirement | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 (2025) |
|---|---|---|---|---|---|
| Privileged account inventory and ownership | PR.AA-01 | AC-2(7), CM-8 | 8.2 Privileged access rights | 5.1, 5.5 | NHI1 Improper Offboarding |
| Least privilege and JIT elevation | PR.AA-05 | AC-6, AC-6(5), AC-2(2) | 5.18 Access rights, 8.2 | 5.4, 6.8 | NHI5 Overprivileged NHI |
| Strong authentication for admin access | PR.AA-03 | IA-2(1) | 8.5 Secure authentication | 6.5 | NHI4 Insecure Authentication |
| Credential vaulting and rotation | PR.AA-01 | IA-5, IA-5(7) | 5.17 Authentication information | 5.2 | NHI2 Secret Leakage, NHI7 Long-Lived Secrets |
| Session recording and privileged activity logging | DE.CM-03 | AU-14, AC-6(9), AU-6 | 8.15 Logging, 8.16 Monitoring activities | 8.5, 8.11 | NHI10 Human Use of NHI |
| Privilege reviews | PR.AA-05 | AC-6(7) | 5.18 Access rights | 6.8 | NHI5 |
SP 800-53 AC-2(7) asks organisations to monitor privileged role assignments and revoke access when they are no longer appropriate; AC-6(9) asks for the execution of privileged functions to be logged; and AC-2(2) for temporary and emergency accounts to be removed or disabled automatically after a set period.
Capability areas
Ask to see each one working on your systems.
| Area | What to look for |
|---|---|
| Discovery | Finds privileged accounts, local admins, service accounts, SSH keys, cloud admin roles and secrets in scripts, scanned continuously |
| Vaulting and rotation | Secure storage, automatic rotation, and dependency handling so a service account password used by many applications can change without an outage |
| Just-in-time access | Time-bound elevation, ephemeral accounts or role activation, approvals, justification and ticket integration. See the JIT Access Guide |
| Session management | Brokered connections without revealing credentials, recording, command control, searchable review and alerting. See the Privileged Session Management Guide |
| Cloud privilege | JIT for cloud consoles and CLIs across providers, plus entitlement analysis (CIEM). See the Cloud PAM and CIEM Guide |
| Endpoint privilege management | Removing local admin rights with controlled, audited elevation. See the Endpoint Privilege Management Guide |
| Secrets for machines | Application credential retrieval, dynamic short-lived credentials and CI/CD integration. See the Secrets Management Buyer's Guide |
| Remote and supplier access | Third-party access without VPNs or shared accounts, with time limits and recording. See the Third-Party Access Guide |
| Infrastructure access | Databases, Kubernetes and SSH with certificates or identity-based access instead of static keys |
| Analytics and detection | Risky session scoring, anomaly detection, SIEM and ITDR integration. See the ITDR Guide |
| Governance | Privileged access reviews, owner attestation and integration with IGA. See the IGA Buyer's Guide |
Vault-centred and JIT-centred approaches
| Question | Vault-centred | JIT-centred |
|---|---|---|
| What it removes | Shared and unknown passwords; credentials in scripts and spreadsheets | Standing privilege; accounts that are always powerful |
| Typical strengths | Legacy servers, network devices, shared accounts, session brokering | Cloud roles, developer access, short-lived grants that expire on their own |
| Typical gaps | Privileged accounts stay privileged between check-outs | Systems that cannot grant or revoke roles through an API |
NIST SP 800-207 states that access "is granted on a per-session basis" with "the least privileges needed to complete the task", which is the goal JIT serves. Cloud providers now offer native JIT, for example Microsoft Entra Privileged Identity Management, where an eligible role assignment must be activated with steps such as MFA, justification or approval.
Non-human identities and AI agents
Machine credentials rarely have a human to notice misuse. HashiCorp's documentation for dynamic database credentials shows the pattern to test for: each service gets unique credentials, so questionable access can be traced to a specific instance. Google Cloud's Privileged Access Manager lets service accounts and agent identities self-elevate only when needed instead of holding roles permanently. For AI agents, the OWASP Top 10 for Agentic Applications recommends task-scoped, time-bound permissions and human approval for high-privilege or irreversible actions. See the AI Agent Authorisation Guide and the CI/CD Pipeline Identity Security Guide.
Evaluation criteria
Score each shortlisted platform from 0 to 5 per criterion in your own environment, multiply by the weight and add up. The weights below are suggested defaults: move weight to cloud and developer access in a cloud-first organisation, or to vaulting and session management in an estate dominated by legacy servers and suppliers.
| Criterion | Weight (suggested default) | What good looks like |
|---|---|---|
| Coverage of your privileged targets | 20% | Working integrations today for your servers, directories, clouds, databases, Kubernetes and SaaS admin roles, demonstrated rather than on the roadmap |
| JIT and zero standing privilege | 15% | Time-bound elevation across platforms with approval, justification and automatic revocation; works with native cloud JIT |
| Vaulting, rotation and discovery | 15% | Accurate continuous discovery; rotation with dependency handling and no outages; no credentials revealed to users where brokering is possible |
| Non-human identity and AI agent support | 15% | Short-lived or dynamic credentials for workloads, pipelines and agents; owners and reviews for service accounts; agent actions attributable and recorded |
| Session management and detection | 10% | Searchable recordings, command-level alerting, risk scoring and events streamed to the SIEM and ITDR |
| Developer and administrator experience | 10% | Native CLI, SSH and database client workflows; access in seconds; few extra steps |
| Security and resilience of the platform | 10% | Phishing-resistant admin MFA, dual approval for high-impact changes, protected infrastructure keys, tested break-glass and recovery |
| Operations and cost | 5% | Configuration over custom code, predictable licensing for human and non-human identities, realistic deployment effort |
Security of the PAM platform itself
Microsoft's guidance on privileged access intermediaries warns that "PIM/PAM solutions typically store the credentials for most or all privileged roles in the organization, making them a highly lucrative target to compromise or to weaponize". It also recommends a second person in business-critical workflows. The BeyondTrust Breach 2024 showed the supplier side: a compromised API key for a remote support SaaS service could reset local application account passwords on customer instances, and the US Treasury says the attacker used it to reach some of its workstations. Ask how the vendor scopes, protects and revokes its own infrastructure keys. See the API Key Management Guide.
Questions to ask vendors
- Show a developer getting just-in-time access to a production database and a Kubernetes cluster from the command line, with approval and recording.
- How do you rotate a service account password used by ten applications without an outage?
- How do you give cloud administrators zero standing privilege across our cloud providers, and how do you work with each provider's native JIT?
- How do you manage SSH keys, and how do you help us move to SSH certificates or identity-based access?
- How do pipelines, workloads and AI agents get privileged access, and can each action be traced to a specific identity and owner?
- How is the platform protected, what happens if it is unavailable, and what is your break-glass procedure?
- Which of your own keys or accounts could reach our environment, how are they scoped, and how fast can you revoke them?
- Can recordings and privileged activity logs be searched, alerted on and exported to our SIEM, and who can delete them?
Red flags
- Session recording without practical review: no search, no command-level alerting and no export.
- JIT that only covers a single platform: standing privilege stays everywhere else.
- Rotation that breaks dependent applications: teams will turn it off.
- Cumbersome developer workflows: engineers will bypass them with long-lived keys.
- Non-human identity support limited to storing passwords: no short-lived credentials, owners or attribution for workloads and agents. Hard-coded admin credentials in scripts remain a common finding; in the Uber Breach 2022 the attacker claimed to have found one in a PowerShell script, which Uber did not confirm.
- Vague answers about securing the platform, its administrators or the vendor's own infrastructure keys.
- A "silver bullet" pitch: claims that PAM alone removes device and endpoint risk.
Proof of concept
Run the proof of concept in your own estate. The targets in brackets are suggested defaults; set your own before testing starts and score every vendor against the same ones.
- Cover a representative set: Windows and Linux servers, one cloud, one database, one Kubernetes cluster, a SaaS admin role and one pipeline or agent identity. Success: all connected within the agreed PoC window without custom code.
- Test discovery accuracy against a list of known privileged accounts, SSH keys and embedded credentials. Success: the platform finds the seeded items (suggested target: at least 95%) and reports few false positives.
- Test JIT end to end for an administrator and a developer. Success: approval, MFA and justification enforced; access revoked automatically at expiry and confirmed in the target (suggested target: grant in under five minutes once approved).
- Rotate a service account with multiple dependencies. Success: rotation completes with no application failure and the old credential no longer works.
- Issue short-lived credentials to a pipeline or agent. Success: credentials are unique per workload, expire on their own and every privileged action is attributable.
- Review a recorded session for a risky action. Success: the action is found by search, an alert reaches the SIEM and the reviewer can see who approved the access.
- Attack the platform. Success: a high-impact admin change requires a second approver, and the platform's own admin and API identities are scoped and logged.
- Make the platform unreachable. Success: break-glass access works as documented and its use raises an alert. Microsoft, for example, recommends two or more emergency access accounts and testing them regularly.
Keep measuring after go-live. See the Identity Security Metrics Guide.
| Measure | What it shows | Target direction |
|---|---|---|
| Accounts with standing privileged access | Progress towards zero standing privilege | Down |
| Privileged credentials rotated on schedule | Vaulting and rotation work in practice | Up |
| Non-human identities with an owner and short-lived credentials | Machine and agent privilege is governed | Up |
| Time from approval to working access | Engineers will use the platform rather than bypass it | Down |
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-207 Zero Trust Architecture
- NIST: IR 7966 Security of Interactive and Automated Access Management Using Secure Shell (SSH)
- NCSC: Secure system administration
- OWASP: Non-Human Identities Top 10 (2025)
- MITRE ATT&CK: T1078 Valid Accounts
- Microsoft Learn: Securing privileged access overview
- Microsoft Learn: Securing privileged access intermediaries
- Microsoft Learn: What is Microsoft Entra Privileged Identity Management?
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for PAM and NHI security programmes. Browse PAM, secrets and NHI security vendors in our NHI and AI products directory, or contact us to discuss your evaluation.
Related NHI Mgmt Group resources: Privileged Access Management Guide · Secrets Management Buyer's Guide · NHI Security Platform Buyer's Guide · ITDR Buyer's Guide · Zero Trust Identity Guide