AC-2(2): Automated Temporary and Emergency Account Management

AC-2(2): Automated Temporary and Emergency Account Management is a narrowly scoped control enhancement, but auditors treat it as a litmus test for whether account lifecycle controls are real or just policy. Temporary and emergency accounts are high-risk because they commonly bypass normal provisioning checks: they are created under pressure, may be shared, and often have elevated privileges. If they don’t expire automatically, they quietly become “forever accounts” that evade periodic access reviews and deprovisioning processes.

For a Compliance Officer, CCO, or GRC lead, the fastest path to compliance is to convert AC-2(2) into a small number of non-negotiables: a clear definition of account types in scope, a required expiration value, automation that enforces the expiration, and a tight evidence bundle that proves the automation ran. You do not need a complex program to meet the requirement; you need strong defaults, consistent tagging, and centralized reporting.

This page gives requirement-level implementation guidance you can hand to IAM, IT operations, and security engineering to build and prove automated expiration for temporary and emergency accounts aligned to NIST SP 800-53 Rev. 5 (NIST SP 800-53 Rev. 5 PDF).

Regulatory text

Requirement (excerpt): “Automatically [remove or disable] temporary and emergency accounts after [time period].” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do:

1. Choose the action: either automatically remove or disable temporary and emergency accounts when they reach their expiration. The safer operational default is “disable first,” with removal after retention needs are met (your choice should be consistent and documented).
2. Define the time period: establish an organizational standard for how long temporary and emergency accounts can exist before automation acts.
3. Make it automatic: manual reminders, ticket follow-ups, or “someone checks weekly” does not meet the “automatically” expectation. Automation must execute the disable/remove action without a person having to remember.
4. Prove it: retain system-generated evidence that the account was created with an expiration and that the disable/remove action occurred.

Primary control reference: AC-2(2) in NIST SP 800-53 Rev. 5 (NIST SP 800-53 Rev. 5 PDF).

Plain-English interpretation

If you ever create an account that is meant to exist only briefly (temporary) or is created to handle an urgent operational/security event (emergency), you must set it up so the system shuts it off automatically after the approved window. The organization should not rely on memory, calendars, or best intentions to clean up emergency access.

Who it applies to (entity and operational context)

Applies to: organizations implementing NIST SP 800-53 controls, including federal information systems, federal contractors, and service organizations handling federal data (NIST SP 800-53 Rev. 5 PDF).

Operationally, it applies anywhere accounts can be created, including:

• Central identity providers (IdP) and directories (workforce IAM)
• Cloud IAM (cloud provider accounts, roles, access keys, break-glass users)
• Privileged access management (PAM) platforms and “emergency access” workflows
• Local system accounts (servers, databases, network devices) where temporary admin users appear
• Third-party managed environments where your organization can request account creation (treat the third party as part of the control boundary and contract for the evidence you need)

Accounts in scope (typical):

• Contractor or short-term workforce accounts
• Time-bound admin accounts used for maintenance windows
• “Break-glass” or emergency admin accounts created during incidents
• Temporary service accounts created for migrations or integrations (if they are truly temporary)

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

1) Write a requirement control card (make ownership and run-state explicit)

Create a one-page control card your operators can run without interpretation:

• Objective: temporary and emergency accounts expire automatically.
• Owner: IAM or security engineering for technical control; GRC for oversight.
• Systems in scope: IdP, PAM, cloud IAM, local accounts, key platforms.
• Trigger events: any creation of a temporary/emergency account; any extension request.
• Execution mechanism: expiry attribute + automated job/workflow.
• Exceptions: what qualifies, who approves, max extension pattern, and how it’s logged.

This maps directly to “operators can show who owns this requirement, how often it runs, or which evidence proves it is operating,” a common audit gap (NIST SP 800-53 Rev. 5 PDF).

2) Define “temporary” and “emergency” in operational terms

Make definitions enforceable in tooling:

• Temporary account: created for a defined business purpose with an expected end date known at creation time.
• Emergency account: created under incident/urgent change conditions, often privileged, and may be outside standard provisioning.

Add a rule: “If it’s privileged and not a named individual’s standard admin account, treat it as emergency unless proven otherwise.”

3) Standardize the creation workflow with mandatory metadata

For every temporary/emergency account, require:

• Account owner (named person or team)
• Requestor and approver
• Justification (free text is fine; require it)
• Expiration timestamp (not “end of week” in a ticket)
• Account type tag (temporary vs emergency)
• Privilege level tag (standard vs privileged)

This is where many programs fail: they build a cleanup script but still allow accounts to be created without a machine-readable expiration field.

4) Enforce automatic disable/remove at expiration (the core of AC-2(2))

Implement automation appropriate to your environment:

• IdP/directory approach: use native account expiration fields and an automated enforcement job (or identity governance workflow) that disables accounts on expiry.
• PAM approach: prefer time-bound privileged elevation (JIT) or credential checkout that expires automatically; if a discrete account exists, enforce disable at expiry.
• Cloud approach: manage emergency users/roles with infrastructure-as-code and attach expiration through automation (for example, scheduled function/job that disables the user, revokes keys, and logs actions).

Design choice: disable vs remove

• Disable is usually safer for investigations and audit trails because the identity record persists.
• Remove reduces clutter but can weaken traceability if logs and identity history are not preserved.
  Pick one primary action for consistency, document it, and show how you preserve traceability either way.

5) Build extension handling that does not break automation

Extensions are unavoidable. Control them:

• Require a new approval (even if lightweight) and a new expiration timestamp.
• Log the extension as a separate event (ticket, workflow record).
• Keep the automation authoritative: extensions update the expiration field; they do not bypass the job.

6) Establish monitoring and control health checks

You need two monitoring views:

• Preventive: creation events missing required fields (owner/expiry/type).
• Detective: accounts past expiration that are still active (should be near-zero; treat any occurrence as an incident and root-cause it).

Track remediation to closure with due dates and validation evidence (NIST SP 800-53 Rev. 5 PDF).

Required evidence and artifacts to retain

Build a minimum evidence bundle per operating period that an auditor can replay:

• Control card/runbook (owner, systems, triggers, exceptions)
• Policy/procedure excerpt defining temporary/emergency accounts and requiring expiration
• Configuration evidence (screenshots/exports) showing:
  • expiry attribute exists and is required in workflow, and/or
  • automation rules/jobs are enabled
• Sample set of account records showing:
  • tag/type, owner, expiration set at creation
• System logs/audit events proving disable/remove occurred automatically
• Exception/extension records with approvals and updated expiry
• Control health check results (reports of expired-but-active accounts, and remediation tickets)

Retention location matters. Store evidence in a controlled repository (GRC tool, ticketing system, or evidence vault) with consistent naming.

Common exam/audit questions and hangups

Auditors tend to probe the same failure modes:

• “Show me how you define temporary vs emergency accounts in your environment.”
• “How do you ensure an expiration is set every time?”
• “Where is the automation? Walk me through what happens at the expiration time.”
• “Provide a population of temporary/emergency accounts and show they were disabled/removed on schedule.”
• “How do you handle extensions, and who approves them?”
• “What about cloud access keys, local accounts, and third-party managed systems?”

Hangup to expect: teams prove the process with tickets but cannot produce system evidence that the disable/remove occurred automatically.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Relying on a weekly manual review to disable expired accounts	“Automatically” is not satisfied	Implement scheduled enforcement (job/workflow) and keep logs
Allowing emergency accounts without expiry “because it’s urgent”	These become the riskiest long-lived accounts	Make expiry mandatory; if urgent, default to a short expiration and extend if needed
No authoritative inventory of temp/emergency accounts	You can’t prove completeness	Require tagging and build a report by tag/type
Disabling accounts but leaving active credentials (keys/tokens) elsewhere	Access persists through alternate paths	Ensure automation revokes credentials, sessions, and keys where applicable
Exceptions handled in side channels (chat/email)	No audit trail	Route extensions/exceptions through a ticket or access workflow with approvals

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AC-2(2). Practically, AC-2(2) reduces the likelihood that high-privilege or out-of-band accounts remain active and get abused without detection. The risk is not abstract: expired emergency access is a common root cause in incident postmortems, and auditors often escalate findings when privileged access lacks reliable expiration and evidence (NIST SP 800-53 Rev. 5 PDF).

Practical execution plan (30/60/90)

Use phases so engineering can deliver quickly without waiting on a perfect future-state.

First 30 days (Immediate)

• Name a control owner and publish the control card (runbook) (NIST SP 800-53 Rev. 5 PDF).
• Identify systems where temporary/emergency accounts exist (IdP, PAM, cloud IAM, core platforms).
• Decide: disable vs remove, and define standard “time period” defaults per account type (document the rule even if you refine it later).
• Implement mandatory tagging + expiration in the request workflow for at least the primary identity system.
• Define the minimum evidence bundle and where it will be stored (NIST SP 800-53 Rev. 5 PDF).

Next 60 days (Near-term)

• Implement automated disable/remove in the primary identity system and PAM.
• Add extension workflow with approvals and logging.
• Produce the first recurring control health check report: expired-but-active accounts, missing metadata, and remediation tickets (NIST SP 800-53 Rev. 5 PDF).
• Expand scope to cloud IAM and critical local/system accounts.

Next 90 days (Operationalize)

• Cover remaining platforms and third-party managed environments through technical integration or contractual requirements for expiration and evidence.
• Automate evidence capture where possible (scheduled exports, log snapshots).
• Run a tabletop: simulate an incident that requires emergency access, then verify the account expires and evidence is complete.
• Establish steady-state governance: periodic health check review, exception review, and documented remediation closure (NIST SP 800-53 Rev. 5 PDF).

Where Daydream fits naturally: If your main failure mode is evidence chaos (screenshots, scattered tickets, inconsistent exports), Daydream can standardize the control card, define the evidence bundle, and run control health checks with tracked remediation so you can prove AC-2(2) is operating, not just designed.

Frequently Asked Questions

Do “break-glass” accounts count as emergency accounts under AC-2(2)?

If they are created for urgent use outside normal provisioning, treat them as emergency accounts and enforce expiration. If you keep a standing break-glass account, you still need a compensating pattern (for example, time-bound enablement) that results in automatic disablement after the approved window (NIST SP 800-53 Rev. 5 PDF).

Is disabling enough, or do we have to delete temporary and emergency accounts?

The text allows “remove or disable,” so either can meet the requirement if it is automatic and consistent (NIST SP 800-53 Rev. 5 OSCAL JSON). Many teams disable first to preserve identity history, then remove later under a separate retention rule.

How do we prove the action was automatic instead of manual?

Keep system-generated logs showing the disable/remove event triggered by a job, workflow engine, or policy rule. Pair that with configuration evidence that the job is enabled and scoped to the tagged temporary/emergency account population.

What if a third party manages the system where the emergency account exists?

Put the requirement in the contract/SOW: emergency accounts must have expirations and be automatically disabled/removed after the agreed time period, and the third party must provide logs or reports as evidence. Treat their evidence as part of your audit package.

How should we handle extensions for ongoing incidents or maintenance?

Require an extension approval and update the expiration timestamp in the system of record. Avoid “do not expire” flags; they create long-lived exceptions that are hard to defend in audits.

We use JIT privileged access instead of creating emergency accounts. Does AC-2(2) still apply?

JIT can satisfy the intent if it results in access being time-bound and automatically revoked, with logs that show the time window and revocation. Document how JIT maps to “temporary/emergency accounts” in your environment and keep the evidence (NIST SP 800-53 Rev. 5 PDF).