Account Management | Automated Temporary and Emergency Account Management

AC-2(2) is a requirement about time-bounding elevated access that was created outside normal lifecycle processes. Temporary accounts (for short-term staffing, implementation work, or time-limited support) and emergency accounts (for break-glass incident response) are high-risk because they often bypass normal governance and linger after the event that justified them.

Operationalizing this control comes down to two design decisions and one engineering decision. First, you must define what qualifies as a temporary account versus an emergency account in your environment, including where those identities live (IdP, OS local accounts, SaaS native identities, database users, cloud IAM users). Second, you must set an organization-defined time period for each account type. Third, you must implement automation that reliably disables or removes the account when the timer expires, and produce auditable evidence that the automation worked.

For FedRAMP and NIST 800-53 testing, assessors commonly focus on whether your “automatic” mechanism is real (system-enforced), scoped to the boundary, and supported by artifacts. This page gives you requirement-level steps you can implement quickly and defend during assessment. ¹

Regulatory text

Requirement (AC-2(2)): “Automatically remove or disable temporary and emergency accounts after an organization-defined time period for each type of account.” ¹

What the operator must do

You must do three things, and each must be provable:

1. Define a time period for temporary accounts and a time period for emergency accounts (they can differ). The requirement explicitly allows “organization-defined,” so your job is to pick values you can defend operationally.
2. Implement automation that disables or removes those accounts after the time period expires. “Automatic” means the system enforces expiry without relying on a person to remember.
3. Show evidence that the time-boxing is applied consistently across the systems in scope (the FedRAMP authorization boundary, if applicable), including any exceptions with approvals and compensating controls. ¹

Plain-English interpretation

If you ever create an account that is meant to exist only briefly (temporary) or only for a crisis (emergency/break-glass), you must put an expiration clock on it and have your systems turn it off automatically when time is up. If you can’t show the expiration and the automated shutoff in logs and tickets, expect an assessor to treat it as a control failure.

Who it applies to (entity and operational context)

This requirement applies to:

• Cloud Service Providers operating a system within a FedRAMP authorization boundary, and the teams who manage identity and access for that boundary (IAM/IdP admins, platform engineering, security operations). ¹
• Federal Agencies where the agency is responsible for operating or overseeing identity controls for systems aligned to NIST 800-53 requirements. ¹

Operationally, it applies anywhere you can create accounts, including:

• Central identity providers (IdP) and directories
• Cloud IAM users/roles and access keys created for short-term needs
• Local admin accounts on hosts or appliances
• Application-native accounts (including “support” users)
• Privileged access management (PAM) vault identities and break-glass users

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

Step 1: Define account types and scope (write it down)

Create a short standard that answers:

• What counts as a temporary account (examples: short-term contractor, time-limited support, migration team user)?
• What counts as an emergency account (examples: break-glass admin, incident response access that bypasses SSO)?
• Where are these accounts created (systems of record and “shadow” identity stores)?
• What does “disable” mean per system (cannot authenticate; tokens revoked; keys disabled)?
• What does “remove” mean per system (deleted; removed from groups; credentials destroyed)?

Output: a one-page control standard that engineering can implement and auditors can test.

Step 2: Set organization-defined time periods by account type

Pick a maximum lifetime for each type. The requirement does not prescribe specific durations; it requires that you define them and then enforce them. ¹

A practical way to defend your choices is to document:

• The business justification (why the account must exist at all)
• The risk rationale (why shorter is better; why longer is necessary if you choose longer)
• The renewal rule (how to extend, who approves, and what evidence is required)

Create a simple decision matrix:

Account type	Creation trigger	Approval	Required expiry field	Renewal allowed	Disable vs remove default
Temporary	Planned work	Manager + system owner	Yes	Yes, with re-approval	Disable first, remove after retention period
Emergency	Declared incident / break-glass	On-call incident commander (or designee)	Yes	Only during active incident	Disable immediately post-incident, then remove

Step 3: Implement automated expiry in your IAM workflow

Your goal is one authoritative “expiry timestamp” and one enforcement mechanism per identity store.

Common implementation patterns:

• IdP / directory: require an “accountExpires” (or equivalent) attribute and a scheduled job that disables users at expiry.
• PAM: configure break-glass accounts with automatic checkout expiration and forced credential rotation after use; also disable the identity if it was enabled only for the event.
• Cloud IAM: prohibit long-lived access keys for emergency use; if keys exist for temporary needs, enforce automated deactivation and rotation via policy-as-code plus scheduled evaluation.

Minimum control expectations:

• Temporary/emergency accounts cannot be created without an expiry value.
• Expiry is enforced by automation (scheduler, workflow engine, IAM-native feature).
• Automation covers the boundary systems, not just the primary directory. ¹

Step 4: Add a detective control for “accounts past expiry”

Automation fails in real life. Add monitoring that checks daily (or at another cadence you can support) for:

• Accounts marked temporary/emergency with expiry in the past but still enabled
• Accounts missing an expiry attribute
• Accounts in the wrong OU/group (created outside workflow)
• Emergency accounts enabled outside an incident ticket window

Route findings to a ticket queue with SLA and escalation.

Step 5: Put approvals and reviews into a single, testable trail

To pass FedRAMP-style testing, you need to connect:

• Request → approval → provisioning → expiry enforcement → deactivation evidence.

Daydream (or any equivalent GRC evidence hub) becomes useful here as the place you map each temporary/emergency account record to its ticket, approval, and disablement log, and produce an assessor-ready package without re-assembling it manually every cycle.

Step 6: Define exceptions tightly

Sometimes you will need an exception (legacy system can’t auto-expire; emergency account must stay available but locked down). If you allow exceptions:

• Require documented compensating controls (extra monitoring, tighter MFA, network restrictions, reduced privileges).
• Put an explicit end date on the exception.
• Review exceptions on a recurring cadence and retain evidence of review outcomes. ¹

Required evidence and artifacts to retain

Keep evidence that proves design and operating effectiveness:

Policy/standard artifacts

• Account management standard defining temporary vs emergency, expiry requirements, renewal process
• System inventory showing identity stores in scope and how expiry is enforced per store
• Exception procedure and compensating control catalog

Operational artifacts (most tested)

• Access request tickets for each sampled account, showing:
  • requestor, justification, approver(s), date/time approved
  • account type (temporary/emergency)
  • expiry date/time
• Provisioning logs or workflow records showing the account was created with an expiry attribute
• System logs showing automated disablement/removal at expiry
• Monitoring results for “past-expiry enabled accounts” and remediation tickets
• Emergency/break-glass usage records tied to incident tickets and post-incident disablement

Assessment packaging

• Control narrative and implementation statement for AC-2(2) in your SSP and supporting procedures (FedRAMP expects structured documentation; use the current templates where applicable). ²

Common exam/audit questions and hangups

Expect questions like:

• “Show me the population of temporary and emergency accounts for the last period. How do you know it’s complete?”
• “Where is the organization-defined time period documented, and who approved it?”
• “Demonstrate that expiry is automatic. What happens if the workflow fails?”
• “How do you handle temporary access inside SaaS applications that don’t rely on your IdP?”
• “Show an emergency account that was enabled, used, and then disabled after the incident.”

Hangups that cause findings:

• Automation exists in the IdP, but local OS accounts or SaaS-native accounts are unmanaged.
• Expiry is recorded in a ticket but not technically enforced.
• Break-glass accounts exist “just in case” and remain enabled indefinitely.

Frequent implementation mistakes (and how to avoid them)

1. Relying on manual deprovisioning

   • Fix: require an enforced expiry attribute and an automated disable job per system. “Calendar reminders” won’t survive assessment. ¹

2. Not distinguishing emergency vs temporary

   • Fix: define both types and assign different controls (approval path, monitoring intensity, renewal rules). Emergency access should be traceable to an incident ticket.

3. Missing “shadow” identity stores

   • Fix: inventory every place an account can exist inside the authorization boundary and map an expiry mechanism to each.

4. Allowing renewals without re-approval

   • Fix: treat renewal as a new access decision. Require updated justification and approval, and update the expiry timestamp.

5. Inconsistent disable vs remove behavior

   • Fix: standardize what you do first (disable) and when you later remove, based on operational needs like investigation and retention. Document it so the assessor doesn’t have to guess.

Risk implications (why assessors care)

Temporary and emergency accounts are common paths to persistent unauthorized access because they are created under pressure, often with elevated privileges, and frequently outside normal joiner-mover-leaver controls. If you can’t prove automatic expiry, assessors may conclude you lack effective account lifecycle governance, which can complicate FedRAMP authorization and continuous monitoring submissions. ¹

Practical execution plan (30/60/90-day)

Use phases to move quickly without inventing time-based claims.

First 30 days (Immediate)

• Publish definitions: temporary vs emergency, required fields, approval roles.
• Identify all identity stores in scope (IdP, PAM, cloud IAM, OS local accounts, key SaaS apps).
• Implement a “no expiry, no account” rule in your request workflow for new temporary/emergency accounts.
• Start a daily report of temporary/emergency accounts and their expiry status (even if enforcement is still in progress).

Next 60 days (Near-term)

• Implement automated disable/removal for the highest-risk systems first: IdP/directory, PAM, cloud IAM.
• Add detective monitoring for accounts that exceed expiry or lack expiry metadata.
• Build the evidence chain: ticket ↔ account record ↔ disable log. Store it in Daydream (or your evidence repository) by account identifier.

Next 90 days (Operationalize)

• Expand automation to remaining systems (SaaS-native, local admin, databases).
• Run an internal control test: sample temporary and emergency accounts and verify end-to-end traceability.
• Formalize exceptions with compensating controls and a recurring review record.
• Update SSP/control narrative and align artifacts to FedRAMP templates for smoother assessor testing. ²

Frequently Asked Questions

Do we have to delete accounts, or is disabling enough?

The text allows “remove or disable,” so disabling can satisfy the requirement if it is automatic and timely. Choose a standard approach per system and document when you later remove accounts for hygiene. ¹

What counts as an “emergency account” in practice?

Treat any break-glass identity created or enabled outside normal access processes as an emergency account. Tie it to an incident record and require automatic disablement after the incident window you define. ¹

Our SaaS app has its own user store and can’t auto-expire users. What do we do?

Either integrate it with your IdP so expiry is enforced upstream, or implement a compensating automated job via the SaaS admin API to disable users at expiry. If neither is possible, document an exception with compensating controls and an end date. ¹

Can we extend a temporary account if the work runs long?

Yes, but treat extension as a renewal that requires re-approval and an updated expiry timestamp. Keep the renewal approval and the updated account record as evidence. ¹

How do assessors test “automatic” disablement?

They usually sample accounts and look for a system-enforced expiry configuration plus logs showing the disablement occurred without manual action. Be ready to demonstrate configuration, workflow rules, and the resulting audit trail. ¹

Where should this be documented for FedRAMP?

Document the control implementation in your SSP and keep procedures and evidence packages aligned to FedRAMP templates to reduce assessor back-and-forth. ²

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates