Open source PAM for CMMC privileged remote access

Open source PAM for CMMC privileged remote access: what the assessment asks for

A defense contractor with CUI systems, administrators who work remotely and a 110-requirement model under NIST SP 800-171 Rev. 2 needs to show who reached those systems, with which account, and what they did. A bastion that brokers every privileged session, requires an authorized role before access, and records the session addresses AC.L2-3.1.6 (use non-privileged accounts for nonsecurity functions) and AC.L2-3.1.15 (authorize remote execution of privileged commands and remote access to security-relevant information) directly. It does not satisfy the framework by itself, because the assessor also examines the policies, the role design, the account inventory and the evidence in final form that proves each assessment objective in NIST SP 800-171A (June 2018) was met.

The timeline matters for planning. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in force, and Rev. 2 is still the standard the Department says it will enforce in the interim. Confirm the current status with your contracting officer and the DoW CIO About CMMC page, because the eCFR text of 32 CFR 170.3(e) still reflects the original four-phase schedule.

AC.L2-3.1.15 is worth 1 point under 32 CFR 170.24, so it may be placed on a POA&M for Conditional Level 2 status only if the score is at least 88 of 110 and the requirement is not on the exclusion list. Treat that as a fallback, not a plan. Before buying anything, ask your implementation partner to map each privileged command set and each class of security-relevant information to a named role, an approver and a recording rule, and to show which of the four 3.1.15 objectives each artifact supports. Teleport Community Edition is limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so confirm license eligibility before the design is fixed.

How AC.L2-3.1.5, 3.1.6 and 3.1.15 map to bastion configuration

This table pairs each access control requirement with what the function must do and how to configure Teleport or JumpServer to meet it. Read each row as a set of design decisions to confirm with your assessor's objectives before building. The main takeaway is that 3.1.15 is the requirement most often left undocumented, because it needs an explicit authorization list of privileged commands and security-relevant information, not just a working bastion.

Requirement	What the function must do	Bastion configuration (Teleport or JumpServer)
AC.L2-3.1.5 (least privilege, parent of 3.1.6)	Limit users, and processes acting for them, to the access needed for their duties. Privileged functions must be separated from ordinary use and the separation must be enforceable, not only written in policy.	Create separate admin and daily accounts for each engineer. Grant standing access only to read-only or ordinary roles, and map privileged roles to named host groups and database users. Confirm in the product docs whether role-based host and command restrictions are available in your edition.
AC.L2-3.1.6 (non-privileged accounts for nonsecurity functions)	Require administrators to use a non-privileged account when performing nonsecurity work, such as email, browsing or document editing. Assessors look for evidence that the privileged account is not used for routine tasks.	Route admin accounts only through the bastion's privileged roles and keep daily work on accounts with no login rights to protected hosts. Document which nonsecurity functions exist on administrator workstations and confirm they run under the non-privileged identity. Review bastion logs for privileged logins from general-purpose sessions.
AC.L2-3.1.15 (remote privileged commands and security-relevant information)	Identify the privileged commands and the security-relevant information that may be run or accessed remotely, then formally authorize each. Authorization must be recorded for both execution and access.	Maintain a written list of permitted privileged commands and security-relevant files or consoles, and restrict the bastion role to that list. Use command filtering or session policies where the product supports them. Require approval for remote privileged execution outside standing roles. In Teleport Community Edition, roles are requested through the CLI; confirm whether moderated sessions and access requests fit your edition.
Assessment evidence for 3.1.15	Assessment objectives cover identifying the commands and information, and authorizing remote execution and remote access. Evidence should show the list, the authorization and the enforcement, in final form.	Keep the authorized command list, the role definitions that enforce it, approval records and a sample of session recordings in version-controlled documentation. Confirm the retention period for recordings against your contract and assessment scope.
Scoring impact (3.1.15)	Under 32 CFR 170.24, this requirement is worth 1 point and is not on the exclusion list, so it can be placed on a POA&M for Conditional Level 2 status if the score threshold is met.	Do not plan on a POA&M for 3.1.15 without first confirming with your C3PAO or sponsor. A complete authorization list and enforced roles are usually simpler to show than a remediation plan for an access control that is part of daily operations.
Phase status (2026)	Phase II certification has been suspended, while self-assessment obligations and DFARS 252.204-7012 remain in place. Controls still need to be operated and evidenced.	Confirm current CMMC status with your contracting officer and the DoW CIO's CMMC page before scoping. Keep the bastion configuration and evidence ready regardless of the assessment timing.

Where the bastion sits relative to the CUI boundary

The bastion is not outside the scope of the assessment. Once it brokers sessions to systems that store, process or transmit CUI, it becomes an asset in that boundary, and its own administrators, service accounts, logs and configuration fall under the same requirements as the systems behind it. Decide early whether the bastion sits inside the CUI enclave, in a management zone that is documented as part of the security boundary, or on the edge, and draw that boundary in the system security plan before any access rules are written. Confirm the placement and data flows with your assessor's expectations and your contracting officer, since the assessment scope is set by your own environment rather than by a product default.

The two common models differ in what the assessor will examine. Teleport issues short-lived certificates from its own certificate authority after an identity check, so the evidence centers on the certificate lifetimes, the roles that map identities to logins and Kubernetes groups, and the signing keys held by the cluster. JumpServer is asset-based: administrators are granted access to registered assets and accounts, and the evidence centers on the asset inventory, the account and permission assignments, and the stored credentials. Expect the assessor to ask which systems are registered as in scope, whether every CUI system is reachable only through the bastion, and how a privileged session on the bastion itself is authorized, recorded and reviewed.

Assessment objectives under NIST SP 800-171A must be satisfied with evidence in final form, not drafts. A requirement is MET only when every applicable objective is met, so an exported role list, a session recording policy or an access review that exists only as a working document will not carry a finding. Before the assessment, confirm that the bastion's configuration exports, role and asset lists, approval records and log retention settings are finalized, dated and traceable to the scope statement, and that the bastion's own administration is covered by the same evidence.

Teleport or JumpServer for CUI environments

Teleport is built around identity-aware access. Users authenticate through an identity provider, receive short-lived certificates from its built-in certificate authority, and reach SSH nodes, Kubernetes clusters and databases through a single access proxy. For CUI environments, this means no long-lived shared SSH keys or Kubernetes tokens sit on engineer laptops or in scripts, which speaks directly to the non-privileged account and remote privileged access expectations an assessor will look for.

Certificate-based access: Teleport issues short-lived certificates and states it is fully compatible with OpenSSH servers and clients, so existing SSH workflows can often be kept while shared keys are retired.
Protocol coverage: It protects SSH nodes, Kubernetes clusters, PostgreSQL, MongoDB, CockroachDB, MySQL, Windows hosts and internal web apps, which helps when CUI sits across mixed estates.
Enterprise-only controls: Moderated sessions, dual authorization, Device Trust and HSM support are listed only in Enterprise, as are FIPS binaries and FedRAMP controls, which only apply to self-hosted Enterprise.
Access requests: Just-in-time access requests and reviews belong to Enterprise Identity Governance, while Community Edition requests roles only through the CLI.
Single sign-on: Community Edition supports GitHub only, so workforce SSO into an CUI environment will usually require Enterprise.

Confirm with Teleport which features your chosen edition includes, and confirm the license terms with counsel before deployment.

Which open-source platforms fit a CMMC Level 2 bastion

A CMMC Level 2 bastion needs three things working together: a gateway that brokers and records privileged sessions, a way to reach browser-based and legacy systems from a controlled zone, and an identity source that enforces MFA and ties every session to a named person. The options below differ mainly in edition limits, protocol coverage and where the identity source lives, so the choice should follow the systems that hold CUI and the assessor's evidence needs.

Teleport Enterprise, self-hosted

Teleport issues short-lived certificates through its own certificate authority, so administrators reach SSH nodes, Kubernetes clusters and databases without shared keys. Session recording and playback are included in both editions, but moderated sessions, dual authorization, Device Trust and HSM support are Enterprise features, and FIPS binaries and FedRAMP controls are limited to self-hosted Enterprise. Confirm with the vendor which FIPS build and which control set apply to your deployment before you describe either in an SSP.

JumpServer Enterprise for regulated scope

JumpServer provides SSH, RDP, Kubernetes and database access from one workspace, with Enterprise features such as ticket and just-in-time approval workflows, custom roles, SSO and LDAP high availability. Enterprise tiers are sized by asset count and high availability depends on the tier, so the asset inventory for CUI systems drives the purchase. Ask the vendor which Enterprise proxies, including RDP and database connectors, are required for your protocols and whether the build is validated for FIPS.

JumpServer Community for small scope

The Community edition is free for self-hosted standalone use up to 5,000 assets, which can suit a small enclave with a narrow list of CUI servers. It lacks the approval workflows, SSO and high availability that many assessors expect to see described, and support comes through GitHub and the forum. Document the decision to run without approvals as a risk, and confirm that the single-node design meets your availability and recording requirements before relying on it.

Apache Guacamole in the DMZ

Guacamole is a clientless gateway that delivers RDP, SSH and VNC through a browser, so engineers and vendors need no client software on their endpoints. It suits a DMZ host placed in front of CUI systems where the target machines should not accept direct inbound sessions. Guacamole does not itself handle identity or approval workflows, so pair it with an identity provider and confirm how session recordings are captured, stored and protected before assessment.

Keycloak for MFA and SSO

Keycloak is an Apache-2.0 identity provider that supports OpenID Connect, SAML 2.0, LDAP and Active Directory federation, and clustering, so it can front the bastion and enforce MFA for every administrative login. Because the bastion's access decisions depend on this identity source, its MFA configuration, session lifetimes and group mapping become part of the evidence. Confirm which second factors your policy accepts and how the bastion receives the group claims it uses for least-privilege roles.

authentik for MFA and SSO

authentik is MIT-licensed except for its enterprise directory, and it offers SSO, MFA and provider integrations that can sit in front of the bastion as an alternative to Keycloak. Check which authentik components you need, since the enterprise directory carries a separate license, and confirm how its MFA enrollment and recovery flows are logged. Keep the chosen identity source consistent across the bastion, the Windows and Linux hosts and the CUI applications so each user has one accountable identity.

Sequencing the rollout so the evidence exists before the assessment

The sequence builds the scope, roles, access path and logs in an order that lets each control run for a period before an assessor samples it. The result is a set of dated records showing the controls operated, not just that they were configured.

Inventory CUI systems and privileged commands
Start by listing every system that stores, processes or transmits CUI, along with the administrative functions and security-relevant information administrators reach on each one. Involve the system owners, the security team and anyone who holds admin rights today, including vendors. This inventory defines the scope for AC.L2-3.1.15, which requires the privileged commands and security-relevant information authorized for remote use to be identified. The step is done when each in-scope system has a named owner and a written list of remote privileged functions, reviewed by the security lead.
Define privileged and non-privileged roles
Separate daily user accounts from dedicated administrative identities, and map each nonsecurity function to the account type allowed to perform it. This is the work behind AC.L2-3.1.6, which expects users to use non-privileged accounts or roles when they access nonsecurity functions. Document who may request each privileged role and what approval it needs. The step is done when a role matrix exists, has been approved by the business and security owners, and is loaded into the bastion's role model as the single source for access decisions.
Deploy the bastion and identity integration
Install the chosen bastion, such as Teleport or JumpServer, in a segment that only administrators can reach, and connect it to the workforce identity provider so that every session starts from a named identity. Confirm which integrations, such as single sign-on, are available in the edition you select, since the Community Edition limits differ from Enterprise. The step is done when a test administrator can reach a target system only through the bastion and the bastion log records that login under the individual's identity.
Enforce MFA and short-lived access
Require multi-factor authentication at the bastion for every privileged session and issue access that expires on its own rather than standing credentials or shared keys. Remove or disable direct logins to CUI systems so the bastion is the only path. Verify the setting with a test that attempts access without the second factor and with an expired credential. The step is done when those tests fail as designed and the results are saved with the date they were run.
Enable session recording and approvals
Turn on session recording for every protocol in scope and set the retention and storage location. Configure approval for elevated or remote privileged commands where the chosen edition supports it, and document the approver for each role. Check that recordings can be searched and played back by the reviewer, and that the logs leave the bastion to your central log store if your monitoring design requires it. The step is done when a recorded session for each protocol can be found, played back and tied to an approved request.
Pilot one system end to end
Choose one lower-risk CUI system and run the full process on it: request, approval, MFA, session, recording, review and revocation. Record each exception and fix the role matrix or configuration before expanding. Ask the system owner and an independent reviewer to walk the path and confirm it matches the written procedure. The step is done when the pilot runs without manual workarounds and the exceptions have owners and closure records.
Extend to all in-scope systems
Apply the proven configuration to the remaining CUI systems in the inventory, one group at a time, and update the role matrix and access lists as each group goes live. Retire the old direct access paths on each system once its bastion route is tested. The step is done when every in-scope system is reachable only through the bastion and each system's access list matches its approved role matrix.
Collect dated evidence and run periodic reviews
Establish a recurring schedule for access reviews, recording spot checks and role recertification, and keep the outputs as dated, final-form records. An assessor will look for evidence that controls operated over time, so the goal is a history rather than a single snapshot. Keep the inventory, role matrix, configuration exports, MFA test results, session logs and review sign-offs in a controlled repository. Confirm with your assessment partner how long a period of operation they expect to see before sampling. The step is done when the evidence set covers each requirement objective with records that carry dates and approvers.

Evidence an assessor examines and where it comes from

This table maps each piece of evidence an assessor is likely to request for AC.L2-3.1.5, 3.1.6 and 3.1.15 to the component that usually produces it. Read it as a checklist of what to build and export before assessment, not as a list of guaranteed outputs. The main takeaway is that a bastion produces most access evidence, but role definitions, approvals and review records often depend on the identity provider, ticketing process and people.

Evidence type	What it shows	Where it usually comes from
Role and account definitions	Which users hold which privileged roles, and that admin and daily accounts are separate identities	Identity provider groups and bastion role definitions; confirm export format with the platform
Privileged command and information list	The commands and security-relevant information authorized for remote use (3.1.15)	Policy document plus bastion role or command restrictions; the list itself is written by the organization
Approval records for remote privileged execution	That remote privileged commands and access to security-relevant data were authorized before use	Teleport moderated sessions or access requests (Enterprise), JumpServer ticket and approval workflows (Enterprise), or the organization's ticketing system
Session recordings and access logs	Who connected to which CUI system, when, and what privileged actions ran	Teleport audit log and session recording; JumpServer audit and session recording; forwarded to a SIEM such as Wazuh for correlation
MFA enforcement settings	That remote privileged access requires multi-factor authentication before a session opens	Identity provider policy export and bastion authentication configuration; confirm which edition supports the needed SSO and MFA integration
Separation of admin and daily accounts	That non-privileged accounts are used for nonsecurity functions (3.1.6)	Identity provider account inventory and bastion role mapping, reviewed against directory naming and group membership
Access review records	That privileged access was reviewed on a schedule and removed when no longer needed	Signed review records from the organization; Teleport Identity Governance or JumpServer reporting where licensed, confirm review cadence in your policy
Recording retention and export	That session evidence is kept long enough and can be produced for an assessor	Retention and storage settings in the bastion and SIEM; confirm retention periods and export procedures in your own environment

What a bastion alone does not satisfy

A PAM gateway enforces access and records sessions, but CMMC Level 2 also asks for documented decisions, reviewed authorizations and an independent judgment of the evidence. The cards below cover the gaps that most often remain after the bastion is live.

Written authorized privileged command list

AC.L2-3.1.15 expects you to identify the privileged commands and the security-relevant information authorized for remote use, and then authorize them. A bastion can restrict sessions, but it cannot decide which commands are authorized. Write the list per system class (for example, database administration or Kubernetes cluster-admin), name the owner who approved each entry, and confirm the bastion's command or role policy matches it. Ask an assessor which artifact they expect to see first.

Approval and periodic review process

Authorization is only defensible if someone approves each privileged role or access request and reviews it on a schedule. Define who approves elevation, how long a grant lasts, and how the list of privileged users is reviewed and removed when people change roles. Check whether your bastion's approval workflows and access reviews are in the edition you plan to run, since some are paid features in several platforms. Keep the signed approvals and review records as evidence.

Definition of security-relevant information

Requirement 3.1.15 covers remote access to security-relevant information, but the term is not self-defining in your environment. Decide which items count, such as audit log stores, identity directory configuration, key material, firewall policy and the bastion's own recording storage. Document the list and make sure the bastion's access rules reflect it. Without this definition, an assessor cannot confirm that the remote access scope was authorized correctly.

Bastion hardening and configuration baseline

The bastion holds privileged credentials and session recordings, so it is itself in scope as a system that protects CUI. Document its operating system build, patching cadence, administrative access, logging destinations, network placement and backup. Confirm that its default settings, including recording retention and MFA enforcement, match your written standard. If you run JumpServer on Linux, the install guide's minimum resources are a starting point, not a hardening baseline.

SPRS score and POA&M decisions

Your SPRS score is based on the 110 Level 2 requirements, and a requirement can only sit on a plan of action and milestones (POA&M) if the rules allow it. Under the CMMC program rule, AC.L2-3.1.15 is a 1-point requirement that can be placed on a POA&M for Conditional Level 2 status if the score is at least 88 of 110, with closeout due within 180 days. Confirm with your contracting office and assessor whether that path applies to your contract. Do not assume a bastion deployment will close the item by the time of assessment.

Independent assessment by authorized assessors

Only a C3PAO authorized or accredited through The Cyber AB can conduct a Level 2 certification assessment, and DCMA DIBCAC handles Level 3. DeployOpen prepares systems, controls and evidence, but it does not issue assessment results or certifications. Before engaging an assessor, confirm the current Level 2 requirement for your contracts, since the Department of War has suspended Phase II and has said Phase I self-assessments remain in place. Ask your assessor which evidence they sample for each objective.

Common questions about CMMC privileged access and open-source PAM

Does CMMC Level 2 currently require third-party certification?

Not for now. The Department of War suspended CMMC Phase II on July 13, 2026, which had been the phase requiring Level 2 certification assessments by C3PAOs for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and the DFARS 252.204-7012 obligations remain in place. The DoW CIO's About CMMC page says implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule. Confirm with your contracting officer which assessment your contracts require, and check the DoW CIO About CMMC page for the current status before you set a plan.

What drives the cost of a self-hosted PAM bastion for CMMC?

Cost comes from four places: the edition, the number of protected assets, recording storage and the effort to onboard each system. Community editions carry no license fee, but the edition decides which features you get. For example, Teleport Community Edition has limits on identity provider options and access requests that Enterprise removes, and JumpServer's free Community tier is sized by asset count. Recording storage grows with session volume and retention periods, which your CUI policy sets. Rollout effort depends on how many systems, protocols and identity sources you connect. When you request a quote, ask for a line-item breakdown covering licenses, infrastructure, storage, onboarding per system and ongoing administration.

Can a small team run a CMMC privileged access bastion itself?

A small team can run one if it has an engineer who owns the access layer, a clear list of systems in scope and a process for reviews and evidence. The work is continuous: patching the bastion, rotating certificates or credentials, reviewing admin access lists, handling vendor sessions and retaining recordings. Assessors will examine whether those steps happen and are documented, not only whether the tool is installed. If your team lacks capacity for any of these, an implementation partner can handle the build and handover, or you can contract ongoing support. Decide ownership of each recurring task before you choose a platform.

How long does a CMMC PAM implementation take?

The duration depends on scope, so confirm it in writing before work starts. The main variables are the number of servers, databases and Kubernetes clusters that hold CUI, the identity provider you integrate with, whether you need approval workflows and just-in-time access, and how many vendor and engineer groups must be onboarded. DeployOpen plans most engagements as fixed-scope projects with agreed deliverables and timelines. Ask any implementation partner for a phased plan that starts with a pilot on a limited set of systems, then adds each system group with its own test and evidence step.

Is Teleport Community Edition allowed for a defense contractor?

Probably not without checking the license first. Teleport's Community Edition license makes 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. Many defense contractors exceed one or both thresholds. Also note that Community Edition supports GitHub single sign-on only, and Enterprise is needed for FedRAMP controls and FIPS binaries on self-hosted deployments. Review the Teleport Community Edition license with your legal team, and confirm the edition against your organization's size and identity requirements.

Which parts of the environment must the bastion not be scoped out of?

Assume the bastion is in scope for CMMC if it can reach, authenticate to, log or store credentials for any system that handles CUI. That usually includes the bastion hosts themselves, their operating systems, the identity provider they trust, the session recording store, the logging pipeline that sends events to your SIEM, and any jump host or vendor gateway. Confirm the security boundary with your assessor or contracting officer early, because the bastion becomes part of the evidence for requirements such as AC.L2-3.1.5, 3.1.6 and 3.1.15. Document which components are in scope and how they are protected.

What does an assessor examine for remote privileged commands under AC.L2-3.1.15?

The assessor checks that you identified which privileged commands and security-relevant information may be accessed remotely, and that someone authorized that remote execution and access. Evidence typically includes the written list of authorized commands and information, role definitions that map to that list, and records showing the bastion enforces those roles. Under 32 CFR 170.24, this requirement is worth 1 point. Evidence must be in final form, not drafts, to count as MET under NIST SP 800-171A, so keep approved versions of the authorization records.

What DeployOpen needs from your team before scoping

A fixed-scope quote for a bastion in front of CUI systems starts with a CUI system inventory: every server, database, Kubernetes cluster and network device that stores, processes or transmits CUI, plus the administrative paths into each one today. Include who reaches each system, from which networks, over which protocols (SSH, RDP, Kubernetes API, database clients) and whether any shared accounts or static keys are in use. Without this list, the scope of AC.L2-3.1.6 and AC.L2-3.1.15 cannot be bounded, and the number of systems the gateway must protect is unknown. Your team should also provide the privileged command list for each administrative role, since 3.1.15 requires you to name the privileged commands and security-relevant information authorized for remote use. The identity provider and network zones decide the design more than any product choice. Tell us which directory is authoritative (Active Directory, LDAP, or an SSO provider), whether MFA is already enforced there, and which administrator groups map to which systems. Document the network zones that separate the CUI enclave from corporate and vendor networks, and where the bastion would sit, including any firewall rules that must change. Confirm whether the bastion itself falls inside the CUI boundary, because that determines what must be assessed alongside it. Retention rules and your current SPRS posture round out the inputs. Session recordings are evidence, so agree how long they are kept, where they are stored, who can review them and how they are protected from alteration. Also confirm your current self-assessment score and the date it was posted to SPRS, since any POA&M decision depends on that score and on the time remaining. DeployOpen prepares systems, controls and evidence for assessment. It does not issue CMMC certifications, attestations or audit reports, and your assessor, C3PAO or self-assessment sign-off remains with you and the Cyber AB process where it applies.

How DeployOpen scopes, delivers and supports CMMC access controls

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source access platforms inside the client's own infrastructure, which is where CUI systems usually sit. For CMMC privileged remote access, the work centers on a bastion, its identity sources, its session records and the evidence an assessor will sample.

How we scope

Inventory which systems hold CUI and which administrators, vendors and engineers reach them remotely
Agree in writing which privileged commands and security-relevant information are authorized for remote use
Confirm the Community or Enterprise edition needed for session approvals, identity sources and recording controls

How we build

Deploy the chosen bastion in the client's own cloud account, data center or enclave with separate admin identities
Configure MFA at the gateway, role-based access to nonsecurity functions and recorded sessions for privileged work
Test non-privileged account use and remote privileged access paths against the assessment objectives before handover

How we hand over

Document the access matrix, approval steps, break-glass procedure and session retention settings in a written package
Map each configured control to the relevant CMMC requirement so assessors can trace it to evidence
Walk the client's team through daily administration, access reviews and evidence collection before scope closes

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement
Patch and upgrade the bastion on a schedule agreed in writing, including platform release and edition changes
Keep evidence current as the CMMC program rules and assessment guidance change, and confirm each change with the client's assessor

Open source PAM for CMMC privileged remote access