AC-2(10): Shared and Group Account Credential Change

The ac-2(10): shared and group account credential change requirement exists because shared secrets break accountability: multiple people can know the same password, key, or token, and you cannot reliably prove who used it after an incident. Your job as a Compliance Officer, CCO, or GRC lead is to force two outcomes: (1) shared and group accounts are rare and justified, and (2) when they do exist, their credentials change when risk changes, especially when people join, leave, or change roles.

This page gives you requirement-level implementation guidance you can hand to IAM, IT, and platform teams. It focuses on practical control design: defining trigger events, forcing rotations through ticketing and access workflows, and collecting audit-ready evidence without heroic manual effort. It also flags where organizations get stuck: unmanaged shared accounts, “break-glass” accounts that never rotate, and service accounts incorrectly treated as exempt.

Primary source references for this control are NIST SP 800-53 Rev. 5 and the NIST SP 800-53 Rev. 5 OSCAL catalog. ¹

Regulatory text

NIST SP 800-53 control AC-2.10 is “AC-2(10): Shared and Group Account Credential Change.” ²

Operator interpretation: you must have a defined, repeatable process to change (rotate) credentials for shared or group accounts when membership changes create a reasonable possibility that someone who should not retain access still knows the credential. The control is aimed at the credential itself (password/secret/key), not just disabling an individual user record.

What the operator must do (minimum):

• Identify which accounts are “shared” or “group” accounts in your environment.
• Define trigger events that require a credential change.
• Execute and document credential changes when triggers occur.
• Retain evidence that rotations occurred and were authorized.

(Framework source: NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English requirement interpretation (what “counts”)

A shared account is a single account used by multiple people (example: “helpdesk_admin” with a shared password). A group account often means access is effectively shared through group membership, or an account credential is distributed to a group. In both cases, multiple humans can know the same credential.

AC-2(10) expects you to treat that shared credential as needing rotation when:

• Membership changes (joiners, leavers, transfers) mean the set of people who know the credential should change.
• A person who knew the credential should no longer know it, because they left, were terminated, changed teams, or no longer has a need-to-know.

Operationally, you are controlling “credential persistence.” If someone’s relationship to the organization changes, you remove their ability to authenticate by changing the shared credential, not by trusting that they will forget it.

Who it applies to (entity and operational context)

You should scope this control to any environment implementing NIST SP 800-53 Rev. 5, especially:

• Federal information systems and programs
• Federal contractors and service organizations handling federal data
• Contractor systems where NIST controls are flowed down contractually

³

Operational contexts where AC-2(10) shows up in audits:

• Privileged “team” logins in infrastructure, databases, network devices, OT/IoT consoles
• Emergency/break-glass administrator accounts
• Shared local admin accounts on servers or appliances
• Shared credentials used by third parties (support partners, managed service providers)
• Runbooks, scripts, or CI/CD jobs where a static secret is known by multiple engineers (treat as “shared knowledge,” even if stored in a vault)

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

Step 1: Build an inventory of shared/group accounts (complete list)

Create a register with, at minimum:

• Account name / identifier
• System or platform (IdP, database, network device, SaaS)
• Credential type (password, API key, SSH key, token)
• Purpose and business justification (why not individual accounts)
• Human owners: business owner and technical owner
• Where the credential is stored/distributed (vault, password manager, runbook, spreadsheet)
• Current authorized membership (named users or roles)
• Rotation method (manual, automated) and rotation triggers

Practical move: start with privileged accounts and any account that appears in incident response runbooks. Those are the ones auditors ask about first.

Step 2: Define “credential-change triggers” and encode them into workflow

Write triggers as explicit events that create a rotation obligation. Common triggers that map cleanly to AC-2(10):

• A user is removed from the authorized group or distribution list.
• A user with knowledge of the credential leaves the company (voluntary or involuntary).
• A user changes roles and loses need-to-know.
• A shared credential is disclosed outside approved storage (example: pasted into a ticket or chat).
• A third party support relationship ends, or their named personnel change.

Control design tip: if you already run joiner/mover/leaver workflows, add a mandatory question: “Does the user know any shared/group credentials?” If yes, generate rotation tasks for each mapped shared credential.

Step 3: Implement a rotation runbook that operators can execute under pressure

Your runbook should be short and consistent across platforms:

1. Open a ticket referencing the trigger event (termination ticket, access removal request, third party offboarding).
2. Approve rotation (system owner or security owner approves; emergency path documented).
3. Rotate the credential (change password/key; invalidate existing tokens where possible).
4. Update authorized storage (vault/password manager) and remove any old copies.
5. Update dependent systems (services, jobs, integrations) and validate functionality.
6. Close the ticket with evidence attachments and timestamps.

If you use Daydream for control operations, this maps cleanly into a control card plus an evidence bundle checklist so rotations do not depend on individual memory.

Step 4: Reduce the number of shared credentials (risk reduction that auditors like)

AC-2(10) is easier when there are fewer shared credentials to rotate. Add these design constraints:

• Prefer individual accounts with MFA and RBAC over shared admin users.
• For third party access, prefer named accounts tied to the third party’s personnel, time-bound access, and session logging.
• For service-to-service needs, prefer managed identities or short-lived tokens rather than long-lived shared secrets (still track and rotate what remains).

This is still within the operator’s scope: you are shrinking the population that creates AC-2(10) obligations.

Step 5: Add recurring control health checks (prove sustained operation)

Auditors often accept a rotation process on paper and then fail you on operation. Schedule a recurring check to confirm:

• The inventory is current (new shared accounts discovered and added).
• Recent joiner/mover/leaver events generated rotation tickets when required.
• Rotations completed and evidence is retained.

Track exceptions with expiration dates and compensating controls.

Required evidence and artifacts to retain

Build an “evidence bundle” per rotation event and a standing set of artifacts.

Standing artifacts (baseline):

• Shared/group account register (current as of last review)
• Policy/standard or runbook defining triggers and rotation steps
• RACI showing who can approve and who performs rotations

Per-event artifacts (each trigger and rotation):

• Source trigger record (HR termination ticket, access removal request, third party offboarding notice)
• Rotation ticket with timestamps, approver, and executor
• System logs or screenshots showing credential changed (where feasible)
• Vault/password manager audit log entry showing update
• Post-change validation note (what was tested, by whom)

Retention: keep evidence in a single system of record (GRC tool or ticketing system) and make it searchable by account name and date.

Common exam/audit questions and hangups

Expect these questions from assessors and customer auditors:

• “Show me all shared and group accounts in scope and who owns them.”
• “What events trigger a credential change? Show the written standard.”
• “Pick a terminated employee. Prove that any shared credentials they knew were rotated.”
• “How do you handle break-glass accounts and emergency access?”
• “How do you ensure third party personnel changes trigger rotations?”

Hangup that causes findings: you can rotate credentials, but cannot prove you did it for the specific trigger event.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating group membership removal as sufficient.
   Fix: if the user ever knew the shared secret, rotate the secret. Group removal does not erase knowledge.

2. Mistake: unmanaged “legacy” shared accounts.
   Fix: discovery sweep (privileged accounts, local admins, network devices), then force each into the register with an owner and justification.

3. Mistake: break-glass credentials never rotate because “they are for emergencies.”
   Fix: define post-use rotation and also rotate on staff departures for those with access to the sealed credential store.

4. Mistake: third party access handled informally.
   Fix: treat third party personnel changes as trigger events; require named access and offboarding attestations.

5. Mistake: secrets sprawl across docs and chat.
   Fix: mandate approved storage (vault/password manager) and incident-triggered rotation when leakage occurs.

Enforcement context and risk implications

No specific public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is operational and evidentiary: shared credentials weaken attribution and increase the chance that a departed insider, or a third party whose engagement ended, can still authenticate. Under NIST-aligned assessments, that often becomes a control deficiency tied to access governance and incident readiness. ³

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign an owner for AC-2(10) operations (IAM/security) and an approver (system owners).
• Create the shared/group account register and capture your highest-risk systems first.
• Publish trigger events and the rotation runbook (one page).
• Pick a single evidence location (tickets + attachments, or GRC evidence repository) and standardize naming.

Days 31–60 (operate and prove)

• Integrate triggers into joiner/mover/leaver and third party offboarding workflows.
• Run a tabletop: terminate a test user who “knows” a shared credential and execute the rotation process end-to-end.
• Start recurring control health checks and log findings with remediation owners.

Days 61–90 (reduce exposure and automate)

• Eliminate or convert shared accounts where feasible (named accounts, RBAC, MFA).
• Automate rotations for platforms that support it (vault rotation, managed identity patterns).
• Use Daydream (or your GRC system) to formalize the control card, evidence bundle checklist, and a recurring attestation task for system owners.

Frequently Asked Questions

Do service accounts fall under AC-2(10)?

If a credential is shared among multiple humans (known, copied, or retrievable by a group), treat it as in scope and rotate on membership changes. If it is a non-human identity with controlled access to the secret store, document the distinction and keep evidence of that control.

What if we cannot rotate immediately because it will break production?

Document an exception with a defined remediation plan, compensating controls (monitoring, restricted secret access), and an expiration date. Auditors usually accept constrained exceptions when you can show ownership, risk acceptance, and follow-through.

How do we handle break-glass accounts?

Store break-glass credentials in an approved sealed system with access logs, restrict who can retrieve them, and rotate after any retrieval or when any authorized retriever leaves or changes roles. Keep retrieval logs and the rotation ticket linked.

Does removing someone from a shared password manager vault satisfy the requirement?

It helps, but it does not address prior knowledge. If the person could have viewed the secret, rotate the secret and retain evidence of the change.

How do we scope “group accounts” in SaaS tools that only support shared logins?

Treat each shared login as a shared account, require a business justification, and define triggers tied to user roster changes. Add monitoring for login activity and require rotation when staffing changes occur.

What evidence is strongest for auditors?

A traceable chain: trigger event record → rotation ticket with approval → system/vault audit log showing the credential changed → validation note. Consistency across events matters more than perfect screenshots.

Footnotes

1. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON

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

3. NIST SP 800-53 Rev. 5