How CMMC Level 2 remote access requirements shape a ZTNA design
A defense contractor or subcontractor whose staff and vendors reach systems that handle CUI remotely has to meet AC.L2-3.1.12 to 3.1.14, which require monitored and controlled remote sessions, cryptographic protection of those sessions, and routing through managed access control points. Level 2 is the CMMC version of NIST SP 800-171 Rev. 2, and assessors score it against the assessment objectives in NIST SP 800-171A (June 2018). For 3.1.12, those objectives cover permitting remote sessions, identifying the permitted types of remote access, and controlling and monitoring the sessions. For 3.1.13, they cover identifying and implementing the cryptographic mechanisms. For 3.1.14, they cover identifying and implementing managed access control points and routing remote access through them.
A requirement counts as MET only when every applicable objective is satisfied with evidence in final form, so drafts of a ZTNA runbook or an unexported access log will not carry a score. Design for this from the start: keep the policy definitions, the list of permitted remote access types, session logs and the change history of access rules in a form you can hand to an assessor. The status of the program is in flux. The Department of War suspended CMMC Phase II on 13 July 2026, while Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO page dated 17 October 2026 describes implementation as paused in Phase 1, while the eCFR text of 32 CFR 170.3(e) still lists the original schedule. Confirm with your contracting officer which level and assessment type apply to each contract before you size the project.
DeployOpen prepares the systems, configurations, procedures and evidence that support these requirements, including the access control design and log retention for a self-hosted ZTNA deployment. It does not issue CMMC assessment results or certifications; those come from the assessment body that applies to your contracts. Ask your implementation partner to map each objective of 3.1.12 to 3.1.14 to a named control point, a log source and an evidence owner, and to confirm that the access logs are retained and exported in a form that matches your System Security Plan.
Mapping requirements 3.1.12, 3.1.13 and 3.1.14 to ZTNA configuration
This table maps each remote access requirement to what the access function must do, how an OpenZiti, NetBird or Pomerium-style design can be configured to meet it, and the NIST SP 800-171A objectives the assessor will test. Read each row as a design check: if the configuration cannot produce the evidence in the last column, the requirement is not yet supported. Confirm each product capability in your own environment before relying on it for an assessment.
| Requirement | What the function must do | How to configure it in a ZTNA design | Assessment objectives supported |
|---|---|---|---|
| AC.L2-3.1.12 Monitor and control remote sessions | Decide which remote access sessions are allowed, define which types of remote access are permitted, and control and monitor each session while it runs | Define access by identity group and service in the controller or policy engine (OpenZiti service policies, NetBird groups and rules, Pomerium route policies). Enable session and connection logging, and confirm that revoking an identity ends active sessions | Permitting remote access sessions; identifying permitted types of remote access; controlling remote access sessions; monitoring remote access sessions |
| AC.L2-3.1.13 Cryptographic protection of sessions | Protect the confidentiality of remote access sessions with cryptographic mechanisms that are identified and implemented | Confirm end-to-end encryption scope for each app type. OpenZiti SDK traffic is encrypted application to application, while tunneler traffic is encrypted tunneler to tunneler. For NetBird and proxy designs, document the WireGuard or TLS path and where traffic is decrypted, including any relay | Identifying cryptographic mechanisms protecting session confidentiality; implementing those mechanisms |
| AC.L2-3.1.14 Routing through managed access control points | Identify the managed access control points that remote access must pass through and route all remote access through them | Place public or proxy routers and NetBird or OpenZiti routers at defined points, and document each one as a managed control point. Use dark services with no inbound ports so traffic reaches applications only through those points. Test that direct network paths are blocked | Identifying and implementing managed access control points; routing remote access through those managed points |
Which self-hosted ZTNA platform fits which CMMC environment
OpenZiti suits environments where the goal is to hide services entirely, so that no listening ports are exposed for remote access. Its controller issues and verifies identities for every participant and defines which identities reach which services through which edge routers. Services connect outward to the mesh, which keeps inbound firewall rules out of the design. It supports three models that can be mixed, so a team can start with a tunneler for legacy hosts and move newer applications to an SDK.
- Dark services: a service with no open ports only accepts connections authorized by policy, which supports the separation of remote sessions from internal listeners.
- Dial-out edge routers: private routers make only outbound connections, so the design avoids inbound firewall changes.
- SDK or tunneler models: tunnelers connect unmodified software, while SDKs embed identity and encryption in the application.
- Licensing: OpenZiti is Apache 2.0 and created and sponsored by NetFoundry. Confirm whether a managed NetFoundry network is part of the design, since it changes where the control plane runs.
Confirm with the vendor how the controller, logs and any audit exports map to your evidence needs, and who operates the self-hosted control plane.
NetBird fits teams that want a WireGuard overlay with central access rules, SSO groups and device checks, and that can run the control plane on their own infrastructure. It is configuration-free for peers and falls back to relays when a direct path is not possible. The self-hosted quickstart runs management, signal, relay and STUN from one combined configuration, with a dashboard, a Traefik reverse proxy and an embedded Dex identity provider that can add external SSO.
- Overlay and identity: SSO and MFA, groups and rules, and SSH with central access policies support the identification and access control expected under the remote access requirements.
- Posture and logging: the README lists device posture checks and activity and traffic event logging. The pricing page places audit event logging, device approvals, posture checks and traffic logging in the Team and Business tiers.
- Quickstart requirements: a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP 80 and 443, UDP 3478, and Docker with the Compose plugin.
- Operator duties: self-hosted operators handle backups, upgrades and scaling themselves.
- Licensing: the core is BSD-3-Clause, while the management, signal, relay and combined directories are AGPLv3.
Confirm which features your edition provides, and whether SSO, SCIM, audit logs and traffic logs are available under the license in use before relying on them as evidence.
Headscale and Pomerium suit narrower cases. Headscale is a self-hosted coordination server for Tailscale clients, and it fits teams that already run Tailscale clients and want to keep coordination in their own environment. Pomerium is an identity-aware proxy that puts policy in front of web applications, so it fits browser access to a limited set of internal apps rather than full network reach. Neither is a complete replacement for a VPN in every case, so the design should cover which traffic types they handle.
- Headscale scope: it relies on the Tailscale client model, so confirm client support for each device type in scope.
- Pomerium scope: policies apply per route and tie to the identity provider, which suits web apps but not arbitrary TCP or UDP services.
- Logging: confirm which request and session logs each product produces and whether they cover the monitoring expected for remote sessions.
- Cryptography: confirm how each product encrypts remote sessions and which cryptographic mechanisms it uses, since this must be documented for the encryption requirement.
- Coverage gaps: a proxy alone may not satisfy routing through managed access points for non-web traffic.
Before choosing either, document the traffic types, clients and logs in scope, and confirm each product's licensing and support with its maintainers.
What the session logs must prove to an assessor
AC.L2-3.1.12 is evidenced by records, not by a policy statement. An assessor working from the NIST SP 800-171A objectives will want to see, for each remote session, who connected, to which service, when, from which device, and when the session ended or was revoked. Confirm that the ZTNA platform records each of these fields at the session level. For OpenZiti, that means checking what the controller and tunnelers log about identity, service and edge router. For NetBird, it means confirming what the activity and traffic event logging captures in your edition, since the pricing page ties audit event logging and traffic logging to specific plans. Do not assume the field list from documentation alone; pull a sample export and check it against the list before the assessment window.
The logs must reach a SIEM you control, on a clock you trust. Forward the ZTNA activity logs to a collector such as Wazuh or Security Onion, so the records survive if the access platform is compromised or reconfigured. Decide the retention period in writing, because it must cover the look-back an assessor will request, and confirm that all components use synchronized time so that a connection in the access log lines up with a host event in the SIEM. Confirm the transport and storage of the log stream with your SIEM team, since the logs themselves become a CUI-adjacent system component in scope for the assessment.
Revocation is the control that closes the session. Test that disabling a user or removing a service assignment terminates active connections, not just future ones. OpenZiti documents immediate termination of active connections on revocation, and that behavior is the evidence for session control under 3.1.12. Record the test: the time of revocation, the time the session dropped, and the log entries on both sides. Keep that test record with the final-form evidence for the assessment, because a requirement is met only when the evidence is in final form.
Evidence assessors ask for and which component produces it
This table maps the evidence an assessor is likely to request for remote access under AC.L2-3.1.12 to 3.1.14 to the component that produces it in a self-hosted ZTNA design. Read each row as a question to ask your assessor and your team: what artifact exists, where it comes from, and what must be true before it counts as final. Drafts, unexported screenshots and undated configurations are the usual reason evidence is rejected.
| Evidence item | Component that produces it | What makes it final, not a draft |
|---|---|---|
| Access policy export (who can reach which app, through which access point) | OpenZiti controller policies or NetBird groups and access rules, exported through the REST API or dashboard | Exported from the production controller or management server, dated, and matched to the approved remote access types in the SSP |
| Identity and MFA configuration | Identity provider such as Keycloak, authentik or ZITADEL, plus the ZTNA SSO and MFA settings | Configuration exported from production with MFA enforcement visible for remote users, and change approval recorded |
| Device posture policy | NetBird posture checks or device approval rules on the Business tier, or equivalent posture settings in the chosen platform | Policy version active in production, with the criteria and the owner who approved them; confirm which posture features your edition includes |
| Session and access logs for remote sessions | NetBird activity and traffic event logs, OpenZiti controller and router logs, forwarded to a SIEM such as Wazuh | Logs retained for the period your policy requires, forwarded off the gateway host, and reviewed with a documented sample |
| Encryption configuration for remote sessions | OpenZiti end-to-end encryption (SDK or tunneler scope), NetBird WireGuard tunnels and relay TLS settings, TLS certificates on proxy endpoints | Configuration showing which segments are encrypted and which algorithms are in use, verified on the live path rather than the design document |
| Network diagram showing managed access control points | Architecture diagram built from edge router, relay and gateway placement, plus route and exit node definitions | Diagram matches the deployed routes and router placement, with a revision date and a sign-off by the system owner |
| Change records for access and configuration updates | Git repository or ticketing system holding infrastructure-as-code, Terraform or Ansible runs, and approval records | Each change linked to an approved ticket, with a commit or run identifier, and no unreviewed manual edits in production |
| System security plan (SSP) entries for 3.1.12 to 3.1.14 | Written SSP narrative maintained by the organization, referencing the artifacts above | Describes the implemented state as of the assessment date, names the responsible roles, and is signed and version controlled |
What ZTNA tooling alone does not satisfy
AC.L2-3.1.12 to 3.1.14 cover only a slice of the 110 Level 2 requirements. A self-hosted ZTNA design gives an assessor evidence for remote access, but the rest of the program depends on documents, process and people that no overlay network or proxy provides.
The other Level 2 requirements
Remote access is one family out of the 14 domains that make up the CMMC Level 2 model. Requirements for audit and accountability, configuration management, incident response, media protection and system integrity still need their own owners, procedures and evidence. Before scoping the ZTNA project, list which requirements the ZTNA layer touches, which it only supports, and which it leaves untouched. Ask your assessor how they expect the boundary to be documented.
System Security Plan and policies
An assessor expects a System Security Plan that describes the boundary, the people who operate it and how each requirement is implemented. Your ZTNA design, its control plane location, identity sources and log destinations must appear in that plan with their actual configuration, not a generic description. Written policies for remote access, acceptable use and account management must match what the system does. A plan that describes an MFA-protected overlay the team never configured will fail review.
POA&M and SPRS process
Requirements that are not fully met can sit on a Plan of Action and Milestones, but only where the rules allow it and only with a clear remediation plan and owner. Scores posted to SPRS must reflect the evidence you can actually produce. Confirm with your contracting officer and assessor which requirements are eligible for a POA&M under the current rule, and how a partly deployed ZTNA rollout should be recorded during the migration period.
FIPS-validated cryptography questions
AC.L2-3.1.13 asks for cryptographic mechanisms that protect remote access sessions, and assessors commonly ask whether those mechanisms are FIPS-validated. Open-source ZTNA components use TLS, mTLS, WireGuard or libsodium depending on the product, and not every build or configuration uses a validated module. Ask the vendor or partner which modules are validated, which build options enable them, and whether the assessor accepts the chosen configuration before you rely on it as evidence.
Personnel and training controls
Several Level 2 requirements concern the people who operate and use the system: screening, awareness training, role-based training and removal of access at separation. A ZTNA policy can revoke a leaver's access within minutes, but only if HR, the identity provider and the ZTNA administrators share a documented process. Record who administers the control plane, who approves device enrollment and how those staff are trained for the tool.
SIEM and review of remote access logs
The 3.1.12 objective to monitor remote access is only met if someone reviews the logs. ZTNA controllers and clients produce session and policy events that must reach a central SIEM with retention and alerting. Decide which events trigger a review, who reviews them, how often, and how the review is evidenced. Confirm that log sources, timestamps and retention meet your SIEM and assessor expectations before the first assessment.
Questions CMMC teams ask before building a ZTNA design
Do we have to self-host the ZTNA control plane for CMMC?
No requirement in the supplied CMMC material names self-hosting. AC.L2-3.1.12 to 3.1.14 require that remote sessions are monitored and controlled, encrypted, and routed through managed access control points, and a managed cloud service can meet those objectives if your assessment evidence covers it. Self-hosting becomes the deciding factor when you need the control plane, its logs and its keys inside your own boundary. Self-hosted NetBird, for example, needs a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, and Docker with the Compose plugin, and the NetBird documentation states that backups, upgrades and scaling then fall to your team. Those tasks are recurring, so budget them as operations, not as a one-time install.
What drives the time a remote access migration takes?
The main drivers are the number of applications and their protocols, how many of them are web, SSH, RDP, database or UDP traffic, and how many depend on the VPN's broad network access without anyone having documented why. Other drivers are the identity provider groups you must map to access policies, the device posture signals you choose to enforce, and whether you run the VPN and the new design in parallel during cutover. Each application needs its own policy, test and rollback plan, so count applications first. Ask any partner to show how they will inventory those dependencies before they quote a schedule.
What does the migration need from our internal staff?
Your staff must supply decisions and facts that only your organization holds. These include the list of CUI systems and the users who reach them, the identity provider and its group structure, the device fleet and which posture signals you can actually collect, and the owners who approve each application's access policy. Engineers also need time to review firewall changes, DNS, certificate handling and log destinations. A named owner for the control plane after go-live matters as much as the build team, because upgrades and certificate renewals recur. Confirm these time commitments in writing with any partner before the scope is fixed.
Can our internal team implement this ZTNA design alone?
A capable platform team can build the design alone if it has time, Linux and container operations experience, and someone who owns the assessment evidence. The work divides into the control plane build, the identity and policy design, client rollout, app-by-app migration, logging into your SIEM, and the evidence package for the assessor. Many teams underestimate the last two because they are mostly documentation and review, and because CMMC evidence must be in final form to count as MET. A partner can take a fixed-scope piece, such as the build and hardening, while your team keeps policy ownership. Decide which pieces you keep before you ask for a quote.
Does the current CMMC phase change how we design remote access?
The technical requirements do not change with the phase. AC.L2-3.1.12 to 3.1.14 come from NIST SP 800-171 Rev. 2, which the CMMC rule still incorporates, and the Department of War said on 13 July 2026 that it will enforce Rev. 2 in the interim. What the phase changes is how and when you are assessed. The Department of War suspended CMMC Phase II on 13 July 2026, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification, and Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. Because the scoring schedule is still being reviewed, confirm the current requirements with your contracting officer and your assessor before you fix the evidence plan.
Which logs must a ZTNA deployment produce for an assessor?
Your evidence should show who connected, to which application, from which device, when, and whether the session was permitted, plus the session end or revocation. For AC.L2-3.1.12, the assessment objectives expect you to monitor and control sessions, so the ZTNA access and activity logs must reach a log store you can review and retain. NetBird lists activity and traffic event logging, and its Team plan includes audit event logging, while traffic logging and streaming sit in the Business plan according to its pricing page. Confirm which log types your chosen edition and your SIEM can hold, because those gaps are often found late.
What should we ask a partner to include in a quote?
Ask for a written scope that lists the applications to migrate, the identity and posture integrations, the hosting environment and the control plane components, and the hardening and backup steps. Request the deliverables for the evidence package, the handover documentation, and the testing performed before cutover. Ask which items are one-time and which recur, such as upgrades, certificate renewals, and retainer-based support, and what changes the quote if the application count or the edition changes. DeployOpen does not publish a price list, and its engagements are fixed-scope with agreed timelines. Ask how the partner will prepare evidence for your assessor without issuing any audit attestation, since independent assessors perform the assessment.
How a CMMC remote access project moves from scope to evidence
This sequence turns the remote access requirements of CMMC Level 2 into a scoped, deployed and logged zero trust design, with evidence that a assessor can trace back to each objective. Each step produces a artifact that the next step depends on.
Confirm CUI systems and remote user types
Start by listing which systems store, process or transmit CUI and which people reach them from outside the enterprise network. Include employees, subcontractors, managed service providers, vendors and administrators, and note the device types each group uses. The business owner and the security lead sign off on this inventory, and the scope statement it produces defines every later decision. The step is done when every remote path into a CUI system is named and tied to a user group.
Map requirements 3.1.12 to 3.1.14 to objectives
Take each of AC.L2-3.1.12, AC.L2-3.1.13 and AC.L2-3.1.14 and break it into the assessment objectives in NIST SP 800-171A (June 2018). For each objective, record the system component, the owner and the artifact that will prove it, such as an access policy export, a configuration baseline or a log sample. Confirm with your assessor or C3PAO which artifact formats they accept. The step closes with a traceability matrix that links every objective to a named source of evidence.
Deploy the self-hosted control plane in your environment
Install the chosen ZTNA control plane, such as OpenZiti or NetBird, inside your own cloud account, data center or enclave, so that the controller, coordination services and any relays sit under your administrative control. Configure identity provider integration, multi-factor authentication, device posture where the product supports it, and encrypted tunnels for every session. The engineering team also documents backup, upgrade and recovery procedures. The step is done when a test user can reach only the approved test service through an encrypted, policy-controlled path.
Migrate applications and retire broad VPN access
Move one CUI application at a time onto the new access path, defining a service, an access policy and a named user group for each. Where an application can be reached only through the ZTNA path, close the matching route in the legacy VPN or firewall rules so that the managed access point is the only route. Run the old and new paths side by side during cutover, then remove the old path once the group confirms access. The step is done when each in-scope application has a documented policy and a tested removal of its previous route.
Connect remote access logs to the SIEM
Forward the ZTNA controller, gateway and client logs to the security information and event management platform used for CUI systems, such as a self-hosted Wazuh deployment. Confirm which events are captured, including session start and end, policy decisions, denied attempts and administrative changes, and set retention to match your contract and internal rules. Test by generating known events and confirming they appear, with correct user identity and timestamps. The step is done when a sample of each event type is searchable and the log source is documented.
Assemble evidence in final form
Collect the final versions of the policies, configuration exports, access lists, test results and log samples mapped in the traceability matrix. Remove drafts, date each artifact, and record who approved it and when. Check each objective against its evidence and mark it as met only where all of its applicable objectives have final evidence. Confirm with your assessment body which evidence it will review. The step is done when the evidence package can be traced from each objective to a dated, approved artifact.
What to confirm with your assessor and the contract owner
Before you scope a remote access design against CMMC, confirm with your contracting officer which CMMC requirements currently apply to your contracts. 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 certification assessments by C3PAOs for applicable contracts. The department also started a 60-day review by a CMMC Reform Task Force, so the schedule and the certification requirement may still change. Ask the contract owner whether your contracts carry a Level 2 self-assessment or a certification assessment, and get the answer in writing.
The security requirements themselves are more stable than the schedule. The department said on 13 July 2026 that it will enforce NIST SP 800-171 Rev. 2 in the interim, even though NIST withdrew Rev. 2 when it published Rev. 3. Ask your assessor to confirm that the assessment objectives they will use are those in NIST SP 800-171A (June 2018) for AC.L2-3.1.12 through 3.1.14. Also confirm that the eCFR text of 32 CFR 170.3(e), which still shows the original four-phase schedule, is not the document your contract officer is working from. The DoW CIO About CMMC page is the place to check the current phase status before each planning decision.
Phase I obligations do not depend on the suspension. Confirm with the contract owner that your Phase I self-assessment, your SPRS score posting, your annual affirmation and your DFARS 252.204-7012 obligations, including incident reporting for covered systems, are current and assigned to a named owner. A remote access design that is ready for an assessment but has no SPRS entry or no owner for the affirmation still leaves you exposed. Record which contract clauses apply, and keep the answers with your System Security Plan so the access logs described in this page can be tied to the requirements they support.
How DeployOpen scopes, deploys and documents CMMC remote access controls
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so a remote access design for CMMC can run in the environment that holds the controlled data. We prepare the systems, controls and evidence for a compliance assessment, but independent assessors make the determination.
How we scope
- Written scope lists the user groups, devices and internal applications that will reach through the ZTNA design.
- We map each remote access session to AC.L2-3.1.12, 3.1.13 and 3.1.14 and record which evidence each one needs.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; a quote follows from that scope.
How we build
- We deploy the controller or coordination plane and edge components inside your cloud account, data center or isolated network.
- We configure identity provider integration, MFA, device posture signals and encrypted paths for each access pattern in scope.
- We test that sessions are blocked without policy, that revocation ends active connections and that logs capture each session.
How we hand over
- Handover includes configuration records, access policy definitions, runbooks and a mapping of control objectives to the logs that support them.
- We document which evidence is final and which items your assessor or C3PAO will still need to review independently.
- Operators receive training on policy changes, log review and the backup and upgrade steps they carry after go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the implementation.
- We can re-run access tests after platform upgrades, new applications or changes to CMMC scope and assessment guidance.
- Before any assessment, confirm with your sponsor or assessor which CMMC phase and assessment method currently apply to your contracts.
