03.07.04 Maintenance tools: requirements and evidence

What 03.07.04 maintenance tools asks you to prove

If a contract requires NIST SP 800-171 and the maintenance tools your staff or vendors use could reach systems that hold CUI, you must be able to show three things: that each maintenance tool is approved, controlled and monitored; that diagnostic and test media are checked for malicious code before use; and that maintenance equipment holding CUI does not leave your control unless it has been verified clean, sanitized or destroyed, or kept within the facility. The requirement, 03.07.04 Maintenance tools, is the Rev. 3 home for all three duties. The risk is practical: a diagnostic laptop, a firmware update USB stick or a vendor's service tool can carry malware into a protected system, or walk out of the building with CUI still on its disk.

The requirement is harder than it looks because it crosses several teams. Engineering owns the tool list, IT operations runs the checks, and facilities or asset management tracks equipment that goes out for repair or returns from a vendor. Rev. 3 also folded Rev. 2's 3.7.2, which covered controls on maintenance tools and personnel, into this requirement, so the Rev. 2 evidence you may already hold does not map one to one. NIST's change analysis classifies the change to 3.7.4 as significant, with more detail and foundational tasks. The assessor will test each of the five determination statements in SP 800-171A Rev. 3, which means your records must show the approval decision, the scan, and the removal decision, not just a policy document.

Which revision applies depends on the contract, not on this page. DoD contracts currently reference Revision 2, and a proposed FAR rule would point to Revision 3, so confirm the required revision and any DoD version status with your contracting officer before you build the evidence set. Ask the contracting officer which ODP values apply, since Rev. 3 requires you to define the parameters a federal agency leaves open. Once the revision is confirmed, an implementation partner can help you design the approval workflow and collect the records, but only an independent assessor can judge whether the evidence meets the requirement.

Which maintenance tools and equipment fall under 03.07.04

Under 03.07.04, the question is not whether a device is labeled a maintenance tool but whether it touches a system that processes, stores or transmits CUI, or equipment that held CUI. The cards below cover the decisions that change the work, from laptops and vendor service tools to equipment leaving the facility for repair.

Laptops and diagnostic software on CUI systems

A technician's laptop becomes a maintenance tool the moment it connects to a CUI system to diagnose, patch or configure it. Record each laptop and the diagnostic software installed on it, and confirm who approves that software and how its use is monitored. Ask whether the same laptop also browses general networks, because that mixed use affects how the organization controls it.

Vendor service tools

Vendors often ship their own diagnostic consoles, firmware updaters and remote service agents for appliances, storage arrays and industrial controllers. Each one needs an approval record, a stated purpose and a monitoring method. Confirm with the vendor which tool versions are current and whether the tool stores CUI or configuration data on its own media.

Hardware test equipment

Protocol analyzers, oscilloscopes, JTAG debuggers and bench testers can read memory or capture traffic that contains CUI. Treat them as maintenance tools when they connect to CUI systems or store captures. Check whether their storage can be cleared, whether captures are logged, and whether the device must stay inside the facility when it is not in use.

Removable diagnostic media

Bootable rescue drives, diagnostic USB sticks and vendor recovery images are scanned before use under the requirement's check for malicious code. Keep a list of approved media, record each scan, and retire media that is lost or reused across enclaves. A drive used on a CUI system and then plugged into a general system is a common gap an assessor will ask about.

Equipment sent for repair or returned to a lessor

Drives, controllers and memory modules that held CUI must not leave the controlled environment unless they are verified as holding no CUI, sanitized or destroyed. Build a checklist that covers warranty returns, lease returns and vendor depot repairs. Ask vendors whether they will sign a sanitization certificate or whether the organization must sanitize before shipping.

Third-party technicians and their own tools

Contract technicians often arrive with their own laptops, USB devices and diagnostic kits. The organization must decide in advance which of those tools may connect to CUI systems, who approves them, and how they are scanned and logged. Where the enclave boundary is clear, tools that never cross it may fall outside 03.07.04, but the organization should confirm that boundary in writing and enforce it on site.

How an assessor tests 03.07.04 under SP 800-171A

This table maps the three SP 800-171A assessment methods to the evidence an assessor requests for 03.07.04 and the findings that usually come up. Use it to check your own records before an assessment, since each row names what the assessor will ask to see and where organizations most often fall short.

Assessment method	What the assessor asks for	Common finding
Examine	Maintenance policy and procedures that cover system maintenance tools and media checks	Policy exists but does not name the tools, approval steps or sanitization triggers
Examine	Procedures for system maintenance tools and tool inspection records	Inspection records missing for tools used on systems that hold CUI
Examine	Sanitization and destruction records for maintenance equipment that left the facility	No record showing the equipment was verified as CUI-free, sanitized, destroyed or kept on site
Interview	Personnel with system maintenance responsibilities explaining how tools are approved and monitored	Staff describe an informal process that is not written down or applied consistently
Interview	Personnel responsible for media sanitization explaining how maintenance equipment is cleared	Sanitization owners unaware that maintenance equipment falls within the requirement
Test	Processes for approving, controlling and monitoring maintenance tools, run in practice	Tools brought in by vendors or technicians without an approval record
Test	Mechanisms that support approval, control or monitoring, such as tool registries or diagnostic media scans	Diagnostic media scanned only when someone requests it, not before each use

Implementing 03.07.04 in the order assessors expect

This sequence builds the inventory, approval, scanning, monitoring and exit records that an assessor will examine for 03.07.04, so each control has a documented owner and a dated artifact behind it. It moves from knowing what tools exist to proving that they are controlled when they leave the facility.

Inventory maintenance tools and equipment touching CUI
Start by listing every maintenance tool, diagnostic laptop, portable test set, firmware loader and piece of field equipment that connects to a system within the CUI boundary. Record the make, model, serial number, owner, location and the systems each item supports, and confirm the list against the system security plan and asset records. Hardware and software inventories from tools such as GLPI or Wazuh Syscollector can help you find devices, but a person must still classify which items are maintenance tools. The output is a versioned maintenance tool register that an assessor can sample against real equipment on the floor.
Define the approval workflow and named owners
Write a procedure that states who may request a maintenance tool, who approves it, who records its use and who can revoke approval. Assign a named owner for each tool category and document the approval criteria, such as vendor support status, required configuration and the systems it may touch. Have the system owner and the security function sign off on the procedure. The output is an approved procedure, a role assignment matrix and a sample of signed approval records for tools already in use.
Set up malicious code scanning for diagnostic media
Before any diagnostic or test media is used on a CUI system, check it with diagnostic and test programs for malicious code. Define the scanning tools, the media types covered (USB drives, optical discs, firmware images, vendor update packages), and who performs the scan and records the result. Test the process on known-clean and controlled samples so the team can show that the scan works. The output is a scanning standard, a scan log template and recorded scan results for each media item used during the review period.
Define monitoring of maintenance tool use
Decide how the organization will watch maintenance tools while they are in use. This may include logging which tool was connected to which system, by whom, for what purpose and for how long, and reviewing those logs against approval records. Where tools are software on managed endpoints, configure the monitoring platform to report their presence and activity. Confirm which tool events are captured and who reviews them. The output is a monitoring procedure, a maintenance session log and evidence that reviews were performed and any unapproved use was investigated.
Write the exit procedure with three disposition paths
Write a procedure for maintenance equipment that holds CUI and must leave the facility, such as a drive returned for warranty repair. Each item must follow one of three paths: verify that it holds no CUI, sanitize or destroy it, or keep it within the facility. Specify who verifies the disposition, which sanitization method applies to each media type, and how the decision is recorded. Ask your media protection team to align this procedure with the media sanitization controls. The output is a signed exit procedure and a disposition record for each item that leaves the facility.
Assemble the evidence package for assessment
Gather the register, approval procedure, scan logs, monitoring records and exit records into one package organized by the examine, interview and test objects in SP 800-171A Rev. 3. Check that each determination statement for 03.07.04 points to at least one artifact and that the people named in the interviews can explain their roles. Walk through a sample of tools end to end to confirm the records match. The output is an assessment-ready evidence binder and a gap list that the organization owns and closes before an independent assessor reviews it.

Open-source tools that produce 03.07.04 evidence

Assessors looking at 03.07.04 want to see which maintenance tools and equipment exist, who approved them, and what is running on the systems that hold CUI. The tools below can generate much of that record, but each one supports a process the organization must already have in place, and none of them decides whether a tool is approved or a device is clean.

GLPI Assets as the maintenance register

GLPI's Assets module tracks computers, monitors, software, network equipment, peripherals, printers, phones and racks, either entered by hand or pushed automatically by the GLPI Agent. Use it as the register of maintenance equipment that may hold CUI, with fields for owner, location, approval reference and disposal status. Licensed under GPL-3.0-or-later, so the register can be hosted inside your own environment. Confirm that the fields you need for approvals and sanitization records exist in your version, or plan custom fields during implementation.

Wazuh Syscollector for endpoint inventory

The Syscollector module gathers hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint, then stores them in the Wazuh indexer. Assessors can compare that inventory against the register to find maintenance tools installed on hosts that were never approved. Licensed under GPL-2.0-only. Check that agent coverage reaches every system that holds CUI, including administrator workstations used for maintenance.

osquery for scheduled host queries

osquery exposes processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables. The osqueryd daemon can run scheduled queries across a fleet, so you can check for unapproved remote access tools, unexpected kernel modules or hashes that differ from the approved maintenance tool list. Licensed under Apache-2.0 OR GPL-2.0-only. Confirm that query results are retained long enough to show monitoring occurred over the assessment period.

Velociraptor for cross-fleet artifact collection

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts across a group of systems. Hunts can also schedule collection on offline machines when they reconnect, which helps when maintenance laptops are only intermittently online. Each hunt produces a notebook for analyzing combined results, which can document checks on maintenance tools before or after a session. Licensed under AGPL-3.0-only, so review the obligations that apply if you modify and distribute it.

Limits of tool-generated evidence

These tools show what is installed and what is running, but they cannot establish that a maintenance tool was approved, that a diagnostic medium was scanned before use, or that a device was sanitized before it left the facility. Those steps need signed approvals, scan records and sanitization logs kept by people. Ask each tool vendor or your implementation partner to confirm which fields and retention settings your environment will actually produce before you describe them to an assessor.

Which evidence passes for approval, scanning and disposition

This evidence shows that the organization decided which maintenance tools may touch systems that handle CUI, controlled how they are used, and watched for use outside that approval. An assessor will start with the approved tool list and then sample tool sessions to confirm each one traces back to an approval. The approval record should identify the tool, its version, its purpose, the systems it may service and the person who approved it.

Approved tool register: A list of each maintenance tool with name, version, vendor or source, authorized systems and the approver's name and date.
Change to the register: Records showing that new tools, version changes and removals went through the same approval step.
Usage logs: Session or command records from privileged maintenance tools, retained so a reviewer can match activity to an approved tool and a ticket.
Monitoring alerts and reviews: Evidence that unapproved tools or unexpected use were detected and reviewed, with dispositions recorded.
Inventory cross-check: Output from an asset or software inventory showing that tools found on systems also appear on the register.

The security team usually owns the register and the review, while the platform team generates usage data. Keep the register current by tying each change to a change ticket, and confirm with your assessor which monitoring evidence they will accept for your environment.

What meeting 03.07.04 costs and what drives it

This table lists the cost components of meeting 03.07.04 Maintenance tools, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No price figures are supplied for this requirement, so use the table to structure a written quote and to compare how much of the work is in-house versus outsourced. The main takeaway is that open-source tooling mainly removes license spend, while engineering, approval workflow and evidence upkeep remain the larger effort.

Cost component	Who is paid	One-time or recurring	What drives it
Tooling and licenses	Software vendors or none for self-hosted open source	Recurring for commercial licenses, minimal for open source	Number of maintenance tools and whether the inventory and scanning platform is licensed or self-hosted
Engineering time for the tool register and approval workflow	Internal staff or implementation partner	One-time build, then periodic updates	Number of maintenance tools, vendors and systems in scope
Staff time for approvals and media scans	Internal maintenance and security staff	Recurring with each maintenance event	Frequency of maintenance visits, remote versus on-site work and volume of removable media
Equipment sanitization or retention decisions	Internal IT, facilities or a destruction vendor	Recurring per item leaving the facility	Number of devices that hold CUI, sanitization method and whether destruction is outsourced
Evidence upkeep	Internal compliance or security staff	Recurring	Log retention, inventory accuracy and how often the register changes
External testing or review	Independent testers or consultants	Periodic	Scope of the system security plan, whether maintenance tools are tested and how many tools are reviewed
Assessor effort	Assessing body or assessor	Per assessment cycle	Quality of evidence on hand, clarity of the register and number of findings to resolve

Who owns 03.07.04 and what an implementation partner can take on

Your organization owns the control. Someone accountable must decide which maintenance tools may be used on systems that hold CUI, approve each one, and make the call when a piece of maintenance equipment is leaving the facility. Those decisions are management decisions, and an assessor will ask who made them and when. A partner can draft the process, but it cannot approve tools on your behalf.

Tool approval: Named owners approve each maintenance tool, including remote diagnostic utilities and vendor-supplied software, before it touches a CUI system.
Register ownership: Your team owns the maintenance tool register and keeps it current as tools are added, updated or retired.
Disposition decisions: Someone with authority decides whether equipment is verified clean of CUI, sanitized, destroyed or kept within the facility.
Policy and training: Maintenance staff and media sanitization personnel must know the procedure, and you must be able to show they were trained.
Scanning follow-through: Your staff act on scan results for diagnostic media before use.

Before engaging anyone, confirm internally who holds each of these decisions and where the approvals are recorded.

Where 03.07.04 programs usually fall short

Most gaps under 03.07.04 are not missing policies. They are maintenance tools and equipment that move in and out of the environment without anyone recording it, checked or verified. Each card below names one gap, the fix that closes it and the evidence an assessor will ask to see.

Vendor laptops connecting unapproved

A vendor technician plugs a personal or unmanaged laptop into a server to run a firmware update, and nobody approved that tool. 03.07.04 expects the organization to approve, control and monitor maintenance tools, so the fix is a written list of approved tools and the vendor devices permitted to run them. Evidence is the approval record, the tool inventory and the session log showing who used which tool. Check that the list covers tools vendors bring, not only tools your own staff use.

Diagnostic media scanned inconsistently

Diagnostic and test media is scanned for malicious code on some visits and skipped on others, often when a technician is in a hurry. The requirement is to check media with diagnostic and test programs for malicious code before use, every time. The fix is a scan step built into the maintenance procedure with a named owner and a log entry per use. Evidence is the scan record tied to each media item and the procedure that makes the step mandatory.

No record of equipment leaving

A drive or controller goes out for warranty repair and no one records it, so the organization cannot show whether it held CUI when it left. 03.07.04 requires that maintenance equipment containing CUI not leave the organization unless it is verified as free of CUI, sanitized or destroyed, or kept within the facility. The fix is a checkout form that records each item, its CUI status and its disposition. Evidence is the signed checkout and return log, and the sanitization or destruction certificate where one applies.

Sanitization claims without verification

A vendor states that a device was wiped before it left, but the organization never checked. Under 03.07.04 the claim is not enough on its own, because the equipment must be verified as holding no CUI, sanitized or destroyed. The fix is to test a sample of returned or retired items, or to require the vendor's documented method and to verify it. Evidence is the verification record, the method used and the person who signed off. Ask the vendor for the method in writing before the device leaves.

Policy written but not followed

The maintenance policy names approved tools, scanning steps and removal rules, but technicians work from habit and the records do not match the written procedure. Assessors test this gap through interviews with maintenance staff and by comparing records with the procedure. The fix is a short procedure per tool or equipment type, a periodic review of records against it and corrective action when they diverge. Evidence is the procedure, the review record and the findings it produced.

How much effort and outside help does 03.07.04 need?

How long does it take to meet 03.07.04 maintenance tools?

No supplied fact gives a duration for 03.07.04 alone, so the honest answer is that the effort depends on how many maintenance tools and devices hold CUI, and how many already have an approval and inspection record. The requirement is narrow compared with the whole of SP 800-171 Rev. 3, but it touches every diagnostic laptop, remote support appliance and hardware tester that can reach a system with CUI. Ask your assessor or contracting officer which revision and assessment method applies, then size the work from a current inventory of tools rather than from a generic estimate.

What does 03.07.04 ask of my own team?

The requirement asks your team to run a small, repeatable process rather than build new technology. Expect four duties: approve each maintenance tool before use, control how tools are used, monitor that use, and scan diagnostic media for malicious code before it is run. Your team also decides how equipment leaving the facility is handled: verified free of CUI, sanitized or destroyed, or kept inside the facility. Those duties need named owners, a written procedure and records that show the process happened.

Can we meet 03.07.04 in-house without outside help?

Yes, many organizations do, provided they have staff who understand the CUI boundary, the maintenance tools in use and the assessment objects the assessor will request. In-house teams usually struggle with the inventory and the evidence trail, because tools are often shared between IT, facilities and vendors. An outside partner can help where the gap is technical, such as deploying an asset inventory or collecting tool records from endpoints, but the organization still owns the control and its decisions.

What can an implementation partner handle, and what stays with us?

An implementation partner can prepare systems and evidence for 03.07.04: deploying and configuring inventory tooling, setting up logging of maintenance activity, documenting procedures and organizing records for assessment. The organization keeps ownership of the control itself, including approving tools, deciding which equipment may leave the facility, and accepting residual risk. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own environment and prepares evidence for assessments. It does not issue audit reports, attestations or certifications. Agree the split in a written, fixed scope before work begins.

How will an assessor test 03.07.04?

Under SP 800-171A Rev. 3, assessors evaluate 03.07.04 with five determination statements using three methods: examine, interview and test. They read the maintenance policy, the procedures for system maintenance tools and tool inspection records. They interview people responsible for system maintenance and media sanitization. They test the processes for approving, controlling and monitoring tools and the mechanisms that support them. Prepare records that show each step operating, not only a policy document. Only an independent assessor or the DoD's assessment body issues the result.

Which SP 800-171 revision applies to my contract?

The revision in your contract is the one that controls, and it is not settled by this page alone. NIST withdrew Rev. 2 on 14 May 2024, but 32 CFR 170.14(c)(3) keeps CMMC Level 2 identical to Rev. 2, and DoW Class Deviation 2026-O0025, Revision 3 names Revision 2 explicitly while a 13 July 2026 DoW CIO memorandum requires baseline compliance with Rev. 2 during the suspension of CMMC Phase 2. A FAR overhaul proposed rule would move contractors to Rev. 3 with DoW-published ODP values, but it was not final as of October 2026. Confirm the revision in writing with your contracting officer. Under Rev. 2, the same tool control appears as 3.7.4, and Rev. 3 merged 3.7.2 into 03.07.04.

What drives the cost of 03.07.04 compliance?

The cost has two parts: the internal labor to write procedures and collect records, and any external help you buy. Internal effort rises with the number of tools, vendors and locations in scope. External fees depend on the written scope, how much inventory and logging must be deployed, and how many people must be interviewed or trained. No supplied fact gives a dollar figure for this requirement, so ask any partner for a quote built from a stated scope, and ask your assessor what evidence they will need before they start. Recurring costs include reviewing tool approvals and keeping inventory current.

Which open-source tools can produce 03.07.04 evidence?

Inventory and monitoring tools can produce much of the evidence that assessors request. GLPI's Assets module records computers, network equipment and other devices, entered manually or pushed by the GLPI Agent. Wazuh's Syscollector collects hardware, installed software, running services and users from each endpoint into dashboard reports. osquery runs SQL queries across a fleet to show running processes and file hashes, and Velociraptor collects forensic artifacts from groups of systems through hunts. Confirm that each tool meets your evidence needs and your own approval process before you rely on it.

How DeployOpen prepares 03.07.04 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure so that maintenance tools, their approval records and their inspection logs can be shown to an assessor. We prepare systems and evidence for 03.07.04 Maintenance tools; your organization owns the control, and an independent assessor reaches the conclusion.

How we scope

Engagements are fixed-scope, with the 03.07.04 boundary, systems and deliverables agreed in writing before work starts.
Scope lists every maintenance tool and diagnostic medium in use, including those held by vendors or contractors.
Scope identifies which equipment that holds CUI may leave the facility and how each item will be verified, sanitized or destroyed.

How we build

We configure inventory platforms such as GLPI to record maintenance tools and equipment against owners and approval status.
We deploy Wazuh or osquery to collect software and process data from endpoints where maintenance tools run, to support monitoring.
We set up Velociraptor or similar tooling to collect forensic artifacts and support scanning of diagnostic media before use.

How we hand over

You receive documentation mapping the 03.07.04 determination statements to the configured records, reports and procedures.
Handover includes runbooks for approving a new maintenance tool, scanning media, and recording removal or sanitization decisions.
Evidence packages list where each artifact is stored, who reviews it and how often, so an assessor can examine and interview against them.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover periodic review of tool inventories and inspection records as the environment changes.
Confirm with DeployOpen in writing which evidence refresh and reporting activities a retainer includes before signing.

03.07.04 Maintenance tools