Account Management

To meet the FedRAMP Moderate “Account Management” requirement (NIST SP 800-53 Rev. 5 AC-2), you must document which account types are allowed and prohibited, name accountable owners for accounts, define prerequisites for role/group membership, and enforce controlled workflows for account creation, changes, disabling, and removal with auditable evidence. ¹

Key takeaways:

• Write down allowed vs. prohibited account types, then make systems enforce the rules through IAM and provisioning workflows. ¹
• Assign “account managers” by system and account type, and make them responsible for approvals, periodic validation, and timely deprovisioning. ¹
• Evidence matters as much as design: keep requests, approvals, change tickets, review results, and exceptions tied to each access decision. ¹

Account Management is one of the controls assessors test early because it connects directly to unauthorized access, least privilege, and incident containment. Under FedRAMP Moderate, you are expected to operate a disciplined access lifecycle inside the authorization boundary: define what accounts can exist, who can approve and manage them, what a user must have before receiving a role or group, and exactly how accounts are created, changed, disabled, and removed. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize AC-2 is to treat it as an “access governance contract” between HR (or requester), system owners, security, and IT operations. Your job is to make the contract explicit (policy + procedure), make it enforceable (IAM tooling + workflows), and make it provable (artifacts that an assessor can trace from request to approval to provisioning to review to removal). ¹

If you’re building toward authorization or tightening continuous monitoring, prioritize traceability and boundary clarity: which systems are in scope, which identity sources feed them, and how you prevent orphaned, shared, or over-privileged accounts from lingering without an owner. FedRAMP templates can speed up documentation alignment for your SSP and supporting procedures. ²

Regulatory text

Requirement (AC-2): “Define and document the types of accounts allowed and specifically prohibited for use within the system; assign account managers; require prerequisites for group and role membership; and establish conditions for account creation, enabling, modification, disabling, and removal.” ¹

What the operator must do:

• Define and document account types: Create an explicit list of account types that may exist in the FedRAMP boundary (and which are forbidden). ¹
• Assign account managers: Name accountable roles (not just teams) who approve, maintain, review, and terminate accounts. ¹
• Set prerequisites for roles/groups: Document what must be true before a user can be added to privileged groups or sensitive application roles (training, clearance/need-to-know, management approval, ticket, etc.). ¹
• Control lifecycle events: Define conditions and workflows for create/enable/change/disable/remove; then implement those workflows and retain evidence. ¹

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

You must be able to answer, for any account in scope: Why does this account exist, who approved it, who owns it, what access does it have, what system rules constrain it, and what would trigger its removal? AC-2 is less about writing a policy and more about running a repeatable, testable lifecycle that prevents “mystery access.” ¹

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers (CSPs) operating a Cloud Service Offering within a FedRAMP authorization boundary. ¹
• Federal Agencies that share responsibility for implementing and maintaining the baseline in their environment and integrations with the CSP boundary. ¹

Operational context (where it shows up in practice):

• Centralized identity (IdP) plus downstream apps and infrastructure accounts.
• Privileged access paths: cloud console admins, production break-glass, database admins, CI/CD service accounts.
• Third-party administered components: managed service providers, SaaS admin portals, support access.
• Joiner/Mover/Leaver (JML) flows triggered by HR, contracting, or agency onboarding.

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

1) Define account types and draw hard boundaries

Create a one-page “Account Type Standard” for the boundary that includes:

• Allowed account types: workforce user, admin user, service account, application account, break-glass/emergency, API token-backed identities, federated identities.
• Prohibited account types (examples): shared named-user accounts, unlabeled generic admins (for example “admin1”), personal email-based accounts, unmanaged local accounts on servers, permanent “temporary” accounts.
  Then map each type to:
• Where it is created (IdP, directory, cloud provider, application)
• Authentication requirements (SSO/MFA where applicable)
• Ownership (account manager role)
• Review cadence and removal triggers (event-based and periodic)

This satisfies the “allowed/prohibited” expectation and gives assessors a clean control narrative. ¹

2) Assign account managers and make the role operational

Document “account manager” assignments by system and account type. Avoid vague ownership like “IT.” Instead, define:

• Request approval owner (who approves access)
• Provisioning operator (who executes or what automated workflow executes)
• Access reviewer (who attests access remains appropriate)
• Deprovision owner (who confirms termination actions)

Tie these to job titles and teams so they survive reorgs. ¹

3) Define prerequisites for group and role membership

For each privileged role or sensitive group, define prerequisites such as:

• Completion of security training or role-based admin training
• Manager approval and system owner approval
• Ticket with business justification and time bounds (if applicable)
• Background check/clearance/need-to-know where your program requires it

Put prerequisites in the access request form so they are captured as evidence, not buried in a wiki. ¹

4) Implement lifecycle workflows you can audit

Build workflows for each lifecycle event:

Create / enable

• Require a request (ticket or IAM request) with identity, role/group, justification, and approver.
• Automate provisioning where possible through IdP/IAM so you can produce logs consistently.
• Enforce naming standards for service accounts and admin accounts.

Modify

• Treat role changes as new approvals, not as “ops tweaks.”
• Require explicit approval for privilege increases; document what changed and why.

Disable

• Define disable triggers (termination, contract end, inactivity, role change, incident containment).
• Disable first when you need fast risk reduction; remove after validation if needed for forensics or retention.

Remove

• Define removal conditions (account should no longer exist) and the mechanism (delete in app, remove from groups, revoke tokens/keys).
• Cover non-human identities: rotate/revoke API keys; remove unused service principals.

These workflows must exist for all in-scope systems, not only your primary directory. ¹

5) Run access reviews that match your risk

AC-2 expects you to manage accounts as living objects, not set-and-forget. Practically:

• Review privileged roles/groups first (admins, production access, IAM policy admins).
• Validate service accounts and API tokens: confirm owner, purpose, and last use, then retire what’s stale.
• Track exceptions with compensating controls and an end date.

Daydream can help by centralizing the evidence set (requests, approvals, reviewer attestations, exceptions) so you can answer assessor sampling quickly without chasing screenshots across tools.

Required evidence and artifacts to retain

Store evidence in a way that supports sampling and traceability from identity to authorization decision.

Minimum artifact set (operator-ready):

• Account Management policy/procedure covering allowed/prohibited accounts and lifecycle conditions. ¹
• RACI or responsibility assignment showing named account managers by system/account type. ¹
• Access request records (tickets/IAM requests) with approvals and justification. ¹
• Provisioning logs or workflow audit trails showing the change was executed. ¹
• Role/group prerequisite documentation and proof of prerequisite completion where applicable. ¹
• Access review outputs: reviewer attestations, remediation actions, and closure evidence. ¹
• Exception register for nonstandard accounts (break-glass, third-party support access), including compensating controls and end conditions. ¹
• SSP/control narrative alignment using FedRAMP templates where appropriate. ²

Common exam/audit questions and hangups

Assessors and auditors tend to probe the same failure points:

1. “Show me prohibited accounts and how you prevent them.”
   They will sample for shared accounts, generic admins, and unmanaged local accounts. Be ready with both documentation and technical enforcement. ¹

2. “Who is the account manager for this service account?”
   Service accounts are a common gap: no clear owner, no review, no decommission path. ¹

3. “How do you handle movers?”
   Role changes often cause privilege creep. Expect sampling of transfers/promotions and proof of access adjustment. ¹

4. “Prove deprovisioning happened.”
   Auditors look for closed-loop evidence: termination event → disable/remove actions in each system. ¹

5. “What are prerequisites for privileged access?”
   If your prerequisites are informal, you will struggle to prove them during testing. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails in assessment	Fix
Writing an access policy that doesn’t match how access is actually granted	Testers validate operation, not intentions	Update procedures to match real workflows, then adjust tooling to close gaps. 1
Treating applications as “out of scope” because SSO exists	Accounts still exist downstream (local roles, tokens)	Inventory every in-boundary system with its own authorization model and cover it in lifecycle steps. 1
No owner for non-human identities	Orphaned service accounts persist	Require an accountable owner and documented purpose for each service account and API identity. 1
Access reviews that produce a PDF but no remediation trail	Evidence lacks closure	Track findings to tickets, show removal or justified retention, and store artifacts centrally (Daydream can help). 1
Break-glass accounts that are always enabled	High-impact access without governance	Require explicit conditions for enablement, monitoring, and post-use review tied to an incident or approved request. 1

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page focuses on authorization and assessment risk.

Practical risk: If account management is weak or poorly evidenced, inappropriate access can persist and you may fail to justify access decisions during FedRAMP authorization reviews, assessor testing, and continuous monitoring submissions. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and document what exists)

• Confirm the authorization boundary and list all identity stores and target systems in scope. ¹
• Publish allowed/prohibited account types and naming standards for admins and service accounts. ¹
• Assign account managers for each system and account type; document responsibilities. ¹
• Implement a minimum evidence trail: every access grant ties back to a request and approval record. ¹

Days 31–60 (make it enforceable)

• Build or tighten IAM workflows for create/modify/disable/remove; reduce manual steps that lack logs. ¹
• Add prerequisites to privileged role requests (training, approvals, justification) so they are captured automatically. ¹
• Start a privileged access review and remediate obvious outliers (orphaned admins, stale service accounts). ¹

Days 61–90 (make it provable and repeatable)

• Run an access review cycle that produces remediation tickets and closure evidence for sampled systems. ¹
• Validate deprovisioning paths for leavers and movers across all key apps, not just the directory. ¹
• Align SSP control narrative and supporting procedures using FedRAMP templates; ensure your evidence map matches what assessors will test. ²
• Centralize artifacts (requests, approvals, reviews, exceptions) so assessment sampling is a search, not a fire drill (Daydream fits well here).

Frequently Asked Questions

Do we have to prohibit shared accounts completely?

AC-2 requires you to document prohibited account types and govern account conditions. Shared accounts are hard to justify because approval, accountability, and review break down; if you permit any, treat them as exceptions with a named owner and compensating controls. ¹

What counts as an “account manager” in practice?

An account manager is the accountable role for access decisions and lifecycle actions for a defined set of accounts (by system or account type). Document who approves, who reviews, and who ensures disabling/removal occurs. ¹

Are service accounts included in AC-2?

Yes. AC-2 is about account types allowed in the system and lifecycle conditions; non-human identities are still accounts and need owners, approval, and removal conditions. ¹

How do we show prerequisites for group/role membership without creating bureaucracy?

Put prerequisites directly into the access request workflow as required fields and attachments (training completion, manager approval). That captures evidence while keeping the process consistent. ¹

We use SSO. Do we still need account reviews in each application?

Often yes, because many apps maintain local roles, admin grants, or API tokens outside the IdP group mapping. Inventory where authorization actually lives and review access where privileges are assigned. ¹

What evidence is most commonly missing during assessments?

Closed-loop proof: request and approval tied to the exact provisioning action, plus evidence that access was later reviewed and removed when no longer needed. Centralizing these artifacts reduces scramble during sampling. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates