Maintenance under 3.7.x is about preserving security while systems are repaired, serviced, or remotely administered. The risk often appears when a laptop leaves the facility, a vendor connects remotely, or a diagnostic tool touches an in-scope system.
For a resource-constrained defense contractor, the practical test is not whether a policy exists on paper, but whether the requirement is implemented inside the defined FCI/CUI boundary, assigned to an owner, and backed by current, checkable evidence.
The rule in plain English
Rev. 2 requires organizations to perform and control maintenance, control maintenance tools and personnel, sanitize equipment before off-site maintenance when needed, check diagnostic media, and protect remote maintenance sessions.
Treat maintenance as a temporary access event. The fact that a technician is fixing equipment does not automatically authorize broad access to CUI.
How to implement it without overbuilding
Create a small number of maintenance paths: internal repair, on-site vendor repair, remote vendor support, and off-site depot repair. Define what authorization, safeguards, and evidence apply to each.
For off-site repair, decide whether the device can be sanitized, the drive removed, or the repair handled under another controlled arrangement. Record the decision before the asset leaves.
What evidence to keep
Keep the maintenance ticket, technician identity, authorization, remote-session record, tool/media checks, sanitization or media-removal record, and closure of temporary access.
For remote work, retain evidence that the session used the approved protected path and ended or was disabled when work finished.
Where teams get into trouble
Weak patterns include permanent vendor support accounts, uncontrolled USB diagnostic media, remote tools outside the managed access path, and shipping failed storage media without first deciding what protected data remains on it.
Small-contractor walkthrough
A laptop containing CUI develops a hardware fault and the manufacturer requests depot repair. The maintenance workflow should decide whether storage can be removed or sanitized, who authorizes the shipment, and how the repair event is recorded before the device leaves control.
- Inventory maintenance methods.
- Disable standing vendor access where feasible.
- Define off-site sanitization rules.
- Approve remote maintenance paths.
Decisions to document before assessment
Before marking this topic ready, make four decisions explicit: inventory maintenance methods; disable standing vendor access where feasible; define off-site sanitization rules; and approve remote maintenance paths. Assign an owner and an evidence location to each decision.
Manual deep review: cover all six maintenance requirements through real repair paths
The Maintenance family is more specific than 'IT performs maintenance.' The assessment asks whether maintenance is performed; whether tools, techniques, mechanisms, and personnel are controlled; whether equipment is sanitized before off-site maintenance; whether diagnostic or test media is checked for malicious code; whether nonlocal maintenance sessions require MFA and terminate when work is complete; and whether maintenance personnel without required authorization are supervised. Model these through four paths: internal on-site work, vendor on-site work, nonlocal/remote maintenance, and off-site depot repair.
For equipment leaving the facility, force a CUI disposition decision before shipment. Determine whether storage can be removed, the device can be sanitized using the approved method, or repair can occur under another controlled arrangement. Record the asset identifier, action taken, approver, destination, and custody information. The point is to prove CUI did not leave organizational control because a broken device was rushed to a vendor.
For nonlocal maintenance, verify MFA is required to establish the external session and that the connection ends when maintenance finishes. Connect the session to the approved remote-access design, technician identity, privileged authorization, and session logs. If a technician lacks the required access authorization, document supervision appropriate to the work. Diagnostic/test media used on CUI systems should also follow the malware-check process before use.
Reconstruct one recent repair from its ticket. Show who performed it, which tool or media was used, what access was granted, what configuration changed, whether media or equipment left the facility, and how remote access or physical custody ended. This produces stronger evidence than a maintenance policy with no operating record.
- Maintenance ticket and technician identity.
- Sanitization or media-removal record.
- Remote-maintenance MFA and session closure evidence.
- Diagnostic-media malware check.
- Escort or supervision record when applicable.
Additional objective-level implementation notes
Maintenance can create temporary access that is more powerful than normal user access. Review vendor utilities, diagnostic laptops, firmware packages, temporary admin accounts, remote-support agents, and replacement media as part of the maintenance path. The repair ticket should not become an informal authorization to bypass normal identity, media, or change-management controls.
Compare a routine internal maintenance event with one exceptional path such as vendor remote support or depot repair. The comparison should show how tool control, diagnostic-media checks, MFA, session closure, sanitization, supervision, and custody differ when the maintenance method changes. This proves the family operates beyond the easiest internal-help-desk case.
Final manual spot check
For a final spot check, inspect a maintenance event that involved a third party or nonlocal connection. Confirm who authorized the technician, how the technician authenticated, whether the session or physical access was supervised as required, what diagnostic media or tools were introduced, whether those media were checked, and how the access ended. If equipment left the facility, include the sanitization or media-removal decision in the same evidence chain.
One more edge case to verify
Also verify that any maintenance-driven configuration change entered the normal change-management record after the repair. Maintenance should not become a permanent exception to configuration control simply because the change was made by a technician during troubleshooting.
Configuration follow-through
Record the result.
A short working check
- ✓Inventory maintenance methods.
- ✓Disable standing vendor access where feasible.
- ✓Define off-site sanitization rules.
- ✓Approve remote maintenance paths.
- ✓Record technician/session details.
- ✓Close temporary access after work.
Common questions
Must a broken drive always be wiped before repair?
The objective is to prevent unauthorized disclosure. Sanitization, drive removal, controlled repair, or another documented safeguard may be appropriate depending on the case.
Can a vendor use its normal remote-support tool?
Only if the organization has evaluated and approved that method in the CUI environment and can protect and evidence the session.
Do diagnostic media need checks?
Rev. 2 includes controls for checking media containing diagnostic and test programs before use.
Should vendor accounts stay enabled?
Standing access creates avoidable risk. Time-limited approved access is easier to defend.
Can normal remote-support software be used for maintenance?
Potentially, if the method is approved and the maintenance-specific controls, including MFA for nonlocal maintenance and termination when work ends, are met and evidenced.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
