Control statement
Uniquely identify and authenticate [Organization-defined: devices and/or types of devices] before establishing a [Organization-defined: ia-03_odp.02] connection.
Discussion
Devices that require unique device-to-device identification and authentication are defined by type, device, or a combination of type and device. Organization-defined device types include devices that are not owned by the organization. Systems use shared known information (e.g., Media Access Control [MAC], Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for device identification or organizational authentication solutions (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.1x and Extensible Authentication Protocol [EAP], RADIUS server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and wide area networks. Organizations determine the required strength of authentication mechanisms based on the security categories of systems and mission or business requirements. Because of the challenges of implementing device authentication on a large scale, organizations can restrict the application of the control to a limited number/type of devices based on mission or business needs.
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 Device Identification and Authentication 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
[Organization-defined: devices and/or types of devices] are uniquely identified and authenticated before establishing a [Organization-defined: ia-03_odp.02] connection.
Examine
- Identification and authentication policy
- system security plan
- procedures addressing device identification and authentication
- system design documentation
- list of devices requiring unique identification and authentication
- device connection reports
- system configuration settings and associated documentation
- other relevant documents or records
Interview
- Organizational personnel with operational responsibilities for device identification and authentication
- organizational personnel with information security responsibilities
- system/network administrators
- system developers
Test
- Mechanisms supporting and/or implementing device identification and authentication capabilities
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-3(1) — Cryptographic Bidirectional Authentication
Authenticate [Organization-defined: devices and/or types of devices] before establishing [Organization-defined: ia-03.01_odp.02] connection using bidirectional authentication that is cryptographically based.
Official discussion
A local connection is a connection with a device that communicates without the use of a network. A network connection is a connection with a device that communicates through a network. A remote connection is a connection with a device that communicates through an external network. Bidirectional authentication provides stronger protection to validate the identity of other devices for connections that are of greater risk.
Organization-defined parameters (2)
Assessment objectives and methods
[Organization-defined: devices and/or types of devices] are authenticated before establishing [Organization-defined: ia-03.01_odp.02] connection using bidirectional authentication that is cryptographically based.
Examine
- Identification and authentication policy
- system security plan
- procedures addressing device identification and authentication
- system design documentation
- list of devices requiring unique identification and authentication
- device connection reports
- system configuration settings and associated documentation
- other relevant documents or records
Interview
- Organizational personnel with operational responsibilities for device identification and authentication
- organizational personnel with information security responsibilities
- system/network administrators
- system developers
Test
- Mechanisms supporting and/or implementing device authentication capability
- cryptographically based bidirectional authentication mechanisms
Related controls
IA-3(2) — Cryptographic Bidirectional Network Authentication
This enhancement is marked withdrawn in the official OSCAL catalog. Related-control metadata below may identify where its intent was incorporated.
IA-3(3) — Dynamic Address Allocation
- (a)Where addresses are allocated dynamically, standardize dynamic address allocation lease information and the lease duration assigned to devices in accordance with [Organization-defined: organization-defined lease information and lease duration] ; and
- (b)Audit lease information when assigned to a device.
Official discussion
The Dynamic Host Configuration Protocol (DHCP) is an example of a means by which clients can dynamically receive network address assignments.
Organization-defined parameters (3)
Assessment objectives and methods
- IA-03(03)(a)
- IA-03(03)(a)[01]dynamic address allocation lease information assigned to devices where addresses are allocated dynamically are standardized in accordance with [Organization-defined: lease information];
- IA-03(03)(a)[02]dynamic address allocation lease duration assigned to devices where addresses are allocated dynamically are standardized in accordance with [Organization-defined: lease duration];
- IA-03(03)(b)lease information is audited when assigned to a device.
Examine
- Identification and authentication policy
- system security plan
- procedures addressing device identification and authentication
- system design documentation
- system configuration settings and associated documentation
- evidence of lease information and lease duration assigned to devices
- device connection reports
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with operational responsibilities for device identification and authentication
- organizational personnel with information security responsibilities
- system/network administrators
- system developers
Test
- Mechanisms supporting and/or implementing device identification and authentication capabilities
- mechanisms supporting and/or implementing dynamic address allocation
- mechanisms supporting and/or implanting auditing of lease information
Related controls
IA-3(4) — Device Attestation
Handle device identification and authentication based on attestation by [Organization-defined: configuration management process].
Official discussion
Device attestation refers to the identification and authentication of a device based on its configuration and known operating state. Device attestation can be determined via a cryptographic hash of the device. If device attestation is the means of identification and authentication, then it is important that patches and updates to the device are handled via a configuration management process such that the patches and updates are done securely and do not disrupt identification and authentication to other devices.
Organization-defined parameters (1)
Assessment objectives and methods
device identification and authentication are handled based on attestation by [Organization-defined: configuration management process].
Examine
- Identification and authentication policy
- system security plan
- procedures addressing device identification and authentication
- procedures addressing device configuration management
- system design documentation
- system configuration settings and associated documentation
- configuration management records
- change control records
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with operational responsibilities for device identification and authentication
- organizational personnel with information security responsibilities
- system/network administrators
Test
- Mechanisms supporting and/or implementing device identification and authentication capabilities
- mechanisms supporting and/or implementing configuration management
- cryptographic mechanisms supporting device attestation
Related controls
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.