MA-7: Field Maintenance

To meet the ma-7: field maintenance requirement, you must restrict or prohibit maintenance performed outside controlled facilities on specified systems, components, or devices, and limit it to approved conditions and methods. Operationalize MA-7 by defining what “field maintenance” covers, approving who can perform it, and retaining evidence that every field service event followed your restrictions. ¹

Key takeaways:

• Treat field maintenance as a high-risk exception path for repair and servicing, with explicit approvals and controls.
• Make restrictions enforceable: approved technicians, approved tools, approved locations, and secure remote support rules.
• Evidence wins audits: tickets, approvals, chain-of-custody, and post-maintenance validation must be easy to produce.

MA-7 exists because maintenance done “in the field” (outside your normal, controlled maintenance environment) is where guardrails often drop: devices are opened, diagnostics run, ports exposed, firmware touched, media connected, and third parties get hands-on access. For federal information systems and contractor systems handling federal data, that combination creates a direct path to unauthorized modification, data exposure, and loss of configuration integrity.

The control is short, but implementation needs precision. You have to define exactly what assets MA-7 applies to in your environment, what you will allow in the field versus what you will prohibit, and how you will enforce those boundaries with workflow, access control, and documentation. Most MA-7 findings are not about a team intentionally doing unsafe work. They happen because the organization cannot prove that field work was restricted, approved, supervised, and verified.

This page translates the MA-7 control statement into an execution-ready operating model: scope, roles, step-by-step process, required artifacts, audit questions, and a practical plan to stand up the control quickly and keep it running.

Regulatory text

NIST SP 800-53 Rev. 5 MA-7 states: “Restrict or prohibit field maintenance on {{ insert: param, ma-07_odp.01 }} to {{ insert: param, ma-07_odp.02 }}.” ¹

What an operator must do with this text

Because the parameters are organization-defined, you must:

1. Define the scope of what you mean by “field maintenance” and which assets it applies to (the “on {{…ma-07_odp.01}}” part).
2. Define the restriction or prohibition rules (the “to {{…ma-07_odp.02}}” part): where it may happen, who may do it, what methods/tools are allowed, and what conditions must be met.
3. Implement enforcement and evidence so you can show field maintenance was either blocked or performed only under your approved constraints. ²

Plain-English interpretation (requirement-level)

You must prevent ad hoc repairs and servicing outside controlled facilities unless you can keep the same security guarantees you would have in a managed maintenance environment. If field maintenance must happen, it needs explicit authorization, controlled access, controlled tools/media, traceable work records, and post-maintenance validation so you can trust the system afterward. ¹

Who it applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 Rev. 5 controls. ²
• Contractors and service providers handling federal data (common in FedRAMP, FISMA-aligned contracts, and agency security requirements) where MA-7 is flowed down in security requirements. ²

Operational context (where MA-7 shows up in real life)

• Break/fix repairs at remote offices, clinics, plants, or kiosks.
• Hardware replacement by a third party field technician.
• On-site maintenance for OT/ICS-like equipment, network devices, or appliances.
• “Smart hands” services in a colocation site.
• Emergency work where normal maintenance windows and supervision are bypassed.

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

Use this as your MA-7 operating procedure. Keep it short enough that engineers and service desk staff follow it.

Step 1: Define MA-7 scope and decisions you will enforce

Create an MA-7 “field maintenance decision” matrix:

Category	Your decision	Examples to list
In-scope assets	Identify systems/devices where field work is restricted	Servers, network gear, endpoints handling federal data, regulated appliances
Prohibited field actions	Actions never allowed outside controlled facilities	Firmware flashing, debug interface access, use of unknown removable media
Allowed field actions	Actions allowed with safeguards	Drive replacement with approved parts and chain-of-custody; vendor RMA swap
Allowed performers	Who can do it	Named internal technicians; approved third party provider under contract
Allowed locations	Where it can occur	Specific sites; secure rooms; approved cages
Supervision requirement	How you maintain control	Escort, remote supervision session, dual authorization

Your goal: remove ambiguity so “field maintenance” does not become a loophole.

Step 2: Put authorization into workflow (no ticket, no touch)

Implement a gating rule: no field maintenance without an approved service ticket that includes:

• Asset ID and location
• Requested maintenance action and reason
• Identity of performer (internal or third party)
• Required safeguards (escort, approved toolset, media restrictions)
• Approval by the control owner (or designated approver)

Make the approval decision explicit: approved, approved with conditions, or denied; must return asset to controlled facility.

Step 3: Control who can physically and logically access the asset

Field maintenance is a blended physical + logical access event. Your procedure should require:

• Identity verification of technicians (badge check, contract verification for third parties).
• Time-bounded access (temporary access windows, escorted entry, sign-in/out).
• Least-privilege logical access during maintenance (temporary admin access if needed, removed afterward).
• Prohibit unmanaged media and tools (no unknown USBs, no personal laptops connecting to management ports) unless explicitly approved under your MA-7 conditions.

Step 4: Control tools, diagnostics, and remote support paths

Most field work involves a laptop, console cable, or remote vendor session. Define allowed methods:

• Approved service laptops / jump kits with security baseline.
• Approved remote access tooling and session logging where feasible.
• Prohibited pathways (for example, direct inbound remote access from a third party to a production device) unless explicitly documented as an exception under MA-7 restrictions.

If you cannot control the toolchain, you cannot claim “restricted” field maintenance in a meaningful way.

Step 5: Chain-of-custody for components and data-bearing parts

If maintenance touches storage, memory, or any component that could contain sensitive data:

• Document part serial numbers removed/installed.
• Record who handled the component at each step.
• Store removed components per your media protection and disposal requirements, or route through approved destruction/RMA processes.

Step 6: Post-maintenance validation (don’t return to service blindly)

Before the system returns to normal operation, require a short validation checklist aligned to your environment:

• Configuration integrity check (baseline comparison, known-good config applied, or approved configuration review).
• Credential/access cleanup (remove temporary accounts, rotate credentials if exposed).
• Security checks relevant to the asset type (logs reviewed for unusual access during the maintenance window; confirm management interfaces restored to standard state).
• Close-out approval in the ticket.

Step 7: Exceptions process (controlled, expiring, reviewable)

You will face emergencies. Build a simple exception path:

• Business justification and risk acceptance owner
• Compensating controls (extra supervision, enhanced logging, isolation)
• Expiration date and post-event review requirement

Step 8: Make it auditable (map owner, procedure, recurring evidence)

Assign:

• Control owner (accountable)
• Process owner (runs the workflow)
• Evidence owner (produces artifacts for assessments)

In practice, many teams use Daydream to map MA-7 to a named owner, a maintenance procedure, and recurring evidence pulls so audit prep is not a quarterly fire drill.

Required evidence and artifacts to retain

Auditors typically want proof of both design (your rule) and operation (your tickets).

Keep these artifacts organized by system/component and time period:

• MA-7 policy/procedure defining “field maintenance,” scope, restrictions, and exception handling.
• Approved technician list (internal roster and approved third party providers).
• Sample of field maintenance tickets showing:
  • approvals,
  • identity of performer,
  • safeguards applied,
  • work performed,
  • parts swapped (if any),
  • close-out validation results.
• Visitor logs / physical access logs tied to maintenance windows (where available).
• Records of temporary access provisioning and removal (where applicable).
• Exception approvals with compensating controls and post-event review notes.

Common exam/audit questions and hangups

Use these to pre-brief your teams.

• “Define field maintenance in your environment. How is it different from normal maintenance?”
• “Which assets are in scope, and how do you prevent field work on the rest?”
• “Show me three recent field maintenance events and the approvals.”
• “How do you control third party technicians and their tools?”
• “How do you ensure the system is trustworthy after field service?”
• “What happens in an emergency when normal controls can’t be met?”

Hangup to expect: teams can describe the process verbally but cannot produce a clean packet of tickets, approvals, and validation records.

Frequent implementation mistakes and how to avoid them

1. Mistake: MA-7 is written as a policy statement only.
   Fix: embed MA-7 into service management workflows so work cannot start without approvals and required fields.

2. Mistake: “Approved vendor” is treated as sufficient.
   Fix: approval must be scoped to specific technicians or roles, specific actions, and specific toolchains. Third party status is not a control by itself.

3. Mistake: No post-maintenance validation.
   Fix: make the close-out checklist mandatory for ticket closure. Tie it to configuration management and access cleanup.

4. Mistake: Exceptions become the normal path.
   Fix: require expirations and post-event review. Track repeat exceptions and convert them into a standard, controlled method or prohibit the pattern.

5. Mistake: Storage handling is undocumented during swaps.
   Fix: add chain-of-custody fields to the ticket and require serial numbers for data-bearing components.

Risk implications (why auditors care)

Field maintenance is a privileged activity performed under imperfect conditions, often involving third parties, physical access, and temporary connections. Weak controls here can result in unauthorized modifications, introduction of malicious components, data exposure through mishandled parts, and loss of system integrity. MA-7 reduces those risks by forcing deliberate decisions and creating traceability. ²

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable MA-7)

• Name a control owner and publish a one-page MA-7 procedure with scope and restrictions.
• Identify in-scope assets and tag them in CMDB/asset inventory (or document the authoritative list).
• Add mandatory ticket fields: asset ID, performer identity, approvals, allowed actions, validation steps.
• Define and publish “prohibited in the field” actions that always require return-to-facility service.

Day 31–60 (make it enforceable)

• Implement technician allow-listing for third party field service (contract language plus operational roster).
• Add a standard “field maintenance close-out checklist” to tickets, and block closure without completion.
• Coordinate with Physical Security to tie maintenance events to entry/visitor logs where possible.
• Train service desk, IT ops, and site leads on the workflow.

Day 61–90 (make it repeatable and audit-ready)

• Run a tabletop test: simulate an emergency field repair and validate approvals, access, and evidence capture.
• Review a sample of recent tickets for completeness; fix form fields and guidance where teams stumble.
• Establish a cadence to review exceptions and recurring field work patterns.
• In Daydream, map MA-7 to the owner, procedure, and recurring evidence artifacts so you can produce an assessor-ready packet on demand.

Frequently Asked Questions

What counts as “field maintenance” for MA-7?

Treat it as maintenance performed outside your controlled maintenance environment, especially where physical access, third party involvement, or uncontrolled tools are introduced. Define it explicitly in your procedure so teams don’t guess. ¹

Can we allow third party technicians to do field repairs?

Yes, if your restrictions define who is authorized, what tools and methods are permitted, and what supervision and validation are required. Your evidence must show those conditions were met for each event. ²

Do we have to prohibit all field maintenance to comply?

No. MA-7 allows either restricting or prohibiting field maintenance based on organization-defined parameters. Many programs allow limited actions in the field and prohibit high-risk actions like firmware changes. ¹

What’s the fastest way to make MA-7 auditable?

Put it into your ticketing workflow with required fields and approvals, then retain a small, consistent evidence set per event (ticket, approval, access records, close-out validation). Assessors want repeatable proof, not verbal explanations.

How should we handle emergency break/fix situations?

Use a defined exception path with named approvers, compensating controls, and a post-event review. Document the reason normal restrictions could not be met and what you did to reduce risk.

How does MA-7 relate to other maintenance controls?

MA-7 focuses on the special risk of maintenance outside controlled facilities. You typically implement it alongside broader maintenance policies, access control, configuration management, and third party risk processes so field events don’t bypass standard safeguards. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5