IA-2(5): Individual Authentication with Group Authentication

Shared accounts exist for real reasons: break-glass access, legacy applications, operational consoles, third-party support scenarios, and service administration where individual accounts are hard to implement. IA-2(5): individual authentication with group authentication requirement draws a hard line: shared access cannot erase accountability. If multiple people can use the same credential, you must still prove who actually used it, when, and under what authorization.

For a Compliance Officer, CCO, or GRC lead, the quickest way to operationalize IA-2(5) is to treat shared accounts as an exception pattern with strict conditions. You inventory shared accounts, force named-user authentication upstream (SSO/MFA or privileged access tooling), broker or record the session into the shared target, and retain logs that tie the activity back to the person.

This page gives requirement-level implementation guidance you can hand to IAM, security engineering, and IT operations. It focuses on concrete workflows (PAM, password vaulting, session brokering, sudo/jump hosts, break-glass), the evidence auditors ask for, and the failure modes that trigger findings.

Regulatory text

Requirement (excerpt): “When shared accounts or authenticators are employed, require users to be individually authenticated before granting access to the shared accounts or resources.” ¹

What the operator must do:

• Identify where shared accounts or shared authenticators exist (including “everyone knows the password” accounts and shared SSH keys).
• Put an individual authentication step in front of shared access. The system must authenticate the person (named identity) first.
• Maintain accountability: access events and actions taken through shared access must be attributable to the individually authenticated user.

Reference: NIST SP 800-53 Rev. 5 ²

Plain-English interpretation

If more than one person can access the same account or credential, you must not allow them to “walk in anonymously.” You can keep the shared account for operational reasons, but the path to use it must start with a unique identity (named user) and end with logs that reliably map the shared session back to that user.

In practice, IA-2(5) is less about banning shared accounts and more about forcing identity-bound entry, controlled elevation, and traceable sessions.

Who it applies to (entity and operational context)

Entity scope (typical):

• Federal information systems and contractors handling federal data where NIST SP 800-53 controls are in scope ².

Operational scope (where you’ll see this control tested):

• Privileged access: domain admin, root, “Administrator,” “oracle,” “sa,” hypervisor consoles.
• Shared local accounts on servers, network appliances, OT/ICS consoles, and security tools.
• Shared cloud credentials (shared access keys), shared break-glass accounts, shared API tokens used interactively.
• Third-party support access where a provider uses a shared credential. (Treat the provider as a third party, but still require individual authentication of the human accessing your environment.)

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

Step 1: Inventory shared accounts and shared authenticators

Build (or refresh) a register that answers:

• Target system/resource (server, database, SaaS admin portal, firewall).
• Shared identifier (account name, key label, token name).
• Type: shared account vs shared authenticator (password, SSH key, hardware token).
• Human use vs non-human use (interactive admin vs service account use).
• Business justification and why individual accounts are not feasible.
• Current controls (vaulted, rotated, session recorded, approvals).

Deliverable: “Shared Access Register” owned by IAM or Security with GRC oversight.

Step 2: Decide the approved access pattern for each shared scenario

Use a simple decision matrix and standardize on a small set of patterns:

Scenario	Preferred pattern	What satisfies “individually authenticated first”
Admin/root access	PAM broker + session recording	User signs into SSO/MFA, PAM grants time-bound access to root without revealing password
Legacy shared password	Vault checkout + MFA + approvals	User authenticates to vault with MFA, checks out password under a ticket/approval, actions logged
Shared SSH key	SSH certificate or brokered SSH	User authenticates to broker; broker issues short-lived cert or mediates session
Break-glass	Sealed emergency account + dual control	Named-user auth to emergency workflow, documented approval, tight logging and post-incident review
Third-party support	Federated named accounts, or brokered support access	Third party’s human authenticates individually (IdP or broker), then gets controlled access

If you cannot implement one of these patterns, document a compensating control and a migration plan. IA-2(5) is frequently assessed as “designed but not operating” when teams rely on intent without workable mechanics.

Step 3: Put an “identity gate” in front of the shared resource

Implement one of these gates (pick what fits your environment):

• PAM / session broker: the user authenticates with their own identity, then the broker connects them to the shared account.
• Jump host / bastion with named accounts: users authenticate to the bastion, then use controlled escalation (sudo) to perform privileged actions.
• Password vault workflow: the user must authenticate to the vault (MFA), request access, and check out the credential with an auditable trail.

Control intent: the shared password/credential is no longer the primary authentication factor for the human. The person’s named identity becomes the security boundary.

Step 4: Bind activity to the individual (attribution)

Meet IA-2(5) in a way auditors recognize by producing logs that answer: who did what, through which shared mechanism, and when. Minimum expectations:

• Authentication logs for the named user (IdP/PAM/vault).
• Authorization trail (approval, ticket, group membership).
• Session metadata (start/stop, target system, account used).
• Where feasible, session recording or command logging for high-impact systems (privileged consoles, production).

Step 5: Tighten governance for shared access

Write a short standard that makes shared access the exception:

• Allowed use cases (break-glass, technical limitation).
• Required controls (named-user authentication first, logging, approvals for privileged use).
• Ownership (system owner + IAM/SecOps).
• Review requirements (periodic access review, validation of justifications, and removal when no longer needed).

This is where Daydream fits naturally: track each shared-account exception, assign control owners, attach recurring evidence (vault logs, approvals, access rosters), and keep the control continuously assessment-ready without rebuilding the story each audit cycle.

Required evidence and artifacts to retain

Auditors usually do not accept “we do MFA” as evidence if the shared account can still be entered directly. Build an evidence set that maps cleanly to IA-2(5):

Policy / standard artifacts

• Shared account standard (allowed scenarios, required gate, logging, approvals).
• Exception register entry for each shared account with justification and compensating controls.

Access control artifacts

• Current roster of people allowed to request/use the shared access path (PAM group, vault group, bastion group).
• Approval workflow evidence (tickets/ITSM records, change approvals) for privileged checkouts or emergency use.

Technical evidence

• IdP/PAM/vault configuration screenshots or exports showing the individual authentication requirement (MFA requirement, SSO integration, group policies).
• Sample logs showing: named user authenticated → shared session established → target accessed.
• For break-glass: evidence of password rotation after use and post-incident review notes.

Review/monitoring artifacts

• Periodic review sign-offs for shared access membership and continued justification.
• Alerts or reports for shared account use (especially after-hours or from unusual locations).

Common exam/audit questions and hangups

• “Show me every shared account and who can access it.” Expect a request for a complete inventory plus system-owner attestations.
• “Can someone log into the shared account directly?” If yes, you need a documented reason and compensating controls, or you will likely get a finding.
• “How do you attribute actions to a person?” Be ready with log samples and a walkthrough from IdP/PAM/vault to the target system.
• “What happens when someone leaves?” They will test offboarding: removal from PAM/vault groups and inability to initiate shared sessions.
• “How is third-party support handled?” They will expect named identities for third-party humans, not a generic “vendoradmin” login.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating the shared password itself as “authentication.”
   Fix: require individual authentication to a gate (IdP/PAM/vault) before the password is even accessible.

2. Mistake: Inventory stops at Windows/Linux and misses appliances and SaaS.
   Fix: include network gear, security tools, databases, CI/CD, cloud consoles, and any place a team shares tokens or keys.

3. Mistake: Shared access exists “temporarily” and becomes permanent.
   Fix: require an exception record with an owner and a retirement plan; review it periodically.

4. Mistake: Third parties share one credential across their team.
   Fix: require individual authentication for each third-party user (federation or brokered access), and restrict to time-bound, approved sessions.

5. Mistake: Logs exist but can’t be correlated.
   Fix: ensure consistent identifiers (username, request ID, ticket number) propagate from the gate into session metadata and monitoring.

Risk implications (why auditors care)

Shared accounts increase the probability of undetected misuse because they weaken attribution. Without individual authentication in front of shared access, you also weaken incident response: you can observe that “root logged in,” but you cannot reliably identify the human. IA-2(5) exists to preserve accountability even when operational constraints require shared mechanisms. ²

A practical 30/60/90-day execution plan

Days 1–30: Establish control and visibility

• Assign a control owner (IAM/SecOps) and an accountable executive sponsor (CISO or CIO).
• Build the Shared Access Register and validate completeness with platform owners.
• Freeze new shared accounts unless approved through an exception process.
• Pick standard patterns (PAM broker, vault checkout, bastion) and document “approved ways of doing shared access.”

Days 31–60: Implement the identity gate for high-risk shared access

• Move privileged shared accounts first (domain admin/root, production consoles, security tooling).
• Integrate SSO/MFA into PAM/vault/bastion for named-user authentication.
• Turn on session metadata logging; enable session recording where feasible for high-impact systems.
• Create a repeatable evidence pack template (what screenshots/logs to export, where stored, who reviews).

Days 61–90: Operationalize and make it auditable

• Eliminate direct login paths where possible (disable interactive login, restrict network paths, rotate credentials into the vault).
• Implement monitoring and triage: alerts for shared-account use and periodic review workflows.
• Run a tabletop: simulate an investigation and prove you can attribute a shared session to a user quickly using retained logs.
• Load control mappings, owners, and recurring evidence tasks into Daydream so audits don’t trigger a scramble.

Frequently Asked Questions

Do we have to eliminate all shared accounts to meet IA-2(5)?

No. IA-2(5) allows shared accounts, but requires individual authentication before access to the shared account or resource. Your job is to make shared access attributable and controlled. ¹

Does a password vault satisfy “individually authenticated first”?

It can, if users must authenticate individually (preferably with MFA) to the vault and the vault’s logs show who checked out the credential and when. If the shared password is still broadly known outside the vault, the control intent is not met.

What about “break-glass” accounts during an outage?

Break-glass is a valid use case, but you still need individual authentication to the break-glass workflow and strong after-action steps such as credential rotation and review documentation. Keep a clear record tying the emergency access to a named user.

How do we handle third-party support that wants a single shared login?

Require individually named accounts for third-party personnel where feasible, or broker their access through a system that enforces individual authentication and records sessions. Treat shared third-party credentials as high-risk exceptions with explicit approvals.

Are shared service accounts in scope for IA-2(5)?

IA-2(5) targets scenarios where shared accounts or authenticators are employed for user access. For non-human service accounts, focus on restricting interactive use and preventing credential sharing among humans, then document the account’s purpose and controls.

What evidence is the fastest path to close an audit request?

Provide the shared account inventory, the access roster for each shared path (PAM/vault groups), and a log set showing a named user authenticated before a shared session began. Add the governing standard and at least one completed periodic review sign-off.

Footnotes

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

2. NIST SP 800-53 Rev. 5