Account Management | Disable Accounts

To meet the account management | disable accounts requirement (NIST SP 800-53 Rev. 5 AC-2(3)), you must disable accounts when they expire, when they are no longer tied to a real user/individual, or when they exceed your defined inactivity threshold. Operationalize this with authoritative identity sources, automated disablement, and auditable evidence across all systems in your FedRAMP boundary. ¹

Key takeaways:

• Define clear disablement triggers: expiration, orphaned ownership, and inactivity thresholds, then enforce them consistently. ¹
• Automate disablement wherever possible and prove it with logs, reports, and exception records. ¹
• Assessors will test both design and operation: they will sample accounts and trace them to HR/contractor status, last activity, and disablement actions. ¹

AC-2(3) is a deceptively narrow enhancement that becomes operationally heavy the moment you map it to real environments. “Disable accounts” sounds like a simple IAM setting until you inventory all identity types (workforce, admins, service accounts, break-glass, API keys mapped to “accounts,” shared functional IDs, third-party support access) and all control planes (SSO, cloud consoles, databases, CI/CD, ticketing, SaaS). The requirement is straightforward: accounts must not remain enabled after they should no longer exist as usable access paths. ¹

For FedRAMP operators, this is a control you win or lose on evidence. You need a defensible definition of “inactive,” a way to determine when an account is no longer associated with an individual, and a mechanism that reliably disables the account across the authorization boundary. You also need to handle exceptions without undermining the rule.

This page gives requirement-level implementation guidance you can hand to IAM, IT ops, security engineering, and your FedRAMP documentation owner to implement quickly and defend during 3PAO testing and ongoing continuous monitoring. For FedRAMP documentation patterns and assessor expectations, align artifacts to FedRAMP templates and required SSP/control narrative conventions. ²

Regulatory text

Requirement (AC-2(3)): Disable accounts when the accounts have expired, are no longer associated with a user or individual, or have exceeded an organization-defined time period of inactivity. ¹

What the operator must do

1. Define what “expired,” “no longer associated,” and “inactive” mean in your environment, in policy and in system-enforceable rules. ¹
2. Detect those conditions from authoritative sources (HR, contractor roster, identity platform, last login/activity).
3. Disable the account promptly and consistently across all in-scope systems. ¹
4. Prove it happened with artifacts that an assessor can sample and re-perform. ¹

Plain-English interpretation

You cannot leave accounts enabled “just in case.” If a user leaves, a contract ends, an account reaches its end date, or an account stops being used for longer than your defined inactivity window, access must be shut off by disabling the account. ¹

This is broader than HR termination. It also covers:

• Orphaned accounts: accounts with no current owner (unknown, departed, vendor no longer engaged).
• Dormant accounts: accounts that exist but haven’t been used recently, beyond your threshold.
• Time-bound accounts: accounts created for a project, incident, migration, or support window that should end automatically.

Who it applies to

Entities

• Cloud Service Providers (CSPs) operating a FedRAMP-authorized system. ¹
• Federal Agencies operating or inheriting controls within the authorized boundary. ¹

Operational scope

• All identity stores and account-bearing systems in the FedRAMP authorization boundary: IdP/SSO, cloud consoles, OS-level accounts, databases, network devices, CI/CD tools, privileged access tools, and key SaaS where accounts grant access to federal data or system administration.
• All account types, including privileged, non-privileged, emergency, and service accounts (service accounts still need an owner and lifecycle).

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

Step 1: Define disablement triggers (policy + technical rules)

Create a short standard that engineering can implement without interpretation:

• Expiration trigger: accounts have an end date (employee end date; contractor end date; time-boxed admin access end date).
• Disassociation trigger: accounts must map to a current person or a documented service owner; if not, disable.
• Inactivity trigger: define your organization’s inactivity window and apply it consistently, with documented exceptions. ¹

Implementation tip: write the inactivity rule in terms of a measurable event (“no interactive login,” “no console sign-in,” “no SSO assertion,” “no VPN auth”) so you can generate evidence without manual judgment calls.

Step 2: Establish authoritative sources of truth for “is this person still valid?”

Assessors will look for a reliable joiner/mover/leaver linkage. You need:

• HR system (employees) and contractor management/roster (non-employees).
• Identity governance or IAM directory as the operational control plane.
• A clear RACI for who updates end dates and who approves exceptions.

Practical mapping:

• Person status: HR/contractor roster
• Account inventory: IdP + directories + cloud account lists
• Last activity: IdP logs, system logs, or application audit logs

Step 3: Build (or buy) an account inventory that supports sampling

Your control will fail in practice if you can’t answer: “What accounts exist today, where, and who owns them?”

Minimum inventory fields:

• Unique account identifier, system, role/privilege level
• Owner (person) or service owner (team + named approver)
• Creation date, last activity date, end date (if time-bound)
• Status (enabled/disabled) and disablement reason code

If you are using Daydream to manage compliance operations, treat this inventory as a first-class control artifact: attach exports and the control procedure to the requirement record so evidence stays tied to the control narrative and testing periods.

Step 4: Automate disablement for each trigger

A. Expired accounts

• Enforce end dates at provisioning time (required field in request workflow).
• Run a daily job (or native IAM feature) that disables accounts past end date.
• Ensure downstream systems receive the disablement (SCIM deprovisioning, directory sync, or connector actions).

B. Accounts no longer associated with a user/individual

• Detect “no owner” conditions: missing manager, missing employee ID, contractor record closed, email no longer valid, or owner not found in directory.
• Route to a queue for rapid remediation: assign owner, justify and document service account status, or disable.

C. Inactive accounts

• Define your inactivity window and the activity signals that count.
• Implement detection: scheduled reports from IdP/app logs.
• Disable automatically, or disable after a short internal notification workflow if you require business confirmation (document that workflow and enforce deadlines).

Step 5: Handle special account classes without creating loopholes

Create explicit sub-procedures:

Account type	What “associated with a user” means	Disablement trigger	Evidence expectation
Privileged admin	Named admin + ticketed approval	HR/roster separation, end date, inactivity	Admin roster, PAM/IdP logs, disablement tickets
Service account	Named service owner + system purpose	Owner missing, purpose retired, inactivity (non-interactive)	Owner register, rotation/usage logs, exception memo
Break-glass	Named custodians + sealed procedure	Post-incident disablement or re-seal	Incident record + account status change
Third-party support	Named sponsor + contract end	Contract end, inactivity, sponsor departure	Contract roster + access approvals + disablement log

Key point: AC-2(3) does not prohibit these accounts. It forces lifecycle control and disablement when triggers occur. ¹

Step 6: Document the control so a 3PAO can test it

In your SSP/control narrative, be explicit:

• The inactivity definition and signals used
• Systems covered and how disablement propagates
• Frequency of monitoring/reporting
• Exception process and approval authority

Follow FedRAMP documentation conventions and attach the artifacts you claim exist. ²

Required evidence and artifacts to retain

Keep evidence that supports both design and operating effectiveness:

Design artifacts

• Access control policy / account management standard covering disablement triggers. ¹
• Procedure/runbook: how accounts are reviewed and disabled in each major system.
• Data flow or integration notes: HR/roster → IAM/IdP → downstream provisioning.

Operational artifacts

• Periodic account inventory exports showing enabled/disabled status and last activity.
• Disablement logs or tickets showing:
  • trigger type (expired / disassociated / inactive)
  • timestamp
  • actor (automation or admin)
  • approvals where required
• Exception register: business justification, compensating controls, approver, review cadence, and closure evidence.
• Samples for assessor testing: be ready to provide account lists and trace a sample to disablement events.

Daydream fit: store evidence as structured checklists mapped to AC-2(3) and your continuous monitoring calendar so you can produce time-bounded evidence packages without rebuilding them each month.

Common exam/audit questions and hangups

Expect these lines of questioning during FedRAMP assessments and agency reviews:

1. “What is your inactivity threshold, and how did you define ‘activity’?”
   Hangup: mixing interactive logins with background token refreshes. Pick a defensible signal and document it. ¹

2. “Show me accounts that are enabled but have no owner.”
   Hangup: service accounts without named owners. Fix by requiring a service owner and a purpose.

3. “Demonstrate end-to-end disablement.”
   Hangup: disabling in IdP but not in local app accounts. Prove deprovisioning propagation or implement periodic reconciliation.

4. “How do you ensure third-party accounts are disabled when the engagement ends?”
   Hangup: no connection between procurement/contract tracking and IAM. Build a workflow trigger off the contractor roster.

5. “How do you manage exceptions?”
   Hangup: exceptions granted verbally or left open indefinitely. Use a register with periodic re-approval evidence.

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating disablement as a quarterly manual review.
  Fix: use automation for end dates and inactivity detection; reserve manual work for edge cases.

• Mistake: no enterprise account inventory across systems.
  Fix: build a minimum viable inventory and reconcile it routinely; start with IdP + cloud console + critical apps.

• Mistake: “inactive” defined but not measurable.
  Fix: define the log source, the event type, and how you calculate last activity.

• Mistake: disabling the user in HR/IAM but leaving API keys or local accounts valid.
  Fix: include non-SSO access paths in scope and run key/account sweeps tied to the same triggers.

• Mistake: service accounts treated as exempt.
  Fix: treat them as accounts that require ownership, purpose, and disablement triggers; document compensating controls where inactivity does not make sense.

Risk implications (why assessors care)

Disablement is one of the highest-signal indicators that your access control program works in real operations. If accounts linger after separation or dormancy, unauthorized access becomes easier to achieve and harder to investigate. It also creates authorization risk: weak evidence or inconsistent operation is difficult to defend in FedRAMP testing and continuous monitoring submissions. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + definitions)

• Define inactivity threshold, “activity” signals, and owner requirements for every account type. ¹
• Identify in-scope systems inside the authorization boundary and rank them by access criticality.
• Produce a first account inventory export for each top system (IdP, cloud console, email/VPN, PAM if present).
• Stand up an exception register and require documented approvals.

Days 31–60 (implement automation + reconciliation)

• Implement end-date enforcement in provisioning workflows.
• Build scheduled detection reports for:
  • accounts past end date
  • orphaned accounts
  • accounts past inactivity threshold
• Implement automated disablement where feasible; otherwise implement ticketed disablement with tight SLAs and evidence capture.
• Start reconciliation: compare IdP disabled users vs downstream app accounts and close gaps.

Days 61–90 (prove operations + make it assessor-ready)

• Run a full disablement cycle and package evidence for a sample-based test: account list → trigger → disablement proof → exception proof.
• Update SSP/control narrative language and attach artifacts per FedRAMP templates. ²
• Add continuous monitoring cadence: recurring reports, metrics for open exceptions, and periodic management review.

Frequently Asked Questions

Do we have to delete accounts, or is disabling enough for AC-2(3)?

AC-2(3) specifically requires disabling accounts under the stated conditions. You can still delete accounts under your retention policy, but the control expectation is that access is removed by disabling when triggers occur. ¹

What counts as “no longer associated with a user or individual” for service accounts?

A service account should be associated with a named service owner (person) and a documented purpose. If the owner is unknown or the purpose is no longer valid, treat it as disassociated and disable it or formally reassign ownership with approval. ¹

How should we define inactivity if different systems have different logs?

Define a system-specific “activity signal” per system (for example, SSO login for SaaS, console login for cloud, PAM checkout for privileged accounts) and document it in the procedure. Auditors care that you can measure it and enforce disablement against it. ¹

Are break-glass accounts allowed under this requirement?

Yes, but they still need lifecycle control, named custodians, and disablement triggers (for example, re-disable after use or periodic revalidation). Document the process and retain evidence of each activation and re-disable action. ¹

How do we show evidence quickly during a FedRAMP assessment?

Maintain an assessor-ready evidence pack: latest account inventories, disablement logs/tickets, and the exception register with approvals. Tie each artifact to the control narrative sections you claim in your SSP. ²

Can we keep inactive accounts enabled if MFA is enforced?

MFA reduces risk but does not satisfy AC-2(3) by itself. If an account meets your expiration, disassociation, or inactivity conditions, the requirement is to disable it or document an approved exception with compensating controls and review. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates