MA-4(5): Approvals and Notifications

Remote maintenance is one of the easiest ways for unauthorized access to look “legitimate.” It often happens under time pressure, involves privileged accounts, and crosses organizational boundaries with third parties (OEMs, MSPs, software support, incident responders). MA-4(5) exists to force an explicit decision point before that access occurs, and to make the decision reviewable after the fact.

This page focuses on the requirement-level mechanics: who approves, what “each nonlocal maintenance session” means in practice, what you need to log, and how to design the workflow so engineers can still get work done. You’ll leave with a simple operating model: a maintenance request that becomes an approval record, which becomes a time-bounded access grant, which produces logs you can reconcile.

Scope note: MA-4(5) is part of NIST SP 800-53 Rev. 5 (Maintenance family). It commonly appears in federal information systems and contractor environments handling federal data, and it maps cleanly to expectations in many security programs that control privileged remote access ¹.

Regulatory text

Requirement excerpt (verbatim): “Require the approval of each nonlocal maintenance session by {{ insert: param, ma-04.05_odp.01 }} ; and” ².

Operator meaning: you must define who can approve (the organization-defined parameter) and then enforce that every remote maintenance session receives that approval before the session starts. Your implementation has to be auditable: an assessor should be able to select remote maintenance sessions from logs and find matching approvals.

Plain-English interpretation

• “Nonlocal maintenance session” = maintenance performed remotely (not physically present at the system). Typical examples: remote vendor support via VPN, remote OEM diagnostics, MSP remote admin, remote patching performed by a third party, remote incident response access.
• “Require the approval of each … session” = approval is per session, not per vendor, not per contract, not per year. If a third party connects today and again tomorrow, those are separate approvals unless your workflow defines a “session” as a bounded maintenance window and you can prove the connection stayed inside it.
• “by [defined approver]” = you must explicitly name eligible approvers (role(s) or specific positions) and ensure the approval is recorded.

Who it applies to

Entity scope

• Federal information systems operating under NIST SP 800-53 control baselines ³.
• Contractor systems handling federal data where NIST SP 800-53 is a contractual or program requirement ³.

Operational scope (where this shows up)

• Third-party remote support and maintenance (OEM, SaaS support requiring privileged access, managed service providers, network/security vendors).
• Internal IT/OT remote maintenance where “nonlocal” is interpreted as remote admin into sensitive environments.
• Environments where remote tooling is used: VPN, bastion/jump hosts, privileged access management (PAM), remote desktop gateways, remote support agents.

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

Step 1: Define “nonlocal maintenance” and “session” for your environment

Write a short standard that answers:

• What access methods count (VPN, remote support tools, PAM sessions, API-based admin actions)?
• What systems are in scope (production only, regulated enclaves, OT networks, all endpoints)?
• What is a “session” (single connection, maintenance window, or ticketed change window)? Keep definitions tight enough that logs can prove compliance.

Step 2: Assign the approver role(s) and approval conditions

The requirement’s parameter means you must pick the approving authority. Common workable patterns:

• System owner approval for that asset/application.
• Operations/IT manager on-call approval for time-sensitive maintenance.
• Security or IAM approval when privileged roles are requested or when the third party is new. Define minimum approval conditions:
• Identity of third party technician (named individual, not “vendor team”).
• Target system(s) or environment.
• Purpose and planned actions (at least a short description).
• Time window (start/end) and access path (PAM, VPN, jump host).

Step 3: Implement a “no ticket, no access” workflow

Build an operational chain that forces the approval to exist before access is granted:

1. Requestor opens a maintenance request (ticket) and tags it “Remote maintenance / nonlocal.”
2. Ticket routes to the correct approver based on system/environment.
3. Approver approves/denies; denial reason is required for audit clarity.
4. Upon approval, access is provisioned in a time-bounded way:
   • Add named user to an access group that expires, or
   • Issue a just-in-time credential, or
   • Allow a PAM session for a defined window.
5. After the window, access is removed automatically or verified removed.

If your tools cannot enforce gating, you can still comply, but you must add compensating controls (for example, manual enable/disable steps with dual verification) and be ready to explain how you prevent unsanctioned remote sessions.

Step 4: Capture and reconcile logs (approval ↔ session)

Auditors will sample remote connections and ask you to show the matching approval. Design reconciliation up front:

• Ticket/approval ID referenced in:
  • PAM session metadata, or
  • VPN connection notes, or
  • Jump host session tags.
• Remote session logs that show:
  • Who connected (named account),
  • When they connected,
  • What system(s) they reached,
  • Session duration and termination method.

Step 5: Build an emergency path that is still controlled

Most teams fail MA-4(5) on “urgent support” exceptions. Define:

• Who can authorize emergency remote maintenance.
• How quickly retrospective approval must be recorded (set an internal standard and follow it consistently).
• What extra monitoring applies (screen recording, command logging, increased alerting) for emergency sessions. Keep this path rare, documented, and reviewed.

Step 6: Operationalize with recurring review

Add a recurring control activity:

• Review a sample of remote maintenance sessions and confirm approvals exist and match scope (system, person, timeframe).
• Review third-party access lists for stale accounts and ensure any standing access is justified under a separate policy (standing access is a common MA-4(5) conflict).

Required evidence and artifacts to retain

Maintain evidence that proves “each session was approved by the defined approver” ²:

• Policy/standard defining nonlocal maintenance, session boundaries, and approver role(s).
• Workflow artifacts: ticket templates, routing rules, approval fields, and screenshots or exports showing approval states.
• Per-session approval records: tickets with approver identity, timestamp, scope, and approval decision.
• Access provisioning records: group membership changes, JIT grants, PAM checkout logs, VPN enablement logs.
• Remote session logs: VPN, PAM, jump host, remote support tool logs; session recordings where available.
• Reconciliation reports: periodic evidence that sessions were matched to approvals, including exception handling.
• Exception register for emergency sessions and post-approval documentation.

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me the last several remote maintenance sessions and the approvals for each.”
• “Who is authorized to approve, and where is that defined?”
• “How do you prevent a third party from initiating a session without approval?”
• “Do you have any standing vendor VPN accounts? If yes, how does per-session approval work?”
• “How do you handle emergency support outside business hours?”
• “Can you demonstrate that approval scope matches what happened (system/time/person)?”

Hangups that trigger findings:

• Approvals exist, but they are generic (“approved vendor support”) with no system/time/person.
• Logs exist, but you cannot connect them to approvals.
• Approval is “implied” by a contract or MSA rather than recorded per session.

Frequent implementation mistakes (and how to avoid them)

1. Blanket approvals disguised as compliance.
   Fix: require a ticket per remote session or per bounded maintenance window, and tie access expiration to the window.

2. Approvals that don’t identify the individual technician.
   Fix: require named identities for third-party users; avoid shared accounts. Record the individual in the approval.

3. Approvals happen after access.
   Fix: gate remote access through PAM/JIT or an enablement step controlled by the approver or on-call manager.

4. Emergency path becomes the default.
   Fix: track emergencies in an exception register and review patterns; if it’s frequent, redesign the standard workflow for speed.

5. No reconciliation between ticketing and access logs.
   Fix: require the ticket ID in the remote session metadata (PAM reason field, VPN connection banner input, jump host login message).

Enforcement context and risk implications

No public enforcement cases were provided for this specific control in the supplied sources. Practically, the risk is straightforward: remote maintenance is a high-likelihood path to unauthorized privileged activity if approvals are informal or untracked. MA-4(5) gives you governance over “who allowed this remote access” and supports incident investigation by tying actions to an explicit decision record ³.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish a one-page standard: definitions, in-scope systems, approver role(s), and what fields are required in an approval ².
• Inventory remote maintenance paths and third parties that use them (VPNs, remote tools, PAM, jump hosts).
• Update ticket templates to capture required approval data (system, person, purpose, window).
• Start manual gating if needed (approved ticket required before enabling access).

Days 31–60 (enforce and connect logs)

• Implement routing to the correct approver and make approval a required workflow state.
• Tie access grants to tickets (JIT where possible; otherwise documented enable/disable steps).
• Configure logs to capture identity, timestamps, and target systems; standardize where ticket IDs are stored.
• Run the first reconciliation: pick a set of remote sessions from logs and prove approvals exist.

Days 61–90 (harden and audit-proof)

• Add emergency procedure with explicit authorization rules and post-event documentation steps.
• Implement recurring review and exception trending.
• Tighten third-party account hygiene (remove shared accounts; require MFA where feasible).
• Put evidence on a predictable cadence so an assessor can validate operating effectiveness without scramble. Daydream can help by mapping MA-4(5) to a control owner, a repeatable procedure, and a recurring evidence pack so you can answer sampling requests quickly ².

Frequently Asked Questions

Does MA-4(5) require approval for internal admins doing remote maintenance, or only third parties?

The text focuses on “each nonlocal maintenance session,” which many programs interpret broadly to include any remote maintenance in scope, regardless of who performs it. Define your scope explicitly and apply it consistently ².

Can a change approval count as the MA-4(5) approval?

Yes, if the change approval is per session (or per bounded window), performed by the defined approver, and includes the required details (person/system/time/purpose). You still need to reconcile it to remote access logs ².

What if the vendor’s support tool initiates outbound connections from our environment?

Treat it as nonlocal maintenance if it enables remote maintenance activity. Require a ticketed approval before enabling the tool, and log when it is enabled/disabled and who approved it ².

How do we handle “always-on” MSP access?

Always-on access conflicts with the “each session” approval intent unless you wrap each connection in a session approval and can prove enforcement. A common fix is moving MSP access behind PAM with time-bounded session approval.

Is email approval acceptable?

It can be, but it often fails audit because it’s hard to reconcile to sessions and easy to spoof or misfile. If you must use email temporarily, store it with the ticket, capture approver identity, and ensure remote access logs reference the same request ID.

What evidence do auditors usually sample?

They often start from remote access logs (VPN/PAM/jump host) and work backward to approvals, because that tests completeness. Prepare for that direction of testing by embedding ticket IDs into session records.

Footnotes

1. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5