Open source PAM for public sector

Open source PAM for public sector: why agency admin access is different

If you run IT or security for an agency, admin access to systems holding citizen or criminal justice data must be tied to a named identity, recorded, and kept on infrastructure the agency controls. That requirement shapes every other choice in a bastion design. Commercial sectors often accept a vendor-hosted session broker and a contractual promise about logs. Public sector assessors usually want to see the control implemented in the agency's own boundary, with evidence that someone other than the administrator can examine it. The starting point is the system's security categorization. NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B selects low, moderate and high baselines containing 149, 287 and 370 controls and enhancements respectively. Which baseline applies depends on the impact rating of the system, so confirm that rating with your authorizing official before you size the access layer.

Oversight also differs. Under FISMA, Inspectors General independently assess agency system security and report to OMB, so the evidence you keep for privileged sessions will be read by people outside your team. If any part of the access path runs in a cloud service that handles federal information on an agency's behalf, FedRAMP scope applies, and a single-agency system on cloud infrastructure that is not offered as a shared service may fall outside it. Ask your legal and procurement teams to confirm that scope in writing. On the product side, Teleport issues short-lived certificates and can be deployed on premises, while JumpServer is a bastion with recording and asset-level permissions. Teleport's Community Edition is limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so most agencies will evaluate Enterprise, whose FedRAMP controls and FIPS binaries apply only to the self-hosted build. JumpServer's Enterprise tiers are priced by quote, and its community edition is licensed under GPL-3.0. DeployOpen prepares the systems, controls and evidence for an authorization, but it does not issue authorizations or attestations. Those decisions belong to your authorizing official and independent assessors.

Which public sector rules shape the PAM build

This table maps the federal and public administration rules most likely to shape an open-source PAM build to the design choices they affect: the bastion, session storage and gateway hosting. Read each row as a starting question for the agency's authorizing official and compliance team, since the applicable baseline depends on the system's authorization boundary and data types. The main takeaway is that the cryptographic module, recording retention and hosting location are usually settled by the rule set, not by the bastion product alone.

Rule or control	What it means for the bastion design	What the agency must confirm with its authorizing official
NIST SP 800-53 Rev. 5 access control and audit families	Expect the access control (AC) and audit and accountability (AU) families to drive per-user accounts, least privilege, session logging and log review. Map each bastion function to a specific control in the selected baseline.	Which baseline (low, moderate or high) applies to the system, and whether the bastion inherits controls from a shared platform or must document its own.
NIST SP 800-53B baseline selection	The baseline sets how many controls and enhancements the bastion and its recording store must satisfy. Higher baselines typically add stricter authentication, logging and alerting requirements at the gateway.	The security categorization of the systems behind the bastion and whether tailoring has been approved, recorded in the system security plan.
CJIS Security Policy v6.1 cryptography (FIPS 140-3 modules, AES-256)	Session traffic and stored recordings for criminal justice information need FIPS 140-3 validated modules or FIPS 197 AES with 256-bit keys outside physically secure locations. Confirm the bastion binaries and TLS libraries use validated modules, since open-source builds are not validated by default.	Whether the agency's CJI is in scope, which locations count as physically secure, and the validation certificate numbers the vendor or partner can provide.
CJIS Security Policy v6.1 vulnerability scanning	Monthly vulnerability scanning of the gateway, recording storage and host operating system must be scheduled and retained as evidence. Plan patch windows for the bastion, since it is a high-value target.	The scanning tool, cadence and who reviews results, and whether scan scope includes the bastion's container images or packages.
32 CFR 2002.14 and NIST SP 800-171 for CUI on non-federal systems	When the bastion or its recording store runs on a non-federal system holding CUI, agencies typically require NIST SP 800-171 requirements on access control, audit and multifactor authentication. Hosting in the agency's own infrastructure simplifies scoping.	Whether the CUI category prescribes other safeguards, and whether the non-federal hosting provider's environment is in the agency's assessment scope.
NIS2 public administration scope (Articles 2 and 3, Annex I)	Central government entities fall under NIS2 regardless of size, and Member States may extend it to local administration. Privileged account requirements then apply to the bastion, so its admin accounts and recorded sessions must be documented.	Whether the agency is a central or local entity under national transposition, and whether any function falls under the national security, defense or law enforcement exclusion.
NIS2 exclusion for defense and law enforcement	Bastions that front defense, national security, public security or law enforcement systems may fall outside NIS2 but still face sector rules. Keep one gateway design so that scope decisions do not fork the architecture.	Which systems are excluded, the legal basis for the exclusion, and whether a separate enclave or gateway is required for excluded systems.

Teleport or JumpServer for an agency: which fits which constraint

Teleport fits an agency team whose main need is SSH and Kubernetes access with short-lived certificates instead of shared keys. Its identity-aware proxy, certificate authority and session recording cover that workload from a single Go binary, and it is compatible with OpenSSH clients and servers. The catch for public bodies is the edition boundary. The Community Edition builds are licensed only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so most agencies will be evaluated against the Enterprise feature set from the start.

Certificate-based access: Users receive short-lived certificates, which removes standing SSH keys and Kubernetes tokens from the estate.
Protocol reach: Confirm SSH, Kubernetes and database coverage against the agency's inventory, including any Windows hosts.
Community threshold: Test the 100-employee and revenue limits against the agency's own headcount and classification before relying on Community builds.
Enterprise identity: Community single sign-on is limited to GitHub, so agency identity integration such as Microsoft Entra ID, Okta or SAML needs Enterprise.
Approval workflows: Roles can only be requested through the CLI in Community, so just-in-time access and reviews need an Enterprise quote.

Confirm in writing which edition, identity provider and protocol set the agency is buying.

Which open source platforms fit a public sector bastion

A public sector bastion usually combines an access gateway, a web-based access workspace, single sign-on tied to agency directories, and identity governance that removes access when staff move or leave. The cards below cover the components that connect these functions, along with the licensing and confirmation points that agency teams must settle before a design is approved.

Teleport for certificate-based access

Teleport issues short-lived certificates through its built-in certificate authority, so administrators do not hold long-lived shared SSH keys or Kubernetes tokens. It is compatible with OpenSSH clients and servers, which eases adoption on existing Linux estates. The key check for an agency is licensing: the Community Edition terms limit distributed builds to organizations under a defined employee and revenue threshold, and features such as moderated sessions, Device Trust and FIPS binaries sit in Enterprise. Confirm the edition before design starts.

JumpServer as the access workspace

JumpServer provides SSH, RDP, Kubernetes, database and web access from one workspace, which suits agencies that must support Windows administration alongside Linux. It is licensed under GPL-3.0. The Community edition is free for self-hosted standalone use up to a stated asset count, and Enterprise adds features such as ticket and just-in-time approval workflows, password rotation and SSO. Confirm the asset count, high availability needs and which approval features the agency requires before selecting the tier.

Keycloak for agency single sign-on

Keycloak brokers sign-in to agency directories through LDAP and Active Directory federation and speaks OpenID Connect and SAML 2.0, so the bastion and its admin consoles can sit behind one authentication flow. It is licensed under Apache-2.0. The main design question is where MFA and PIV or smart card evidence are enforced: at Keycloak, at the gateway, or both. Confirm how the agency's PIV credentials map to Keycloak authentication flows and which assurance level the policy requires.

midPoint for joiner, mover and leaver

midPoint is an identity governance platform that can provision and remove privileged accounts as staff join, change roles or leave, and run periodic access reviews. For an agency bastion this matters because the gateway is only as current as the account list behind it. It is licensed under EUPL 1.2 or later. Confirm the authoritative HR or contractor source, the review cadence the agency's policy requires, and which long-term support release the agency will standardize on.

OpenBao for credential vaulting

OpenBao stores and distributes secrets, certificates and keys under MPL-2.0 and is hosted under the OpenSSF, so it is a candidate for vaulting service credentials that the bastion injects or rotates. HashiCorp Vault 1.15.0 and later uses the Business Source License 1.1 with IBM named as licensor, which the Open Source Initiative does not approve as open source. Agencies with open source procurement rules should record that distinction. Confirm which key management and FIPS requirements apply to the vault itself.

PIV and MFA at the gateway: how the login chain works

The gateway should be the only place where an agency administrator proves identity, and every later step should trust that proof. In a typical design, the administrator authenticates to the identity provider first, using a PIV credential or another phishing-resistant factor, and the identity provider then passes a signed assertion or token to the bastion. Teleport can take this role through its identity-aware access proxy, issuing short-lived certificates after login, while JumpServer relies on its SSO and RADIUS or LDAP integrations for the same result. Whichever platform is chosen, the agency should document the exact chain: which identity provider issues the assertion, which claims carry the username and group membership, how long the resulting session lasts, and what happens when the PIV certificate is revoked. Confirm with the vendor whether PIV or smart card login is supported natively at the gateway or only through an upstream identity provider, because that choice decides where the PIV validation actually happens.

Unique user identification is the control that makes the recording useful. Under 45 CFR 164.312, which applies to healthcare entities rather than to most agencies, the same logic appears as unique user identification and audit controls, and agencies that handle comparable data often adopt it as a design pattern. In practice, each administrator should map to one named account at the gateway, linked to one identity in the directory, with no shared root or service accounts used for interactive sessions. Test this by logging in with two administrators through the same target and confirming that the session log, the certificate or token subject and the directory record all show the same person. Any shared account that remains should be listed as an exception with a documented owner.

The FIPS status of the gateway and the exact PIV integration method are the two items to settle before design sign-off. Ask the platform vendor which cryptographic modules the gateway uses, whether a FIPS-validated build exists for the version you plan to run, and whether that build is available under the edition you will license. Teleport's feature matrix states that FIPS binaries are limited to self-hosted Enterprise, so the answer changes the licensing discussion. Then confirm the integration method with the agency's assessor, who will decide whether the chain meets the authentication requirements applied to the system. Record the answers in the system security plan so the evidence matches the design.

How a public sector PAM rollout moves from scoping to audit evidence

The sequence turns an agency's admin access into identity-bound, recorded and retained sessions on infrastructure the agency controls, with each phase ending in a artifact an assessor or inspector can examine. The order matters because the baseline sets the controls, identity design sets the gateway, and retention decisions set what the evidence can prove later.

Scope the system and select the control baseline
The agency's security or compliance lead lists the systems that admin access reaches, classifies the information they hold, and maps them to a control baseline. NIST SP 800-53B defines low, moderate and high baselines, so the team should confirm which baseline its authorization requires and whether any system falls under a separate regime such as FBI CJIS Security Policy. Named owners, a system boundary and an agreed list of in-scope protocols (SSH, RDP, Kubernetes, databases) are the output. The step is done when the boundary document is signed by the authorizing official or equivalent owner.
Design identity, PIV and MFA at the gateway
The identity team decides how administrators are identified and authenticated before they reach the bastion. The design covers the authoritative directory, whether PIV or another phishing-resistant factor is required for each role, how unique administrator identities differ from everyday accounts, and how the gateway trusts the identity provider. Teams should confirm with their agency's identity office which federal or agency credential policies apply. The output is a written authentication matrix by role and target system, reviewed by security staff.
Build the bastion in an agency-controlled environment
Engineers deploy the bastion, such as Teleport or JumpServer, inside the agency's own cloud account, data center or enclave, so that session data and credentials stay under agency control. They configure the gateway, certificate or session policies, network paths to targets and logging to the agency's monitoring. Edition-dependent features such as SSO connectors, moderated sessions or FIPS binaries are checked against the chosen edition before build. The step closes with a reproducible configuration record and a test report showing that direct access to targets is blocked except through the gateway.
Decide recording storage and retention
The agency decides where session recordings are written, how long they are kept, who can search or play them, and how they are protected from alteration. Retention periods come from the agency's records schedule and the frameworks that apply, not from the tool's defaults, so legal and records officers must sign off. Storage sizing depends on session volume and recording settings, which should be measured during the pilot. The output is a retention schedule, an access list for recordings and a documented integrity approach for the recording store.
Pilot with a limited group of administrators
A small set of named administrators uses the gateway for real work against a defined list of systems, while the team keeps existing access in place as a fallback. The pilot tests login paths, approval steps, recording quality, playback for reviewers and the behavior of break-glass accounts. Problems found here are logged with owners and fixed before the wider cutover. The step is complete when the pilot group has run through every role in the authentication matrix and the defects list is closed or accepted in writing.
Cut over and remove shared credentials
The team moves all administrators in scope onto the gateway, then disables direct logins and retires shared or static privileged credentials on the targets. Vaulted or rotated credentials replace any remaining shared passwords where the platform supports it. Each removal is recorded with the date, the system and the approver. The output is an inventory showing that no in-scope target accepts direct administrative login outside the gateway, verified by a follow-up access test.
Hand over evidence for assessment
The team packages the evidence an assessor, inspector or internal auditor will sample: the boundary and baseline decisions, the authentication matrix, the configuration baseline, the admin access list, approval records, sample session recordings with metadata, retention settings and the cutover inventory. Each artifact is mapped to the control it supports. DeployOpen prepares these materials, but independent assessors decide whether controls are effective. The step closes when the agency's owner accepts the evidence package and the agency has a written owner for ongoing access reviews.

Evidence an agency assessor or Inspector General will ask for

This table maps each piece of evidence an agency assessor or Inspector General typically requests for privileged access to the component that produces it and the edition condition that affects it. Read each row as a question to ask your implementation partner before the bastion goes into production. The main takeaway is that recordings, approvals and retention settings are only as useful as the records you can export, and several of them depend on whether you run Community or Enterprise editions.

Evidence	Producing component and edition condition	What the assessor checks
Named admin account list	Teleport user and role records or JumpServer user and asset permission exports; export is available in both editions, but confirm the export format with the vendor	Each privileged person has a unique named identity, with no shared root or local admin accounts
Authentication records showing PIV or MFA use	Keycloak event logs for the identity provider; Teleport authentication audit events; PIV or MFA enforcement depends on the chosen factor and on Teleport Enterprise features for device and identity controls, so confirm the setup	Strong authentication applied at the gateway for every privileged session, with failures and exceptions recorded
Session recordings with playback	Teleport session recording with playback is included in both editions; JumpServer session records and recording transcoding are part of its platform, with some components in Enterprise	Who connected, when, to which system and what commands or screens were used, retrievable on request
Approval and break-glass records	Teleport moderated sessions and dual authorization are Enterprise-only; JumpServer ticket and just-in-time approval workflows are Enterprise features	Each elevated or emergency session has a documented requester, approver, reason and expiry
Retention settings and storage location	Recordings and logs held on the agency's own storage, configured in the gateway and forwarded to the SIEM; confirm retention periods against the agency's records schedule	Retention matches the policy, recordings cannot be altered, and storage sits inside the authorized boundary
Vulnerability scan results at the required cadence	Scan output from the scanner the agency selects, covering the bastion host, gateway components and recording store; cadence set by the applicable baseline, such as monthly scanning under CJIS Security Policy v6.1	Scans run at the cadence the baseline requires, findings are tracked to remediation and the bastion is in scope
Change records for gateway upgrades	Ticketing system plus version history from the release notes of Teleport (for example, 18.11.4 on October 14, 2026) or JumpServer releases; the SIEM receives the upgrade log	Upgrades are tested, approved, dated and traceable to the version deployed

Questions agencies ask before hiring a PAM partner

What drives the cost of an open source PAM project for an agency?

The main drivers are the edition you need, the number of assets and users, how much session recording you keep, how highly available the gateway must be, and how much accreditation paperwork the agency expects. JumpServer's pricing page separates a free self-hosted Community edition, limited to 5,000 assets in a standalone topology, from Enterprise tiers priced by quote, with HA tiers at Standard and above. Teleport's pricing page says customers pay for active users and protected resources, and it does not publish prices. Recording storage and the labor to document controls recur over time, while design, deployment and the first assessment package are largely one-time. Ask any partner for a quote that itemizes licenses, storage sizing, gateway HA, documentation and support as separate lines.

How long does a PAM rollout take in a government environment?

The duration depends mainly on how many systems must be onboarded, how many identity sources must be connected, and how long the agency's approval and accreditation steps take. Each protocol and system family adds configuration and testing, and recordings must be routed to storage the agency controls before go-live. No general duration is supplied for this work, so ask the partner to state phases, dependencies and the agency decisions each phase waits on, and to tie the timeline to a written, fixed scope. Pilot onboarding of a small set of administrator groups usually shows the real pace before the wider rollout is committed.

What does the agency's own staff need to provide for a PAM project?

The agency typically supplies four things: its identity sources (for example, directory services and the single sign-on or MFA system the gateway will trust), a current inventory of servers, databases, Kubernetes clusters and network devices with named owners, the list of roles and the people who approve privileged access, and an authorizing official who accepts the risk and the security plan. Staff also need to confirm which network zones and enclaves the bastion may sit in. Without a reliable inventory, onboarding slips, so ask the partner to define the inventory template and the decisions it needs before work starts.

Can an agency run open source PAM without an outside partner?

Yes, an agency with experienced platform, security and compliance staff can run JumpServer or Teleport itself, since both are self-hosted and have public documentation and source code. The harder parts are usually sustained: applying upgrades, handling security patches, keeping HA and backups tested, producing evidence for assessors, and supporting administrators after hours. A partner can cover planning, hardening, integration, documentation and support under a fixed scope or retainer. Ask the partner which of these tasks it would hand over to the agency, and which it would keep, so the agency can compare the staffing load against its own team.

Is Teleport Community Edition allowed for a government agency?

Agencies should not assume it is. The Teleport 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. Most agencies will exceed that employee threshold, so they should plan for an Enterprise license if they choose Teleport. Teleport's feature matrix also limits FedRAMP controls and FIPS binaries to self-hosted Enterprise, and it limits Community single sign-on to GitHub. Ask legal and procurement to confirm the license position with Teleport before any build is deployed.

How are session recordings stored and retained inside the agency boundary?

Recordings should live on storage the agency controls, inside the same boundary as the bastion, with access restricted to a defined audit role. Teleport's feature matrix includes session recording with playback in both editions, and JumpServer supports session recording with a transcoding worker in its Enterprise components. Retention periods come from the agency's records schedule and the frameworks that apply, so the design must set how long recordings are kept, how they are encrypted, how integrity is checked, and how they are exported to a SIEM. Ask the partner to show where each recording is written, who can replay it, how deletion is logged and how a recording is produced for an auditor.

Which compliance evidence should a PAM partner prepare for an agency?

A partner can prepare the configuration, role and approval records, session logs, MFA settings and architecture documents that map to the agency's control baseline, including the NIST SP 800-53 Rev. 5 controls that the agency's baseline selects. Relevant federal rules such as the FBI CJIS Security Policy, which requires FIPS 140-3 certified modules or AES with 256-bit keys for CJI at rest and in transit outside physically secure locations, shape the cryptography choices. Partners do not issue audit reports or authorizations, so the agency must engage its assessors and authorizing official. Ask which evidence items the partner will deliver and in what format.

What to ask an implementation partner before signing

Start with the edition, because the answer decides which controls exist at all. Ask the partner to name the exact edition of Teleport or JumpServer they propose, and to confirm in writing whether that edition supports the agency's required authentication, such as PIV smart cards or other MFA at the gateway, and whether it ships FIPS-validated binaries or relies on FIPS-capable builds. Teleport's feature matrix limits FIPS binaries and FedRAMP controls to self-hosted Enterprise, so ask for the matrix line item for each requirement, not a general statement of support. Ask for the written license terms that apply to agency use, including how the Teleport Community Edition threshold applies to a government body, and what JumpServer features the quote depends on, such as SSO, LDAP HA or approval workflows, which the pricing comparison lists as Enterprise features. Any gap should appear in the signed scope, not in a later change order.

Next, pin down where the session recordings live and how long they stay there. Ask which storage location the design uses, who can read it, whether recordings are encrypted at rest with keys the agency controls, and how retention and deletion are enforced and logged. The partner should also show how recordings are searched and exported for an investigation or an inspector general request, and how a legal hold would stop deletion. On the evidence side, ask the partner to map each control to the agency's baseline, such as the NIST SP 800-53 Rev. 5 controls selected by the agency's low, moderate or high baseline, and to state which items are produced by the platform, which by configuration, and which by agency process. A partner that prepares evidence but does not issue assessments should say so plainly. Ask who holds the platform's own administrator credentials, how those accounts are separated from daily admin identities, and whether break-glass access is recorded, because a bastion that its own administrators can bypass fails the review it was built for.

Finally, settle deployment and maintenance before the contract is signed. Ask whether the design runs fully on agency infrastructure, whether it works with no outbound internet access, and how installation media, container images and updates reach an isolated network. Ask for the upgrade and patch process in writing: the release cadence the partner will follow, how security patches are tested and approved, how a rollback works, and who performs each step in a fixed-scope engagement and who does so under a retainer. Confirm the support path for each edition, including any response commitments, which should appear as stated terms rather than assumptions. Ask how the partner documents the configuration so that agency staff can run it after handover. Each answer should be recorded in the statement of work, so the agency can check it against the platform it actually receives.

How DeployOpen scopes and supports public sector PAM

The sequence below shows how an agency moves from a bastion design question to a running, documented and supported privileged access layer on its own infrastructure, with assessment evidence prepared but authorization left to the agency and its assessors.

Confirm the agency's authorization boundary
DeployOpen works with the agency's security office, records owner and assessor to establish which systems, networks, identity sources and administrator populations fall inside the privileged access scope. The agency confirms which frameworks apply, such as NIST SP 800-53 baselines, FBI CJIS Security Policy or CUI requirements, and whether any cloud component is in scope for FedRAMP. The output is a written scope statement that both parties sign before design begins.
Design the bastion and identity path
DeployOpen documents the gateway topology, network zones, high availability approach and how administrators reach it, including where PIV or other multi-factor authentication is enforced. The design also covers the identity provider integration and which edition features the requirements depend on, such as SSO, access requests or FIPS builds. The agency reviews the design against its own policies. Done means an approved architecture diagram and a requirements-to-controls mapping.
Set recording, retention and evidence rules
DeployOpen and the agency define what session recordings capture, where they are stored inside the agency's infrastructure, how long they are kept under the agency's records schedule, who can search or play them, and how integrity and access to recordings are controlled. The agency confirms retention periods with its records officer and legal counsel, since no retention figure is set here. Done means a written retention standard and a sample recording reviewed by the agency.
Build and harden the platform in place
DeployOpen installs the chosen open-source platform, such as JumpServer or Teleport, inside the agency's own cloud accounts, data center or enclave, then applies the hardening baseline agreed in the design. This includes host configuration, cryptographic settings, logging to the agency's monitoring tools, and disabling unused protocols. Changes are made through code or documented configuration where possible. Done means a hardening record that maps each setting to a requirement and passes the agency's acceptance checks.
Integrate with identity, logging and target systems
DeployOpen connects the gateway to the agency's directory, multi-factor service, SIEM and the servers, databases and Kubernetes clusters in scope, then tests each path with named administrator accounts. Vendor and break-glass paths are tested separately under the agency's approval rules. Done means a test log showing that every in-scope target is reachable only through the gateway, with recordings and audit events arriving at the agency's systems.
Prepare controls and evidence for assessment
DeployOpen assembles the operational evidence an assessor will request, such as access lists, approval records, session logs, configuration baselines and change history, and maps each item to the relevant control. DeployOpen does not issue audit reports, authorizations or certifications. Independent assessors or the authorizing official make those determinations. Done means an evidence index the agency has reviewed and can hand to its assessor.
Document, hand over and support
DeployOpen delivers runbooks for administrators, operators and the agency's security staff, including account onboarding, break-glass use, recording retrieval and upgrade steps. The agency's staff are trained on these procedures. Ongoing support, upgrades and continuous testing can be contracted as a retainer, with the scope written out in advance. Done means signed handover documents and an agreed support scope, with the decision on any retainer made separately.

Open source PAM for public sector