MA-5(3): Citizenship Requirements for Classified Systems

The ma-5(3): citizenship requirements for classified systems requirement is simple to read and easy to fail in practice: maintenance is where organizations quietly expand privileged access, bring in break-glass support, or allow “temporary” remote troubleshooting that bypasses normal onboarding. MA-5(3) targets that exact risk by forcing a hard eligibility check for maintainers on classified systems.

For a Compliance Officer, CCO, or GRC lead, the operational goal is to convert a single sentence into a repeatable gate in your identity, HR/contractor onboarding, and change/maintenance processes. That gate must work for employees and third parties, cover both scheduled maintenance and diagnostics, and remain effective during incidents when teams feel pressure to “just get the system back.”

This page gives requirement-level implementation guidance you can put into a control narrative, a procedure, and an evidence plan. It focuses on how to define scope, how to enforce the rule technically and procedurally, and what assessors typically request to validate that the control is not “policy-only.” The control text comes from NIST SP 800-53 Rev. 5 ¹.

Regulatory text

Requirement (verbatim): “Verify that personnel performing maintenance and diagnostic activities on a system processing, storing, or transmitting classified information are U.S. citizens.” ²

Operator meaning: For any classified system, you must (1) identify who can perform maintenance/diagnostics, (2) verify those individuals are U.S. citizens before they get that capability, and (3) be able to prove both the verification and the enforcement during audits/assessments ².

Plain-English interpretation

• What the control is trying to prevent: A non-U.S. citizen gaining the ability to administer, repair, troubleshoot, update, or run diagnostics on a classified system through routine operational work.
• What “verify” means in practice: You need a defined verification method, a responsible owner, and a record that ties the verification to the person’s identity and their authorization to conduct maintenance.
• What counts as “maintenance and diagnostic activities”: Any action that requires elevated privileges or trusted access to system internals. Common examples include patching, firmware updates, hardware replacement, log-level changes for troubleshooting, configuration edits, remote hands, hypervisor actions, storage operations, and running vendor diagnostics.

Who it applies to

In-scope entities

• Federal information systems implementing NIST SP 800-53 controls ³.
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually, and the system processes, stores, or transmits classified information ³.

In-scope operational contexts

• On-site maintenance: data center techs, facilities/remote hands, field service engineers.
• Remote maintenance/diagnostics: OEM support, managed service providers, cloud/hosting support, remote admin tools, out-of-band management paths.
• Emergency break-fix: incident response troubleshooting that requires privileged access.
• Subcontractors of third parties: the “vendor’s vendor” performing repair work. Treat them as third parties in scope if they touch classified systems.

Out of scope (be careful)

• Systems that do not process/store/transmit classified information are outside the stated MA-5(3) scope ². If you have mixed environments, you need clear boundary definitions so maintainers don’t accidentally cross into classified scope.

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

Step 1: Define the “classified system” boundary and maintenance paths

1. Inventory systems that process/store/transmit classified information.
2. Document all maintenance interfaces and access paths:
   • Admin consoles, bastions/jump hosts, privileged access management, remote desktop, SSH, hypervisor consoles, out-of-band management (iLO/iDRAC), support tunnels.
3. Identify roles that can perform maintenance/diagnostics (not titles, actual permissions).

Deliverable: “Classified Maintenance Access Matrix” mapping systems → maintenance functions → roles/groups → access methods.

Step 2: Set a control owner and a single source of truth for eligibility

1. Assign a control owner (often Security, IT Ops, or Facilities for on-prem).
2. Decide what system is authoritative for citizenship verification status (HRIS for employees, vendor management system for third parties, or a dedicated compliance register).
3. Define acceptable verification evidence types (document types and verification steps) aligned to your organization’s legal/HR guidance. MA-5(3) requires verification; it does not prescribe the method ².

Practical tip: Don’t store sensitive identity documents in random ticket attachments. Store “verified/not verified + verification date + verifier” in a controlled system, and keep underlying documents in an HR/secure repository with strict access.

Step 3: Build a hard access gate (technical + procedural)

Implement enforcement so the rule is true even under pressure:

Technical gates (preferred):

• Create dedicated IAM groups/roles for “Classified Maintainer.”
• Configure PAM so only that group can request privileged sessions to classified assets.
• Restrict remote support tooling so it cannot connect to classified assets unless the operator is in the “Classified Maintainer” group.

Procedural gates (minimum):

• Maintenance tickets must include the assigned maintainer(s).
• A designated approver checks citizenship verification status before approving work.
• No ticket approval, no maintenance window authorization.

Control behavior statement to aim for: “Maintenance access is granted only after citizenship verification and is removed when the role ends.”

Step 4: Extend the rule to third parties and supply chain support

1. Update third-party onboarding to require named individuals for any maintenance/diagnostics on classified systems.
2. Contractually require the third party to provide only U.S. citizens for those tasks and to notify you of staffing changes before access is needed.
3. Require your own verification step. Don’t rely exclusively on a third party’s assurance if you cannot evidence it to an assessor.

Common reality: OEMs rotate support engineers. You need a way to re-check eligibility when named personnel change.

Step 5: Operationalize for break-glass and incidents

1. Define “break-glass maintenance” procedures that still enforce the gate:
   • Pre-approved pool of verified U.S.-citizen maintainers.
   • Pre-provisioned accounts that are disabled by default and enabled only with incident approval.
2. Prohibit ad-hoc granting of admin access to unverified individuals during outages.
3. Log and review all emergency maintenance events.

Step 6: Monitor and test the control

• Run periodic access reviews for maintenance groups on classified systems.
• Sample maintenance tickets and validate:
  • Maintainer is verified.
  • Access was time-bound and logged.
  • Work was authorized.

Daydream (used appropriately) can help by mapping MA-5(3) to a control owner, documenting the procedure, and scheduling recurring evidence collection so you’re not rebuilding proof during an assessment ².

Required evidence and artifacts to retain

Maintain evidence that proves both design (the rule exists) and operation (it works):

Personnel eligibility evidence

• Citizenship verification register for maintainers (employee and third party): name, unique ID, verification status, verification date, verifier, scope (classified maintenance).
• Onboarding/offboarding records showing maintenance role assignment and removal.
• Role descriptions for “maintenance and diagnostic” functions on classified systems.

Access control evidence

• IAM/PAM configuration exports showing restricted groups/roles.
• Access request/approval logs tying a person to a privileged session.
• System access logs for maintenance interfaces (jump host logs, PAM session recordings where applicable, admin audit logs).

Process evidence

• Maintenance SOP requiring citizenship verification prior to assignment.
• Ticket samples (planned and emergency) showing:
  • named maintainer,
  • approval,
  • execution window,
  • post-implementation review/closure notes.

Common exam/audit questions and hangups

Assessors tend to test edge cases:

1. “Show me all maintainers for System X and proof they are U.S. citizens.”
2. “How do you prevent a non-verified user from getting maintenance access during an incident?”
3. “Do your third parties provide remote support? Show the technical controls that restrict their access.”
4. “What do you consider ‘maintenance and diagnostics’?” If your definition is too narrow, they will challenge it.
5. “How do you handle subcontractors?” Many programs fail here because the prime third party is covered but the subcontractor isn’t.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
“Policy says U.S. citizens only” with no enforcement	Audits test actual access paths	Implement IAM/PAM gates and ticket approvals tied to eligibility
Treating OEM support as “outside your control”	Remote diagnostics often equals privileged access	Restrict support paths; require named, verified personnel
One-time verification with no lifecycle	People change roles, accounts linger	Tie eligibility to role assignment and offboarding workflow
No evidence for emergency maintenance	Incidents are where exceptions happen	Pre-approved verified pool + break-glass logs + post-incident review
Storing sensitive documents in tickets	Creates privacy and retention risk	Store verification status in a register; keep documents in secure HR repository

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Treat this as an assessment and contract-performance risk: failure typically shows up as a control deficiency during authorization, reauthorization, or customer audits, and it can block system approval to operate for classified workloads. The operational impact is often larger than the control’s short text suggests because maintenance access is broad and hard to unwind once granted ³.

Practical execution plan (30/60/90)

You asked for speed, so this plan is built around getting to an auditable gate quickly, then hardening it.

First 30 days (Immediate stabilization)

• Identify classified systems and list maintenance access paths.
• Freeze new maintainer access to classified systems unless citizenship is verified.
• Create the “Classified Maintainer” role/group and move existing maintainers into it.
• Stand up a simple verification register (even a controlled spreadsheet) with an owner and access controls.

By 60 days (Enforcement and third-party coverage)

• Integrate verification into onboarding for employees and third parties.
• Update maintenance SOP and ticket templates to require named maintainers and verification check.
• Implement PAM or equivalent approval workflows for privileged maintenance sessions on classified assets.
• Amend third-party contracts or SOWs for classified maintenance to require U.S.-citizen staffing and prior notification of personnel changes.

By 90 days (Assurance and audit readiness)

• Run an access review of all maintenance roles on classified systems and remediate exceptions.
• Test break-glass: simulate an incident, prove only verified maintainers can gain access, and retain logs.
• Build an evidence package: control narrative, matrix, sample tickets, access logs, and the eligibility register export.

Frequently Asked Questions

Does MA-5(3) apply to help desk staff who reset passwords?

If password resets enable privileged maintenance or diagnostic access on a classified system, treat that function as in scope. If the help desk only supports non-privileged end-user access and cannot reach classified maintenance interfaces, document the boundary and keep it out of scope ².

Do we have to collect and store copies of passports or birth certificates?

MA-5(3) requires verification, not a specific document retention approach ². Many programs store a verification attestation record (status/date/verifier) and keep underlying documents in a restricted HR repository per internal policy.

How do we handle third-party remote support for classified systems?

Restrict the support path through IAM/PAM so only verified U.S.-citizen individuals can initiate or join privileged sessions. Contractually require named support personnel and require notification and re-verification when those names change.

What about dual citizens or naturalized U.S. citizens?

The control text requires U.S. citizenship, so a naturalized U.S. citizen qualifies if you can verify citizenship status ². Document your verification method and apply it consistently.

Does “maintenance and diagnostic activities” include patching and configuration changes?

Yes if those actions are part of system maintenance/diagnostics and require privileged access on a classified system. Define this explicitly in your maintenance SOP so operations teams don’t interpret it narrowly.

What evidence is most persuasive to an assessor?

A tight chain: eligibility register for maintainers, IAM/PAM controls that enforce membership, and ticket/log samples proving only verified individuals performed maintenance on the classified system ².

Footnotes

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

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

3. NIST SP 800-53 Rev. 5