RMFInsider

A vendor wants remote access to patch an appliance sitting on your boundary. MA-4 Nonlocal Maintenance lets you say yes, and it tells you exactly what you owe the assessor afterward: a written approval, a maintenance method documented in the system security plan, strong authentication on the way in, a record of the session, and evidence that the session and the underlying network connection were both torn down when the work finished. Nothing in the control forbids vendor remote maintenance. What generates the finding is the other version, where the approval happened on a phone call, the session rode the same path as everything else, and the only surviving record is a calendar entry that says “vendor call.”

MA-4 lives in NIST SP 800-53 Rev 5, published September 2020 with updates as of December 10, 2020, and refreshed when NIST issued Release 5.2.0 on August 27, 2025. The base control sits in the low, moderate and high baselines, so it applies to every system you own. The Maintenance family gets skipped in control reviews because it sounds like a facilities problem. It is not. It is an access control problem wearing a maintenance badge.

What MA-4 Actually Says

Rev 5 states the control in five parts. Read them as five separate artifacts, because that is how they get assessed:

• Approve and monitor nonlocal maintenance and diagnostic activities.
• Allow nonlocal maintenance and diagnostic tools only as consistent with policy, and document the allowed ones in the system security plan.
• Employ strong authentication when establishing the session.
• Maintain records of nonlocal maintenance and diagnostic activities.
• Terminate the session and the network connection when maintenance is complete.

The discussion draws the line that decides whether MA-4 applies at all: nonlocal maintenance is carried out over an external or an internal network, while local maintenance requires physical presence at the system. An internal network still counts. The contractor who badges into your building, then reaches the device from a laptop on a different VLAN, is doing nonlocal maintenance, and I have watched that argument cost a team a week with an assessor who was right.

One Rev 4 habit is worth unlearning. Rev 4 had a separate enhancement, MA-4(2) Document Nonlocal Maintenance, that an organization could decline to select. Rev 5 absorbed it into the base control, so documenting the method is item b now and cannot be tailored out.

The Approval and Documentation Chain

The approval is where this control fails, and it fails for a human reason. The vendor call is urgent, the engineer is helpful, and the ISSO is three rooms away, so somebody says yes out loud. Six months later the assessor asks who approved it and there is nothing to show.

MA-2 Controlled Maintenance makes the approval explicit. It requires you to schedule, document and review maintenance, repair and replacement records in line with manufacturer or vendor specifications, and to approve and monitor all maintenance whether performed on site or remotely, and whether the component is serviced in place or hauled elsewhere. MA-5 Maintenance Personnel adds the people half: a process for authorizing maintenance personnel, a current list of authorized maintenance organizations, verification that anyone working unescorted holds the required access authorizations, and a supervisor with both the access and the technical competence when they do not.

What an Approval Record Needs to Contain

A defensible approval is boring and short. Name the system, the component, the vendor organization and the individual, the method, the window, the escort, and the approving official with a date. The ISSO drafts it. The ISSM or the official the AO designated in policy signs it. The security plan records the method once, and each session points back at the plan.

The second half of the chain is the one people miss. A vendor maintenance path is also a remote access path, which puts AC-17 Remote Access in play: usage restrictions, configuration and connection requirements, and implementation guidance documented for each allowed type of remote access, with each type authorized before connections are permitted. If “vendor nonlocal maintenance” is not one of your enumerated AC-17 types, you have two findings on one set of facts. The path also has to survive the authorization boundary you drew under SC-7, and a maintenance tunnel nobody put on the diagram is a boundary finding.

Then there is the account. The vendor needs an identity, and that identity usually keeps existing between sessions because disabling it is inconvenient. That is exactly the condition that makes AC-2 the control assessors sample first: a privileged account with no documented owner, no recertification date, and a last-logon stamp from two quarters ago.

Strong Authentication on the Maintenance Path

Item c says strong authentication, and Rev 5 is unusually specific about what it means. The discussion ties the requirement back to the network access requirements in IA-2, then states that strong authentication requires authenticators resistant to replay attacks and should include multifactor authentication. The example given is a PKI certificate stored on a token protected by a password, a passphrase or a biometric, and it points at SP 800-63B.

In DoD that usually resolves to a CAC or an approved hardware token on the maintainer’s end, not a shared credential in a vault three people at the vendor can reach. Which raises the question of who issues, rotates and revokes it, and that is the authenticator management problem IA-5 exists to solve, including the maintenance accounts nobody claims.

Two enhancements tighten this. MA-4(4) Authentication and Separation of Maintenance Sessions requires replay-resistant authenticators and requires maintenance sessions separated from other network sessions using physically or logically separated communications paths, with encryption named as the way to separate a path logically. MA-4(6) Cryptographic Protection covers the session itself. Neither is in the standard moderate baseline, so if your system picks them up, that came from an overlay or an AO decision and the implementation statement should say so.

Monitoring, the Per-Session Record, and the Disconnect

Items a, d and e are the ones an assessor can test without talking to you, because they either produce artifacts or they do not. MA-4(1) Logging and Review turns monitoring into something checkable: log organization-defined audit events for nonlocal maintenance and diagnostic sessions, and review those records to detect anomalous behavior. The event list comes from AU-2 and the review obligation lines up with AU-6. Note what the enhancement never does: name a role. If your procedure does not say who reads the maintenance session logs and how often, the control is open no matter how good the logging is.

The Per-Session Record

MA-2 is also where record content comes from. Its guidance lists date and time, a description of the work, the names of the individuals who performed it, the name of any escort, and the components removed or replaced. Make that a form the vendor fills in before the session closes, not a thing you reconstruct in January:

• Date, start time and stop time, in a single time zone stated on the form.
• The approval this session executes against, by reference number or date.
• Vendor organization and the named individual who held the credential.
• The maintenance method and access path used, matching the security plan.
• What was changed, and the change or ticket number it maps to.
• The escort or supervising individual, where MA-5 requires one.
• Components removed, replaced or reconnected.
• Confirmation that the session and the network connection were terminated, and who verified it.

That last line is item e, and MA-4(7) Disconnect Verification makes it explicit: verify session and network connection termination after the session completes. It pairs with AC-12 Session Termination. SP 800-53B does not place MA-4(7) in any of the three baselines, so it is an overlay or AO addition when you see it. Write the verification step in anyway, because “the session closed” and “the firewall rule closed” are different sentences and only one is usually true. The vendor will be done in twenty minutes. The POA&M will be open for a year.

When the Equipment Leaves the Facility

Sometimes the fix is a return merchandise authorization and a drive in a box. MA-2 requires that organization-defined personnel explicitly approve removing components for off-site maintenance, that organization-defined information be removed from the associated media before the equipment leaves, and that afterward you check the potentially impacted controls still function. MA-3(3) Prevent Unauthorized Removal is the harder version: maintenance equipment holding organizational information does not leave unless it is verified to contain none, or sanitized or destroyed, or retained on site, or explicitly exempted by an authorized official. MA-3(1) Inspect Tools and MA-3(2) Inspect Media cover the inbound direction, the vendor’s laptop and diagnostic media, which has to be checked for malicious code first.

MA-4(3) Comparable Security and Sanitization gives you two paths. Either require that the nonlocal maintenance and diagnostic service run from a system with security capability comparable to the one being serviced, or remove the component first, sanitize it of organizational information, then inspect and sanitize it for potentially malicious software before reconnecting it. The first option is why vendor-managed support systems get scrutiny. The second is why you need a certificate, and the wipe, degauss and destroy decision under MP-6 is the same decision with different paperwork.

MA-4(3) is also the enhancement that appears first as impact level rises. The FedRAMP control set requires it only at the top baseline class, and the DoD Cloud Computing SRG tailoring follows the same shape, picking it up ahead of the logging, separation, cryptographic and disconnect-verification enhancements. Check your baseline export in eMASS before arguing about which enhancements apply, because the assessor is reading the same export.

The Evidence Package an Assessor Will Ask For

Build this once per system and MA-4 stops being a scramble.

• The MA-1 maintenance policy and procedure, with nonlocal maintenance addressed by name.
• The security plan section documenting approved nonlocal methods and tools, which is item b.
• The MA-5 list of authorized maintenance organizations, with an owner and a review date.
• Signed approvals, per method or per session, with the approving official named.
• Completed per-session records, including the termination verification line.
• Audit log extracts for a sample of sessions, plus the record showing someone reviewed them.
• Sanitization certificates for any component that left the facility.
• AC-17 documentation listing vendor maintenance as an authorized remote access type.

If that looks like a subset of a much larger pile, it is, and the fastest way to find the gaps is to work from the full ATO artifact inventory rather than one control at a time.

MA-4 is not a hard control. It punishes informality. The vendor access is almost always defensible; the verbal approval, the shared credential, the session on the production path and the connection that stayed up are what turn a routine patch into a finding with a remediation date. Write the approval down before the call, make the vendor fill in the record before they hang up, and verify the disconnect yourself.

If you want the rest of the pile organized the same way, control by control with the artifact each one produces, that is what the RMF Checklist is built to do, so the next time a vendor asks for twenty minutes of access you already know what you will hand the assessor.