MA-5: Maintenance Personnel
To meet the ma-5: maintenance personnel requirement, you must (1) run a defined authorization process for anyone who performs system maintenance and (2) keep an up-to-date list of approved maintenance organizations and/or individuals. Operationalize MA-5 by tying maintenance access to identity, scope, and time bounds, then retaining evidence that only authorized parties performed maintenance.
Key takeaways:
- Maintain a current, approved roster of maintenance personnel/organizations and make it the gate for maintenance work.
- Require documented authorization before maintenance begins, including scope, method, and access pathway.
- Keep artifacts that prove the control operated: approvals, tickets, access logs, and roster change history.
MA-5 is easy to “say yes to” in policy and easy to fail in an assessment because the control is evidence-driven. Auditors usually do not debate whether you intend to control maintenance access; they ask you to prove that maintenance is performed only by authorized personnel and that you can show the authorized list on demand. The operational reality is messy: internal admins “just fix it,” third-party field technicians show up with short notice, OEM support needs remote access, and facilities teams may touch devices without being in IT’s IAM workflows.
This page translates MA-5 into a checklist you can implement quickly: define who counts as maintenance personnel, build an authorization workflow that attaches to your ticketing/change process, and create a single roster that acts as the source of truth. You will also see what evidence to retain, what exam teams commonly test, and where teams break the chain of custody between “approved” and “actually did the work.” The goal is assessment readiness without slowing urgent repairs.
Regulatory text
Requirement (excerpt): “Establish a process for maintenance personnel authorization and maintain a list of authorized maintenance organizations or personnel;” (NIST SP 800-53 Rev. 5 OSCAL JSON)
Operator meaning:
You need two things that work together:
- An authorization process that decides who may perform maintenance (and under what conditions).
- A maintained list (roster) of authorized maintenance organizations/personnel that is current, governed, and used as the gate for maintenance activity.
A policy statement alone does not satisfy MA-5. Your process must be operational (tickets/approvals/access provisioning) and your list must be usable during operations and audits (exportable, owned, reviewed, and tied to evidence of actual maintenance events). (NIST SP 800-53 Rev. 5)
Plain-English interpretation (what MA-5 is trying to prevent)
MA-5 reduces the risk that maintenance becomes a backdoor for:
- Unauthorized system access (a technician account, shared credentials, “temporary” VPN that never expires).
- Malware introduction through tools, removable media, or remote support channels.
- Untracked configuration changes that undermine baselines and incident response.
You are proving governance over the “people and companies that touch the system,” not only the technical mechanism they use.
Who it applies to
Entities:
- Federal information systems and contractor systems handling federal data where NIST SP 800-53 is the control baseline. (NIST SP 800-53 Rev. 5)
Operational contexts that commonly fall under MA-5:
- Infrastructure maintenance (servers, network devices, storage, hypervisors).
- Endpoint maintenance (imaging, break/fix, hardware replacement).
- Cloud and managed services where the third party provides admin-level support.
- OT/IoT and facilities-integrated systems (badging, cameras, building management) where “maintenance” is often performed by non-IT groups or vendors.
- Emergency maintenance windows and incident-driven remediation.
Define “maintenance personnel” explicitly for your program:
Include anyone who can change configuration, firmware, software, or hardware components of in-scope systems, whether internal staff or a third party. If they can attach tools, run diagnostics, swap components, or access admin interfaces, treat them as maintenance personnel for MA-5 purposes.
What you actually need to do (step-by-step)
1) Assign ownership and a single system of record
- Control owner: usually IT Ops, SecOps, or Infrastructure; GRC sets requirements and tests evidence.
- System of record for the roster: IAM group/HR system for employees plus a vendor/third-party register for external parties, or a dedicated “authorized maintenance roster” register.
- Non-negotiable rule: maintenance cannot start unless the performer is on the authorized list or is added through an approved exception workflow.
Practical tip: Put the roster behind a workflow tool with approvals and an audit trail. Daydream can track MA-5 ownership, procedures, and recurring evidence artifacts so your roster governance does not live in someone’s spreadsheet. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2) Build an authorization workflow that matches how maintenance is requested
Your workflow should attach to how work enters the system today: service desk tickets, changes, incident tasks, facilities work orders, or OEM dispatch emails.
Minimum fields to capture in the authorization record:
- Requestor and business justification.
- System(s)/asset(s) in scope.
- Maintenance scope (what will change).
- Authorized personnel/organization (must match roster entry).
- Access method (onsite, VPN, bastion, remote support tool).
- Time window and expiration.
- Approver(s) (system owner + security if elevated access is involved).
Output: an approval artifact linked to the maintenance ticket/change record.
3) Create and maintain the authorized maintenance roster
Treat this as a controlled register, not a contact list. For each authorized person or organization, record:
- Legal entity name (for organizations) and named individuals (for personnel).
- Engagement type (employee, contractor, OEM, MSP).
- Systems/technology domain they are allowed to maintain.
- Access prerequisites (background checks if your program requires them, training, NDA/contract, security onboarding).
- Identity binding (corporate identity, federated identity, or named account mapping).
- Status (approved, suspended, expired) and who approved it.
- Start/end date or review cadence.
Operational rule: disable or remove roster entries when contracts end, personnel change roles, or access is no longer needed.
4) Tie roster authorization to access controls (make the roster enforceable)
MA-5 is stronger when the roster gates technical access:
- Require named accounts for maintenance work. Avoid shared “vendor” or “tech” logins.
- Map roster entries to IAM groups/roles used for admin access.
- For third-party maintenance, use time-bounded access (JIT/JEA patterns) where feasible and ensure session logging.
- If maintenance is onsite, tie authorization to badge access or escort requirements for sensitive spaces.
Even if MA-5 does not spell out technical controls, assessors will ask how you ensure “authorized list” translates into real-world access decisions.
5) Control the exception path (break-glass maintenance)
Emergency repairs happen. Your exception process should still produce evidence:
- Who approved the emergency authorization.
- Why pre-approval was not feasible.
- What access was granted and when it expired.
- Post-maintenance review that confirms the performer was either added to the authorized list retroactively (with justification) or the exception was closed and access removed.
6) Operate the control with recurring reviews
Do not wait for an audit. Run a recurring operational review that answers:
- Who is on the authorized roster today?
- Who performed maintenance since the last review?
- Were they authorized at the time of work?
- Are there stale/unused authorizations that should be removed?
Required evidence and artifacts to retain
Keep evidence that proves both “process exists” and “process was followed.” Common MA-5 evidence set:
- Maintenance personnel authorization procedure (SOP) with roles and approvals.
- Authorized maintenance roster export with approval metadata and last update.
- Roster change history (add/modify/remove) showing approvals and timestamps.
- Tickets/changes/incidents that show maintenance authorization before work began.
- Access logs for admin systems (VPN/bastion/remote support) tied to named individuals.
- Third-party contracts/SOWs that identify authorized maintenance parties and permitted work scope (as applicable).
- Termination/offboarding evidence for removed maintenance personnel (deprovisioning records).
Audit posture tip: store artifacts in a single evidence collection location per system boundary (GRC repository) and map each artifact to MA-5 so retrieval is not a scavenger hunt. Daydream is a natural place to map MA-5 to the control owner, implementation procedure, and recurring evidence artifacts. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Common exam/audit questions and hangups
Assessors often test MA-5 with sampling and negative testing. Expect questions like:
- “Show the current list of authorized maintenance organizations/personnel for this system boundary.”
- “Pick three recent maintenance events. Prove each performer was authorized at the time.”
- “How do you authorize OEM support engineers who change frequently?”
- “What prevents a project team from bringing in a contractor to ‘help’ without security review?”
- “What is your process for emergency maintenance authorization and how do you validate afterward?”
Hangups that trigger findings: roster exists but is not current; authorization approvals are missing or happen after the work; third-party identities are not attributable to individuals; facilities/Ops maintenance is out of scope “by assumption” with no documentation.
Frequent implementation mistakes (and how to avoid them)
| Mistake | Why it fails | Fix |
|---|---|---|
| Roster is a spreadsheet with no approval trail | Hard to prove governance and point-in-time authorization | Put roster changes behind workflow approvals and keep change history |
| “Vendor account” shared across technicians | No individual accountability; weak evidence | Require named accounts or named session attribution |
| Tickets show maintenance happened, but no pre-approval | Authorization process exists only on paper | Add a required approval step in ticket templates for in-scope assets |
| No coverage for onsite break/fix | Physical maintenance can alter system state | Treat onsite technicians as maintenance personnel; document escort/badge rules |
| Stale authorizations remain after contracts end | Unauthorized access persists | Link roster to offboarding and contract end dates; run recurring reviews |
Risk implications (why operators care)
Weak MA-5 operation shows up as “uncontrolled privileged access through maintenance.” That can expand breach impact, complicate forensics, and undermine your ability to assert system integrity after incidents. In federal and regulated contractor contexts, poor evidence for MA-5 can also cascade into broader findings across access control, configuration management, and incident response because maintenance actions touch all three. (NIST SP 800-53 Rev. 5)
Practical 30/60/90-day execution plan
First 30 days (stabilize and make it auditable)
- Name the MA-5 control owner and approvers.
- Inventory maintenance pathways: service desk, change, incident, facilities, OEM channels.
- Draft the MA-5 SOP: authorization steps, required fields, exception path.
- Stand up the initial authorized maintenance roster and populate it from HR/IAM and third-party records.
- Pick one “system of record” location for evidence and start attaching tickets and approvals.
Next 60 days (make it enforceable)
- Update ticket/change templates to require MA-5 authorization fields for in-scope assets.
- Bind roster entries to IAM roles/groups for admin access where possible.
- Remove shared maintenance accounts; migrate to named identities or attributable sessions.
- Implement emergency maintenance exception workflow with after-action review.
- Run a first operational review: reconcile maintenance events vs roster and remediate gaps.
By 90 days (operational maturity and steady-state)
- Formalize recurring roster review and maintenance event sampling as a control test.
- Add contract language or onboarding checklists so third-party maintenance personnel cannot start work without roster entry.
- Improve evidence quality: standardized export format, consistent ticket linking, and access log retention alignment.
- In Daydream, map MA-5 to the control owner, procedure, and recurring evidence artifacts so assessments become repeatable instead of bespoke. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Suggested control statement (drop-in)
“Only authorized maintenance organizations and personnel may perform maintenance on in-scope systems. Authorization is documented prior to maintenance through the approved workflow, and the authorized maintenance roster is maintained with approvals, review, and removal upon termination or contract end.” (NIST SP 800-53 Rev. 5 OSCAL JSON)
Frequently Asked Questions
Does MA-5 apply to internal IT admins, or only third-party technicians?
It applies to both. Anyone who performs maintenance on in-scope systems should be authorized through your process and covered by the authorized roster. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Can the “authorized maintenance list” be an IAM group membership export?
Yes if it clearly identifies individuals, approval provenance, and scope. Auditors will still ask how you govern additions/removals and how the list maps to actual maintenance events.
How do we handle OEM support engineers who rotate frequently?
Authorize the OEM organization and require named, attributable access for each engineer at the time of work, then expire it. Keep the ticket approval plus the access/session logs tied to that named individual.
What counts as “maintenance” for MA-5?
Treat any activity that can change system state as maintenance: configuration changes, patching, diagnostics tools, firmware updates, hardware swaps, and remote admin sessions. Document your definition and apply it consistently.
What’s the minimum evidence set to pass an assessment for MA-5?
A written authorization procedure, a current authorized roster with approval trail, and sampled maintenance records showing authorized performers plus supporting access logs. If you cannot show point-in-time authorization, expect a finding.
We outsource IT to an MSP. Does MA-5 still require our own roster?
You still need a maintained list for your environment. You can source the roster from the MSP, but you must govern it (approval, updates, removals) and be able to produce it during an audit.
Frequently Asked Questions
Does MA-5 apply to internal IT admins, or only third-party technicians?
It applies to both. Anyone who performs maintenance on in-scope systems should be authorized through your process and covered by the authorized roster. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Can the “authorized maintenance list” be an IAM group membership export?
Yes if it clearly identifies individuals, approval provenance, and scope. Auditors will still ask how you govern additions/removals and how the list maps to actual maintenance events.
How do we handle OEM support engineers who rotate frequently?
Authorize the OEM organization and require named, attributable access for each engineer at the time of work, then expire it. Keep the ticket approval plus the access/session logs tied to that named individual.
What counts as “maintenance” for MA-5?
Treat any activity that can change system state as maintenance: configuration changes, patching, diagnostics tools, firmware updates, hardware swaps, and remote admin sessions. Document your definition and apply it consistently.
What’s the minimum evidence set to pass an assessment for MA-5?
A written authorization procedure, a current authorized roster with approval trail, and sampled maintenance records showing authorized performers plus supporting access logs. If you cannot show point-in-time authorization, expect a finding.
We outsource IT to an MSP. Does MA-5 still require our own roster?
You still need a maintained list for your environment. You can source the roster from the MSP, but you must govern it (approval, updates, removals) and be able to produce it during an audit.
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream