In Nugget #14 we covered the physical space housing your systems. This nugget covers what happens when someone, internal staff, a vendor, or an MSP, needs to actually touch that equipment. Maintenance is one of the more mundane-sounding control families in CMMC, right up until a routine repair becomes the way CUI walks out the door or malware walks in.
CMMC Level 2 maintenance requirements come from the Maintenance (MA) family of NIST SP 800-171 Rev 2, all six of which are Level 2 controls. NIST SP 800-171A assesses each one through the same lens: can you show, not just tell, that maintenance activity is controlled, sanitized, scanned, authorized, and supervised.
MA.L2-3.7.1: Perform maintenance on organizational systems
This control requires organizations to actually perform maintenance, on a defined schedule not on an ad hoc basis. That means a documented maintenance schedule covering both preventive and corrective maintenance, and records of maintenance activities as they’re performed: what was done, when, on which system, and by whom. Those records are what an assessor will ask to see; a policy stating maintenance happens is not itself evidence that it happens
Example: A manufacturing contractor defers firmware updates and hardware maintenance on its CUI-hosting servers for over a year to avoid production downtime. When a drive finally fails, the recovery process takes the CUI environment offline for three days and the outdated firmware is found to have several unpatched vulnerabilities that had been flagged for months.
Potential Pitfalls:
- Unscheduled downtime from deferred maintenance disrupting operations at the worst possible time
- Unpatched systems accumulating known vulnerabilities that become direct assessment findings
- Emergency repairs costing significantly more than a scheduled maintenance program would have
MA.L2-3.7.2: Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance
Example: An MSP technician performing routine maintenance connects a personal USB diagnostic tool that was never approved or scanned by the organization’s IT security team. The tool is later found to have been carrying a credential-harvesting payload from a prior job site.
This control is about more than blocking rogue technicians. Assessors specifically look for:
- A documented approval process for maintenance tools, both organization-owned and vendor-supplied
- Formal maintenance agreements with third parties (MSPs, OEM support vendors) that define scope and access boundaries
- Access controls limiting maintenance personnel, internal or external, to only the systems relevant to their work
Potential Pitfalls:
- Uncontrolled tools introducing malware or unauthorized changes
- Maintenance procedures causing data corruption because the tool or technique wasn’t vetted
- No formal agreement in place with third-party maintenance providers, leaving scope undefined
MA.L2-3.7.3: Ensure equipment removed for off-site maintenance is sanitized of any CUI
Example: A defense contractor ships a malfunctioning server to an OEM repair center without wiping it first. The drive contains unreleased technical drawings tied to a DoD contract, which are now sitting on a bench at a third-party facility with no chain-of-custody documentation.
Potential Pitfalls:
- CUI exposure to unauthorized individuals outside the organization’s control
- Legal and contractual exposure under DFARS 252.204-7012 for failing to safeguard CUI
- Reputational damage that follows a contractor into future award decisions
MA.L2-3.7.4: Check media containing diagnostic and test programs for malicious code before the media are used in organizational systems
Example: A technician brings in a USB drive loaded with diagnostic utilities from a previous engagement at another company. It’s plugged directly into a CUI-hosting workstation without being scanned first, and it’s carrying malware picked up at that prior site.
Potential Pitfalls:
- Malware introduced through unchecked diagnostic media, spreading before anyone notices
- Operational downtime while infected systems are isolated, cleaned, and restored
- Data integrity issues from malware that corrupts files before detection
MA.L2-3.7.5: Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete
Example: An organization allows its MSP to connect via a remote support tool secured only by a username and password. The credentials are reused across multiple client environments, and when one of those environments is compromised, the attacker walks straight into this organization’s network through the same remote access path.
Assessor Reality Check: This is arguably the most commonly failed MA control in CMMC assessments, and its absence from most compliance conversations is part of why. Remote vendor support, MSP access, and administrator maintenance sessions are extremely common in DIB environments, and MFA is required for every one of them. There are no vendor exemptions. Assessors will also check that sessions are actually terminated when maintenance ends, not left open indefinitely for convenience. A session log showing connections that were never closed is a direct finding.
MA.L2-3.7.6: Supervise the maintenance activities of maintenance personnel without required access authorization
This control assumes the technician is legitimately present to do the work. The requirement is about what happens next: if that person hasn’t been vetted or granted access authorization to your CUI environment, they can’t be left alone with it. Supervision by an authorized individual is the control that closes that gap.
Example: A government contractor brings in a third-party technician for an emergency repair without first confirming the technician holds the appropriate access authorization. The technician is left alone in the server room and, while there, browses project files unrelated to the repair.
Potential Pitfalls:
- Unauthorized access to sensitive information by personnel who were never properly vetted
- Insider threat exposure, intentional or not, from unsupervised access
- Compliance violations for allowing unescorted access without required authorization
Common Failures Across This Control Set
MA.L2-3.7.1 Maintenance deferred or undocumented; no defined schedule
MA.L2-3.7.2 No formal agreement or tool approval process for third-party maintenance
MA.L2-3.7.3 Equipment shipped off-site without sanitization or chain-of-custody documentation
MA.L2-3.7.4 Diagnostic media used without malware scanning beforehand
MA.L2-3.7.5 Remote maintenance sessions lack MFA or aren’t terminated when complete
MA.L2-3.7.6 Unauthorized personnel left unsupervised during maintenance
SSP Mapping Note
All six controls in this nugget belong under the Maintenance (MA) section of your SSP. The control most often left undocumented is MA.L2-3.7.5, since organizations frequently treat vendor remote access as an IT operations matter rather than a compliance-relevant control requiring its own documented MFA enforcement and session termination process.
For each control your SSP should document:
- The specific technical or procedural implementation
- The policy governing it, including tool approval and sanitization procedures
- Who is responsible for authorizing and supervising maintenance activity
- How compliance is verified, including MFA enforcement for remote sessions
For assistance assessing your facility’s physical security posture or documenting alternate work site safeguards, contact DTC’s C3PAO team.