AC-2: Account Management

AC-2: Account Management is one of the fastest ways to fail an audit if you treat it as “we have SSO.” The requirement you’re operationalizing here is narrow but high-impact: define and document the types of accounts you allow, and the types you forbid, for the system. ¹

For a CCO, GRC lead, or security compliance owner, the practical goal is simple: make account types explicit (human, privileged, service, shared, guest, break-glass, third-party, API, local OS accounts), state what’s prohibited (for example, shared named accounts, orphaned service accounts, direct local admin accounts), and show that your IAM and ITSM processes enforce the rules. AC-2 becomes easy to defend when every account has an owner, a purpose, an approval trail, and a consistent lifecycle from request to removal.

This page gives you a requirement-level runbook: who should own it, the decisions you must document, step-by-step operating procedures, the minimum evidence to retain, and the exam questions that commonly expose gaps.

Regulatory text

Requirement excerpt: “Define and document the types of accounts allowed and specifically prohibited for use within the system;” ²

What the operator must do (plain-English):

• You must publish a written, system-scoped definition of account categories you permit and account categories you forbid.
• Those definitions must be concrete enough that engineering/IT can implement them and an auditor can test them (for example, “no shared named accounts” is testable; “accounts should be managed securely” is not).
• The documented rules must match reality across identity providers, directories, endpoints, cloud consoles, databases, and critical applications in scope for the system boundary. ¹

Plain-English interpretation (what AC-2 is really asking)

AC-2 is a governance requirement disguised as an IAM requirement. The control asks whether you have made explicit decisions about account types, and whether those decisions are documented so they can be consistently executed.

A practical way to read AC-2:

• If you cannot list your allowed account types, you cannot enforce least privilege consistently.
• If you do not explicitly prohibit risky account types, they will appear through exceptions, migrations, third-party access, and emergency changes.
• If you cannot prove the rules are enforced, the “documentation” is just paper. ¹

Who it applies to

Entities: Federal information systems, federal contractors, contractor systems handling federal data, and service organizations supporting those environments commonly inherit AC-2 expectations. ²

Operational context (where teams get tripped up):

• Systems with multiple identity planes: SSO for workforce, separate local accounts on servers, cloud-provider IAM users, database users, and SaaS-native users.
• Privileged access paths: break-glass admin, emergency access, and managed service provider access.
• Non-human access: service accounts, workload identities, API tokens, robotic process automation accounts.
• Third-party access: consultants/contractors needing time-bound access; support engineers needing scoped admin rights.

If it can authenticate to your system (human or machine), it falls into an account type you need to classify as allowed or prohibited.

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

1) Set control ownership and a one-page “control card”

Assign a single accountable owner (often IAM, Security Operations, or GRC with IAM execution). Then create a control card that includes:

• Objective (AC-2 account types allowed/prohibited)
• In-scope systems and identity stores
• Trigger events (new hire, role change, termination, third-party onboarding/offboarding, privilege elevation, incident/break-glass use)
• Execution steps (below)
• Exceptions process (who can approve, time limits, compensating controls)
• Evidence bundle (what you retain and where)

This is the difference between “a policy exists” and “a control operates.”

2) Define account-type taxonomy and write the allowed/prohibited list

Create a short standard (one to two pages) with:

• Allowed account types (examples you can adapt):
  • Named workforce user accounts (SSO-backed)
  • Privileged admin accounts (separate from daily user, MFA enforced)
  • Service accounts/workload identities (owned by a team, non-interactive where possible)
  • Break-glass accounts (restricted, monitored, tightly controlled)
  • Third-party accounts (time-bound, sponsored by an internal owner)
• Prohibited account types (examples you can adapt):
  • Shared named accounts for routine access
  • Unowned/orphaned service accounts
  • Permanent third-party accounts without a sponsor and expiry
  • Local OS accounts for administrative access where centralized IAM is required
  • Generic “admin/admin” style defaults and vendor backdoor accounts

Make each entry testable by adding attributes such as:

• Owner required (yes/no)
• Expiration required (yes/no)
• Allowed authentication methods (SSO, key-based, certificate, token)
• Privilege boundaries (what it may access)
• Logging/monitoring requirements

3) Map account types to provisioning workflows (ITSM + IAM)

For each allowed account type, define the creation workflow:

• Request intake method (ticket, HRIS event, automated JML)
• Required approvers (manager, system owner, data owner)
• Required fields (purpose, role, owner, expiry, justification)
• Technical enforcement (group membership rules, SCIM provisioning, PAM checkout)

For each prohibited account type, define the preventive/detective measures:

• Prevent creation (IAM guardrails, Terraform policies, directory restrictions)
• Detect and remediate (periodic scans for local users, cloud IAM users, dormant accounts)
• Exception process (documented, time-bound, compensating controls)

4) Implement lifecycle rules (joiner/mover/leaver + non-human)

Auditors will test whether your definitions are enforced during lifecycle events:

• Joiner: accounts created only from approved sources; no manual side accounts without approvals.
• Mover: role changes trigger access review and group changes; privileged access re-approved.
• Leaver: disable and remove access promptly; revoke tokens/keys; transfer ownership of service accounts.
• Non-human: service accounts have owners, rotation/credential management, and disablement when workloads retire.

5) Run recurring “control health checks”

AC-2 breaks over time. Establish recurring checks and track remediation to closure:

• Reconcile identity stores (IdP vs. directories vs. cloud vs. critical apps)
• Identify prohibited account types that exist anyway
• Identify accounts missing required attributes (owner, expiry, justification)
• Identify stale/dormant accounts and privileged accounts without current approval

Keep a simple issues log with owners, due dates, and closure evidence.

6) Make it audit-ready with an evidence bundle per cycle

Define the minimum evidence you retain each cycle so you can answer: “Show me your rule, show me enforcement, show me proof.”

Daydream note (earned mention): Daydream is helpful here when you need a repeatable control card, an evidence checklist per run, and a remediation tracker that ties findings to validated closure without turning AC-2 into a spreadsheet exercise.

Required evidence and artifacts to retain

Keep evidence in a single, known location (GRC repository) and link it to each operating period.

Minimum evidence set (practical):

• Account Management Standard: allowed account types + prohibited account types (system-scoped) ¹
• Control card/runbook with owner, triggers, cadence, and exception rules
• Screenshots or exports showing enforcement rules (IdP policies, PAM policies, directory restrictions) where feasible
• Sample tickets for account creation/change/removal across account types (workforce, privileged, service, third-party)
• Joiner/mover/leaver workflow documentation (HRIS/ITSM integration notes)
• Evidence of periodic account review/health checks:
  • Account inventory export(s)
  • Findings list (including prohibited types discovered)
  • Remediation tickets and closure proof
• Exception register: approved exceptions, rationale, expiry, compensating controls, closure

Common exam/audit questions and hangups

Auditors and customer assessors usually probe AC-2 with questions like:

• “List all account types in scope. Which are prohibited?”
• “How do you prevent shared accounts? Show me.”
• “How do you control service accounts? Who owns them?”
• “How do third parties get access, and how is it removed?”
• “Show a sample of terminations and the access removal evidence.”
• “How do you detect accounts created outside the standard process?”
• “What’s your exception process, and how do you ensure exceptions expire?” ¹

Hangup that causes findings: Teams can answer in words but cannot produce a testable list, or cannot reconcile multiple identity stores where prohibited account types commonly hide.

Frequent implementation mistakes (and how to avoid them)

1. Publishing a policy without a testable account-type list.
   Fix: Write the allowed/prohibited table with attributes (owner, expiry, auth method, privilege boundary).

2. Ignoring non-human identities.
   Fix: Treat service accounts and API/workload identities as first-class account types with owners and lifecycle events.

3. Assuming SSO eliminates local/cloud-native accounts.
   Fix: Inventory where accounts exist (cloud IAM, endpoints, DBs, SaaS) and write prohibitions for unmanaged identity planes.

4. No exception discipline.
   Fix: Require an expiry for every exception, a named approver, and a compensating control (monitoring, reduced scope, PAM).

5. Evidence scattered across teams.
   Fix: Define an evidence bundle and a retention location. Collect the same artifacts every cycle.

Enforcement context and risk implications

No public enforcement cases were provided in the source set for this requirement, so you should treat enforcement discussion as general risk context rather than case-driven precedent.

Operationally, weak account management increases the likelihood of:

• Orphaned access after role changes or termination
• Privilege creep and uncontrolled admin paths
• Untracked third-party access
• Service account sprawl with unknown owners and hard-coded credentials

Those translate into audit findings, failed customer security reviews, and elevated incident blast radius.

Practical 30/60/90-day execution plan

First 30 days (stabilize the requirement)

• Name the AC-2 owner and publish a one-page control card (objective, scope, triggers, exceptions, evidence).
• Draft the allowed/prohibited account-type standard for the system boundary.
• Identify all identity planes in scope (IdP, directory, cloud IAM, endpoints, top-tier apps) and assign technical owners.
• Define the evidence bundle and storage location so you stop losing artifacts.

Days 31–60 (implement and connect workflows)

• Map each allowed account type to a provisioning workflow (ticket fields, approvals, automation path).
• Implement guardrails for prohibited account types (where you can prevent) and detection queries (where you can’t).
• Stand up the exception register with expiry and compensating controls.
• Run your first account inventory reconciliation and log findings with remediation owners.

Days 61–90 (operate and prove)

• Run the second health check and show trend: fewer prohibited accounts, more complete account metadata.
• Validate joiner/mover/leaver evidence end-to-end with samples across workforce, privileged, service, and third-party accounts.
• Close the highest-risk gaps (orphaned privileged access, unmanaged third-party accounts, unknown service account owners).
• Package an “AC-2 audit kit” folder with your standard, workflows, samples, reviews, exceptions, and remediation closure proof.

Frequently Asked Questions

Do we have to prohibit shared accounts to meet AC-2?

AC-2 requires you to define and document what’s allowed and what’s prohibited. If you allow shared accounts, document the limited cases, required controls, and approval path; auditors will expect tight restrictions and strong accountability. ¹

How detailed does “types of accounts” need to be?

Detailed enough that an assessor can test whether an account is compliant. A workable level is categories (workforce, privileged, service, break-glass, third-party) with required attributes like owner, expiry, and permitted authentication methods.

Are service accounts in scope for AC-2?

Yes in practice, because they are accounts used within the system and introduce persistent access paths. Classify them explicitly, require ownership, and define lifecycle triggers for creation and retirement.

What’s acceptable evidence for “documented prohibited accounts”?

Keep the written standard plus proof of enforcement or detection. Good evidence includes IAM policy configuration snapshots, a query/report showing prohibited accounts are absent (or being remediated), and related tickets.

We have multiple directories and SaaS apps. Do we need an allowed/prohibited list per app?

You need definitions that apply to the system boundary and cover all identity planes in scope. You can keep one master account-type standard, then add an appendix listing app-specific exceptions or additional prohibited types where an app has unique risk.

How should we handle third-party access under AC-2?

Define third-party accounts as a distinct allowed type with a sponsor, expiry, and offboarding trigger. Keep onboarding/offboarding tickets and access logs to show the accounts match the documented rules.

Footnotes

1. NIST SP 800-53 Rev. 5 PDF

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