How to use this privileged access management requirements checklist
Administrators, vendors and engineers all need access to servers, databases and Kubernetes clusters, and the team has to agree on what that access must look like before anyone compares platforms. This checklist gives the group a shared list of requirements to sign off. It is organized into functional, security, integration, operational and compliance groups. Functional items cover which protocols must be brokered, such as SSH, RDP, Kubernetes and databases. Security items cover session recording, approvals, just-in-time elevation, credential vaulting and MFA. Integration items cover the identity provider and SIEM. Operational items cover high availability, upgrades and backup. Compliance items cover the evidence your assessors will ask for.
Treat every item as a question to verify, not a box to tick from a feature list. Each requirement should be confirmed in a proof of concept on your own network, or in a written response from the vendor or implementation partner that names the edition and version concerned. Pay particular attention to the edition column: in Teleport, for example, the feature matrix places just-in-time access requests, moderated sessions and dual authorization in Enterprise, and in JumpServer, ticket-based approval workflows and password rotation are listed among Enterprise features. In practice, the requirements you cannot drop, such as approvals on vendor sessions or single sign-on through your own directory, usually decide the edition long before the feature comparison does. Confirm current edition terms with the vendor, because licensing thresholds and tier contents change.
Be clear about what this checklist cannot do. It helps your team define requirements and test them, but it does not produce an audit report, attestation or certification. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue the findings. Keep the completed checklist, the proof-of-concept results and the written vendor answers together, because they become the starting point for the evidence your assessor will request.
Functional requirements: protocols, recording and approvals
This table lists the functional requirements to agree before choosing a PAM platform, with why each matters and how to verify it. Use it to test each candidate against your own protocols and approval rules, not against a generic feature list. The main takeaway is that several controls, including moderated sessions, dual authorization and ticket-based approvals, sit in paid editions on some platforms, so verify edition limits early.
| Requirement | Why it matters | How to verify |
|---|---|---|
| SSH access to servers | Shared keys and unmanaged root logins make it hard to tie an action to a named person; certificate-based or proxied access gives per-user accountability. | Confirm the platform issues per-user, time-limited credentials and works with your existing OpenSSH clients and server configuration in a pilot. |
| RDP and VNC access to Windows and desktop hosts | Administrators and vendors often work through graphical sessions, which need the same recording and credential control as shell access. | Apache Guacamole supports VNC, RDP and SSH; for Teleport and JumpServer, confirm RDP and VNC support and proxy options for your Windows versions. |
| Kubernetes and container access | Cluster admin rights are broad, so access should be scoped by role, namespace and identity, with commands and sessions attributable. | Test a role limited to one namespace, then confirm the audit trail records the user, cluster and action. Teleport protects Kubernetes clusters; confirm the same for other tools. |
| Database access (Oracle, SQL Server, PostgreSQL, MySQL) | Direct database admin access bypasses application controls, and regulators expect those sessions to be attributable and logged. | Confirm each engine you run. Guacamole documents MariaDB or MySQL, PostgreSQL and SQL Server authentication backends. JumpServer lists Oracle and SQL Server access as an Enterprise feature, so confirm the edition. |
| Session recording, playback and retention | Examiners and auditors sample recorded sessions, so recordings must be complete, searchable and kept for the period your framework requires. | Record a test session, play it back, and confirm where recordings are stored, how long they are kept and whether storage sits inside your boundary. Teleport includes session recording with playback in both editions. |
| Moderated sessions and dual authorization | Two-person control over high-risk sessions is a common control, and it often decides whether a platform fits regulated production access. | Teleport lists moderated sessions and dual authorization as Enterprise features. Confirm the same for any other candidate before shortlisting it. |
| Just-in-time access requests and approvals | Standing admin rights are hard to justify; time-limited, approved elevation with a recorded reason is easier to evidence. | In Teleport Community Edition, roles can only be requested through the CLI; JIT requests and reviews are part of Enterprise Identity Governance. JumpServer lists ticket and just-in-time approval workflows as Enterprise features. Test an approval end to end. |
| Break-glass access | Emergency access must work when the identity provider or approval service is down, and every use must be logged and reviewed afterwards. | Document the break-glass path, test it during a planned outage, and confirm the account is alerted on, time-limited and reviewed. Ask vendors how this works without the approval workflow. |
Security requirements: vaulting, rotation, SSO and MFA
Credential handling and sign-in are where PAM platforms differ most by edition, so agree these requirements before comparing products. The four cards below cover how access credentials are issued and retired, which single sign-on and MFA options each product supports, and the hardware and device controls some buyers require.
Short-lived certificates versus shared keys
Decide whether administrators will keep using shared SSH keys and Kubernetes tokens, or move to identity-issued credentials that expire on their own. Teleport issues short-lived certificates and states it is fully compatible with OpenSSH servers and clients, so existing tooling can often stay in place. Confirm with the vendor which client versions, bastion paths and automation accounts still need long-lived keys, because those become the exceptions your audit will ask about. Ask for an inventory of every shared credential before rollout.
Password vaulting and rotation
Check whether the platform stores target account passwords, injects them into sessions so users never see them, and rotates them on a schedule or after each use. JumpServer lists password rotation as an Enterprise feature, so a Community deployment may need a separate secrets tool for this. Confirm rotation support for each target type you run, including Oracle, SQL Server and network devices, and confirm where the vault keys are held and who can recover them.
Single sign-on and identity provider fit
List the identity providers your workforce uses and test each one against the edition you plan to run. Teleport Community Edition limits single sign-on to GitHub, while Enterprise supports Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML. JumpServer lists SSO as an Enterprise feature. Guacamole supports Active Directory, LDAP, CAS, OpenID Connect, SAML and smart card extensions, so a browser gateway may fit a mixed directory better. Confirm group mapping and session timeout behavior with a test tenant.
MFA, HSM, FIPS and Device Trust
Write down which second factors are required for privileged logins, whether hardware keys are mandatory, and whether a managed device must be trusted before a session starts. Guacamole documents Duo and TOTP extensions, which covers many but not all factor types. Teleport lists Device Trust, HSM support and FIPS binaries as Enterprise features, with FIPS binaries available only in self-hosted Enterprise. Ask each vendor to confirm which of these exist in your chosen edition and build before you accept them as requirements.
Which PAM requirements sit in paid editions
Build the edition matrix before you shortlist vendors. Take each requirement from this checklist (protocols, session recording, approvals, vendaor credential rotation, SSO and MFA, high availability and support) and record, for each candidate platform, whether the Community Edition includes it, whether it needs a paid edition, and whether the vendor's own documentation says so in writing. Mark anything you cannot confirm as open. This turns a general feature list into a concrete record of what you would pay for, and it makes the licensing decision visible early instead of after a pilot. Two license limits decide the edition question for many organizations. Teleport's Community Edition license makes the distributed builds available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Check that threshold against your own headcount and revenue, including affiliates if your counsel treats them as one organization. JumpServer's free Community edition covers up to 5,000 assets in a standalone topology, so count assets, including the ones you expect to add during the first year, before you assume the free tier fits.
High availability and support terms change the decision more than most buyers expect. JumpServer's pricing separates active-standby high availability (Standard and Pro tiers) from a full HA cluster (Ultimate tier), and lists LDAP HA among Enterprise features, so a bastion that must survive a node failure may require a paid tier even when the asset count fits the free limit. Ask each vendor how failover works, what state is replicated, and whether recording storage and the session proxy fail over together. Support terms also differ: JumpServer's Community edition is supported through GitHub and the forum, while Enterprise adds email and ticket support with an SLA and an account manager. Ask which response times apply to your severity levels. Request each vendor's current edition comparison in writing and attach it to your requirements record, because feature matrices change between releases. Ask the vendor to confirm, per requirement, which edition includes it, the version where it first appeared, and any limits on protocols, asset counts or user counts. Ask whether approvals, dual authorization, access reviews and identity provider integrations are included in the price you are quoted. Confirm your identity provider and SIEM integration requirements against the edition the quote covers, not the edition in the marketing summary.
Integration requirements: identity provider, SIEM and ticketing
A PAM platform rarely works alone. It needs to authenticate people through your directory or identity provider, send session and command events to your monitoring stack, route approvals through your ticketing system, and read asset or account data from wherever your inventory lives. Agree each connection, its export format and its owner before you compare products.
Identity provider federation
Decide whether the PAM tool authenticates against Active Directory or LDAP directly, or against a federated identity provider using SAML or OpenID Connect. An open source identity provider such as Keycloak can sit in front of the PAM tool, handle MFA and pass group claims through, so the PAM platform does not need its own user store. Check which SSO protocols the edition you need supports, and confirm how group membership maps to PAM roles. Test what happens when the identity provider is unavailable, including break-glass login.
LDAP and Active Directory sync
Many organizations keep privileged group membership in Active Directory or LDAP and expect the PAM tool to follow it. Confirm whether the tool reads users and groups directly, how often it syncs, and whether removing a user from a group revokes live sessions and access. Ask whether service accounts can bind for lookups without holding domain admin rights, and whether sync works across several domains or forests.
SIEM forwarding for session and command events
Audit events from the PAM tool should reach your SIEM, such as Wazuh, in a structured format with timestamps, user identity, target system, source address and, where recorded, executed commands. Confirm the export method (syslog, webhook, file or API), the field names, and whether session recordings stay on the PAM server or can be indexed. Verify that events arrive with the original user identity, not a shared gateway account, and that delivery failures are logged.
Ticketing systems for approvals
Access requests and approvals often live in a ticketing system, so the PAM tool must either provide its own approval workflow or accept approvals from an external system. Confirm whether approvals can be tied to a ticket identifier, whether the approver must be different from the requester, and how the tool behaves when the ticket system is down. Note that some approval and ticket workflows are listed as Enterprise features on some PAM products, so confirm the edition before you design around them.
Asset inventory and cloud sync
The PAM tool needs an accurate list of target systems, accounts and cloud resources. Decide whether assets are entered by hand, imported from a CMDB, or synchronized from cloud provider APIs. Ask how new instances are discovered, how decommissioned systems are removed, and whether account lists refresh on a schedule. Stale inventories create gaps where privileged access is granted outside the tool, so check how drift is detected and reported.
Secrets store connection
If the PAM tool injects or rotates credentials, it has to connect to a secrets store such as OpenBao, HashiCorp Vault or Infisical. Confirm which stores the tool supports natively, which authentication method it uses to reach the store, and who owns the root or unseal keys. Check the license of the secrets store before you choose it, since HashiCorp Vault 1.15.0 and later uses the Business Source License 1.1, which is not an OSI-approved open source license. Test rotation and failover in a proof of concept.
Operational requirements: high availability, upgrades and support
This table lists the operational requirements to agree before choosing a PAM platform, covering availability, backup, release tracking, footprint, storage, support and offline patching. Read each row as a question to answer in writing, then use the verification column to test the answer in a proof of concept or a vendor response.
| Requirement | What to agree | How to verify |
|---|---|---|
| High availability design | Whether the gateway must survive a node failure during business hours, and whether the edition you need supports active-standby or clustered deployment. JumpServer lists HA tiers by edition, and Teleport HA depends on your deployment design. | Confirm the HA model for your chosen edition in writing, then test failover of the gateway and the session path during a proof of concept. |
| Backup and restore of recordings and configuration | Which items must be restorable: database, recording storage, roles, policies, certificates and integration settings. Agree a restore time you can defend to your auditor. | Run a full restore into a separate environment and confirm that recorded sessions play back and that roles and approvals match production. |
| Upgrade cadence and release tracking | Release timing differs by project. Teleport 18.11.4 was released on October 14, 2026, following 18.11.3 on October 2, 2026 and 18.11.0 on August 25, 2026. JumpServer v5.1.0 was published on October 15, 2026, after v5.0.0 on September 17, 2026. Agree which release train you will follow and how fast security patches must land. | Ask the vendor or partner for its release notes, deprecation policy and upgrade path between major versions. Test an upgrade on a copy of production before scheduling it. |
| Installation footprint | JumpServer's quickstart asks for a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM. Confirm whether your production topology needs more capacity, separate nodes or a Kubernetes deployment, and whether the database and recording storage sit on the same host. | Build the target topology in a test environment and measure CPU, memory and disk use under a realistic session count before approving the design. |
| Storage sizing for recordings | Recording volume depends on session count, session length, protocol and whether recordings are transcoded. Agree retention periods from your framework and sector rules, plus the growth rate you expect. | Run a sample of typical sessions, measure the stored size per hour of activity, and project storage for the full retention period. Confirm where recordings are encrypted and how they are replicated. |
| Support channels and SLAs | Community support and paid support differ. JumpServer Community is supported through GitHub and the forum, while Enterprise adds email and ticket support with an SLA and an account manager. Teleport support terms depend on the edition and contract. | Request the written SLA, severity definitions, response targets and escalation path for each edition you evaluate. Confirm who answers when a partner and a vendor disagree. |
| Offline patching | If the environment is air-gapped or change-controlled, agree how packages, container images and signed artifacts reach the enclave, who approves them and how long a patch cycle takes. | Perform a dry run of media transfer, checksum verification and an offline upgrade, and record the steps as a change record your assessor can review. |
Compliance requirements the checklist must map to
Two US rules set the baseline for most privileged access requirements in this checklist. The HIPAA Security Rule at 45 CFR 164.312 asks covered entities and business associates for unique user identification, audit controls that record and examine activity in systems that hold ePHI, person or entity authentication, and transmission security. For a PAM platform, that means every administrator, vendor and engineer session must trace to a named individual rather than a shared root or service login, and the session logs must be retained and reviewed in a way you can demonstrate. The FTC Safeguards Rule at 16 CFR 314.4 asks covered financial institutions to require multi-factor authentication for any individual accessing any information system, to encrypt customer information in transit and at rest, and to monitor and log the activity of authorized users. Both rules point to the same checklist items: named identities, MFA at the gateway, and recorded sessions.
Turn each requirement into a named piece of evidence before you choose a platform. For unique identification, the evidence is the list of individual accounts mapped to the identity provider, plus a sample showing that no shared credential reaches a target system. For authentication, it is the MFA policy configuration and login logs from the gateway. For audit controls, it is the session recording inventory, the retention settings, and records showing who reviewed which sessions and when. Ask whether the recording format is searchable and whether recordings can be exported in a form your assessor can read. Confirm these details with each candidate platform and in your own environment, since the features that produce this evidence differ between community and enterprise editions.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, and your counsel or compliance lead should confirm which provisions apply to your organization. In practice, an implementation partner can configure the gateway, document the access model, and package the evidence described above so that your assessor can test it. Agree in writing, before work starts, which requirements the scope covers and which evidence each deliverable produces.
How to agree requirements before choosing a platform
This sequence turns vague expectations about privileged access into a signed requirement list that names the systems, protocols, recording rules, approval paths, identity sources and edition limits a PAM platform must meet. Each step closes with a document or test result that the next step relies on.
Inventory target systems and protocols
Start by listing every server, database, Kubernetes cluster, network device, web console and Windows host that privileged users reach, along with the protocol each one uses, such as SSH, RDP, Kubernetes API, or a native database client. Record who reaches each system today (employees, engineers, vendors) and through which path, including shared accounts and VPN or jump host routes. Ask the infrastructure owners to confirm the list. The step is done when each system has an owner, a protocol and an access path written in one register that every later step uses.
Classify sessions and retention by regulation
For each system group, decide which sessions must be recorded, how long recordings and logs must be kept, who may view them and where they must be stored. Map these decisions to the rules that apply to your organization, such as the HIPAA audit controls in 45 CFR 164.312 or the monitoring and logging duties in 16 CFR 314.4, and confirm the interpretation with your compliance lead. Note whether recordings must stay inside your own network and whether you need search and playback. The output is a retention table per system group, signed by compliance.
Set approval and break-glass rules
Define which access requires a request, which approver signs off, how long elevated access lasts, and whether a second person must be present during a session. Write a separate break-glass procedure for emergencies, covering who holds emergency credentials, how use is logged, and how the account is reviewed afterwards. Check which of these controls are in the community edition and which need the commercial edition, as the Teleport and JumpServer feature matrices differ on moderated sessions, dual authorization and ticket workflows. The step is complete when the approval matrix and break-glass runbook are reviewed by security and operations.
Confirm identity sources and MFA
List every directory and identity provider that must authenticate administrators and vendors, including Active Directory, LDAP, an existing SSO service or a new one, and how contractor identities are created and removed. Confirm which MFA methods are required and whether hardware tokens or passkeys are expected. Verify with the platform's documentation which single sign-on and directory integrations are included in each edition, since some are limited to paid tiers. The output is an identity source sheet that states, for each group of users, where identity comes from and how MFA is enforced.
Run a proof of concept against edition limits
Choose two or three representative systems, one per critical protocol, and test the candidate platform end to end: a login through the agreed identity source, an approved elevation, a recorded session, playback, and a break-glass use. Record which features work only in a paid edition, the asset and user counts that trigger a tier change, and the hardware and high availability design each tier needs. Ask the vendor or implementation partner to confirm any capability you cannot test yourself. The step closes with a written test report listing pass, fail and open items.
Sign off the requirement list
Consolidate the register, retention table, approval matrix, identity sheet and proof of concept results into one requirement list. Ask security, compliance and operations owners to each sign it, noting any requirement they accept as out of scope and any they reject. Also record the open items the platform must resolve before go-live and the questions to put to vendors or partners. The step is done when the signed document is the single reference for vendor evaluation, quoting and the implementation scope.
Questions buyers ask about PAM requirements
How long does it take to agree privileged access requirements?
The time depends on how many systems, protocols and approval chains are in scope and how many teams must sign off. Requirements usually stall on three points: which admin paths must be recorded, who approves vendor and emergency access, and how long recordings must be kept. Organizations with a clear inventory of privileged systems and an identity provider already in place move faster because the open questions are narrower. Ask any implementation partner for a written scope and a list of the decisions that must come from your side before they can give a timeline.
What does defining PAM requirements cost, and who gets paid?
Defining requirements is mostly internal effort: security, identity, compliance and the platform teams review access paths, regulatory obligations and existing tooling. Costs rise when a partner runs discovery workshops, inventories servers, databases and Kubernetes clusters, or maps controls to a framework your auditors use. These are usually one-time costs, while the work of keeping the checklist current recurs whenever systems or regulations change. DeployOpen does not publish prices. Ask for a written quote that lists the discovery activities, the deliverables and who from your side must attend.
Can our own team write a PAM requirements checklist?
Yes, if the team can answer the questions that shape the choice: which protocols reach production, where session recordings must be stored, how approvals work, how credentials are vaulted and rotated, and which identity provider and MFA methods apply. Internal teams often miss the edition questions, such as whether approval workflows, SSO or high availability sit in a paid tier. Reviewing the checklist with an outside party who has run a PAM rollout catches gaps before procurement starts. Your auditors and the business owners of critical systems should also review it.
Which PAM requirements push the edition cost up?
Edition cost usually follows a few features rather than the basic bastion function. Commercial-grade items to check include moderated sessions and dual authorization, just-in-time access requests with reviews, device trust, SSO with enterprise identity providers, password rotation, and high availability. For example, Teleport's feature matrix limits Community Edition single sign-on to GitHub, and JumpServer's pricing comparison places ticket and just-in-time approval workflows and password rotation in its Enterprise tiers. Ask each vendor to confirm in writing which edition includes every requirement on your list.
What does a PAM proof of concept need from our side?
A proof of concept needs a defined set of test systems, a test identity provider or a copy of production directory settings, and named testers who represent administrators, vendors and auditors. It also needs agreed success tests, such as recording a session end to end, denying access without MFA, approving a time-limited elevation and retrieving a recording for an examiner. Test networks should match the production network zones so firewall and proxy behavior is realistic. Ask the partner to write the test cases and acceptance criteria before the environment is built.
How do we compare Teleport, JumpServer and Guacamole fairly?
Start from your requirements, not from a product. Score each option against the same protocol list, recording and retention rules, approval workflow, identity integration, licensing terms and operating model. Teleport issues short-lived certificates and protects SSH, Kubernetes and several databases, while JumpServer is a PAM platform and bastion with a broader set of protocols in one workspace. Apache Guacamole is a clientless gateway for VNC, RDP and SSH from a browser, and its manual lists its own authentication extensions and recording player. Run the same test cases on each candidate and weigh the results against the edition limits you found in the checklist.
Can an implementation partner help define PAM requirements?
Yes. An implementation partner can run discovery, document privileged paths, draft the checklist, map requirements to controls your auditors examine, and test candidate platforms against the same criteria. DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms in your own infrastructure, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Most engagements are fixed-scope, so ask for the scope, deliverables and timeline in writing before work starts and confirm which items are included in the quote.
How DeployOpen scopes and delivers PAM selection and implementation
DeployOpen turns this checklist into a written scope before any platform is chosen, then plans, implements and hardens the chosen open-source PAM platform inside your own infrastructure. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm which protocols, databases and Kubernetes clusters the PAM platform must reach, and which are in scope for the first phase.
- Agree session recording retention, storage location and who may review recordings before any platform is selected.
- Record which requirements depend on paid editions, such as just-in-time approvals, SSO options and high availability, in the written scope.
How we build
- Deploy the chosen platform in your cloud accounts, data center or air-gapped network, with identity provider and MFA integration.
- Configure roles, approval workflows, credential vaulting and rotation according to the agreed requirements matrix.
- Test access paths, session recording and break-glass procedures against the written acceptance criteria before go-live.
How we hand over
- Deliver architecture, configuration and runbook documentation so your administrators can operate and audit the platform.
- Provide evidence packs of access lists, approval records and session logs to support your internal and external assessors.
- Train named administrators on daily operation, recording review and upgrade procedures before the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing of the PAM platform as a retainer after handover.
- Review each platform release and edition change against the agreed requirements before applying updates.
- Maintain backups and documented restore procedures for configuration, credentials and session recording storage.
