MA.L2-3.7.5 Nonlocal maintenance: requirements and evidence

What MA.L2-3.7.5 nonlocal maintenance requires and why it is hard

A contractor that lets a vendor or administrator work on a CUI system from outside the network must be able to show two things: every remote maintenance session is established with multifactor authentication, and every such session is closed when the work ends. That is the whole of MA.L2-3.7.5. It is the Level 2 version of requirement 3.7.5 in NIST SP 800-171 Rev. 2, the Maintenance family item that corresponds to control MA-4 (Nonlocal Maintenance) in SP 800-53 Rev. 4, and the CMMC Scoring Methodology assigns it 5 points. Because it is worth more than 1 point, it cannot be carried on a POA&M. It has to be MET before the organization can reach Conditional or Final Level 2 status.

The requirement is short, but it is hard to satisfy in practice for three reasons. First, the tooling often belongs to the vendor: a remote support portal, a vendor-managed VPN client or a jump host that the contractor does not administer. The contractor still owns the obligation, so it needs contract terms or configuration control that forces the vendor's access path through its own MFA. Second, shared accounts are common for vendor and administrator access, which breaks the link between a person and a session and makes the MFA result hard to attribute. Third, sessions are often left open after a ticket closes, through persistent VPN tunnels, standing remote desktop sessions or tokens that never expire.

Before an assessment, confirm three things: which remote paths reach CUI systems, whether each one enforces MFA at session establishment, and what evidence shows that sessions end, such as logs of disconnects, idle timeouts and revoked accounts. SP 800-171A treats nonlocal maintenance procedures, configuration settings and maintenance records as the kinds of evidence an assessor will look for, so the maintenance records should show when each session started, who authenticated, and when it was closed. Ask the vendor in writing for these artifacts before the work begins.

How an assessor tests MFA and session termination for 3.7.5

This table compares the two assessment objectives NIST SP 800-171A sets for MA.L2-3.7.5, showing what an assessor examines, the evidence requested and where findings usually occur. Read each row as a separate test, because a requirement is MET only when both objectives are satisfied with final-form evidence.

Test element	Objective 1: MFA for nonlocal sessions	Objective 2: Termination at completion
What the assessor examines	Configuration of the mechanisms that strongly authenticate nonlocal maintenance sessions, including every path that reaches the system from an external network	Configuration and behavior of session timeouts, disconnect actions and tunnel teardown for nonlocal maintenance sessions
Sample tested	A selection of maintenance sessions over external connections, such as vendor remote access, cloud management consoles and jump hosts	The same sample, checked from start to finish to confirm each session closed when the work ended
Evidence requested	Authentication configuration exports, MFA enrollment records for maintenance accounts and sign-in logs showing a second factor for each sampled session	Session logs showing start and end times, disconnect records and maintenance tickets showing when work was complete
Maintenance and diagnostic records	Records tying each nonlocal session to an authorized person, a work order and the second factor used	Records confirming the session ended when the work order closed, with no open sessions left over
Common finding: MFA scope gap	MFA enforced on the VPN but not on a vendor jump host or direct remote desktop path that reaches the same systems	Sessions left open after the vendor left, or idle timeouts set so long that sessions remain active between work windows
Common finding: weak second factor	Static passwords or shared accounts presented as a second factor, or recovery codes used routinely without review	Termination enforced only on the client, so the server keeps the session open
Final-form evidence	Current configuration and logs, not drafts or screenshots from a test environment, must show MFA working on the production path	Procedures and records must be finalized and dated, showing the termination control operating during the assessment period
What to confirm before the assessment	Inventory of every external path for maintenance, including those run by service providers, and whether each one requires a second factor	Whether terminations are enforced by the system or depend on people, and how the organization proves that each session ended

Which nonlocal maintenance paths fall in scope

MA.L2-3.7.5 applies to any maintenance session that reaches an organizational system over an external network connection. The paths below are the ones assessors usually ask about, and each one changes what must be authenticated, logged and terminated.

Vendor remote support sessions

A vendor engineer connecting to a CUI system to troubleshoot, patch or reconfigure it is the most common nonlocal maintenance path. The session starts outside your network, so MFA must be enforced before the vendor reaches the system, and the connection must close when the ticket closes. Check whether the vendor uses its own remote access tool, whether accounts are shared, and whether you can see the session start and end times.

Administrator sessions from home or hotels

Administrators who maintain servers, firewalls or directory services from a home office, a hotel or a client site are performing nonlocal maintenance even when they use company laptops. Each path from an untrusted network into a maintenance interface needs MFA at session establishment. Confirm that VPN logins, direct SSH or RDP, and web administration consoles all enforce the same factor and time out or end when the work is finished.

Cloud consoles used for maintenance

Administrative work in cloud management consoles, hypervisor web interfaces and infrastructure APIs can be nonlocal maintenance when it is performed from outside the boundary of the CUI environment. Treat each console login as a maintenance session if it changes configuration, restarts services or pulls diagnostics. Confirm with your cloud provider and your system security plan which consoles fall in scope and how their session timeouts are set.

Third-party diagnostic connections

Diagnostic links that a manufacturer, integrator or monitoring service opens into equipment that handles CUI are nonlocal maintenance, including dial-in modems, managed remote monitoring agents and vendor-hosted analysis tools. These connections often bypass normal identity systems. Inventory every one, document who holds the credential, and confirm that each can be disabled between jobs without waiting on the vendor.

Internal staff versus third parties

Being an employee does not remove a session from scope, and being a contractor does not automatically put it there. The question is whether the person reaches the system over an external network connection. A staff member on the corporate LAN is local maintenance, while the same person on a home connection is nonlocal. Record how each population connects, because assessors test the path, not the job title.

Scope decisions that change the work

Whether CUI systems can be reached from outside is the decision that determines how much of this requirement you must build. If CUI enclaves accept no inbound maintenance paths, the work centers on proving that boundary holds and that no exception exists. If remote maintenance is required, every path needs MFA, termination and a record. Document the decision in the system security plan and confirm it with your assessor before evidence collection begins.

Sequence to implement nonlocal maintenance controls

This sequence moves MA.L2-3.7.5 from an unknown set of remote access paths to a small number of governed, MFA-protected maintenance sessions that close on a defined trigger and leave records an assessor can test. The organization owns the outcome, and an implementation partner or internal engineers can carry out the technical steps.

Inventory every external maintenance path
List every way a vendor, administrator or service provider can reach a system that handles CUI from outside the organization's network. Include VPN concentrators, vendor-managed tunnels, remote desktop gateways, SSH bastions, cloud consoles, modem or out-of-band management interfaces, and any remote support tool installed on a system. Record the owner, the accounts used, and the systems each path reaches. The output is a maintenance path register that the system security plan can reference, and it is complete when a network scan and a review of firewall and gateway configurations find no path missing from the list.
Route each path through one controlled entry point
Consolidate the paths from the register so that nonlocal maintenance enters through a defined gateway or jump host, and block direct inbound access to maintenance interfaces from external networks. Firewall rules on OPNsense or a similar packet filter can restrict source addresses, destination ports and protocols to that entry point, with aliases for approved vendor address ranges and logging enabled on each rule. The output is a firewall rule set and a diagram showing that no maintenance session bypasses the gateway. Confirm the exact rule behavior and logging options against the vendor documentation for your version.
Enforce MFA at session establishment
Configure the entry point so that every nonlocal maintenance session requires at least two independent factors before access is granted. Identity providers such as authentik can enforce an authenticator validation stage during login with TOTP apps, WebAuthn or FIDO2 passkeys, or other enrolled second factors. FreeIPA can enroll TOTP and hardware tokens for directory accounts. Remove any path that accepts only a password, and make sure vendor accounts cannot skip the stage through a legacy protocol. The output is a test showing a login attempt with a valid password and no second factor is refused.
Configure time-limited and on-demand session termination
Set session lifetimes and idle timeouts on the gateway and on each maintenance tool so that sessions end without manual action when the work is complete or the window closes. Prefer on-demand enablement, where the vendor account is turned on for an approved ticket and disabled afterward, so that no standing external path remains open between jobs. Document the settings and who approves each enablement. The output is a configuration baseline with the timeout values, the approval workflow, and the account disablement step recorded in the change record.
Record maintenance sessions
Make sure each nonlocal session produces records that show who connected, from where, when, which systems were reached, which actions were taken, and when the session ended. Forward gateway, identity provider and firewall logs to a central store protected from alteration, and tie each session to a maintenance ticket. SP 800-171A lists maintenance records and diagnostic records as potential evidence for this requirement. The output is a sample set of session records that an assessor can trace from request to termination without gaps.
Test that each session closes at completion
Run scripted tests against the live configuration to confirm that MFA is required, that sessions end at the configured idle and maximum lifetimes, that terminating the work removes the external path, and that a disabled vendor account cannot reconnect. Repeat the tests after every change to the gateway or identity settings. Keep the test scripts, dated results and any remediation in the evidence file. The output is a signed test record for each objective in SP 800-171A, which is the evidence a self-assessment or certification assessor will ask to see in final form.

Evidence that proves MFA and termination to an assessor

An assessor tests two things for MA.L2-3.7.5: that a second factor is required before a nonlocal maintenance session starts, and that the session ends when the work is done. Each artifact below proves one part of that claim, and each must be final, dated and taken from the production environment rather than a draft or a screenshot made for the audit.

MFA configuration exports

Export the authentication policy that governs maintenance accounts, showing which stages and enrolled second factors apply to them, such as TOTP apps, WebAuthn passkeys or hardware tokens. Name the flow or policy, its version and the export date. Check that no maintenance account can bypass the second factor through a recovery path, a legacy password-only flow or a group that was exempted for convenience. Re-export after every change to the flow.

Authentication logs for maintenance sessions

Keep logs that show each maintenance login over an external path recorded a second-factor event, with the account, source address, time and the factor type used. Filter them to the maintenance group so the assessor can sample sessions without reading every login. Sessions that show a password success with no second-factor event are findings, so search for them before the assessor does and document how each was resolved.

Session termination logs

Show that each nonlocal session closed when the work ended, either through an explicit logout, a timeout or a firewall state removal. Pair the session start and end times with the change or ticket that authorized the work. Firewall rule logs for the VPN or maintenance path can show the connection was torn down. Sessions that remain open past the ticket close time are the most common gap.

Maintenance and diagnostic records

Keep a record for each nonlocal maintenance event listing the technician, the systems touched, the purpose, the start and end times and the approving owner. Diagnostic output produced during the session belongs with the record. These records connect the authentication and termination logs to a specific piece of work, which is how an assessor confirms the sessions were maintenance and not general access.

Written nonlocal maintenance procedures

Document the steps a technician follows to request a nonlocal session, the second factor required, how the session is ended and who reviews the records. Name the owner and the approval date. The procedure should match what the logs show in practice. An assessor who finds a procedure that describes a different process than the one in the logs will test the logs more closely.

Keeping evidence current and final

Assign an owner to review each artifact on a fixed schedule and at every change to the access path, identity provider or firewall policy. Retain logs for the period your own policy and the assessor's sampling need, and confirm that retention with the assessment team. Only final versions count toward a MET finding under the assessment objectives, so mark drafts clearly, store approved copies separately and date every export.

What meeting 3.7.5 costs in money and effort

This table breaks the cost of meeting MA.L2-3.7.5 into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to structure a request for quotes, not as a price estimate, since no figures for this requirement have been supplied.

Cost component	Who is paid	One-time or recurring	What drives it up or down
MFA tooling or licenses	Software vendor or subscription provider	Recurring if commercial; one-time setup	Number of administrators and maintenance users, and whether a second factor is already licensed. Self-hosted open-source options such as authentik can remove per-user license spend, though hosting remains a cost.
Identity integration engineering	Implementation partner or internal engineers	One-time, with occasional rework	Number of identity sources and maintenance accounts, and whether an existing identity provider or FreeIPA directory can be reused. Ask whether the quote covers testing each maintenance path.
Jump host or gateway build	Implementation partner or internal engineers	One-time build; recurring patching and hardening	Number of maintenance paths and vendors. Each separate external route into the boundary adds build, testing and monitoring effort.
Firewall and access rule configuration	Implementation partner or internal engineers	One-time build; recurring rule review	Number of source addresses, aliases and ports allowed for vendor access. Ask whether rule match logging is configured for review.
Session logging and retention	Internal staff or managed service provider	Recurring	Volume of maintenance sessions and log retention period. Confirm that logs show who connected, when, and when the session was terminated.
Session termination testing	Implementation partner or internal engineers	One-time, repeated after changes	Number of session types and vendor tools. Testing should prove that connections end when maintenance is complete, not only after a timeout.
Evidence upkeep	Internal compliance staff or consultant	Recurring	Frequency of maintenance events and how many records are kept current, such as maintenance logs and approvals. Final-form evidence is required for a MET result.
External review or assessor support	Consultant for readiness; certified assessor for assessment	Recurring at each assessment cycle	Scope of the review and the assessor's rates. Only an independent assessor can make the final determination, so separate readiness work from assessment fees in any quote.

Open-source tools that can support the 3.7.5 evidence

MA.L2-3.7.5 has two testable parts: MFA on every nonlocal maintenance session over an external connection, and termination of that session when the work ends. The tools below can produce configuration and log evidence for those parts, but each one covers only a slice of the path, so the assessor will look at how they fit together in your environment.

Enforcing second factors with authentik

authentik (MIT) includes an authenticator validation stage that checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. For 3.7.5, the question is whether the flow that protects maintenance access requires a second factor and whether the stage is bound to the applications used for remote maintenance. Confirm that the methods you enable are all acceptable as MFA under your assessment, since SMS and email codes may be weaker than hardware or passkey options.

Second factors in FreeIPA

FreeIPA (GPL-3.0-or-later) supports two-factor authentication with HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server during migration, which can help when maintenance accounts move from an older system. Check that privileged maintenance accounts cannot bypass OTP and that the token enrollment records are retained as evidence.

Restricting external access with OPNsense

OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, and it supports aliases for address groups. Use it to allow maintenance traffic only from approved vendor or administrator addresses and to block every other external path to maintenance interfaces. Enable logging on the relevant rules so that rule matches can be reviewed in the live log view, which supports the termination and monitoring evidence an assessor will ask for.

Protecting web maintenance interfaces with Coraza

Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and it integrates with Caddy, HAProxy, Traefik and Nginx. It defends web-based maintenance consoles against injection and cross-site scripting attacks. It does not authenticate anyone, so it is not an MFA control and does not satisfy 3.7.5 by itself. Use it as hardening for the interface that sits behind your MFA gate.

Who does what for nonlocal maintenance controls

Your organization owns MA.L2-3.7.5 in full. The requirement is about who is allowed to maintain your systems from outside your network and how those sessions are controlled, and those decisions cannot be delegated to a vendor or a consultant. Internal staff decide which vendors and technicians may connect, approve each access window, and keep the records that prove the control operated. An assessor will ask for these records, so they must be complete, dated and kept current throughout the year, not assembled the week before an assessment.

Vendor access decisions: Approve which external maintainers may establish nonlocal sessions, for which systems, and for what purpose.
Session authorization: Record who requested each session, who approved it, the start and end times, and the work performed.
MFA policy: Define which second factors are accepted for maintenance accounts and confirm that no account bypasses them.
Termination checks: Confirm that each session was closed when the work finished, and investigate any session left open.
Records and the SSP: Keep the maintenance logs and describe the nonlocal maintenance practice in the system security plan.

Before an assessment, confirm that someone internal can walk an assessor through a single session from request to closure using only your records.

Questions buyers ask about MA.L2-3.7.5 cost, time and effort

What drives the cost of meeting MA.L2-3.7.5?

The main cost driver is how many nonlocal maintenance paths your organization has, because each path needs its own MFA enforcement, session termination and test evidence. The cost has four parts: staff time to configure and test, the MFA platform (open-source or licensed), any hardware tokens you choose to issue, and the external access gateway you already run or must add. Configuration and testing are one-time costs. Token replacement, license renewals, account reviews and periodic session log reviews recur. Ask any provider for a quote that lists each path, who performs each task, which licenses or hardware are included, and which evidence items are delivered. Without a written scope, the number is not comparable across bids.

Can a team meet MA.L2-3.7.5 without an outside partner?

Yes. The organization owns its controls, so an internal team can configure MFA for nonlocal maintenance sessions, terminate those sessions when the work ends and keep the records. An implementation partner can prepare systems and evidence, but it cannot issue reports or certificates. Only an independent assessor or certification body can do that. Internal teams usually need outside help when they lack hands-on experience with the MFA platform, the firewall or VPN, or when they need to present evidence in a form an assessor will accept. Whichever route you choose, the requirement is MET only when every assessment objective is satisfied with evidence in final form, not drafts.

What does MA.L2-3.7.5 need from internal staff?

Four groups of staff usually carry the work. System administrators configure the second factor for each maintenance account and confirm that vendor and contractor accounts cannot skip it. Network staff identify every external path used for maintenance and make sure each one ends when the session ends. Compliance or GRC staff record the maintenance records, configuration settings and enrollment records that serve as evidence. Vendor managers confirm with outside technicians that they use the approved method. Expect the work to pull these people away from routine operations during setup, so schedule it with those teams before the assessment window opens.

How long does MA.L2-3.7.5 take with several maintenance paths?

No duration figure applies to every environment, so the timeline depends mainly on the number of maintenance paths. A single vendor portal with one MFA method takes far less effort than a mix of vendor VPNs, remote desktop gateways and cloud consoles, where each path needs its own configuration, termination test and evidence set. Consider three things in your plan: the time to inventory every external path, the time to enroll and test second factors for each user group, and the time to collect evidence that the sessions end. Ask providers for a fixed-scope schedule that lists paths and milestones. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

Can a POA&M cover MA.L2-3.7.5 if the work is not finished?

No. MA.L2-3.7.5 is a 5-point requirement under the CMMC scoring methodology, and 32 CFR 170.21(a)(2) does not allow requirements worth more than 1 point on a plan of action and milestones (POA&M). It must be MET to reach Conditional or Final Level 2 status. If it is NOT MET, its 5 points are subtracted from the maximum score of 110. Plan the MFA and session termination work before the assessment, and collect the evidence in final form. Treat any open gap on this requirement as a blocker to scheduling, not as an item to track after the fact.

How does the current CMMC phase status affect MA.L2-3.7.5 timing?

The Department of War suspended CMMC Phase II on 13 July 2026. Phase II had been scheduled to start on 10 November 2026 and would have required Level 2 certification for applicable contracts. The suspension started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so the requirement still applies to contracts that carry those obligations. The DoW CIO page also says implementation is paused and may only require self-assessments at Levels 1 and 2, while the eCFR text still shows the original schedule. Confirm your current obligations with your contracting officer before you set a deadline.

What happens to the score if MA.L2-3.7.5 is not met?

The 5 points for MA.L2-3.7.5 are subtracted from the maximum score of 110. A single unmet requirement of this weight can move an organization below the threshold for Conditional or Final Level 2 status, and because it cannot be placed on a POA&M, it blocks that status until it is MET. Assessors check two objectives: that MFA is used to establish nonlocal maintenance sessions over external connections, and that those sessions are terminated when maintenance is complete. Before the assessment, confirm both objectives with a test session and keep the configuration settings and maintenance records that show the result.

How DeployOpen scopes and prepares MA.L2-3.7.5 evidence

DeployOpen approaches MA.L2-3.7.5 Nonlocal maintenance as a configuration and evidence task inside your own environment. We prepare the MFA gate for maintenance sessions, the session termination behavior and the records an assessor will examine, while your organization keeps ownership of the control and an independent assessor makes the determination.

How we scope

Inventory every external path used for vendor or administrator maintenance sessions, including VPN, remote desktop and vendor portals.
Confirm which systems in the CUI boundary accept nonlocal maintenance and which second factors your organization already enrolls.
Agree the written scope, deliverables and timeline with you before any work starts, since engagements are fixed-scope.

How we build

Configure MFA enforcement for maintenance accounts, for example through an authenticator validation stage that checks enrolled TOTP, WebAuthn or FIDO2 factors.
Restrict external maintenance entry points with firewall rules and aliases, with logging enabled for each rule match.
Test that MFA is required to establish a session and that sessions end when the maintenance window closes, and record the results.

How we hand over

Document the maintenance access procedure, the authentication settings and the session termination method in your system security plan inputs.
Deliver configuration exports, test records and firewall and identity logs that map to the two SP 800-171A assessment objectives for 3.7.5.
Hand over evidence in final form, with a short walkthrough so your team can show it to an assessor without DeployOpen present.

How we support

Confirm with your assessor or C3PAO which evidence formats they accept before we finalize the records.
Review the nonlocal maintenance configuration whenever systems, vendors or maintenance tools change, under a retainer if you want ongoing support.
Ask for the retainer terms and the scope of ongoing testing in writing, so responsibilities for each recurring task are clear.

MA.L2-3.7.5 Nonlocal maintenance