03.07.06: Maintenance Personnel

03.07.06: maintenance personnel requirement means you must control who performs maintenance on systems that process, store, or transmit CUI, and prevent maintenance activities from becoming an unmonitored path to data exposure or malware introduction. Operationalize it by defining authorized maintenance personnel, gating access, supervising or escorting third-party maintainers, and keeping maintenance evidence. ¹

Key takeaways:

• Treat maintenance as privileged access: pre-approve people, methods, and tools before work starts. ¹
• Third-party maintenance requires additional safeguards such as escorting, monitoring, and tight access controls. ¹
• Evidence matters: you need logs, tickets, approvals, and personnel authorization records tied to each maintenance event. ¹

Maintenance is one of the easiest places for a “shadow admin” pathway to form. The work is urgent, often performed outside normal change windows, and frequently involves elevated privileges, removable media, diagnostic utilities, or temporary remote access. For organizations that handle CUI, those conditions create predictable audit exposure: you may have a reasonable access control program, but you cannot prove that the people who touched production systems during maintenance were authorized, monitored, and constrained.

The 03.07.06: maintenance personnel requirement sits in the NIST SP 800-171 Rev. 3 maintenance family and is assessed like an operational control, not a policy statement. Assessors will look for a repeatable process that applies to employees and third-party maintainers, and they will sample real maintenance events to confirm that approvals, access gating, and supervision happened as designed. ¹

This page translates the requirement into an implementation playbook you can hand to IT operations, security engineering, and facilities or plant teams (for OT contexts). The goal is fast execution: define who can maintain what, under which conditions, and what proof you keep after the work is done.

Regulatory text

Regulatory excerpt (as provided): “NIST SP 800-171 Rev. 3 requirement 03.07.06 (Maintenance Personnel).” ¹

Operator interpretation: You must manage maintenance personnel as a controlled access population. That includes (1) identifying and authorizing who can perform maintenance, (2) controlling and monitoring their access during maintenance, and (3) applying stricter handling when maintenance is performed by third parties or in a way that could bypass normal security controls. Maintain records that show this happened for actual maintenance activity. ¹

Plain-English interpretation

If someone is going to service, repair, upgrade, diagnose, or otherwise “maintain” a system that handles CUI, they cannot be an unknown or unmanaged actor. You decide in advance who is allowed to do that work, how they will access the system, what they are allowed to do, and how you will watch and record the activity. ¹

Who it applies to

In-scope entities

• Federal contractors and subcontractors processing, storing, or transmitting CUI in nonfederal systems. ¹
• Any nonfederal organization implementing NIST SP 800-171 Rev. 3 as a contractual or program requirement for CUI handling. ¹

In-scope operational contexts

Apply this requirement wherever maintenance can touch CUI systems, including:

• Data center and endpoint repair, warranty service, and break/fix work
• Network maintenance (switches, firewalls, VPN appliances)
• Server and hypervisor maintenance (patching, firmware, component replacement)
• Cloud operations when third parties or managed service providers perform administrative maintenance on your tenant or connected tooling
• OT/ICS environments if they process or bridge CUI, particularly where field technicians service controllers, HMIs, or engineering workstations ¹

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

Step 1: Define “maintenance” and mark the system boundary

1. Publish a maintenance definition that includes break/fix, patching, firmware updates, diagnostics, configuration changes, calibration, and component replacement for CUI systems.
2. Identify the “CUI maintenance boundary”: which assets are in scope (endpoints, servers, network gear, OT assets, admin workstations, jump hosts, management planes).
3. Assign an owner for maintenance governance (often IT Ops with Security oversight) and an approver role for exceptions. ¹

Output: a scoped asset list and a maintenance procedure that clearly states what triggers the maintenance-personnel controls.

Step 2: Establish a maintenance personnel authorization model

1. Create a list of authorized maintenance roles (examples: desktop support, network engineer, system administrator, OT technician).
2. For each role, define prerequisites:
   • identity in your IAM directory (no shared accounts)
   • required training (CUI handling, secure maintenance procedures)
   • background screening or vetting requirements if you use them contractually
3. Create an approval workflow for adding/removing authorized maintainers, tied to HR joiner/mover/leaver processes for employees and contract onboarding/offboarding for third parties. ¹

Operator tip: treat “authorized maintainer” like a privileged access group. If your privileged access is controlled but your maintenance population is not, assessors will treat this as a gap.

Step 3: Gate maintenance access and make it time-bound

1. Require maintenance to start from a controlled path (ticket or change record) for any CUI system.
2. Implement access gating:
   • maintenance accounts are assigned by role and least privilege
   • elevated access is granted only for the maintenance window, then removed
3. Control remote maintenance:
   • allow only approved remote access methods
   • disable ad hoc remote tools and unmanaged inbound connections
4. Control tools and media:
   • require approved diagnostic tools
   • restrict removable media and document any approved use for maintenance. ¹

Minimum viable control (fast to implement): “No ticket, no access.” Block privileged access elevation unless a maintenance record exists and identifies the maintainer.

Step 4: Add supervision/monitoring for third-party maintenance

Third-party maintainers introduce two issues: you do not control their internal security, and their access can be broader than needed.

1. Require contractual and onboarding steps for third parties who may perform maintenance on CUI systems:
   • named individuals (not just “the vendor”) approved to perform maintenance
   • acknowledgment of your maintenance rules (no data exfiltration, no unsanctioned tools)
2. Require escorting or active monitoring for on-site maintenance in CUI environments.
3. For remote maintenance by third parties:
   • route access through a managed jump host
   • record sessions where feasible
   • restrict commands/permissions to the maintenance scope
4. Require immediate removal of third-party access after the maintenance event, not “end of contract.” ¹

Step 5: Record and retain maintenance evidence

1. Ensure each maintenance event produces a complete record:
   • requestor, approver, maintainer identity
   • asset(s) maintained
   • date/time window
   • actions taken and outcome
2. Retain technical evidence:
   • system logs showing admin actions during the window
   • remote access logs (VPN, jump host, PAM)
   • endpoint management logs for patching/updates
3. Review a sample of maintenance events on a recurring cadence to confirm the process is being followed and to catch “informal” maintenance workarounds. ¹

Required evidence and artifacts to retain

Use this as an audit-ready checklist:

Evidence	What it proves	Owner
Maintenance policy/procedure for CUI systems	You defined maintenance rules and personnel expectations	GRC / Security
Authorized maintenance personnel roster (employees + third parties)	Only approved individuals can perform maintenance	IT Ops / HR / Vendor mgmt
Maintenance tickets/change records	Work was authorized, scoped, and tracked	ITSM owner
Approvals for privileged access elevation	Access was intentionally granted	IAM / PAM owner
Remote access logs (VPN/jump host/PAM)	Who connected, when, and from where	Security / IT
Session monitoring artifacts where used	Oversight of third-party maintenance actions	Security
Offboarding records for maintainers	Access removed promptly	IT Ops / IAM
Periodic review notes	Ongoing governance and issue remediation	GRC / IT Ops

All of the above align to assessment readiness expectations under NIST SP 800-171 Rev. 3. ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me the last few maintenance events on CUI systems and the identities of the maintainers.” ¹
• “How do you prevent a third party from having persistent admin access after maintenance?” ¹
• “Which systems are in scope for this control, and how do you know?” ¹
• “What technical controls enforce the policy (PAM, jump hosts, session logs), and what happens if they fail?” ¹

Hangups that cause findings:

• Tickets exist, but they don’t name the individual maintainer (only the company).
• Remote sessions are allowed through multiple tools, so you cannot show consistent logs.
• Emergency maintenance bypasses approvals and never gets reconciled back into the system of record.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating warranty/break-fix as “outside IT controls.”
   Fix: require escorted access and a ticket even for hardware swaps on CUI assets. ¹

2. Mistake: shared “vendoradmin” accounts.
   Fix: require named accounts per individual and disable them by default, enabling only for approved windows. ¹

3. Mistake: documenting a policy but not capturing event-level evidence.
   Fix: map every maintenance event to a ticket/change record and attach logs or references to where logs are stored. ¹

4. Mistake: allowing third-party remote tools (screen-sharing, RMM) without governance.
   Fix: standardize on approved access paths (VPN + jump host/PAM) and block the rest. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement, so you should treat enforcement risk as indirect: failure here can contribute to broader findings around access control, incident introduction, and inability to demonstrate compliance during an assessment. ¹

Operational risk is straightforward:

• Maintenance accounts and sessions are a common pathway for privilege escalation if not governed.
• Third-party maintenance can create opaque access if you cannot identify individuals and review activity.
• Missing evidence turns a potentially controlled activity into an audit failure because you cannot prove the control operated. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleeding)

• Inventory where maintenance happens for CUI systems: ITSM queues, ad hoc admin work, facilities/OT work orders.
• Publish a one-page “maintenance access rule” for CUI systems: ticket required, named maintainer required, approved access path only. ¹
• Identify all third parties with any maintenance role and freeze standing access until you can validate named individuals and access methods.

Days 31–60 (standardize process and tooling)

• Stand up an authorized maintainer roster (employees and third parties) with an approval workflow.
• Align IAM/PAM groups to the roster so authorization is enforced technically, not only procedurally.
• Route third-party remote maintenance through a single controlled method you can log consistently. ¹

Days 61–90 (evidence, testing, and operational hardening)

• Start recurring sampling: pick recent maintenance events and confirm the chain of evidence (ticket → approval → access logs → closure).
• Add monitoring expectations for higher-risk maintenance (privileged sessions, remote maintenance, work touching boundary systems like VPN, identity, backups).
• Build an assessor-ready evidence package that maps 03.07.06 to your policy, control steps, and recurring evidence collection. Daydream can help you keep this mapping current and evidence-ready across teams without chasing screenshots at the last minute. ¹

Frequently Asked Questions

Does 03.07.06 apply to internal IT staff, or only to third-party technicians?

It applies to maintenance personnel generally, which includes employees and third parties performing maintenance on CUI systems. Build one process with stricter safeguards where third parties or remote access increase risk. ¹

What counts as “maintenance” for this requirement?

Treat any activity that services or changes the system’s operational state as maintenance, including diagnostics, repairs, patching, firmware updates, and configuration changes. Document your definition so teams don’t reclassify work to avoid controls. ¹

We have emergency break/fix work. Do we still need approvals?

Yes, but handle it as “expedited approval” with after-the-fact reconciliation if needed. The control expectation is that you can show who did the work, why it was necessary, and what access they used. ¹

How do we handle a third party that insists on using their remote support tool?

Make your approved access path a contractual and technical requirement for CUI systems. If you permit an exception, document it, restrict it to named individuals and time windows, and preserve logs that let you reconstruct activity. ¹

What evidence is usually missing during an assessment?

The most common gap is event-level traceability: tickets that don’t name maintainers, access logs that don’t tie to a ticket, or third-party work that happens “off-system” without a record. Make the ticket the hub and attach identities and log references. ¹

Can we satisfy this with policy only if we’re a small team?

A policy helps, but assessors typically expect proof the process ran on real maintenance events. Keep it simple: a ticketing record, named maintainer, and access logs from one approved remote method can cover a lot of ground if consistently applied. ¹

Footnotes

1. NIST SP 800-171 Rev. 3