Control statement
Manage system identifiers by:
- a.Receiving authorization from [Organization-defined: personnel or roles] to assign an individual, group, role, service, or device identifier;
- b.Selecting an identifier that identifies an individual, group, role, service, or device;
- c.Assigning the identifier to the intended individual, group, role, service, or device; and
- d.Preventing reuse of identifiers for [Organization-defined: time period].
Discussion
Common device identifiers include Media Access Control (MAC) addresses, Internet Protocol (IP) addresses, or device-unique token identifiers. The management of individual identifiers is not applicable to shared system accounts. Typically, individual identifiers are the usernames of the system accounts assigned to those individuals. In such instances, the account management activities of [AC-2](#ac-2) use account names provided by [IA-4](#ia-4) . Identifier management also addresses individual identifiers not necessarily associated with system accounts. Preventing the reuse of identifiers implies preventing the assignment of previously used individual, group, role, service, or device identifiers to different individuals, groups, roles, services, or devices.
Organization-defined parameters
These values must be resolved through the organization’s tailoring and governance process. Bracketed parameter references in the control text identify where a decision is required.
From control text to operational evidence
Use Identifier Management as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to identity proofing, authentication strength, credential lifecycle, and trusted identity assertions.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- identity-proofing records
- authenticator issuance and revocation logs
- MFA and federation configuration
- credential inventory and rotation evidence
Common failure patterns
- strong authentication applied only to interactive users
- service credentials without ownership or rotation
- weak recovery paths that bypass MFA
- federated trust not reviewed after partner changes
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
- IA-04a.system identifiers are managed by receiving authorization from [Organization-defined: personnel or roles] to assign to an individual, group, role, or device identifier;
- IA-04b.system identifiers are managed by selecting an identifier that identifies an individual, group, role, service, or device;
- IA-04c.system identifiers are managed by assigning the identifier to the intended individual, group, role, service, or device;
- IA-04d.system identifiers are managed by preventing reuse of identifiers for [Organization-defined: time period].
Examine
- Identification and authentication policy
- procedures addressing identifier management
- procedures addressing account management
- system security plan
- system design documentation
- system configuration settings and associated documentation
- list of system accounts
- list of identifiers generated from physical access control devices
- other relevant documents or records
Interview
- Organizational personnel with identifier management responsibilities
- organizational personnel with information security responsibilities
- system/network administrators
- system developers
Test
- Mechanisms supporting and/or implementing identifier management
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Control enhancements
Enhancements add specificity, strength, or scope to the base control. Baseline badges show explicit selections in the official SP 800-53B OSCAL profiles.
IA-4(1) — Prohibit Account Identifiers as Public Identifiers
Prohibit the use of system account identifiers that are the same as public identifiers for individual accounts.
Official discussion
Prohibiting account identifiers as public identifiers applies to any publicly disclosed account identifier used for communication such as, electronic mail and instant messaging. Prohibiting the use of systems account identifiers that are the same as some public identifier, such as the individual identifier section of an electronic mail address, makes it more difficult for adversaries to guess user identifiers. Prohibiting account identifiers as public identifiers without the implementation of other supporting controls only complicates guessing of identifiers. Additional protections are required for authenticators and credentials to protect the account.
Assessment objectives and methods
the use of system account identifiers that are the same as public identifiers is prohibited for individual accounts.
Examine
- Identification and authentication policy
- system security plan
- procedures addressing identifier management
- procedures addressing account management
- system design documentation
- system configuration settings and associated documentation
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with identifier management responsibilities
- organizational personnel with information security responsibilities
- system/network administrators
Test
- Mechanisms supporting and/or implementing identifier management
Related controls
IA-4(2) — Supervisor Authorization
This enhancement is marked withdrawn in the official OSCAL catalog. Related-control metadata below may identify where its intent was incorporated.
IA-4(3) — Multiple Forms of Certification
This enhancement is marked withdrawn in the official OSCAL catalog. Related-control metadata below may identify where its intent was incorporated.
IA-4(4) — Identify User Status
Manage individual identifiers by uniquely identifying each individual as [Organization-defined: characteristics].
Official discussion
Characteristics that identify the status of individuals include contractors, foreign nationals, and non-organizational users. Identifying the status of individuals by these characteristics provides additional information about the people with whom organizational personnel are communicating. For example, it might be useful for a government employee to know that one of the individuals on an email message is a contractor.
Organization-defined parameters (1)
Assessment objectives and methods
individual identifiers are managed by uniquely identifying each individual as [Organization-defined: characteristics].
Examine
- Identification and authentication policy
- system security plan
- procedures addressing identifier management
- procedures addressing account management
- list of characteristics identifying individual status
- other relevant documents or records
Interview
- Organizational personnel with identifier management responsibilities
- organizational personnel with information security responsibilities
- system/network administrators
Test
- Mechanisms supporting and/or implementing identifier management
IA-4(5) — Dynamic Management
Manage individual identifiers dynamically in accordance with [Organization-defined: dynamic identifier policy].
Official discussion
In contrast to conventional approaches to identification that presume static accounts for preregistered users, many distributed systems establish identifiers at runtime for entities that were previously unknown. When identifiers are established at runtime for previously unknown entities, organizations can anticipate and provision for the dynamic establishment of identifiers. Pre-established trust relationships and mechanisms with appropriate authorities to validate credentials and related identifiers are essential.
Organization-defined parameters (1)
Assessment objectives and methods
individual identifiers are dynamically managed in accordance with [Organization-defined: dynamic identifier policy].
Examine
- Identification and authentication policy
- system security plan
- procedures addressing identifier management
- procedures addressing account management
- system design documentation
- system configuration settings and associated documentation
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with identifier management responsibilities
- organizational personnel with information security responsibilities
- system/network administrators
- system developers
Test
- Mechanisms supporting and/or implementing dynamic identifier management
Related controls
IA-4(6) — Cross-organization Management
Coordinate with the following external organizations for cross-organization management of identifiers: [Organization-defined: external organizations].
Official discussion
Cross-organization identifier management provides the capability to identify individuals, groups, roles, or devices when conducting cross-organization activities involving the processing, storage, or transmission of information.
Organization-defined parameters (1)
Assessment objectives and methods
cross-organization management of identifiers is coordinated with [Organization-defined: external organizations].
Examine
- Identification and authentication policy
- procedures addressing identifier management
- procedures addressing account management
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with identifier management responsibilities
- organizational personnel with information security responsibilities
Test
- Mechanisms supporting and/or implementing identifier management
Related controls
IA-4(7) — In-person Registration
This enhancement is marked withdrawn in the official OSCAL catalog. Related-control metadata below may identify where its intent was incorporated.
IA-4(8) — Pairwise Pseudonymous Identifiers
Generate pairwise pseudonymous identifiers.
Official discussion
A pairwise pseudonymous identifier is an opaque unguessable subscriber identifier generated by an identity provider for use at a specific individual relying party. Generating distinct pairwise pseudonymous identifiers with no identifying information about a subscriber discourages subscriber activity tracking and profiling beyond the operational requirements established by an organization. The pairwise pseudonymous identifiers are unique to each relying party except in situations where relying parties can show a demonstrable relationship justifying an operational need for correlation, or all parties consent to being correlated in such a manner.
Assessment objectives and methods
pairwise pseudonymous identifiers are generated.
Examine
- Identification and authentication policy
- system security plan
- procedures addressing identifier management
- procedures addressing account management
- system design documentation
- system configuration settings and associated documentation
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with identifier management responsibilities
- organizational personnel with information security responsibilities
Test
- Mechanisms supporting and/or implementing identifier management
Related controls
IA-4(9) — Attribute Maintenance and Protection
Maintain the attributes for each uniquely identified individual, device, or service in [Organization-defined: protected central storage].
Official discussion
For each of the entities covered in [IA-2](#ia-2), [IA-3](#ia-3), [IA-8](#ia-8) , and [IA-9](#ia-9) , it is important to maintain the attributes for each authenticated entity on an ongoing basis in a central (protected) store.
Organization-defined parameters (1)
Assessment objectives and methods
the attributes for each uniquely identified individual, device, or service are maintained in [Organization-defined: protected central storage].
Examine
- Identification and authentication policy
- system security plan
- procedures addressing identifier management
- procedures addressing account management
- system design documentation
- system configuration settings and associated documentation
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with identifier management responsibilities
- organizational personnel with information security responsibilities
Test
- Mechanisms supporting and/or implementing identifier management
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.