MA-5(2): Security Clearances for Classified Systems

MA-5(2) requires you to verify that anyone who performs maintenance or diagnostics on a system that processes, stores, or transmits classified information has (1) the appropriate security clearance and (2) formal access approval for the system’s highest classification level and any relevant compartments. Operationalize it by gating maintenance work through an eligibility check, enforcing contract and scheduling controls, and retaining auditable proof for every maintenance event. ¹

Key takeaways:

• Scope every maintenance path (internal staff and third parties) that can touch the classified system, including remote support and break/fix.
• Require both clearance level and formal access approvals, including compartments; “cleared” alone is insufficient. ¹
• Build evidence at the event level: each maintenance ticket should link to the tech’s verified eligibility and approvals.

The ma-5(2): security clearances for classified systems requirement is a maintenance control, but it behaves like an access control in audits. The rule is simple: if a person is going to perform maintenance or diagnostic activities on a classified system, you must verify they hold the right clearance and formal access approval for the highest classification level on that system and for any compartments present. ¹

Where teams get stuck is not the concept, but the operations. Maintenance happens in emergencies, after hours, through OEM support channels, and via “temporary” remote sessions. Those are exactly the conditions where clearance and access-approval checks get skipped, delegated verbally, or handled outside the ticketing workflow.

This page gives you requirement-level implementation guidance you can execute without rewriting your entire security program. You’ll get: a plain-English interpretation, applicability boundaries, a step-by-step operating procedure, the artifacts auditors ask for, and the failure modes that trigger findings. If you use third parties for any diagnostics (hardware, hypervisor, storage, network, endpoint tooling), treat this requirement as both a personnel screening gate and a third-party due diligence control.

Regulatory text

Requirement (verbatim): “Verify that personnel performing maintenance and diagnostic activities on a system processing, storing, or transmitting classified information possess security clearances and formal access approvals for at least the highest classification level and for compartments of information on the system.” ¹

Operator translation (what you must do):

1. Identify all maintenance and diagnostic activities that can touch the classified system (hands-on, logical, local, remote).
2. Before any such activity occurs, verify the individual’s security clearance is high enough for the system’s highest classification level. ¹
3. Verify the individual has formal access approval for any compartments present on the system (not only the general classification level). ¹
4. Make the verification repeatable and auditable, with retained evidence tied to maintenance events.

Plain-English interpretation

This control is about preventing uncleared or improperly approved people from gaining privileged access during maintenance. Maintenance is high-risk because it often requires elevated permissions, physical access, tool attachments, diagnostics that expose logs/data, or temporary bypasses.

MA-5(2) expects you to treat “maintenance performer eligibility” as a precondition. If you cannot confidently prove “this named person had the right clearance and the right approvals at the time of the work,” you should expect a control failure.

Who it applies to (entity and operational context)

Applies to:

• Federal information systems that process, store, or transmit classified information. ²
• Contractor-operated systems handling federal classified information, including environments where maintenance is performed by a third party (field service, managed service providers, OEM support). ²

Operational contexts that are in-scope:

• Break/fix hardware replacement, on-site diagnostics, depot repair intake where media or components could be accessed.
• Remote troubleshooting sessions (screen share, remote shell, remote KVM, “call-home” support channels).
• Scheduled maintenance (patching, firmware updates, storage swaps, hypervisor work) when it involves maintenance personnel interacting with the classified system.
• Diagnostics that include log pulls, memory dumps, packet captures, or exporting system state, because those actions can expose classified content.

Out of scope (practically):

• Routine IT work on systems that do not process, store, or transmit classified information. This enhancement is explicitly about classified systems. ¹

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

Step 1: Define “maintenance and diagnostic activities” for your environment

Create a short, enforceable scope statement that lists:

• Roles allowed to perform maintenance/diagnostics (internal admins, platform engineers, cleared field techs, OEM).
• Interfaces considered “maintenance access” (console/KVM, hypervisor admin, storage controller, privileged endpoint tools, direct physical access).
• Emergency pathways (after-hours call trees, on-call rotation, break-glass accounts).

Practical tip: If a person could end up with admin/root/firmware access, treat it as MA-5(2) maintenance even if the ticket says “inspection.”

Step 2: Establish the clearance + formal access approval eligibility rule

Write a control procedure that implements the regulatory text as a gate:

• Clearance check: the individual’s clearance must meet or exceed the system’s highest classification level. ¹
• Access approval check: the individual must have formal access approval for the compartments on the system. ¹

Make the rule explicit for three cases:

1. Internal personnel: HR/security office confirms clearance and accesses/compartments; system owner confirms need-to-know alignment and authorizes maintenance role.
2. Third-party personnel: contract requires cleared staffing; your security function validates the named individuals before scheduling work.
3. Subcontractors: prohibit silent substitution; require named-person approval before access is granted.

Step 3: Put the verification into the workflow (ticketing + scheduling)

Operationalize verification by designing it as a “no evidence, no work” workflow:

Minimum workflow controls

• A required ticket field: “MA-5(2) eligibility verified (Y/N)” with approver name/role.
• A required attachment or reference ID to the clearance/access approval verification record.
• A scheduling rule: facilities escort, remote access enablement, or maintenance window approval cannot proceed unless eligibility is verified.

Why this matters: Auditors do not want a policy statement; they want to see the control running inside the process that produces maintenance work.

Step 4: Enforce access paths so only eligible people can perform maintenance

Verification is necessary but weak without technical and procedural enforcement:

• Restrict privileged maintenance access groups to cleared/approved identities.
• Disable ad-hoc remote access methods that bypass identity proofing (shared credentials, generic vendor accounts).
• Require authenticated, logged maintenance sessions, and ensure logs can tie activity to a person.

If you must allow a third party to perform maintenance, bind them to an individual identity and time-bound access that matches the ticket.

Step 5: Handle emergency maintenance without breaking MA-5(2)

Write an emergency procedure that still verifies eligibility:

• Define who can approve after-hours eligibility checks.
• Keep a pre-verified roster for on-call cleared maintainers.
• If a non-rostered person is proposed (common with OEM dispatch), require verification before dispatch is accepted.

Step 6: Monitor and re-verify on change

Re-verify eligibility when:

• A third party rotates staff.
• The system’s highest classification level changes.
• Compartments present on the system change. ¹

This is where many programs drift: approvals were correct when the contract started, then access expanded and the roster didn’t.

Required evidence and artifacts to retain

Retain artifacts that prove verification occurred and that it applied to the actual worker:

Core evidence (auditor-ready)

• MA-5(2) procedure: how you verify clearance and formal access approvals for maintenance/diagnostics. ¹
• System classification/compartment designation record (what “highest classification” and compartments mean for the system).
• Approved maintainer roster (internal and third party) with:
  • Person identity (name, unique identifier)
  • Verified clearance level (no need to store sensitive details beyond what your security office allows)
  • Verified compartments/access approvals
  • Verification date and verifier
• Maintenance tickets (sample set) showing:
  • The named technician(s)
  • The eligibility verification approval
  • The maintenance window
  • Links/attachments to the verification record
• Access control evidence that restricts maintenance access to the approved set (group membership export, access request approvals, remote access logs).

Retention practice (pragmatic): Keep evidence in the same system where maintenance work is managed (ticketing) and the same system where access is managed (IAM). Daydream is useful here as a control-to-evidence map so MA-5(2) always has a current owner, procedure, and recurring evidence checklist tied to your maintenance workflow.

Common exam/audit questions and hangups

Expect these questions:

• “Show me how you verify clearance and formal access approval before maintenance begins.” ¹
• “How do you confirm compartments are covered, not just classification level?” ¹
• “Pick three recent maintenance events. Who did the work, and where is the proof they were approved at the time?”
• “How do you prevent an OEM from dispatching a different technician than the one you approved?”
• “What happens during an emergency outage at night?”

Hangups that trigger findings:

• The roster exists, but tickets don’t reference it.
• Tickets show “Vendor onsite” without a named person.
• Remote sessions are recorded, but identity is shared (“vendoradmin”).

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating “cleared” as sufficient	MA-5(2) also requires formal access approvals and compartments. 1	Add a compartment/access-approval verification step; document it in the ticket.
Approving a company, not a person	The requirement is about “personnel” performing the activity. 1	Require named technicians in tickets and dispatch notes.
Allowing ad-hoc remote support tools	Bypasses the gate and weakens attribution	Standardize remote access, require individual accounts, log sessions.
No linkage between verification and each maintenance event	Auditors test samples; policy alone won’t satisfy	Make “eligibility verified” a required ticket control with evidence attached.
Subcontractor substitution	Common in field service networks	Contract clause + dispatch confirmation + deny onsite access if name mismatches.

Risk implications (why operators care)

MA-5(2) failures can create an immediate confidentiality risk: maintenance personnel often gain privileged access and can view system contents, configurations, or logs. For classified systems, a single improperly approved maintenance event can become a reportable incident depending on your program rules, and it can jeopardize the system’s authorization posture.

From a GRC standpoint, MA-5(2) also becomes a supply chain control. If a third party provides maintenance, you need third-party due diligence that confirms cleared staffing, substitution controls, and evidence delivery, then you need operational enforcement so the contract terms actually happen on Tuesday at 2 a.m.

A practical 30/60/90-day execution plan

First 30 days (stabilize and stop uncontrolled maintenance)

• Inventory maintenance pathways: on-site, remote, OEM, MSP, after-hours.
• Identify all people currently able to perform maintenance (privileged groups, break-glass access, field service contacts).
• Publish an interim rule: no maintenance/diagnostics on classified systems without documented verification of clearance and formal access approvals, including compartments. ¹
• Update ticket templates to require named technicians and an eligibility verification checkbox plus attachment.

Next 60 days (make it repeatable and auditable)

• Build the approved maintainer roster with verifier workflow (security office + system owner).
• Add contract language or addenda for third parties: named cleared personnel, no substitution without approval, evidence delivery per ticket.
• Restrict privileged maintenance access to rostered identities; remove shared accounts used for maintenance.
• Pilot evidence collection on a small set of maintenance events and run an internal mock audit.

Next 90 days (scale and sustain)

• Automate gates where possible: roster-driven access approvals, ticket-to-access workflows, recurring attestations.
• Add continuous monitoring triggers: if a new person requests maintenance access, require verification before granting access.
• Operationalize an emergency maintenance playbook with pre-verified on-call coverage.
• In Daydream, map MA-5(2) to a control owner, written procedure, and recurring evidence artifacts so it stays audit-ready as staff and third parties change. ¹

Frequently Asked Questions

Does MA-5(2) apply to remote maintenance performed by an OEM support engineer?

Yes if the remote activity is maintenance or diagnostics on a system that processes, stores, or transmits classified information. You still must verify the individual’s clearance and formal access approvals for the highest classification level and compartments on the system. ¹

What counts as “formal access approval”?

The control requires formal approval for the relevant classification level and compartments on the system. Keep it concrete in your program: an approval record tied to the person, the system (or system category), and the compartments. ¹

If a technician has the right clearance, do we still need compartment approval?

Yes. MA-5(2) explicitly requires approvals for “compartments of information on the system,” not only the classification level. ¹

Can we satisfy MA-5(2) with a quarterly roster review alone?

A roster helps, but audits usually test at the maintenance-event level. Make each maintenance ticket show who did the work and link to the verification record that covers clearance and access approvals. ¹

How do we handle emergency break/fix without delaying restoration?

Pre-verify an on-call pool of eligible maintainers and require dispatch to use only those individuals. If a new person is proposed, run the verification step before granting access or allowing onsite entry. ¹

We outsource hardware maintenance. What should we demand from the third party?

Require named cleared personnel, documented access approvals for the system’s highest classification level and compartments, and a no-substitution rule without your approval. Then enforce it operationally through ticketing and physical/remote access gates. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5