How CMMC Level 2 shapes remote access for a defense contractor
A defense contractor that stores or processes CUI usually has staff and vendors reaching those systems from outside the office, and the assessor will ask how each of those sessions is controlled, monitored and evidenced. Under 32 CFR 170.14(c)(3), CMMC Level 2 uses the same requirements as NIST SP 800-171 Revision 2, which the CMMC Model counts as 110 requirements. Remote session control falls under the access control domain, with AC.L2-3.1.12 as the core practice, supported by related practices on remote access, authentication and audit. The requirement is not a product purchase. It is a set of controls you must operate and records you must be able to produce for each session. The current status matters for planning. On 13 July 2026 the Department of War suspended CMMC Phase II, which would have required Level 2 certification by a C3PAO for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and the DFARS 252.204-7012 obligations remain in place, and a Class Deviation issued on 3 September 2026 directs contracting officers to name Revision 2 explicitly. Confirm with your contracting officer and your DoW CIO guidance which obligations apply to each of your contracts before you size the remote access program, because the assessment step you prepare for may be a self-assessment now and a certification later. DeployOpen designs and implements the self-hosted remote access layer and prepares the evidence that supports your own assessment, including configuration records, session logs and access reviews. DeployOpen does not issue assessments, attestations or certifications, and the scoring against the NIST SP 800-171A objectives is your organization's determination, or that of an independent assessor where one is required. Ask any implementation partner to show you how each control will be evidenced in final form, because a requirement counts as MET only when the evidence is final, not drafts.
Which remote access requirements the gateway must satisfy and how to configure it
This table maps each CMMC Level 2 remote access requirement to what the gateway must do and how to configure Apache Guacamole to meet it. Read each row as a design input: the requirement ID, the configuration that addresses it, and the evidence your assessor will ask to see. Confirm every requirement ID and its wording against the NIST SP 800-171 Rev. 2 text and the SP 800-171A objectives with your assessor before you finalize the design.
| Requirement | What the gateway must do | Guacamole configuration and evidence to keep |
|---|---|---|
| AC.L2-3.1.12 (monitor and control remote access sessions) | Detect remote sessions as they happen and allow administrators to end them. | Enable session recording and review logs; document who can terminate sessions and how that is exercised. |
| AC.L2-3.1.13 (cryptographic protection of remote sessions) | Encrypt the browser-to-gateway and gateway-to-target paths for every protocol in use. | Enforce HTTPS on the web application; confirm TLS settings for guacd connections; keep cipher configuration in version control. |
| AC.L2-3.1.14 (route remote access through managed access control points) | Ensure all remote sessions pass through one controlled entry point, not direct paths. | Place the gateway in a DMZ; block direct RDP, SSH and VNC from user networks to targets at the firewall; document the single ingress rule set. |
| AC.L2-3.1.15 (authorize remote execution of privileged commands) | Authorize privileged activity from remote sessions before it runs. | Use separate accounts for privileged work; restrict connections by group; document approval steps for privileged targets. Confirm with the assessor how command-level authorization is evidenced. |
| IA.L2-3.5.3 (MFA for network and privileged access) | Require a second factor for remote users and for privileged access. | Use the TOTP or Duo extension, or SAML or OpenID Connect with an MFA-enforcing identity provider; test that MFA cannot be skipped. |
| AU.L2-3.3.1 and AU.L2-3.3.2 (audit records and traceable user actions) | Create audit records of remote sessions and tie each action to an individual user. | Store recordings and authentication logs centrally; use individual accounts only; keep the database backend (MariaDB or MySQL, PostgreSQL or SQL Server) backed up and access-controlled. |
| AC.L2-3.1.1 and AC.L2-3.1.5 (authorized users and least privilege) | Limit access to approved users, and to only the targets and functions each role needs. | Map Active Directory or LDAP groups to Guacamole connection permissions; review grants periodically; avoid shared accounts and administrator defaults. |
Which open-source platforms fit a CMMC remote access design
A CMMC remote access design is only as strong as the control point every session passes through. The cards below cover the gateway, the identity and logging components it depends on, and the one agent-based tool that needs its own scoping. Read them together: the gateway enforces, the identity provider proves who connected, and the SIEM shows what happened.
Apache Guacamole as the gateway
Apache Guacamole is a clientless gateway licensed under Apache-2.0 that serves RDP, SSH and VNC sessions to a standard HTML5 browser. The Java web application handles the interface and authentication, while the guacd daemon loads protocol plugins that connect to target systems. Confirm the version you deploy against the Apache Guacamole release notes and the manual before you write the build baseline.
Docker or native installation
The Guacamole manual covers both native and containerized Docker installation. The choice affects patch cadence, how you rebuild the gateway host, and how the hardened configuration is reproduced across environments. Document which method you chose, who owns image or package updates, and how the gateway is isolated from the enclave it reaches.
MFA and SSO extensions
Guacamole ships extensions for Active Directory and LDAP, Duo and TOTP multi-factor authentication, SAML, OpenID Connect, CAS and smart card single sign-on. Pick the combination your identity provider supports and test that MFA cannot be bypassed by a direct connection path to guacd. Confirm each extension's behavior with your assessor's control interpretation before relying on it for AC and IA evidence.
Session recording player
The session recording player extension lets administrators replay remote sessions captured at the gateway. This supports review of privileged and vendor activity, but storage location, access rights to recordings, retention periods and integrity protection are design decisions you must make and document. Confirm how recordings are stored and protected before the first production session.
Identity provider and SIEM
The gateway enforces MFA and connection permissions, but it does not decide who your users are or keep the long-term audit trail. You must select the identity provider that will authenticate users and the SIEM that will receive gateway, identity and host logs. Both choices are outside this list, and the design depends on them, so settle them early and confirm log formats and retention with your team.
RustDesk as a separate decision
RustDesk is an agent-based tool with its own ID and relay servers, and its Server Pro features are a separate licensing and scoping decision. Agent-based access installs software on endpoints and adds a control plane outside the browser gateway. Treat it as a distinct system with its own inventory, authentication and logging review before it is allowed into a CUI environment.
How the design changes for internal staff, vendors and privileged admins
Employees who reach CUI workstations from home or while traveling need a predictable path: a directory identity, a second factor at the gateway and a session tied to a named user and a specific workstation. Under AC.L2-3.1.12, the assessor will ask whether remote sessions are monitored and controlled, so the design should show that every staff session passes through one gateway that logs it.
- MFA method: The Guacamole manual documents Duo and TOTP extensions and several single sign-on options. Confirm which second factors your identity provider and your version support for the gateway login.
- Approval: Routine staff access is usually granted through directory group membership. Per-session approval is not a documented Guacamole feature, so confirm whether you need an external workflow.
- Time limits: Define idle and maximum session durations in policy, then test them in your version instead of relying on defaults.
- Recording depth: The session recording player extension is documented. Decide whether all CUI workstation sessions are recorded and where recordings are stored and how long they are kept.
- Termination: Confirm that disabling a directory account ends an active session, and that an administrator can end a session from the console.
Before writing these behaviors into the system security plan, test each one on a lab build connected to your identity provider.
Equipment vendors and managed service providers are external identities that need access to CUI-adjacent systems for a defined task. The design goal is that each vendor reaches only the connections it needs, during a window someone approved, with a record of what it did. Assessors look for evidence that vendor access is controlled in the same way as internal access, even though the people involved do not work for you.
- Separate accounts: Create one account per vendor person rather than a shared login for the company. Guacamole connection permissions can then limit each account to named hosts.
- MFA for external identities: Apply the same second factor to vendor accounts as to staff, and confirm how external identities are enrolled and reset.
- Approval and time windows: Grant access for a ticketed task and an agreed window. Confirm whether your version enforces a start and end time, or whether the window is enforced by disabling the account on schedule.
- Recording and review: Record every vendor session and assign someone to review recordings after each task. Confirm how long recordings are retained and where they are stored.
- Revocation at contract end: Keep a list of vendor accounts tied to contracts and remove them at the end date, including any connection permissions and stored credentials.
For each vendor, confirm in writing which hosts, which hours and which recording rules apply, and check that the gateway enforces them.
Administrators who manage the gateway, the identity integration, the database behind Guacamole or the CUI servers themselves carry the most risk. Their sessions need stronger controls than standard user access, and their activity needs its own records. Keep privileged accounts separate from everyday user accounts so that an administrator's email and browsing do not share a login with administrative access.
- MFA method: Require the strongest second factor your identity provider supports for administrative accounts. Confirm which factors are available through each Guacamole extension you deploy.
- Approval: Limit administrative connections to named administrators and documented change tickets. Keep a record that links each privileged session to the ticket it served.
- Time limits: Use shorter maximum durations for administrative sessions than for staff sessions, and confirm that the limit applies to all protocols you publish.
- Recording depth: Record privileged sessions in full, including the gateway configuration changes made during the session. Protect recordings from the administrators whose activity they capture.
- Termination and logging: Confirm how a privileged session ends when an administrator is removed, and where the database backend and gateway logs are kept. Keep guacd reachable only from the web application tier.
Test the privileged path end to end, including removal of an administrator, and confirm that each step produces a log an assessor can read.
What to configure first so the gateway can produce evidence
Start by drawing the boundary. Before any Guacamole host is installed, define which systems store, process or transmit CUI and which remote paths reach them, because every later setting is judged against that scope. Then place the gateway outside the CUI enclave, in a segment that only admits the user's browser session and the gateway's own connections into the enclave. The web application and guacd should run on separate hosts or containers so that the component that handles user logins and the component that opens protocol connections to target systems can be hardened, patched and monitored independently. Guacamole's architecture documentation describes this split, and your boundary diagram should show it explicitly.
Next, make the gateway the only identity and authorization source for remote sessions. Use a database authentication backend from the Guacamole manual (MariaDB or MySQL, PostgreSQL or SQL Server) so that users, connections and permissions live in one auditable store. Connect an MFA or SSO extension, such as the Duo or TOTP extensions, or a SAML or OpenID Connect integration, and confirm that MFA is enforced for every login path, including any local account you keep for break-glass use. Then assign permissions per connection rather than per group of hosts, so each vendor or engineer reaches only the named target systems. Confirm with your assessor which rules satisfy the access control and session practices in your System Security Plan before you finalize the design.
Finally, prove the controls work. Enable session recording and set retention to match your policy, and confirm where recordings are stored and who can read them. Forward gateway application logs, authentication events and connection records to central storage that the gateway administrators cannot edit. Then run a negative test: from a workstation outside the approved path, attempt direct RDP, SSH and VNC connections to CUI systems and confirm that the firewall blocks them. Record the results, the test date and the tester. Keep these records in final form, since an assessor looks for evidence that is finished and dated rather than a draft configuration.
What the assessor will ask to see and which component produces it
This table maps each evidence item an assessor is likely to request for remote sessions to the component that generates it. Use it to confirm, before the assessment, that every item exists in final form and is traceable to a named user, session and time. Items produced only by a gateway, identity provider or log store need a documented owner and retention setting.
| Evidence item | Producing component | What the assessor checks | Where it usually fails |
|---|---|---|---|
| System security plan entries for remote access | Documentation owned by the contractor (SSP), informed by gateway configuration | Remote access is described as a single managed path with defined users, MFA and session controls | Plan describes a VPN or vendor tool that is no longer in use, or lists a gateway without its configuration |
| Network diagram showing the single managed entry point | Network design, with Guacamole placed behind a controlled boundary | All remote sessions to in-scope systems traverse one gateway, and no direct paths exist | Diagram omits a vendor VPN, a jump host or a split tunnel that bypasses the gateway |
| Access control lists and connection permission exports | Guacamole connection and user permissions, exported from the database or admin interface | Only authorized users can reach specific hosts, with least privilege per connection | Permissions granted to groups that have grown beyond their original purpose, with no review record |
| MFA configuration and login logs | Identity provider or Guacamole MFA extension, with authentication logs | MFA is enforced on every remote login path, including administrators and vendors | MFA applied to the portal but not to direct protocol or backup logins, or exceptions without approval |
| Session recordings and retention settings | Guacamole session recording (through the recording player extension) and the storage system holding recordings | Sessions are recorded for in-scope access, and retention settings match the stated policy | Recording disabled for some connections, or storage purged on a schedule that conflicts with the SSP |
| Audit log samples tied to user identity | Guacamole logs, identity provider logs and a central log store | Each session event maps to a named account, source address, target host and timestamp | Shared accounts or generic service logins make individual activity impossible to attribute |
| Change records for gateway and permission updates | Ticketing system, linked to configuration changes on the gateway | Permission and configuration changes were approved, made and reviewed | Changes made directly in the admin interface without a ticket or approval |
| SPRS score support | Assessment worksheet and evidence index, not a single tool | Each claimed requirement is backed by evidence that meets the assessment objectives | Score claimed for remote access controls without evidence in final form, which is confirmed against 32 CFR 170.16 and 170.24(b) as they apply |
What buyers ask before hiring a partner for CMMC remote access
Is a self-assessment enough for CMMC remote access right now?
For most contractors today, the working answer is yes for Level 2 self-assessment, but confirm it against your own contract language. On 13 July 2026 the Department of War suspended CMMC Phase II, which had covered Level 2 C3PAO certification. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Class Deviation 2026-O0025, Revision 3 has contracting officers name SP 800-171 Revision 2 explicitly, so the 110 Rev. 2 requirements, including remote session control under AC.L2-3.1.12, still apply in practice. Ask your contracting officer and your legal team which clauses your contracts carry, because the schedule is still moving and the eCFR text has not caught up with the DoW CIO page.
What drives the effort of a self-hosted remote access build?
Effort rises with the number of places remote sessions can reach and the number of people who need them. The main drivers are:
- The CUI scope: how many systems hold or process CUI and whether each one must be reached remotely
- Identity integration: whether sign-in runs through Active Directory, LDAP, SAML or OpenID Connect, and how MFA is enforced at the gateway
- Enclave count: each separate network segment needs its own gateway path, firewall rules and logging
- Vendor count: each external user needs an account, approval workflow, time window and removal process
- Recording volume: storage size, retention periods and review workload grow with session count and length
Ask any partner to walk through each driver with your own system inventory before quoting.
How long does a CMMC remote access project take?
No fixed duration applies to every contractor, and any partner who gives one without seeing your environment is guessing. Duration depends on the scope drivers above, on how quickly your identity and network owners can approve changes, and on whether an existing gateway can be reused. Use the written scope to set milestones: design and boundary decisions, a pilot with a small group, hardening and evidence collection, then handover. Ask for the schedule to be tied to named deliverables and client dependencies, not to calendar weeks alone.
What does our team need to provide for a remote access engagement?
Three groups of people carry most of the work. The identity team owns directory integration, MFA enrollment, group design and account removal. Network owners decide DMZ placement, firewall rules, routing and how the gateway reaches internal hosts. The CUI scope owner confirms which systems and data are in scope and approves the list of users and vendors who may connect. Without these people available for reviews and sign-offs, design decisions stall. Agree on named owners and review dates in the written scope before work starts.
Can an internal IT team build CMMC remote access without a partner?
Yes, many teams with Linux, identity and network skills can build it, provided they have the capacity and an independent review. The Apache Guacamole gateway is documented with database, Active Directory, LDAP, SAML, OpenID Connect and Duo or TOTP extensions, so the technical path is well covered. The harder parts are evidence and repeatability: documenting how each control meets its assessment objectives in final form, testing session monitoring and termination, and keeping the configuration stable through upgrades. Assess your team against those tasks honestly, and consider a partner for a targeted review or evidence preparation even if the build stays in-house.
What does DeployOpen provide for assessors and what does it not?
DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and it does not act as your C3PAO or assessor. Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and Level 3 by DCMA DIBCAC. Expect a partner to deliver configuration records, access and session logs, test results and a control-by-control evidence package for your own assessor to review. Confirm in the written scope exactly which artifacts are included.
Which evidence will an assessor ask to see for remote sessions?
Assessors look for proof that remote sessions are authorized, monitored, controlled and terminable, and that the records are final. Expect to show:
- The approved list of remote users and vendors, with MFA enrollment records
- Gateway configuration exports showing session limits, idle timeouts and connection permissions
- Session logs and, where used, recordings tied to named accounts
- Test records showing an unauthorized or ended session was blocked or terminated
- The access review and removal records for vendors at contract end
Each requirement is judged against the assessment objectives in NIST SP 800-171A, and a requirement counts as met only when the evidence is in final form, not in draft.
What a gateway alone does not satisfy
A Guacamole gateway enforces session controls, but CMMC Level 2 assessors also look for the documents, scoping decisions and reviews that surround it. Each gap below needs a named owner, a written decision and evidence that the decision is followed in practice.
Policies and procedures
Assessors expect written policies and procedures for remote access, session monitoring, MFA and incident handling, and evidence that people follow them. A gateway configuration alone does not show who approved the design or how exceptions are handled. Check that each remote access practice has a named document owner, a review date and a link to the system configuration it describes.
CUI scoping and boundary decisions
The gateway must sit inside a boundary that is defined around where CUI is stored, processed and transmitted. Decide which hosts, jump points and session recordings fall inside that boundary, and document why any system sits outside it. Owners should confirm that the recording store and the gateway's database are treated as in scope if they can hold CUI.
Vendor agreements and access reviews
Remote sessions opened by suppliers or managed service providers need contracts that require MFA, named accounts, recording and prompt revocation. Schedule periodic access reviews that compare active gateway accounts with current contracts and staff roster changes. Ask your legal and contracts team to confirm which flow-down terms reach the vendor's own endpoints.
Organization-defined parameter values
Rev. 3 requirements contain organization-defined parameters, such as how long a session may stay idle or how many failed logons are allowed. NIST does not set these values, and if a federal agency does not specify them, the nonfederal organization must assign them. Record each value, the reason for it and the approver, and confirm with your contracting officer which revision your contract requires.
Log review and incident response
Gateway logs only protect you if someone reviews them on a schedule and acts on what they show. Define who reads session and authentication logs, how often, what counts as suspicious, and how a finding becomes an incident ticket. Test the process once with a planted event so the team can show the review happened.
Endpoint and session controls on workstations
The gateway cannot see what happens on the user's own laptop, such as copied files, unlocked screens or a compromised browser. Set requirements for managed endpoints, screen locking, clipboard and file transfer restrictions, and the browser versions allowed to open sessions. Confirm with the endpoint team which of these controls their management tooling can enforce and produce as evidence.
How a CMMC remote access rollout moves from scope to evidence
The sequence turns scattered remote paths into one managed entry point whose configuration, access decisions and session records can be shown to an assessor as final, working evidence. Each step produces an artifact that the next step depends on.
Confirm scope and framework version
Start by fixing which assessment rules apply to the contract. Confirm with the contracting officer and the sponsor which NIST SP 800-171 revision the contract and the current DoW direction require, since the CMMC Level 2 requirements are tied to Revision 2 and the 110 requirements that come with it, while a proposed FAR change would move to Revision 3. Then define the system boundary: which systems store, process or transmit CUI and which people and vendors reach them. The step is done when the scope statement and the chosen framework version are signed off by the compliance lead and the executive owner, and the in-scope asset list is written down.
Document current remote access paths
Inventory every way people and vendors reach in-scope systems today, including VPN concentrators, direct RDP or SSH exposure, vendor remote support tools, jump hosts and personal remote desktop apps. Record who uses each path, which accounts it uses, whether MFA applies and where session logs go. Interviews with help desk staff and system owners usually find paths that are not in any diagram. The step is done when each path has an owner, a risk note and a decision to keep, consolidate or retire, and that list is tied to the scope statement from the previous step.
Design the single managed entry point
Design one controlled entry point for interactive remote sessions into the CUI boundary, usually a gateway placed in a DMZ or a segmented network zone that the internal systems trust only for named protocols. Decide where identity is checked, where MFA is enforced, how connections are granted per user and per system, and where recordings are stored. Write the network rules that allow traffic from the gateway to targets and block all other inbound paths. The step is done when the architecture diagram, firewall rule set and access model have been reviewed against the scope statement and the documented paths.
Build and harden the gateway
Deploy the gateway, its web application, database and any session recording component on the platform chosen for the design, following the vendor installation guidance. Apply operating system and container hardening, restrict administrative access, disable unused protocols and features, set session timeouts and enable encrypted transport for every hop. Capture the configuration as code or documented settings so the state can be rebuilt and compared later. The step is done when a hardening checklist has been run, the results are saved with the date and the person who ran it, and any deviation has a written justification and an owner.
Integrate MFA and logging
Connect the gateway to the organization's directory so that every user is an individual identity, and enforce multi-factor authentication for every interactive remote session, including administrators and vendors. Forward authentication events, connection start and stop records, permission changes and session recordings to a central log store that the team can search and protect from alteration. Test the logic with positive and negative cases: a valid user with MFA, a user without MFA, a disabled account and a vendor account outside its time window. The step is done when each test result is recorded and the log entries for those tests can be retrieved from the central store.
Migrate connections and retire direct paths
Move each system and vendor connection from the old paths to the gateway in controlled batches. For each batch, confirm that the user can connect through the gateway, that the access grant matches the approved request and that the log records exist. Then disable the old path, remove its firewall rules and revoke any shared or unmanaged credentials that were used on it. Keep a dated record of each cut-over and each retired path. The step is done when the documented path inventory shows no remaining route into the CUI boundary that bypasses the gateway, and the change records are complete.
Collect evidence and run internal readiness review
Assemble the evidence package against the assessment objectives for each in-scope requirement, including the access control, identification and authentication, and audit and accountability requirements that the gateway supports. Include the scope statement, architecture, configuration baselines, MFA and session policies, sample logs, recordings, access reviews and change records, and mark anything still in draft. Have someone outside the build team test the package by walking through each requirement and asking whether an assessor could confirm it. The step is done when every requirement has a finished evidence set, open gaps are logged with owners, and the review findings are closed or formally accepted by the executive owner.
How DeployOpen scopes, delivers and supports CMMC remote access
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source remote access inside the client's own infrastructure, including gateway, identity and session logging for CMMC remote session control. We prepare the systems, controls and evidence a C3PAO will review, but we do not issue assessment results or certifications; independent assessors do.
How we scope
- Written scope lists which remote access paths, protocols and enclave systems are in and out of the assessed boundary.
- We map each remote session control to the AC.L2-3.1.12 objective and related practices agreed for your assessment.
- Scope records which Rev. 2 requirements apply and which organization-defined parameters your team must set.
How we build
- We deploy the browser gateway in your environment with MFA enforced at the gateway before any session opens.
- Connection permissions, session recording and audit logging are configured and tested against the agreed control list.
- Security testing of the gateway and its exposed interfaces is included where the written scope calls for it.
How we hand over
- Deliverables include configuration baselines, network diagrams, runbooks and an evidence map tied to each practice in scope.
- Handover sessions walk your administrators through account provisioning, session review and log retrieval.
- Documentation is kept in your own systems so your team can show the design and operating records to an assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Patch and upgrade cycles for the gateway, its database and its identity connectors are planned and documented.
- Confirm with DeployOpen in writing which assessment milestones and evidence refreshes a retainer covers.
