MA-3 Maintenance tools: requirements and evidence

What MA-3 maintenance tools requires and why it is hard to show

MA-3 requires the organization to approve, control and monitor the maintenance tools used on its systems, and to review the list of approved tools at a defined frequency. The control focuses on diagnostic and repair tools that sit outside the system's authorization boundary, such as a laptop with a vendor diagnostic suite, a portable imaging device or a firmware flashing kit. Those tools can read, change or copy data from a system that has already been authorized, and the authorization itself does not reach them. MA-3 closes that gap by making each tool a known, approved item with defined rules for when and how it may be used.

SP 800-53B allocates MA-3 only to the moderate and high baselines, not to the low baseline, and it is not part of the privacy baseline. The moderate and high baselines add MA-3(1), MA-3(2) and MA-3(3), which cover inspecting tools and media, preventing unauthorized removal, and restricting the use of tools to authorized personnel. Confirm the exact enhancement wording and selection in the SP 800-53B profiles and in the CPRT entry before you write it into your system security plan, since your authorizing official will expect the baseline you select to match the system's impact level.

The control is hard to show because maintenance tools rarely live in one place. Diagnostic software sits on engineers' laptops, licenses are tied to vendor portals, and field kits move between sites and contractors' bags. An assessor testing the organizational process will ask for the approved tool list, the approval record for each tool, the review date and the monitoring records, and a sample of those records is only as good as the inventory behind it. Start by building one inventory that covers every tool, its owner, the systems it touches and its approval status, then set a review frequency that your own policy defines and keep the dated review records. Asset inventory tools such as GLPI's Assets module can hold tool and software records alongside hardware, and Wazuh's system inventory can show installed software on managed endpoints, although neither proves that a tool was approved. Confirm with your own environment which tools can be detected automatically and which must be recorded by hand.

Which systems, tools and teams fall under MA-3

MA-3 scope is set by the system's baseline, the tools that touch it, and the people who bring those tools in. Decide these three things before you write the tool list, because each one changes which evidence an assessor will ask for. Related controls MA-2 and PE-16 draw on the same records, so plan them together.

Moderate and high baseline systems

SP 800-53B allocates MA-3 to the moderate and high baselines only, so a low-impact system carries no MA-3 requirement. Confirm the impact level in the system security plan for each boundary, since a single shared platform may inherit the higher baseline of its most sensitive workload. Record which baseline each system uses and why, because assessors start by checking the selection. Tailoring can change the set, so document any tailoring decision in the plan.

Privacy baseline exclusion

MA-3 is not part of the privacy control baseline, so a system selected only for privacy controls does not bring MA-3 into scope on that basis alone. Many PII-heavy systems also run at moderate impact, which does bring MA-3 in. Check the impact categorization and the baseline selection, not just the data type. Note the exclusion in the plan so an assessor can see the scoping logic.

Tools that cross the authorization boundary

The control concerns diagnostic and repair tools that sit outside the system's authorization boundary, such as a laptop with a vendor diagnostic suite plugged into a server. Tools that run entirely inside the boundary are still listed, but the boundary question determines how much control the organization must document. Walk the boundary diagram with the maintenance team and mark every point where a tool enters or leaves.

Tools brought in by staff

Engineers often carry personal or ad hoc utilities such as packet analyzers, disk imaging tools, firmware flashers and remote support clients. Each one is a maintenance tool once it touches a system, so it needs approval before use. Inventory what staff actually run by asking for tool history from jump hosts, admin workstations and ticket notes. Unapproved tools found in this review are a finding, not a paperwork gap.

Tools brought in by vendors

Vendor field engineers and support contractors frequently arrive with their own diagnostic laptops and licensed tools. The contract and the on-site procedure must say which tools may be used, how media are checked before connection, and who approves any change to the list. Ask vendors for their tool list before the work order, and verify it on arrival where your procedures allow. Vendor-supplied firmware or updater tools belong on the list too.

Network operations and field teams

Network operations staff and field engineers use tools that reach devices remotely, such as management consoles, configuration backup utilities and serial or console adapters. These overlap with MA-4 for remote sessions and with MA-2 for on-site work. Assign each team a written list of approved tools, and confirm that the list covers both local and remote use. Field work at remote sites needs the same list as headquarters work.

How an assessor tests MA-3 maintenance tools

This table breaks the SP 800-53A assessment procedure for MA-3 into its examine, interview and test methods, the objects each method uses and the evidence an assessor will ask for. Read each row as a request the assessor will make, and prepare that record before fieldwork starts.

Assessment method	Assessment object	Evidence requested	Common findings
Examine: policy	Maintenance policy and procedures that address system maintenance tools	Approved policy and procedure text showing how tools are approved, controlled, monitored and reviewed, with version and approval dates	Procedure covers maintenance generally but never mentions diagnostic or repair tools, or no review frequency is set
Examine: tool records	System maintenance tools and their associated documentation	Approved tool list with tool name, version, owner, system it applies to, approval date and approver	Tools in use on the system do not appear on the approved list, or entries lack versions and owners
Interview	Organizational personnel with system maintenance responsibilities	Walkthrough of how a technician requests a tool, who approves it and how its use is logged; the assessor compares answers across staff	Administrators describe an informal process that differs from the written procedure
Test: approval process	Organizational processes for approving maintenance tools	Sample of tool approval requests with decisions, reasons and dates, plus evidence that tools were checked before use	Tools were added to the environment without a documented approval step
Test: control process	Organizational processes for controlling maintenance tools	Records showing where tools are stored, who may use them, and how media or tools brought onto the system are checked	Tools are shared on removable media or personal laptops with no check or sign-out record
Test: monitoring process	Organizational processes for monitoring maintenance tools	Usage logs, session records or alerts showing tool use was observed and reviewed against the approved list	Logs exist but nobody reviews them, or tool activity cannot be tied to a named person
Test: periodic review	Organizational processes for reviewing previously approved tools at a defined frequency	Dated review minutes, the revised approved list and records of tools removed or re-approved	Review is scheduled in policy but no review has been recorded, or removed tools remain approved

How to implement MA-3 in five steps

This sequence turns MA-3 from a policy statement into a working control: every diagnostic and repair tool is known, approved or retired on a recorded decision, used only through controlled channels, watched in operation, and reviewed on a set schedule.

Define approval criteria and a named owner
Before any tool is approved, the organization sets the criteria a tool must meet, such as its purpose, the systems it may touch, who may operate it, whether it stores or transmits system data, and whether it has been sanitized or verified before use. A named owner, usually the system owner or the team responsible for system maintenance, holds the decision and the review date. Done means a written criteria document and an owner assignment that the maintenance policy references. Confirm with your own assessor which criteria they expect to see, since the discussion in the control focuses on tools outside the system authorization boundary.
Build the initial inventory of tools in use
Staff, vendors and field technicians often use diagnostic and repair tools that nobody has recorded, including laptop utilities, firmware update packages, protocol analyzers and vendor service software. Collect them through interviews with maintenance staff, a review of maintenance tickets and vendor support records, and a scan of the systems where tools are installed. Record each tool with its version, the systems it touches, its source and the person who uses it. Done means an inventory that a second person has reviewed for gaps. Self-hosted asset tools such as GLPI can hold this inventory, and endpoint tools such as Wazuh Syscollector can help confirm which software is installed on managed endpoints.
Approve or retire each tool with a recorded decision
Each inventoried tool gets a decision against the criteria from step one: approved for a stated scope, approved with conditions, or retired. Record the reasoning, the approver, the date and any conditions, such as restricted systems, required sanitization or a prohibition on connecting to production networks. The output is the approved tool list, which should be the only list maintenance staff are permitted to use. Done means every tool on the inventory has a decision and every retired tool has a removal or blocking action assigned.
Control tool use through tickets and access rules
Approved tools are used only in the context of an authorized maintenance activity. Link each use to a maintenance ticket or work order that names the tool, the system, the operator and the planned window. Restrict who can run each tool through account or local permissions, and keep removable media and vendor laptops that carry tools under the same rules. Helpdesk systems such as Zammad can hold these tickets and approvals so the request, approval and closure stay in one record. Done means a sample of recent maintenance work shows an approved tool, a ticket and an authorized operator for each use.
Monitor tool use and record exceptions
Monitoring confirms that tools are used as approved. Review logs from managed systems for execution of maintenance utilities, changes to installed software and access by maintenance accounts, and compare what you see against the tickets and approved list. Unapproved tools, use outside a ticket and use on systems not named in the approval are exceptions that need a recorded investigation and a decision. Done means monitoring results are reviewed on a schedule the organization sets, and every exception has a documented outcome.
Set the periodic review date and record the outcome
MA-3 requires previously approved tools to be reviewed at a defined frequency. Set that frequency in the maintenance policy, schedule the review, and record it. A review re-checks each approved tool against the criteria, confirms its version and source are current, removes tools no longer needed, and reconsiders conditions after system or vendor changes. The output is review minutes or a signed review record that lists tools kept, changed or retired, with the next review date. Done means the review record exists, the approved list has been updated to match it, and the next review date is on the calendar. Ask your assessor how often they expect the review to occur and whether the frequency must be stated in a specific policy document.

Evidence that passes an MA-3 review

MA-3 is tested by checking whether the organization can show which maintenance tools were approved, who controls them, how their use is monitored, and whether the approved list was reviewed on schedule. The cards below cover each artifact an assessor is likely to request, how to keep it current between assessments, and which items are usually sampled.

Maintenance policy and procedures

The policy and procedures documents set the rules for which tools may be brought onto a system, who approves them, and how they are removed. Assessors examine these documents first because every other artifact should trace back to them. Check that the procedures name the tool approval process, the owner of the approved list, and the review frequency the organization has defined. Confirm the document version, approval date and owner are visible, and that a review cycle is recorded so the document does not go stale between assessments.

Approved maintenance tool list

The approved list is the core artifact for MA-3. Each entry should record the tool name, version or firmware level, vendor or source, the systems it may be used on, the named owner, and the date it was approved. A list that omits versions makes it impossible to show that a tool used during maintenance was the one approved. Keep the list in a controlled location with change history, and reconcile it against the software and asset inventory so tools found on systems but missing from the list are flagged.

Approval records with justification

For each tool, keep a record showing who requested it, the maintenance need it serves, the risk review performed, and the decision of the approving authority. Assessors sample these records to confirm that approval happened before use, not after. A useful record also states the conditions attached to approval, such as restricted systems, required sanitization of media, or removal after the task. Where a tool was rejected, retain the rejection so the record shows the control operated in both directions.

Tool-use logs and tickets

Each time an approved tool is used on a system, there should be a matching maintenance ticket or log entry that names the tool, the system, the operator, the start and end times, and the work performed. Assessors often pick a sample of systems and ask for the tool records behind recent maintenance. Confirm that tickets are linked to change records and that the ticketing system is the place where work is requested, so gaps between a ticket and an actual tool session are easy to spot.

Monitoring records

MA-3 asks the organization to monitor tool use, not only approve it. Monitoring evidence can include inventory reports showing which tools are installed on managed endpoints, alerts when an unapproved executable appears, and reviews of those alerts. Open-source inventory tools such as Wazuh can collect software and process data from endpoints, which helps show whether a diagnostic utility is present where it should not be. Confirm with your own environment which tools can detect removable or portable diagnostic devices, since endpoint inventory does not always cover them.

Periodic review records

The organization must review previously approved tools at a defined frequency, and assessors check that the review happened and was acted on. Keep dated review minutes or sign-offs that show each tool was confirmed, retired, or re-approved, along with any changes to version or scope. Record the review frequency the organization set in its own policy, and do not rely on a generic cycle. A review that finds a tool no longer needed should also show the removal and the date access ended.

What meeting MA-3 costs in money and effort

This table breaks the cost of meeting MA-3 into its components, showing who is paid, whether each cost is one-time or recurring, what pushes it up or down, and what to request in a quote. Read it before asking an implementation partner or auditor for pricing, since no fee or duration for MA-3 has been published by NIST. The main takeaway is that most of the recurring effort comes from keeping the approved tool list and its evidence current, not from the initial setup.

Cost component	One-time or recurring, and who is paid	What drives it up or down	What to request in a quote
Tooling and licenses	Recurring if commercial. Paid to tool vendors. Open-source tools such as GLPI and Wazuh carry no license fee, though hosting and staff time still apply.	Number of tools under approval, vendor license tiers, and whether diagnostic tools are already covered by existing platforms	Itemized license terms, renewal dates, and confirmation of which tools are open source and which require a subscription
Engineering time for inventory and approval workflow	One-time to build, then periodic updates. Paid to internal staff or an implementation partner under a fixed-scope agreement.	Number of maintenance tools in use, number of sites, and how many tools are already recorded in asset or inventory systems	Written scope listing tools to be inventoried, workflow steps, integration points with the asset register, and deliverables
Evidence upkeep	Recurring. Paid to internal compliance or security staff for keeping the tool list, approval records and monitoring logs current.	Frequency of new tools, number of vendors providing maintenance access, and how often the approved list changes	Defined review cadence for the approved tool list, named owners for each record, and the format of evidence exports
Periodic review of the approved tool list	Recurring at the frequency the organization defines in its own policy. Paid to internal reviewers or an outside assessor if one is engaged.	Length of the review cycle set in the MA-3 policy, number of reviewers, and the effort needed to re-verify each tool	Confirmation of the review interval the organization must set, and whether the partner will prepare review packages
External review or testing	Occasional. Paid to a security testing provider if tools that connect to systems are tested for integrity or unsafe functions.	Number of tools that touch production systems, whether tools are tested on arrival, and the scope of testing	Clear scope of what is tested, test methods, and reporting format for findings tied to approved tools
Auditor sampling	Recurring at each assessment cycle. Paid to the independent assessor, not to the organization or its partner.	Number of tools in the inventory, number of maintenance events sampled, and the completeness of approval records	Assessor's stated sample approach and evidence list before fieldwork begins, obtained directly from the assessor

Open-source tools that produce MA-3 evidence

MA-3 evidence is mostly records: which diagnostic and repair tools exist, who approved them, where they run and when they were reviewed. The three tools below cover different parts of that trail, and none of them is a complete MA-3 solution on its own. Confirm each capability against your own environment before you rely on it for assessor sampling.

GLPI Assets as the tool register

GLPI's Assets module manages computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered manually or pushed automatically by the GLPI Agent through native inventory, which is available in GLPI since version 10. Use it to hold one record per maintenance laptop, diagnostic appliance or repair utility host, with an owner and an approval reference. Confirm with the vendor whether portable tools such as USB-run diagnostic software can be recorded as software items and linked to the systems they touch.

Wazuh Syscollector for installed software

Wazuh's Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint. It stores the results in the Wazuh indexer, where the dashboard shows inventory views and reports. This lets you check whether an approved diagnostic or repair tool is actually present on a system, and whether an unapproved one has appeared. Confirm that the software inventory identifies specific maintenance utilities, since generic package names may need a tool-by-tool allowlist to match.

Zammad tickets for approvals and tool use

Zammad is a web-based helpdesk that brings email, chat, telephone and social media into one ticket system. For MA-3, it can hold the approval request for each new maintenance tool, the review decision, and tickets opened each time a tool is used on a system. Keeping these in one queue gives assessors a dated, attributable trail. Confirm that your configuration can attach approval decisions to the tool record and restrict who may close approval tickets.

Licensing and deployment checks

GLPI is licensed under GPL-3.0-or-later, Wazuh's Syscollector is part of the GPL-2.0-only Wazuh project, and Zammad is licensed under AGPL-3.0-only. Each license sets obligations if you modify and distribute the software, and the AGPL adds network-use obligations for Zammad. Have counsel confirm how these terms apply to your deployment. Also confirm that none of the three tools records maintenance tools specifically, meaning tool name, version, approver and review date, before you treat it as the MA-3 register.

Gaps the tools will not close

None of these tools decides whether a tool is approved, and none of them runs the periodic review of the approved list. Those are organizational processes that the assessor will test through interviews and examined procedures. Inventory data also cannot show a tool that was brought in and removed between scans, so define how often scans run and how off-cycle tool use is reported. Document these gaps in the security plan so the assessment does not treat the tools as the control.

Who owns MA-3, who helps and where the auditor stops

Your organization owns MA-3. Only your staff can decide which diagnostic and repair tools are allowed on your systems, who may use them, and under what conditions. Those decisions carry the accountability that an assessor will test, so they cannot be delegated to a vendor or consultant. Your team also sets the review cycle for the approved list and records what changed and why.

Approved tool list: Name an owner for the list, define what qualifies as a maintenance tool, and record each approval with the tool, its version, the systems it may touch and the approver.
Approval decisions: Assess each tool for security impact before approval, including whether it runs outside the system authorization boundary and whether it carries its own updates or licensing risk.
Control and monitoring rules: Decide how tool use is requested, logged and reviewed, and who may remove a tool from the list.
Periodic review: Set a defined frequency for re-reviewing approved tools, and retain the minutes or tickets that show the review happened.
Procurement input: Confirm with your contracts or procurement team that vendor support terms cover the tools you approve.

Before any assessment, confirm that you can name the person who signed each approval and show the review record for the last cycle.

Where MA-3 programs usually fall short

Most MA-3 findings come from the gap between a tool list that exists on paper and the tools that actually touch systems. The cards below cover the gaps assessors most often test against, from review frequency and vendor tools to the link between the approved list and the security plan.

No defined review frequency

MA-3 requires the organization to review previously approved maintenance tools at a defined frequency, and the frequency has to be written down. A tool list that was approved once and never revisited fails that expectation even when every tool on it is legitimate. Fix this by setting the review interval in the MA policy or procedures, assigning an owner, and keeping dated review records. Check that the interval appears in the same document the assessor examines for MA-3.

Vendor tools that never reach the list

Vendors often bring diagnostic laptops, firmware update utilities and remote support agents onto a system during service visits, and none of them appear on the approved list. The NIST discussion focuses on diagnostic and repair tools outside the system authorization boundary, so these are exactly the tools an assessor asks about. Fix this by making tool approval a condition of the vendor support contract, and by requiring vendors to name every tool before they connect.

Approvals recorded only in chat

When a maintenance engineer asks for a tool in a chat thread and someone replies with a thumbs-up, the approval exists but cannot be examined, sampled or traced. Assessors need records that show who approved which tool, for which system, on what date and under which conditions. Fix this by routing requests through a ticket or change record in a helpdesk or change system, with the approver, scope and expiry fields filled in before any use.

No link to the security plan

An approved tool list that sits apart from the system security and privacy plan leaves the plan describing maintenance in general terms while the real tools go unnamed. Assessors compare the two documents, and a gap between them is a finding even when the tools are controlled. Fix this by referencing the approved tool list from the plan, updating the plan whenever the list changes, and recording the version of the list the plan was last reviewed against.

Inventories never reconciled with actual use

A tool inventory written at approval time drifts from reality as laptops are reimaged, agents are installed and utilities are copied between systems. The inventory then describes what was intended, not what runs on the systems. Fix this by comparing the approved list against software inventory data collected from the systems, and investigating anything that appears without an approval record. Open-source inventory tools such as Wazuh's Syscollector, which gathers installed software from each endpoint, can supply that comparison data, though you should confirm coverage for maintenance laptops and out-of-band devices in your own environment.

Questions buyers ask about MA-3 cost, effort and help

Does MA-3 apply to a low baseline system?

No. MA-3 Maintenance tools is allocated to the moderate and high baselines in SP 800-53B only, so a system categorized as low does not need it in its baseline. The privacy baseline does not include it either. If your system is low impact, confirm the categorization in your system security plan, because a tailored or overlay-driven program can still choose to adopt the control. Assessors will check the baseline your authorization actually uses, so the first step is to confirm which baseline applies and record that decision.

How much effort does a first maintenance tool inventory take, and what drives it?

The effort depends mostly on how many systems, sites and maintenance vendors are in scope and how much of the tooling is already written down. Work usually includes listing diagnostic and repair tools used on systems outside the authorization boundary, recording each tool's owner, version, purpose and approval status, and collecting the maintenance records that show where those tools were used. Organizations with centralized asset records and a single maintenance vendor generally finish faster than those with tools scattered across teams. No duration is set by NIST, so ask any provider for a fixed-scope estimate built from your own inventory of systems and tools.

Can open-source tools produce the evidence for MA-3?

Open-source tools can produce part of the evidence, mainly the inventory and monitoring records. GLPI's Assets module can hold computers, network equipment, software and peripherals, entered manually or pushed by the GLPI Agent. Wazuh's Syscollector collects hardware, installed software, services and users from endpoints, which helps show what is installed on systems where maintenance tools may run. Zammad can hold tickets that record approval requests and decisions. None of these tools decides whether a tool is approved. The approval policy, the review record and the monitoring procedure still have to be written and signed by the organization. Confirm each tool's capabilities against its own documentation before relying on it.

What does the team need to supply for MA-3?

The organization owns the control, so its own staff must supply the decisions and the records. Expect to provide a named owner for maintenance tools, the list of systems and sites in scope, the maintenance policy and procedures, records of past maintenance sessions, and the people who approve tools. Assessors will interview personnel with maintenance responsibilities, so those people need to be available. A partner can help structure the inventory and configure the tooling, but the approvals and the signed review must come from inside the organization.

Can a partner prepare MA-3 evidence without issuing the assessment?

Yes, a partner can prepare the systems, records and documentation that an assessor will examine, but it cannot issue the assessment result. DeployOpen plans and implements self-hosted platforms in the client's own environment and prepares controls and evidence for compliance assessments. Only an independent assessor or certification body issues assessment reports or certifications. In practice, the partner's scope might cover the tool inventory, the monitoring configuration and the evidence pack, while the organization keeps ownership of the policy and approvals. Ask any provider to put that split of roles in the written scope before work starts.

How often must the approved maintenance tool list be reviewed?

MA-3 requires the organization to review previously approved maintenance tools at a defined frequency, so the answer is the frequency you set and document. NIST does not fix a single interval in the control, so choose one that fits your risk and change rate, write it into the maintenance procedures, and keep dated records of each review. Reviews should also be triggered by significant changes, such as a new vendor, a new tool version or a new system type. Assessors will check that the stated frequency was followed, so an interval you cannot meet is worse than a realistic one you keep.

What does a quote for MA-3 help with usually include?

A useful quote separates one-time work from recurring work. One-time items include scoping, building the tool inventory, configuring the inventory and monitoring tools, and assembling the first evidence pack. Recurring items include periodic tool reviews, updating records after maintenance, and keeping the tooling running. Ask for the systems and sites covered, the tools in the inventory, the evidence formats to be delivered, and what is excluded, such as the independent assessment itself. DeployOpen works on fixed-scope agreements with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list.

How DeployOpen scopes and prepares MA-3 evidence

DeployOpen works on MA-3 Maintenance tools as a self-hosted implementation partner: we set up the tool approval register, the controls around diagnostic and repair tools, and the records an assessor will ask for. The organization keeps ownership of the control and its approval decisions, and an independent assessor tests the result.

How we scope

We confirm which systems fall under the moderate or high baseline where MA-3 applies, since it is not in the low baseline.
The written scope lists the maintenance tool types, sites and teams covered, including tools brought in by vendors and contractors.
We agree in writing which MA-3 enhancements and tool review cycles are in scope before work starts, as engagements are fixed-scope.

How we build

We set up an approved maintenance tool register with tool name, version, owner, purpose and the systems each tool may touch.
We configure monitoring and logging of tool use so approved tools can be matched against actual maintenance sessions.
We prepare a review workflow that records each periodic review of the approved tool list, with owner sign-off and dated decisions.

How we hand over

You receive the tool register, approval and review procedures, and the configuration of the inventory and monitoring sources.
Deliverables include a mapping of each MA-3 determination statement to the artifact that answers it, so assessors can trace evidence quickly.
We walk your maintenance and security staff through the register and review cycle so the records keep up after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which covers changes to the approved tool list over time.
We can prepare evidence packages before an assessment, but the assessor independently tests the controls and issues its own report.
Ask us to confirm in writing what the retainer covers for tool reviews, monitoring changes and re-verification after system changes.