AC-2(8): Dynamic Account Management

AC-2(8) requires you to create, activate, manage, and deactivate accounts dynamically, meaning account state changes must be automated or near-real-time based on authoritative triggers (hire, role change, termination, contract end, device posture). Operationalize it by wiring HR/identity sources to your IAM, enforcing just-in-time access where possible, and keeping auditable logs of every account lifecycle event. ¹

Key takeaways:

• Dynamic account management means event-driven account lifecycle, not manual ticket queues for routine changes. ¹
• You need defined triggers, automation paths, exception handling, and proof that changes executed as designed. ²
• Evidence is mostly system records: identity source feeds, provisioning logs, deprovisioning results, and periodic health checks. ²

The ac-2(8): dynamic account management requirement is one of those controls that looks small on paper and becomes operationally decisive in audits and incidents. If you cannot reliably show that accounts are created and removed based on real events (not human memory), auditors will treat your access control program as fragile, even if MFA and password policies are strong.

“Dynamic” is about time and authority. Time: how quickly a required account change happens after a trigger event. Authority: whether changes are driven from an authoritative source of truth (HR system, identity governance tool, contractor roster, device management system) rather than ad hoc administrator action. NIST does not mandate a specific tool. It expects you to design a repeatable mechanism and prove it operates.

This page gives you requirement-level implementation guidance you can put into a runbook. It focuses on triggers, workflows, exceptions, and evidence you can hand to an assessor without scrambling.

Regulatory text

Control statement (excerpt): “Create, activate, manage, and deactivate [organization-defined parameter] dynamically.” ¹

Operator interpretation (what NIST expects you to do)

You must be able to change account states (creation, activation, modification, deactivation) in response to events without relying on manual, case-by-case administrator work as the normal path. ¹

Practically, that means:

• Define which account populations are in scope (workforce, privileged admins, service accounts, contractors/third parties, break-glass accounts) and what “dynamic” means for each population. ²
• Define the trigger events that require an account change (joiner/mover/leaver, contract end, access approval expiration, device noncompliance, failed re-verification, role change). ²
• Implement event-driven workflows in your IAM/IGA/SSO directory and connected systems so the change happens automatically, or via tightly controlled exception handling. ²
• Retain evidence that the workflow executed and that exceptions are governed. ²

Plain-English interpretation of the requirement

Dynamic account management means: “When something changes about the person/system that should change their access, our systems change the account automatically, and we can prove it.” ²

A useful way to frame it for operators is to split it into four verbs:

1. Create: Accounts are provisioned from authoritative identity records, with standard attributes and baseline groups.
2. Activate: Access becomes usable only when prerequisites are met (e.g., manager approval completed, training complete, MFA enrollment, device compliance).
3. Manage: Changes to role, department, location, clearance, or project membership update group memberships and entitlements through rules.
4. Deactivate: Terminations, contract end dates, and access expirations disable access promptly across connected systems, not just the central directory.

Who it applies to (entity and operational context)

This applies to organizations implementing NIST SP 800-53 Rev. 5 controls, including federal information systems, service organizations supporting those systems, and contractors handling federal data. ²

Operationally, you should assume it applies wherever you have:

• Central identity (IdP/SSO, directory services)
• Cloud apps and infrastructure accounts tied to human identity
• Privileged access tooling (PAM) and admin roles
• Third-party access (contractors, consultants, support providers) that must be time-bounded and offboarded reliably

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

1) Write the “control card” (owner + triggers + runbook)

Create a one-page control card that an auditor can read in minutes:

• Objective: dynamic account lifecycle management across defined systems
• Control owner: IAM lead (primary), HRIS owner (upstream), Security (oversight)
• In-scope systems: IdP, directory, email, endpoint management, key SaaS apps, PAM, VPN
• Trigger events: joiner/mover/leaver, contractor end date, privilege elevation approval, access expiry, device noncompliance
• Execution path: automated provisioning/deprovisioning flows, exception path, monitoring
• Exception rules: when manual steps are allowed and how they’re approved and reviewed

This directly addresses a common audit failure mode: nobody can articulate how the requirement “runs.” ²

2) Identify authoritative sources and define the “truth hierarchy”

Document your sources of truth and what attributes you trust from each:

• HRIS: employment status, start/end dates, manager, department
• Contractor/third-party roster system: sponsor, end date, company, access scope
• IAM/IGA: identity IDs, groups, entitlement catalog, access approvals
• Device management: device compliance state (if used as an activation condition)

Decide what happens on data conflicts. Example: HR says “terminated,” IAM must disable even if an app owner objects. Put that in policy and implement it in automation logic. ²

3) Implement event-driven lifecycle flows (joiner/mover/leaver)

Build or configure workflows that execute on events, not human reminders:

• Joiner flow: create identity, assign baseline groups, create mailbox, assign default apps, require MFA enrollment before activation where applicable.
• Mover flow: update groups/roles based on department/role changes, remove old access, enforce re-approval for sensitive entitlements.
• Leaver flow: disable central identity, revoke sessions/tokens where your platform supports it, remove from groups, disable email forwarding rules, remove from VPN/PAM, and queue downstream deprovisioning.

Key design decision: if downstream systems cannot deprovision automatically, you need a compensating control (documented manual runbook plus monitoring and evidence). ²

4) Handle privileged and service accounts explicitly

Auditors will ask whether “dynamic” applies to privileged access. Your answer should be “yes, with a defined model”:

• For admins: prefer time-bound role activation through PAM or just-in-time elevation, with automatic expiry.
• For service accounts: manage creation and rotation/deactivation through an inventory plus automated disabling when owners depart or when services retire.

If you can’t automate a class of accounts, define an exception path with stricter review and monitoring. ²

5) Define your minimum evidence bundle (make audits boring)

For each lifecycle execution cycle, standardize what you save:

• Trigger input (HR event feed record, contractor end date record, access approval)
• Workflow execution record (provisioning job ID, directory audit log, IGA transaction log)
• Output confirmation (account disabled status, group membership change, downstream app deprovision success)
• Exception approval (ticket, approver identity, reason, time bound)
• Retention location (GRC repository or evidence vault)

This is the difference between “we do this” and “we can prove this.” ²

6) Run control health checks and remediate gaps

Dynamic systems drift. Set a control health check that looks for:

• Active accounts with terminated status in HR
• Contractor accounts past end date
• Privileged group members without current approval
• Orphaned accounts in key systems not linked to a valid identity

Track findings to closure with owners and due dates; keep remediation evidence. ²

Required evidence and artifacts to retain

Keep artifacts that show design and operation:

Design evidence

• Control card/runbook (scope, triggers, automation, exceptions)
• Data flow diagram: HR/roster → IAM/IGA → downstream systems
• Access model: role/group mapping rules, entitlement catalog references
• Exception procedure: who can approve, how long, monitoring

Operating evidence

• Samples of joiner/mover/leaver events with logs showing successful provisioning/deprovisioning
• Directory/IdP audit logs for disablement, group changes, and role assignments
• PAM logs for admin elevation and expiry (if used)
• Exception tickets with approvals and closure proof
• Health check reports and remediation tickets

Common exam/audit questions and hangups

Expect these questions in a NIST-based assessment:

• “What are your authoritative sources for identity status and end dates?” ²
• “Show me a termination where access was removed across SSO and a critical downstream system.” ²
• “How do you prevent a role change from accumulating access over time?” ²
• “Which accounts are excluded from automation, and what compensating controls exist?” ²
• “How do you detect failures in provisioning jobs?” ²

Frequent implementation mistakes (and how to avoid them)

1. Dynamic in the directory only. Disabling in the IdP but leaving local accounts active in key systems. Fix: maintain a deprovisioning coverage map and test the leaver flow per system. ²

2. No contractor end-date enforcement. Contractors are often missing strong “leaver” triggers. Fix: require sponsor and end date at account creation; enforce expiry in IAM. ²

3. Mover events don’t remove old access. Role updates add groups but never remove. Fix: use rule-based “desired state” membership, not additive grants. ²

4. Exceptions become the default path. Manual tickets pile up and the control stops being dynamic. Fix: cap exception duration, require reason codes, and review exception volume in control health checks. ²

5. Evidence is anecdotal. Teams describe the process but can’t produce logs. Fix: predefine the evidence bundle and store it in a consistent location per cycle. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source set for this requirement, so treat “enforcement” here as audit and incident risk. The risk is straightforward: delayed deactivation and unmanaged role changes create unauthorized access, which expands breach impact and complicates incident containment. AC-2(8) reduces that exposure by making access lifecycle changes systematic and provable. ²

Practical execution plan (30/60/90)

Use these phases as an operator’s plan. Adjust sequencing to your environment.

First 30 days (stabilize scope + triggers)

• Name the control owner and publish the control card (scope, triggers, exceptions). ²
• Inventory account populations: workforce, privileged, service accounts, third-party users. ²
• Map authoritative sources and document required identity attributes (status, manager, end date). ²
• Pick your “critical systems” list for end-to-end deprovision proof (start small, prove it works). ²

Next 60 days (implement automation + evidence)

• Implement joiner/mover/leaver automation for the central directory/IdP and your top critical systems. ²
• Add contractor end-date expiry and sponsor requirements. ²
• Define and operationalize the minimum evidence bundle; run a mock audit with sampled events. ²
• Build monitoring for provisioning failures and exception aging. ²

Next 90 days (expand coverage + control health)

• Expand downstream app integrations based on risk and access volume. ²
• Implement privileged access dynamics (time-bound elevation, automatic expiry) where feasible. ²
• Start recurring control health checks and track remediation to closure. ²
• Operationalize reporting for auditors: “Here are sampled lifecycle events, with logs and outcomes.” ²

Where Daydream fits (without making this a tool decision)

If you struggle with ownership, evidence consistency, or audit readiness, Daydream can host the control card, standardize the evidence bundle, and track control health findings to closure. That directly addresses the common failure mode where the control exists in policy but not in operating proof. ²

Frequently Asked Questions

What does “dynamically” mean in AC-2(8)?

It means account lifecycle actions are triggered by authoritative events and executed through automated or event-driven workflows as the normal operating mode. You should still have an exception path, but it can’t be the primary mechanism. ¹

Do third-party (contractor) accounts fall under this requirement?

Yes, if they are accounts in your system boundary. Treat contractor end dates and sponsor status as core trigger events, and enforce expiry and deactivation through IAM rather than manual reminders. ²

We can disable SSO quickly, but some apps have local users. Is that noncompliant?

It’s a gap unless you implement a compensating control. Document which systems can’t deprovision automatically, require manual steps with approvals, and prove completion through logs or screenshots captured as evidence. ²

How do we prove “dynamic” operation to an auditor?

Provide sampled joiner/mover/leaver events that show the trigger record, the workflow execution log, and the resulting account state change across key systems. Add exception tickets only where automation is not possible. ²

Does AC-2(8) require just-in-time access for admins?

NIST’s enhancement text requires dynamic management; it does not mandate a specific technology pattern. Just-in-time elevation with automatic expiry is a strong way to meet the “dynamic” intent for privileged roles when your tooling supports it. ²

What’s the fastest place teams fail this control in practice?

Movers and contractors. Role changes often accumulate access, and contractor end dates are frequently missing or unenforced; both issues break the “manage and deactivate dynamically” expectation. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5