IA-3 Device identification and authentication guide

What IA-3 device identification and authentication asks for

An assessment is coming, and some devices on your network connect without a verified identity. IA-3 requires the system to uniquely identify and authenticate defined devices or device types before it establishes a local, remote or network connection. The control does not ask you to authenticate every endpoint in the abstract. It asks you to decide which devices or device types count, and then to make sure each one proves who it is before it is allowed to talk to something else.

The risk is simple. Hardware or endpoints that nobody has identified can join the network, receive traffic, and reach systems they were never meant to touch. This is hard for two reasons. Device inventories are usually incomplete, especially for printers, sensors, lab equipment, and laptops that were added outside the normal process. Many devices also cannot present credentials at all, because they lack a certificate store, an agent, or support for the protocols you would use to authenticate them. Those gaps are where an assessor will look first.

SP 800-53B selects IA-3 for the moderate and high baselines but not for the privacy baseline. Your first decision is therefore the impact level of the system, followed by the device scope. Start by asking which device types the assessor will treat as in scope, then compare that list against your asset inventory. Confirm with your assessor and your own risk documentation how the device types are defined, because the control leaves that definition to the organization. The output of this step is a written list that the rest of the work depends on.

Which devices fall under IA-3 device identification and authentication

IA-3 applies only to the devices the organization names, so the scope is set by a short list of decisions rather than by the control text alone. The cards below cover the device types, connection types, baseline choice and hosting environment that move the work up or down, and each one is a decision to make and record before evidence collection starts.

Name the device types explicitly

IA-3 requires the organization to define which devices or device types must be uniquely identified and authenticated, so the first decision is the list itself. Workstations and servers are usually in scope, while network equipment, kiosks, mobile devices and IoT or industrial devices often need separate treatment because they may lack native certificate support. Build the list from the asset inventory, group devices by type, and record the reason each group is included or excluded. An assessor will test whether the list matches what is connected.

Map which connections trigger the control

The control covers devices before they establish a local, remote or network connection, so each connection type needs its own answer. Local connections include console or physical port access, remote connections include VPN and remote administration, and network connections include switch port and wired or wireless network attachment. Document which connection paths each device type uses. Missing one path, such as an out-of-band management interface, is a common gap an assessor finds during interviews.

Baseline selection changes the work

SP 800-53B selects IA-3 for the moderate and high baselines but not for the low or privacy baselines, so the system's impact level determines whether the control is in scope at all. None of the three current enhancements are selected in any baseline, which means the base control carries the requirement unless the organization tailors in more. Confirm the baseline in the system security plan before buying tooling, and record any tailoring decision with its rationale.

Enhancements raise the bar if adopted

The three current enhancements cover cryptographic bidirectional authentication, dynamic address allocation and device attestation, and none is selected by a standard baseline. Adopting one, for example to require mutual certificate authentication for industrial controllers, adds issuance, rotation and revocation work for each device class. Decide whether these enhancements are needed for the risk, and if so, budget for the certificate authority and address management changes they require. Ask the assessor early whether a tailored enhancement will be tested.

Cloud, data center and air-gapped differ

In cloud environments, device identity is often tied to managed instances, virtual machines and workload identities, which can be issued and rotated automatically, though the organization still needs to define the device types. In on-premises data centers, the work usually involves certificate authorities, network access control and physical inventory. In air-gapped networks, no external identity service is available, so the organization must run its own certificate authority and manual issuance procedures, which typically increases effort for both build and evidence.

Ask for a scoped device list in writing

Before any quote or implementation starts, ask for a written scope that names each device type, connection path, baseline and hosting environment in scope. Confirm which items the implementation partner will configure, which the organization will operate, and which the independent assessor will test. A fixed scope with named device groups makes both cost and evidence predictable. Ask whether changes to the device list after work starts are priced as change requests.

How an assessor tests IA-3 device identification and authentication

This table maps the single SP 800-53A determination statement for IA-3 to the examine, interview and test methods an assessor uses, the objects each one touches and the evidence to prepare. Read each row as a request the assessor is likely to make, and use the findings column to check your device inventory and connection controls before fieldwork begins.

Assessment method	What the assessor looks at	Evidence to prepare	Common findings
Examine	The list of devices requiring unique identification and authentication, and the device connection reports that show what actually connected	A current, complete device inventory with the device types in scope, plus connection logs covering the review period	The device list omits devices or device types that were defined as in scope
Interview	Personnel with operational responsibility for device identification and authentication, and system and network administrators	Named owners for device onboarding, certificate or credential issuance and exception handling, with a description of how each step works	Administrators describe a process that differs from the written procedure or cannot name who approves exceptions
Test	The mechanisms that support and implement device identification and authentication before a local, remote or network connection is made	Configuration exports and test results showing that unregistered or unauthenticated devices are refused at the network or access layer	Devices are allowed to connect without authentication, or a fallback path bypasses the mechanism during testing
Defined device scope	Whether the organization has defined which devices or device types require identification and authentication	A written definition of the device types in scope and the reason each is included or excluded	Scope is undefined, so the assessor cannot confirm that the list is complete
Connection timing	Whether identification and authentication happen before a connection is established, not after	Sequence documentation or captured handshake records showing the check occurs at connection time	Authentication happens only at a later session stage, after the device has already reached network resources
Exceptions and variance	Any devices exempted from the mechanism and the approvals behind each exemption	A dated exception register with owner, compensating controls and review dates	Exceptions exist with no approval or review record
Enhancements in scope	Whether the organization has chosen to implement any of the three current IA-3 enhancements beyond the base requirement	Documented decision on each enhancement, with supporting configuration where one is claimed	Enhancements are claimed as implemented without matching configuration or test evidence

How to implement IA-3 in the order an assessor expects

This sequence moves from defining which devices and connection paths are in scope, through inventory, identity source and enforcement, to documented procedures and recurring logs. Each step produces an artifact an assessor can sample against IA-3 and its assessment objects.

Define device types and connection paths in scope
Start by naming the device types the system must identify and authenticate, such as workstations, servers, network devices, IoT sensors or virtual machines, and listing each connection path they use: local, remote and network. Assign the work to the system owner with input from network and endpoint administrators, because IA-3 applies to defined devices, so the definition sets the boundary for everything that follows. The step is complete when the scope statement names each device type, each connection path and the system boundary it falls within, and the security team has approved it. Output: an approved device scope statement that maps device types to connection paths.
Build and maintain the device inventory
Create a device inventory that lists every device in each defined type, with a unique identifier, owner, location, function and the connection paths it uses. Pull the initial population from network discovery, directory records, hypervisor and cloud inventories and endpoint management tools, then reconcile the sources so no device appears in one list and not another. Assessors typically ask for a list of devices requiring unique identification and authentication, so the inventory must be exportable and dated. Confirm with your own tools how each source records device identity, since that determines what counts as a unique identifier. Output: a versioned device inventory with a named owner and a documented update process.
Choose identity source and credential method per device type
For each device type, select how the device proves its identity: for example, directory-joined computer accounts, client certificates issued by an internal certificate authority, or pre-shared keys where certificates are not practical. FreeIPA includes an integrated certificate authority based on Dogtag, and OpenBao's PKI secrets engine can issue dynamic X.509 certificates, so confirm with each vendor whether either fits your device population and lifecycle. Record the chosen method, the issuing authority and how credentials are revoked when a device is retired. Output: a device authentication decision record that lists, for each device type, the identity source, credential type and revocation path.
Configure enforcement at each connection point
Configure each connection point so that a device must present its credential before a local, remote or network session is established. Typical enforcement points include network access control, VPN and wireless gateways, firewall rules that permit only authenticated device identities, and directory or certificate checks at server logon. OPNsense is a stateful packet filter whose rules use source, destination, port and protocol with aliases for groups, so it can restrict traffic by address, but address-based rules alone do not prove device identity, so pair them with credential checks where the platform supports it. Test each point with an authorized device and an unauthorized one, and keep the test results. Output: enforcement configuration exports and test records for every connection point in scope.
Document authentication procedures and assign owners
Write the procedures that operate device authentication: how devices are enrolled, how credentials are issued and renewed, how devices are removed, how exceptions are approved and who reviews denied connections. Assign a named owner for each procedure and a backup, and link each procedure to the device types and connection points it governs. The procedures must match what the configuration actually does, so have the operators walk through them against the live environment. Output: an approved device authentication procedure set with a responsibility matrix and a version history.
Collect connection and denial logs as recurring evidence
Set up logging at each enforcement point so that successful device connections and denied attempts are recorded with device identifier, time, connection path and result. OPNsense can log each rule match for review in its live log view, which supports denial evidence for firewall-enforced paths, but confirm the log retention and export options for your deployment. Schedule a recurring review in which the owner samples logs against the device inventory, investigates unknown identifiers and records the outcome. Assessors commonly test this with interviews of administrators, so keep the review records alongside the logs. Output: a log collection configuration, a recurring review schedule and dated review records that reconcile logs to the inventory.

How the IA-3 enhancements change the work

The three current IA-3 enhancements are not part of any SP 800-53B baseline in Release 5.2.0, so an organization with a moderate or high system must meet the base IA-3 requirement and nothing more unless it adopts an enhancement by choice or a contract or authorizing official requires it. The base control is the baseline obligation; the enhancements are a decision to justify in the system security plan. Release 5.2.0 also withdrew IA-3(2), so the numbering you will see in older material may not match the current catalog. Confirm the current enhancement titles in the CPRT entry for IA-03 before you write them into a plan.

The first enhancement concerns cryptographic bidirectional authentication, which requires the device and the system to authenticate each other before a connection is established, not only the device to the system. If you adopt it, the work moves into certificate and key management: you need a device trust chain, a process for issuing and revoking device certificates, and a way to show that the check runs before each connection. The second concerns dynamic address allocation, where device addresses assigned through DHCP must be tied to the device's identity and lease terms defined in the enhancement. Adopting it means reviewing DHCP logs and lease records alongside your device inventory. The third concerns device attestation, which requires verifying device properties, such as configuration or integrity state, before a connection. It adds hardware or software attestation evidence that your assessor must be able to examine.

Before adopting any enhancement, ask your authorizing official or contract owner whether they expect it, and ask your assessor how they will test it. Record the decision, the reason, and the planned evidence in the system security plan, and decide whether the enhancement belongs in your device onboarding process or in a separate project with its own cost and schedule. A self-hosted certificate authority such as the one in FreeIPA can support bidirectional authentication, but you must confirm which device certificate and attestation capabilities your chosen platform provides before you commit to them in writing.

Which evidence passes an IA-3 assessment

An assessor testing IA-3 looks for two things: a defined, current list of the devices that must be uniquely identified and authenticated, and proof that the system enforces that identification at every connection point. The cards below cover the artifacts that show both, and how to keep each one current between assessments.

Authoritative list of devices

This is the defined set of devices or device types that IA-3 requires the system to identify and authenticate, and it is the first thing an assessor will ask for. Keep it as a controlled document or inventory export with an owner, a version and a change history. Between audits, reconcile it against the asset inventory on a fixed schedule and record every addition and removal. Check that it covers devices that connect remotely and over the network, not only those on the corporate LAN.

Device certificate and credential issuance records

Issuance records show how each defined device received its unique identity, such as a certificate, key pair or enrollment credential. Log the device identifier, the issuing authority, the issue and expiry dates, and the approver. An internal certificate authority, such as the one included with FreeIPA, or a secrets engine that issues short-lived X.509 certificates, such as OpenBao's PKI engine, can produce these records automatically. Confirm that issuance logs are retained and exportable for the assessment period.

Configuration exports at each connection point

An assessor needs to see that the system actually requires device authentication before a connection is established. Export the relevant settings from each enforcement point, including VPN concentrators, network access controls, 802.1X or certificate-based authentication on wireless and wired networks, and gateway or load balancer client certificate requirements. Store exports with timestamps and hashes, and rerun them after every significant change. Confirm that each defined device type is covered by at least one enforcement point.

Connection and denial logs

Logs of successful and failed device connections show the control operating over time, and denied attempts show that unidentified devices were actually refused. Forward these logs to a central store and retain them according to your audit policy. Review a sample on a recurring basis and document the review. Ask your auditor which time window and sample size they expect before collecting them, since the choice affects how much history you need to keep.

Device connection reports for examine

The SP 800-53A examine method for IA-3 names device connection reports as an assessment object, so assessors will expect reports generated directly from the system rather than hand-built summaries. Schedule the report to run at a fixed interval, such as monthly, and store each output with its generation date and the query used. Compare the report against the authoritative device list to find devices that connected without a matching identity or devices on the list that never appear.

Procedures naming the list maintainer

Assessors interview the people who run the device identification process, so the procedures must name who maintains the device list, who approves issuance and who handles revocation when a device is retired or lost. Document the handoff steps, the review frequency and the escalation path. Test the procedure during the interview period by asking the named owner to walk through a recent change. Confirm that the roles match the current staff and that the document is reviewed on a set cycle.

What meeting IA-3 costs in money and effort

This table compares the main cost components of meeting IA-3 Device identification and authentication, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to shape your quote request, since no dollar figures or durations are supplied for this control.

Cost component	One-time or recurring, and who is paid	What drives it up or down	How to keep it down
Tooling or licenses	Recurring for commercial device identity or certificate products, paid to the vendor. Open-source options carry no license fee but still need hosting and operator time.	Number of device types, whether an existing directory or PKI can be extended, and vendor licensing based on device count	Check whether your current directory and certificate authority already support device identities before buying new products. Ask quotes to price per device and per year separately.
Device inventory and discovery	One-time for the first full inventory, then recurring as devices are added. Paid mostly to your own IT staff, sometimes to an implementation partner.	Number of device types, spread across sites, cloud accounts and OT segments, and how much inventory data already exists	Start from the connection paths that are already logged. Scope the defined device list to the devices that actually need unique identification, as IA-3 requires.
Engineering time to configure enforcement	One-time, paid to internal engineers or a partner under a fixed-scope agreement	Number of connection paths (wired, wireless, VPN, remote management, service-to-network), and whether devices support certificate-based authentication	Group devices by authentication method so one pattern covers many devices. Ask for the work broken into connection paths in the quote.
Certificate and identity lifecycle work	One-time setup, then recurring for issuance, renewal and revocation. Paid to staff or a managed service.	Whether certificate issuance is automated or manual, and how many devices need renewal cycles	Automate issuance and renewal where devices allow it. Open-source certificate authorities such as those in FreeIPA or OpenBao's PKI secrets engine can remove license spend, but they still need operators.
Evidence upkeep	Recurring, paid to the control owner and audit support staff	How often device lists change, whether connection logs are retained centrally, and how many systems must show evidence	Generate device lists and connection reports automatically from source systems, so evidence updates without manual rework.
External testing or review	Recurring or per engagement, paid to a security testing provider or assessor	Scope of device types tested, whether testing covers rogue device connection attempts, and frequency	Ask whether test scope can reuse the device inventory and enforcement settings already documented.
Auditor sampling time	Recurring per assessment cycle, paid to the independent assessor	Number of device types and connection paths the assessor samples, and how well evidence is organized	Prepare the list of defined devices, sample connection records and configuration exports before fieldwork so sampling takes less time. Confirm the assessor's fee basis in writing.

Which open-source tools support IA-3 evidence

IA-3 is satisfied by the mechanisms that identify and authenticate devices before they connect, and by the records that show those checks ran. The tools below cover different parts of that picture: certificate issuance for device credentials, and connection logging at the network boundary. None of them decides on its own whether your organization meets the control, and each needs to be confirmed against your own environment and licensing.

FreeIPA certificate authority

FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag for issuing and managing certificates. For IA-3, it can back device credentials so that each enrolled device presents a certificate tied to a known identity. Check that your device classes can enroll, that certificate records and revocations are retained, and that the device list you define under IA-3 matches what the CA actually issues to.

OpenBao PKI secrets engine

OpenBao (MPL-2.0) has a PKI secrets engine that issues dynamic X.509 certificates, so services and devices receive certificates without someone generating a key and certificate signing request by hand. For IA-3, the value is repeatable issuance with an audit trail of who or what requested each certificate. Confirm the license terms that apply to your use, and check how certificates are renewed and revoked when a device is retired.

OPNsense connection rules and logs

OPNsense (BSD-2-Clause) is a stateful packet filter. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses for policy. For IA-3, rules that admit only defined device addresses on defined ports support the connection side of the control, and per-rule logging gives reviewers records of matches. It does not authenticate the device itself, so pair it with a credential mechanism and confirm your address allocation approach.

Coraza is not IA-3 evidence

Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects HTTP traffic for attacks such as SQL injection and cross-site scripting. It does not identify or authenticate devices, so do not cite it as IA-3 evidence. It may still belong in your boundary protection and input validation evidence under other controls, which an assessor will test separately.

Who does what for IA-3: your team, a partner and the auditor

Your organization owns IA-3 in the sense that matters to an assessor: the decisions about which devices are in scope, how they are identified and authenticated, and which risks are accepted. These decisions belong to accountable staff, usually in security, IT operations or the system owner's office, and they must be documented before any technical work starts. A partner can build what you decide, but it cannot make those decisions on your behalf.

Device scope decision: Define which device types require unique identification and authentication before connection, and record why others are excluded.
Device inventory: Maintain the list of devices requiring unique identification and authentication, since this is the first examine object an assessor will request.
Policy and procedures: Approve the identification and authentication policy and the operating procedures that cover enrollment, certificate issuance, revocation and exceptions.
Risk acceptance: Decide, in writing, which of the three current IA-3 enhancements you will not adopt and why, with named approval.
Ongoing ownership: Assign a person to review device connection reports and revise scope when the environment changes.

Confirm the scope decision and each risk acceptance are signed by someone with authority over the system before the assessment begins.

Questions buyers ask about IA-3 device identification and authentication

How much effort does IA-3 take compared with other IA controls?

IA-3 is one of the lighter identification and authentication controls to scope, because it has a single determination statement in SP 800-53A Rev. 5 and no enhancement is selected in any SP 800-53B baseline. The effort is concentrated in building a complete list of devices that need unique identification and authentication, then proving that each device class is configured to authenticate before it connects. Controls such as IA-2, IA-4 and IA-5 usually demand more work because they touch every user account, identifier and authenticator lifecycle. Effort rises for IA-3 when the device population is large, mixed or poorly inventoried, such as industrial equipment, lab instruments or shadow IT. Ask any partner to estimate effort from your device inventory, not from the control count.

Can we implement IA-3 in-house without an outside partner?

Yes, an organization can implement IA-3 in-house if it has staff who understand device identity, certificates and network access, and the capacity to document the result. The organization owns the control, so internal teams can select mechanisms, define which devices are covered and produce the evidence. An outside partner is most useful when the environment spans many device types, when existing networks lack a device registry, or when the team needs help building an identity platform to issue device credentials. Whichever path you choose, an independent assessor still tests the control. Only an independent auditor or assessor issues assessment results, so internal or partner work is never the final word on compliance.

What does IA-3 require from our staff?

IA-3 needs a small group of people with clear roles, mainly the owners of the device inventory, the network administrators who control connections, and the directory or certificate administrators who manage device identities. SP 800-53A names personnel with operational responsibility for device identification and authentication and system and network administrators as interview subjects, and it lists device connection reports and lists of devices requiring unique identification as examine objects. Inventory owners must keep the device list current. Network administrators must show how devices are blocked or allowed based on authentication. Directory and certificate administrators must explain how identities are issued, renewed and revoked. Plan for these people to be available during the assessment interviews as well as during implementation.

How long does an IA-3 implementation take?

The duration depends mainly on how many device types are in scope, how complete the existing inventory is, and whether devices can accept certificates or other unique credentials without replacement. Other drivers include the number of network segments that enforce authentication, change windows for production equipment, and whether an identity platform must be built first. NIST does not set implementation timelines for SP 800-53, and no supplied figure gives a duration for IA-3, so any number you hear should be treated as a guess. The reliable route is a fixed-scope written plan that lists the device classes, the systems involved, the deliverables and the dates agreed before work starts. Ask for that plan with each deliverable and assumption spelled out.

Are the three IA-3 enhancements required at the moderate or high baseline?

No. SP 800-53B Release 5.2.0 selects IA-3 for the moderate and high baselines, but it selects none of the three current enhancements at the low, moderate, high or privacy baselines. IA-3(2) is withdrawn, so only IA-3(1), IA-3(3) and IA-3(4) remain as current enhancements in the catalog. The enhancements cover cryptographic bidirectional authentication, dynamic address allocation and device attestation. Your organization may still choose to adopt one because of its risk assessment, a contract or a system-specific requirement, and tailoring can add controls. Confirm the exact baseline selection and any tailoring decisions against the OSCAL baseline profiles and your authorizing official's requirements.

Can a partner issue an IA-3 certification or attestation for us?

No. A partner can prepare systems, device inventories, configurations and evidence for IA-3, but it cannot issue an audit report, attestation or certification. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports or certifications. Only an independent auditor, assessor or certification body can test the control and issue a result, and the organization remains responsible for its own controls. When you evaluate a partner, ask for a written scope that separates implementation work from assessment, and confirm which assessor will review the evidence and under which program the result is recognized.

How DeployOpen scopes and prepares IA-3 evidence

DeployOpen works on IA-3 as a scoped implementation task inside your own infrastructure. We identify which devices and device types need unique identification and authentication, prepare the mechanisms and records that show it, and hand over the evidence so your organization and its independent assessor can test it. DeployOpen does not issue assessment results or certifications.

How we scope

Agree in writing which device types, network segments and connection paths fall under IA-3 before work starts.
Confirm which SP 800-53B baseline your system is on, since IA-3 applies at moderate and high but not at low or privacy.
Record the owners who decide device identity rules and the assessment objects your assessor will request.

How we build

Configure device identity mechanisms on your platforms, such as certificate-based identity issued from a self-hosted certificate authority.
Connect device connection logs and inventory exports so each device's identification and authentication can be shown.
Test that unidentified or unapproved devices are refused before local, remote or network connections are established.

How we hand over

Deliver the device inventory, configuration records, test results and runbooks mapped to the IA-3 determination statement and assessment methods.
Document open items and the gaps still owned by your organization in a written handover.
Provide your assessor with the artifacts they need, while your organization retains ownership of the control and its results.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing for device identity platforms are available as a retainer.
Quotes follow from the written scope, so ask for a breakdown of build, testing, documentation and handover effort.

IA-3 Device identification and authentication