IAM-002 Identity Inventory and Unique Identifiers
Description
An inventory of all identities, covering human users, service accounts and other non-human identities, is maintained. Every identity is assigned a unique identifier. Shared or generic accounts are prohibited except where documented and justified, and where one is permitted each user authenticates as themselves before the shared account or resource is released to them, so every shared session resolves to a named individual.
Rationale
Non-unique identifiers make it impossible to attribute actions to individuals and undermine the audit trail, and a current identity inventory is the prerequisite for access reviews and offboarding. Without individual authentication, the justification records why the shared account exists and the log still cannot say who used it. Privileged access management tooling and jump hosts deliver this by brokering the shared credential behind a personal login.
Applicability (9 profiles)
164.312(a)(2)(i) is required rather than addressable, which removes the documented-and-justified shared account route IAM-002 otherwise leaves open for systems holding electronic protected health information.
Framework Mappings (11)
| IAM-03 | Identity Inventory | full |
| IAM-12 | Unique Identities | full |
| IAM-03 | Identity Inventory | full |
| IAM-12 | Unique Identities | full |
| HIPAA-164.312.a.2.i | Unique User Identification | full |
| 5.16 | Identity management | full |
| NIS2-CIR-11.5 | Identification | partial |
| AC-2(9) | Account Management | Restrictions on Use of Shared and Group Accounts | full |
| IA-2 | Identification and Authentication (Organizational Users) | partial |
| IA-2(5) | Identification and Authentication (Organizational Users) | Individual Authentication with Group Authentication | full |
| IA-4 | Identifier Management | full |
Evidence (3)
Identity inventory export from the IdP or privileged access management tool listing all human, service, and non-human accounts with their unique identifiers.
Example: Okta, Azure AD, or AWS IAM user/service-account export (CSV or API JSON) showing every identity with a distinct username or principal identifier, account type, and status.
Test: Export the identity list from the identity provider and from each cloud identity service in use, through the provider's user and role listing interface. Verify: (1) no two entries share an identifier, (2) every shared or generic account carries a documented justification and a named owner, (3) the human account count reconciles with the human resources record of active personnel, (4) service and other non-human identities appear in the export rather than only human users.
Policy or standard prohibiting shared and generic accounts, with defined exceptions and a documented approval process for any permitted exceptions.
Example: Identity Management Policy or Access Control Standard document containing a clause explicitly prohibiting shared credentials, specifying that any exception requires documented approval with a named business justification.
Test: Request the identity management policy or equivalent standard. Verify: (1) the document explicitly prohibits shared or generic accounts, (2) an exception process is defined with approval requirements, (3) any in-scope exceptions are backed by a completed approval record.
Access log for a permitted shared account showing the individual authentication that preceded each use.
Example: Broker session log, shared-ops account, 30-day extract 2026-08
Test: Query the access log for each permitted shared account over 30 days. Verify: (1) every use of the shared account is preceded by an individual authentication event for a named user, (2) the two events are linkable through a session or request identifier, (3) no use of the shared account appears without a preceding individual authentication, (4) the individual authentication used the factors required for that user's own account, (5) shared accounts with no permitted-use record are absent from the log entirely.
Questions (3)
Is a centralised inventory of all identities, including human users, service accounts, and other non-human identities, maintained?
The inventory should be sourced from the IdP or IAM platform (e.g. Okta, Azure AD, AWS IAM), not maintained only in a spreadsheet. It must include both human and non-human identities.
Are shared or generic accounts in use in any of your production systems?
Shared accounts undermine audit trail integrity. Any active shared accounts must have a documented justification and a named individual accountable for activity on that account.
Where a shared account is permitted, does each user authenticate as themselves before being given access to it?
Answer yes only where the individual authentication is enforced by a broker, a privileged access tool or a jump host rather than being a convention. Without it, the justification records why the shared account exists and the log still cannot say who used it. Answer yes as well if no shared accounts are permitted at all.