CMMC Level 2 Practice 3.7.5: Require multifactor authentication to establish nonlocal maintenance sessions via external

CMMC Level 2 Practice 3.7.5 requires you to enforce multifactor authentication (MFA) any time a maintenance session is initiated remotely (nonlocal) through an external connection (for example, a third party support engineer connecting over the internet). Operationalize it by inventorying all remote maintenance paths, forcing MFA at the access point, and retaining logs and configurations that prove MFA is required and works. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Key takeaways:

• Scope “nonlocal maintenance via external” across people, tools, and devices, not just VPN users. (NIST SP 800-171 Rev. 2)
• Put MFA enforcement at the boundary (VPN/ZTNA/remote access gateway) and validate it with logs and test evidence. (NIST SP 800-171 Rev. 2)
• Evidence wins assessments: keep configs, access policies, tickets, and authentication logs mapped to each maintenance pathway. (DoD CMMC Program Guidance; 32 CFR Part 170)

“Remote maintenance” is a high-risk exception pathway because it often bypasses normal user workflows: emergency fixes, firmware updates, specialized admin tools, and third party support. CMMC Level 2 Practice 3.7.5 focuses on one narrow but common failure mode: remote maintenance sessions established through external connections without strong user verification. The requirement is not asking you to “have MFA somewhere in the environment.” It asks you to require MFA to establish the remote maintenance session when that session is nonlocal and initiated through an external network. (NIST SP 800-171 Rev. 2)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as an access-path control: enumerate every way maintenance can occur remotely, decide where MFA will be enforced, and prove it with repeatable evidence. You will also need to align IT operations, security engineering, and third party management so external support cannot create “shadow” access (shared admin accounts, persistent vendor VPNs, or break-glass credentials with no second factor). CMMC assessments reward clarity: a tight control statement, complete scoping, and evidence that matches how maintenance really happens. (DoD CMMC Program Guidance; 32 CFR Part 170)

Requirement: CMMC Level 2 Practice 3.7.5

Target keyword: cmmc level 2 practice 3.7.5: require multifactor authentication to establish nonlocal maintenance sessions via external requirement

This practice is mapped to NIST SP 800-171 Rev. 2 control 3.7.5 and is assessed under the CMMC Program. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Regulatory text

Provided excerpt: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.7.5 (Require multifactor authentication to establish nonlocal maintenance sessions via external).” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Operator interpretation (what you must do):

• Identify maintenance sessions that are nonlocal (remote) and initiated via external connections (outside your internal network boundary).
• Ensure MFA is required to start the session, not optional and not bypassable through alternate tooling.
• Maintain evidence that MFA is technically enforced on the actual path used for maintenance and that the enforcement applies to internal admins and third parties performing maintenance. (NIST SP 800-171 Rev. 2)

Plain-English interpretation

If someone is going to remotely “work on” your systems from outside your environment, they must prove their identity with MFA before they can get in. Password-only access is not acceptable for remote maintenance entry points. This includes third party remote support and your own admins connecting from home or while traveling if they are starting a maintenance session through an external network. (NIST SP 800-171 Rev. 2)

What counts as a “maintenance session” in practice

• Remote administration to apply patches, fix outages, update configs, rotate certificates, modify firewall rules, or perform troubleshooting.
• Remote access to network devices, servers, hypervisors, OT/IoT management consoles, and security tooling when the purpose is maintenance/administration.
• Support sessions initiated by a third party for diagnostics or remediation. (NIST SP 800-171 Rev. 2)

Who it applies to

Entity scope

• Organizations seeking CMMC Level 2 certification and handling CUI in scope of CMMC assessment. (32 CFR Part 170; DoD CMMC Program Guidance)

Operational scope (systems and pathways)

Apply the requirement to any system where remote maintenance can occur, including:

• CUI enclaves and supporting infrastructure (identity, remote access gateways, endpoint management).
• Third party support access routes (vendor portals, remote support tools, managed service access).
• Emergency access methods (break-glass accounts) when used externally. (NIST SP 800-171 Rev. 2)

What you actually need to do (step-by-step)

1) Build a complete inventory of nonlocal maintenance pathways

Create a “Remote Maintenance Access Register” with:

• Who: internal IT, security admins, developers with admin access, third party support roles.
• What: systems/devices maintained (servers, firewalls, endpoints, SaaS admin consoles that affect CUI workflows).
• How: protocols/tools (VPN, RDP, SSH, remote support agents, bastion hosts, ZTNA, cloud console access).
• Where MFA is enforced today (IdP, VPN, PAM, remote support tool).
• Gaps (password-only, shared accounts, persistent tunnels, unmanaged endpoints). (NIST SP 800-171 Rev. 2)

Practical scoping tip: ask operations for the last few maintenance tickets and trace the actual access path used. Your register should match reality, not diagrams.

2) Decide the enforcement point for MFA (and make it hard to bypass)

Pick a control pattern per pathway, then standardize where possible:

Pattern A: MFA at remote access gateway

• Enforce MFA on VPN, ZTNA, bastion host, or remote desktop gateway.
• Pros: clean boundary, strong audit trail.
• Watch-out: alternative paths (direct SSH exposed to internet, unmanaged remote tools). (NIST SP 800-171 Rev. 2)

Pattern B: MFA at Identity Provider (SSO) for admin consoles

• Use SSO with MFA for cloud/admin portals and management planes.
• Pros: central policy.
• Watch-out: local accounts and “emergency admin” accounts that bypass SSO. (NIST SP 800-171 Rev. 2)

Pattern C: MFA through Privileged Access Management (PAM)

• Require MFA to check out credentials or start privileged sessions.
• Pros: strong session governance, can support third parties.
• Watch-out: direct device logins outside PAM. (NIST SP 800-171 Rev. 2)

Rule for operators: if more than one path can start maintenance, every path needs MFA or must be disabled.

3) Lock down third party maintenance access

For third parties, implement these minimum operational constraints:

• Named accounts only (no shared “vendoradmin” logins).
• MFA required at the point of entry (IdP, VPN, PAM, or remote support platform).
• Time-bounded access through approvals and ticket linkage when feasible.
• No persistent vendor tunnels unless you can prove MFA is required at session start and access is monitored. (NIST SP 800-171 Rev. 2)

Your third party risk program should require these as contract and onboarding conditions for any third party that performs maintenance on in-scope systems. (DoD CMMC Program Guidance)

4) Implement and validate MFA technically

For each pathway in the register:

• Configure MFA policy (who, what apps, what networks).
• Confirm “MFA required” is enforced for remote maintenance roles/groups.
• Attempt a controlled test: verify access fails without second factor and succeeds with it.
• Capture evidence (screenshots/exports of policy + authentication logs showing MFA challenge). (NIST SP 800-171 Rev. 2)

5) Add monitoring and recurring evidence capture

Assessors will look for proof the control operates over time, not just a one-time configuration.

• Centralize authentication logs where practical.
• Review remote maintenance authentication activity for anomalies and policy drift.
• Re-run a lightweight access-path test after major changes (IdP policy changes, VPN upgrades, new support tools). (DoD CMMC Program Guidance; 32 CFR Part 170)

Daydream fit: use Daydream to map 3.7.5 to a documented control statement, assign an owner, and schedule recurring evidence requests (policy export + sample MFA logs + maintenance access register updates). This keeps the evidence trail continuous rather than assembled the week before assessment. (DoD CMMC Program Guidance)

Required evidence and artifacts to retain

Keep evidence tied to each remote maintenance pathway.

Governance artifacts

• Control narrative for 3.7.5 (scope, enforcement points, exceptions).
• Remote Maintenance Access Register (system/pathway inventory and owners).
• Third party access standards (requirements for named accounts and MFA). (NIST SP 800-171 Rev. 2)

Technical artifacts

• MFA policy configuration exports (IdP/VPN/ZTNA/PAM/remote access gateway).
• Group/role mappings showing maintenance users are covered by MFA policy.
• Screenshots or configuration snippets showing MFA required at session establishment.
• Authentication logs showing MFA challenges for remote maintenance sessions.
• Remote access logs (VPN/ZTNA/bastion) showing session start events. (NIST SP 800-171 Rev. 2)

Operational artifacts

• Maintenance tickets/requests that demonstrate approved remote maintenance activity.
• Access approval records for third parties (where your process requires it).
• Exception approvals (if any) with compensating controls and expiration. (DoD CMMC Program Guidance)

Common exam/audit questions and hangups

Expect the assessor to press on scope and bypass routes.

1. “Show me all ways a third party can remotely maintain in-scope systems.”
   Hangup: teams forget remote support agents, out-of-band device management, or cloud console access. (NIST SP 800-171 Rev. 2)

2. “Where is MFA enforced, and can the user reach the target without it?”
   Hangup: MFA is on VPN, but SSH is exposed or local accounts exist. (NIST SP 800-171 Rev. 2)

3. “Prove MFA is required to establish the session.”
   Hangup: you can show an MFA policy, but you cannot show logs or a test that ties to maintenance sessions. (NIST SP 800-171 Rev. 2)

4. “How do you handle emergency maintenance?”
   Hangup: break-glass accounts exist but have no MFA and no guardrails for external use. (NIST SP 800-171 Rev. 2)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails 3.7.5	Avoid it by
MFA “available” but not required	Optional MFA does not meet “require”	Enforce conditional access requiring MFA for remote maintenance roles and entry points. (NIST SP 800-171 Rev. 2)
Only VPN has MFA	Maintenance may occur through other tools	Inventory every pathway; disable or gate noncompliant paths. (NIST SP 800-171 Rev. 2)
Shared third party accounts	No individual accountability; MFA may be bypassed	Require named accounts and onboarding tied to identity lifecycle. (NIST SP 800-171 Rev. 2)
Local admin accounts bypass SSO/MFA	External session can start without MFA	Reduce/disable local accounts, or enforce MFA at the gateway/PAM. (NIST SP 800-171 Rev. 2)
Evidence assembled late	Gaps appear under questioning	Schedule recurring exports/log samples; keep the access register current. (DoD CMMC Program Guidance)

Enforcement context and risk implications

CMMC Level 2 assessments are performed against the CMMC Program requirements in regulation and program guidance, and the practice is mapped directly to NIST SP 800-171 Rev. 2. Noncompliance creates a predictable risk: a compromised password (internal admin or third party) can become direct remote maintenance access into in-scope systems. Treat this control as a primary barrier against external credential abuse for privileged activity. (32 CFR Part 170; DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and stop obvious bypass)

• Name an owner (IAM or security engineering) and a compliance counterpart for evidence.
• Build the Remote Maintenance Access Register from tickets, firewall rules, VPN/ZTNA apps, and third party lists.
• Identify any internet-exposed admin services or remote tools used for maintenance and prioritize gating them behind MFA.
• Draft a short control narrative for 3.7.5 with scoping rules and enforcement points. (NIST SP 800-171 Rev. 2)

By 60 days (standardize enforcement and third party controls)

• Enforce MFA for each registered pathway (VPN/ZTNA, bastion, PAM, SSO).
• Convert shared third party accounts to named accounts; remove or quarantine legacy access paths that cannot support MFA.
• Implement a ticket-linked approval workflow for third party maintenance where your operations model supports it.
• Start collecting recurring evidence (policy exports + authentication logs). (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

By 90 days (prove operation and harden exceptions)

• Run a tabletop “remote maintenance attempt” test across pathways and document expected MFA prompts and log outputs.
• Review and reduce exceptions; add expirations and compensating controls for any remaining edge cases.
• Package assessor-ready evidence: register, policies, log samples, and a walk-through script that ties artifacts to each pathway.
• Use Daydream to keep the evidence set current with scheduled requests and a control-to-evidence map for 3.7.5. (DoD CMMC Program Guidance)

Frequently Asked Questions

Does 3.7.5 apply only to third party maintenance, or also to my internal admins working remotely?

It applies to nonlocal maintenance sessions established via external connections, regardless of whether the user is internal or a third party. Scope based on the access path and purpose (maintenance), not employment status. (NIST SP 800-171 Rev. 2)

If we require MFA for VPN, is that enough?

Only if VPN is the sole way to establish remote maintenance sessions and there are no alternate paths that bypass VPN. Validate by enumerating pathways and confirming inbound rules, remote tools, and local accounts cannot start maintenance externally without MFA. (NIST SP 800-171 Rev. 2)

Do remote support tools (screen sharing, RMM, remote assist) fall under this requirement?

If they are used to perform maintenance and are initiated externally, treat them as nonlocal maintenance pathways. Configure the tool to require MFA at sign-in/session start and retain logs showing MFA events. (NIST SP 800-171 Rev. 2)

How should we handle break-glass or emergency maintenance accounts?

Define whether they are permitted for external use; if they are, require MFA or move emergency access behind a gateway/PAM that enforces MFA. If they are not, document the restriction and implement controls to prevent external session establishment with those accounts. (NIST SP 800-171 Rev. 2)

What evidence is most convincing to an assessor for 3.7.5?

A complete pathway inventory, the MFA enforcement configuration for each pathway, and authentication/session logs showing MFA is required when sessions are initiated. Add a small set of recent maintenance tickets that tie to those sessions. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

We have a third party that cannot support MFA. Can we claim an exception?

Treat it as a risk decision that must be time-bounded and backed by compensating controls, then work to eliminate it. For assessment readiness, you need clear documentation of the exception and proof that alternative compliant access is the standard. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)