What 03.05.02 device identification and authentication asks for
03.05.02 requires that you uniquely identify and authenticate the devices, or types of devices, you define before a device can establish a connection to a system that handles CUI. The requirement is about the device itself, not the person using it, so a laptop, server, printer or sensor must prove what it is before the network accepts it. Under NIST's tailoring it is the Rev. 3 counterpart of Rev. 2 requirement 3.5.2, and NIST's change analysis classifies the change as minor. The practical effect is that an assessor will still expect the same outcome you would have demonstrated under Rev. 2: every device class that can reach CUI has a verified identity before it connects. The hardest decision sits with you, not with NIST. The organization-defined parameter names the devices or device types that must be uniquely identified and authenticated, and NIST does not assign that value. If your contract or agreement does not specify it, you must define it, and the assessor will check that the definition exists and covers what actually connects to the CUI boundary. Start by listing device classes such as managed endpoints, servers, network equipment, mobile devices, and any devices that reach the enclave through VPN or wireless access, then record which ones are in scope and why. A vague definition like "all devices" is hard to test, while a precise one gives you a checklist to audit against.
This is where most organizations struggle. Many do not have a device inventory that is complete enough to support the requirement, because devices are added by different teams, through cloud consoles, or by vendors during maintenance. Bring-your-own-device use and Internet of Things equipment, such as cameras, badge readers and building controls on the same network segment, often sit outside the inventory entirely. Confirm with your assessor, in writing, how they expect the device list to be produced and maintained, and confirm which environments the list must cover. Then test the gap: pick a network segment that touches CUI, compare what is connected with what is recorded, and treat any unidentified device as a finding to resolve before the assessment. Why this matters for scoring is specific to CMMC Level 2, which still uses Rev. 2 and assesses 3.5.2 as IA.L2-3.5.2. Under 32 CFR 170.24 that practice carries 5 points, and 32 CFR 170.21 does not allow it on a plan of action and milestones for Conditional status, so an unresolved device identification gap can block a conditional outcome. Check the current status of the DoD contract requirements with your contracting officer before you plan, because the applicable revision for your contract may differ from the Rev. 3 text you are reading.
Which devices and connections fall under 03.05.02
03.05.02 applies to whatever the organization defines as a device or device type that must be uniquely identified and authenticated before it connects. The defined list is the organization's own ODP value, so each decision below changes the work an assessor will examine.
Managed endpoints and servers
Company-owned laptops, workstations and servers are usually the first devices an organization defines because they hold CUI directly. Decide whether every managed endpoint is in scope or only those that reach CUI systems, and record the identity each one presents, such as a certificate issued at enrollment or a domain computer account. Check that the device inventory matches the list in your ODP value, because assessors compare the two.
Network infrastructure devices
Switches, routers, firewalls and wireless access points control whether other devices can reach the CUI enclave. Decide whether administrative connections to these devices are authenticated as devices, and whether ports that accept new hardware require device authentication before a connection is established. Confirm the method, such as IEEE 802.1X with EAP, and document which infrastructure devices are named in the ODP value.
IoT and operational devices
Printers, cameras, badge readers, sensors and industrial controllers often cannot run an agent or accept a user login. Decide whether they are defined as a device type, which devices of that type are in scope, and how each one proves its identity, for example with a certificate or a MAC-based allowlist that is itself controlled. Record the exceptions and the compensating controls, since the assessor will ask why a listed device type was not authenticated.
Personal devices reaching CUI systems
Bring-your-own-device access is the scoping decision most often left undefined. If personal phones or laptops may reach CUI systems, the ODP value must say so, and device authentication must cover them, usually through enrollment in a mobile device management or certificate process. If personal devices are excluded, the access controls must block them, and the decision should appear in the system security plan.
Cloud workloads and service identities
Virtual machines, containers and automated jobs authenticate to other systems without a person present. Decide which workload types are devices for this requirement, how each receives its identity, and how that identity is revoked when the workload is retired. Short-lived certificates issued by an internal certificate authority are one approach to evaluate. Confirm with your assessor whether service accounts are handled under 03.05.01 or 03.05.02.
Devices of external service providers
Vendor laptops, managed service provider jump hosts and maintenance equipment can connect to CUI systems even though the organization does not own them. Decide whether these devices are in the ODP value, and whether the connection requires device authentication before access is granted. The contract should require the provider to identify its devices, and the organization should keep a current list of them for the assessor.
How an assessor tests device identification and authentication
This table maps how SP 800-171A Rev. 3 tests 03.05.02, step by step, against the objects an assessor examines, interviews and tests. Read each row as a question the assessor will ask and the evidence you should have ready before the assessment begins. The main takeaway is that the defined device list and the ODP value carry much of the weight, so an assessor will check that they exist and match what the system actually does.
| Test step | What the assessor examines or interviews | Evidence requested | Common findings |
|---|---|---|---|
| Determination statement 1: devices or device types are uniquely identified and authenticated before a connection is established | Examines the identification and authentication policy and procedures, and the procedures for device identification and authentication | Written procedure showing how each listed device type gets a unique identity and is checked before it connects | Procedures describe user accounts only, with no device steps |
| Determination statement 2: the authentication happens before the system connection is established | Examines system design documentation to confirm where device checks sit in the connection flow | Architecture diagrams and network access rules showing the device check occurs before access is granted | Devices are checked after a session opens, or shared service accounts bypass the check |
| ODP check: the devices or device types to be identified are defined | Examines the list of devices requiring unique identification and authentication, and the organization's assigned ODP value | Signed device list or device-type definition, with a version date and owner | ODP left blank, or the list covers only servers and omits laptops, phones or IoT devices |
| Examine method across the test | Reviews the device list against the design documentation to confirm the scope matches | Reconciled inventory extract showing each listed device or type and its identity method | Inventory is out of date and does not match the systems in production |
| Interview method: responsibilities for device identification | Interviews personnel responsible for device identification and authentication | Named owners, responsibilities in writing, and a short walk-through of how a new device is onboarded | Staff cannot describe how a device is enrolled or who approves it |
| Interview method: information security responsibilities | Interviews personnel with information security responsibilities about exceptions and reviews | Exception records, review minutes, and the escalation path for unrecognized devices | Security staff are unaware that a device list exists or who maintains it |
| Test method: mechanisms that implement device identification | Tests the mechanisms that support device identification, such as certificate issuance, 802.1X or RADIUS, or Kerberos | Configuration exports, a live demonstration of a rejected unknown device, and a certificate or credential issuance log | Mechanism is configured but not enforced, or unknown devices can still reach the network |
| Test method: revocation and removal of device credentials | Tests how device credentials are revoked when a device is retired or lost | Revocation records and a test showing a revoked device is refused | Revoked certificates remain trusted because revocation checking is not configured |
Order of work to identify devices before they connect
This sequence turns the 03.05.02 requirement into a working admission process: the organization decides which devices must be identified, gives each one a credential it can prove, and enforces that check before a device reaches CUI. Each step produces a record an assessor can examine, interview against and test.
Define device types and document the ODP value
The organization decides which devices or device types must be uniquely identified and authenticated before they establish a connection to the system, and records that decision as the value of the organization-defined parameter for 03.05.02. Typical scope includes workstations, servers, network appliances, printers, mobile devices and remote endpoints, but the list must reflect the system's own boundary. The security office, system owner and IT operations sign off on the record. The step is complete when a dated, approved ODP statement exists and matches the system security plan. Confirm with your assessor how they expect the value to be expressed.
Build and reconcile the device inventory
Operations staff build a list of every device in each defined type, drawing on directory records, network discovery, endpoint management and asset tables. They then reconcile the list against the network: any device seen on the network but missing from the inventory is investigated, and any inventory entry with no network presence is confirmed as retired or out of scope. The inventory becomes the list of devices requiring unique identification and authentication that an assessor will examine. It is complete when the reconciliation exceptions are closed and the owner of the list has signed it.
Choose the device authentication mechanism
The architecture team selects how each device type proves its identity. NIST's discussion of 03.05.02 gives IEEE 802.1X with EAP, RADIUS with EAP-TLS and Kerberos as examples of device authentication solutions, and notes that PKI with certificate revocation checking can be part of the approach. The choice depends on the device types, the directory in use and whether the devices are on-premises or remote. The design document should show the authentication path for each device type and the systems involved. It is complete when the design is reviewed and recorded in the system design documentation.
Issue device credentials with revocation checking
Engineers provision a unique credential for each device, usually a certificate or a Kerberos machine account, from an issuing authority the organization controls. Open-source options include the integrated certificate authority in FreeIPA and the PKI secrets engine in OpenBao, which issues X.509 certificates on request. Private keys stay on the device or in a protected store, and the process records which device received which credential. Revocation checking is configured so that a lost or retired device's credential stops working. The step is complete when a sample of devices authenticates successfully and a revoked test credential is refused.
Enforce the admission rule and log admissions
Network engineers configure the access point, switch or boundary device to require device authentication before granting network access, so an unauthenticated device stays on a quarantine or blocked segment. Firewall rules in platforms such as OPNsense can restrict what admitted devices may reach, and aliases keep device groups manageable. Each admission and refusal should be logged and retained so that reviewers can see which devices connected and when. The step is complete when the enforcement rule is in production and the admission logs show both accepted and refused events.
Document procedures and test refusal of unidentified devices
Staff write the device identification and authentication procedures, covering enrollment, credential renewal, revocation, exceptions and the steps for handling an unknown device. Personnel with these responsibilities should be able to explain the procedure in an interview. The team then runs a test with an unregistered device, a device with a revoked credential and a device with an expired one, and records that each is refused and logged. The results, the procedures and the approved ODP record form the evidence package that the assessor will examine and test.
Self-hosted open-source tools that produce device identity evidence
Device identification under 03.05.02 is proven with records: which devices are defined, how each one is authenticated before connecting, and how network access is granted or denied. The three tools below can each produce part of that record, but none of them decides which devices must be identified or whether your configuration meets the requirement. The organization owns that decision, and an assessor tests the result.
Device certificates from FreeIPA
FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates, and it is licensed under GPL-3.0-or-later. Where devices are enrolled and issued certificates, the issuance and revocation records can serve as evidence of how each defined device is identified. Confirm which device types your fleet includes, whether every one can present a certificate, and whether revocation checking is enabled, because the Rev. 3 discussion notes that PKI with revocation checking can be part of device authentication.
Dynamic X.509 certificates from OpenBao
OpenBao (MPL-2.0) has a PKI secrets engine that issues dynamic X.509 certificates, so services and devices can obtain certificates without generating a key and certificate signing request by hand. Its issuance logs and role definitions show which identities may receive certificates and under what constraints. Confirm that device enrollment, not only service enrollment, is covered, and that the certificate lifetimes and renewal process match the device authentication procedure your organization documents.
Network access rules from OPNsense
OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group the approved device addresses, and per-rule logging records matches for review in the live log view. This gives you a record of which defined devices were allowed to reach the system. Confirm that your network access method, such as IEEE 802.1X with EAP, RADIUS with EAP-TLS or Kerberos, is supported in your environment, because a packet filter enforces addresses and ports but does not perform device authentication on its own.
Coraza is not device evidence
Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and it integrates with Caddy, HAProxy, Traefik and Nginx. It inspects web requests for attacks such as SQL injection and cross-site scripting. It does not identify or authenticate devices, so its logs should not be cited as evidence for 03.05.02. Keep it in your architecture for application protection and cite other records for device identity.
Evidence that passes 03.05.02 and how to keep it current
An assessor testing 03.05.02 looks for three things: a defined list of devices, a documented way of identifying and authenticating them, and records showing the rule works in practice. The cards below cover the artifacts that usually carry that proof, how often each should be refreshed between formal assessments, and who in the organization should own it.
Approved ODP device list
This is the list of devices or device types that must be uniquely identified and authenticated before they connect, and it is the organization-defined parameter the requirement depends on. Record each device type, its owner, its identifier method and the date it was approved. Check that the list matches what the network and certificate systems actually admit, since a list that omits a device class leaves that class outside the requirement. Refresh it on every change to the device inventory and review it at least quarterly. Ownership sits with the system owner, with the security team approving changes.
Device identification and authentication procedure
This written procedure explains how each approved device type is identified, which credential it presents, who issues that credential and how the device is checked before a connection is set up. Assessors interview the people who run this process, so the document must match their actual practice. Confirm that it names the identity source, such as a directory, certificate authority or network access server, and that it covers exceptions. Review it at least annually and after any change to the network access or identity stack. Ownership sits with the identity or infrastructure team lead.
System design documentation of the admission path
Design documents show where a device meets the admission control point before it reaches CUI systems, including the network access servers, certificate checks and the path that denies unidentified hardware. Diagrams without this detail do not show the control working. Include the protocols in use, for example IEEE 802.1X with EAP or RADIUS with EAP-TLS, and where certificate revocation checking happens. Update the diagrams whenever a network segment, switch fabric or access server changes. Ownership sits with the network architect, reviewed alongside the system security plan.
Certificate issuance and revocation records
When devices authenticate with X.509 certificates, the issuance and revocation records prove that each device received a unique credential and that lost or retired devices lost their access. Keep the request, approval, issue date, device binding and revocation entries for each certificate. Confirm that the certificate authority publishes revocation information that the admission point actually checks. Reconcile active certificates against the approved device list each quarter. Ownership sits with the PKI administrator, with periodic review by the security team.
Admission and denial logs from the access point
Logs from the network access control point show which devices were admitted, which were refused and why. They provide operating evidence that the control runs continuously, not only in a test window. Confirm that the logs record device identity, result and timestamp, and that they flow to a central store where audit records are retained under the organization's audit requirements. Review denials for patterns such as unknown hardware or expired certificates. Ownership sits with the security operations team, with review at a defined cadence set in the monitoring procedure.
Test records for refused unidentified devices
Test records show that a device without an approved identity is refused before it establishes a connection. Assessors use the test method for this requirement, so an untested control earns little credit. Run a test with an unregistered device and a device with a revoked or expired credential, and record the input, the expected result, the actual result and the tester. Repeat the tests after every change to the admission path and at least once per assessment cycle. Ownership sits with the security engineering or assessment team, with results reviewed by the control owner.
What meeting 03.05.02 costs in money and effort
This table breaks the cost of meeting 03.05.02 into its components, showing who is paid for each, whether it is one-time or recurring, what pushes it up and how to keep it down. No fees or durations were supplied for this requirement, so use the table to structure the quote you ask for, and request each line item separately.
| Cost component | One-time or recurring | What drives it up | How to keep it down |
|---|---|---|---|
| Device inventory and ODP definition | One-time, then updated on change | Large or poorly tracked device estate, unclear device types, shadow devices | Define device types in writing so the ODP has a bounded list; reuse existing asset inventory data |
| Engineering time for authentication design and rollout | One-time, with ongoing changes | Many device types, legacy equipment that cannot run modern authentication, mixed network segments | Start with the device types that connect to the CUI system; phase in the rest with documented exceptions |
| Certificate authority and identity tooling | Setup is one-time; hosting and maintenance recur | Number of certificates issued, need for high availability, revocation checking at scale | Self-hosted open-source options such as FreeIPA with its integrated certificate authority or OpenBao PKI, run in the client's own infrastructure, remove per-device license spend |
| Network access hardware or licensing | One-time hardware, recurring licensing where applicable | Need for port-based access control across many switches or sites, vendor licensing per port or per device | Confirm what the existing network equipment already supports before buying; ask the quote to separate hardware from license fees |
| Evidence upkeep | Recurring | Frequent device changes, manual evidence collection, unclear ownership of the device list | Automate exports of device registrations and certificate logs; assign a named owner for the device inventory |
| External testing or review | Recurring or per engagement | Scope that includes many device types, an external test of the authentication path, retesting after fixes | Scope testing to the device authentication path and the defined device types, and agree the scope in writing before work starts |
| Assessor time | Per assessment cycle | Incomplete or inconsistent evidence, many device types to sample, unclear ODP values | Prepare a single evidence package that maps each device type to its authentication method and records; ask the assessor for their sampling approach |
Your team, an implementation partner and the assessor
Your organization owns the requirement. The control only works if someone decides which devices or device types must be uniquely identified and authenticated before they connect, because that decision is the organization-defined parameter (ODP) for 03.05.02. Your team also keeps the device inventory current, sets the admission policy for what happens when an unknown or non-compliant device appears, and writes the procedures that staff follow when devices are enrolled, renewed or retired. Assessors will ask these people questions directly, so they must be able to explain the reasoning behind each choice.
- ODP decision: Record which device types are in scope, such as laptops, servers, network printers or industrial controllers, and the reason each is included.
- Device inventory: Maintain the list of devices requiring unique identification and authentication, with an owner and status for each entry.
- Admission policy: Define the rule that blocks or quarantines a device without a valid identity before it reaches the system.
- Procedures: Document enrollment, certificate or credential renewal, revocation and decommissioning steps.
- Interview readiness: Make sure the personnel responsible for device authentication can describe how it works.
Confirm that the ODP value is written down and approved, because a requirement with an undefined parameter cannot be assessed as met.
An implementation partner such as DeployOpen plans, builds and documents the technical path that identifies devices and authenticates them, inside your own cloud accounts, data centers or air-gapped networks. The partner does not own the requirement and does not decide the ODP value. Its role is to turn your policy into working mechanisms and to produce the configuration records, diagrams and test results that show those mechanisms operate as described. Design and rollout of the certificate authority and the admission path are commonly the parts organizations outsource, because they require specialist configuration and careful testing.
- Design: Plan the device identity model, the certificate authority hierarchy, and the network access path that enforces authentication before connection.
- Build: Deploy and configure components such as an internal certificate authority, 802.1X or RADIUS-based network access, and firewall rules that block unauthenticated devices.
- Documentation: Produce system design documentation and configuration baselines that an examiner can compare against the requirement.
- Test evidence: Run and record tests showing that an unidentified device is refused and an enrolled device is admitted.
- Limits: The partner prepares systems and evidence. It does not issue audit reports, attestations or certifications.
Scope the work in writing so that deliverables, handover of credentials and the device inventory format are agreed before build starts.
An independent assessor tests whether 03.05.02 is met, using the assessment procedure in SP 800-171A Rev. 3. The assessment uses examine, interview and test methods, and it checks that the ODP value is defined. Only the assessor or the relevant certification or assessment body issues a report or determination. Depending on the contract, the assessment may be a self-assessment by your organization, a government-led assessment, or a third-party assessment, so confirm with the contracting agency which applies and what it will accept as evidence.
- Examine: Reviews policy, procedures, system design documentation and the list of devices requiring identification.
- Interview: Speaks with staff who run device identification and with personnel responsible for information security.
- Test: Checks that the mechanisms refuse an unidentified device and admit an identified one.
- ODP check: Confirms that the organization-defined device scope is written down and approved.
- Report: Only the assessor issues the findings or certification outcome.
Before engaging an assessor, ask which assessment type the contract requires and whether it accepts the evidence your partner and team have prepared.
Where organizations fall short on device identity and how to close it
Most device identification failures are not missing technology. They come from an unclear device list, an undefined parameter, and admission rules that nobody checks after go-live. The cards below pair each gap with the action that closes it and the evidence an assessor will ask to see.
No authoritative device inventory
Without a maintained list of devices that must be uniquely identified, the organization cannot show which devices fall inside 03.05.02. Teams often rely on DHCP leases, switch port tables or a spreadsheet that was last updated during a previous audit. Close the gap by naming one system of record for devices that can reach CUI, reconciling it against network discovery each cycle, and keeping the change history. Evidence: the dated device list, the reconciliation output and the named owner.
ODP never defined in writing
03.05.02 has one organization-defined parameter: the devices or types of devices to be uniquely identified and authenticated before a connection is established. If no one has written that value down, the requirement cannot be assessed as met, and the ODP check in SP 800-171A cannot pass. Close it by documenting the device types in scope, approving the definition, and tying it to the system security plan. Evidence: the approved ODP statement with version history and the SSP section that references it.
Devices admitted on network location alone
Placing a device on a trusted VLAN or subnet is not device identification. A device that plugs into a conference room jack or a rack port can receive access simply because of where it sits. Close the gap by requiring a cryptographic device identity, such as an 802.1X supplicant with EAP or a certificate, before the network grants access. NIST's discussion of device authentication names IEEE 802.1X with EAP, RADIUS with EAP-TLS and Kerberos as examples. Evidence: the access policy, authentication logs showing each device identity, and a test where an unidentified device is refused.
Expired or unrevoked device certificates
Where devices authenticate with certificates, expired certificates break access and unrevoked ones keep granting it after a device is lost or retired. NIST notes that PKI with certificate revocation checking can be part of device authentication, so revocation is part of the requirement, not an optional extra. Close the gap by setting issuance and renewal ownership, automating renewal where the platform supports it, and confirming that revocation is checked at admission. FreeIPA includes an integrated certificate authority based on Dogtag, and the OpenBao PKI secrets engine issues short-lived X.509 certificates. Evidence: the certificate inventory, revocation records and a tested revocation case.
Personal and IoT devices outside the rule
Personal phones, badge readers, cameras, printers and building controllers often connect to the same network as CUI systems but sit outside the admission process. Assessors ask how the organization knows these devices are excluded or how they are handled when they are in scope. Close the gap by classifying every device type as in scope or out of scope in the ODP, isolating out-of-scope devices from CUI segments, and blocking unknown device classes at the boundary. OPNsense rules can pass, block or reject traffic by source, destination, port and protocol, and aliases can group device addresses. Evidence: the device-class decision record, the firewall rule set and a test showing isolation.
Admission logs not retained or reviewed
Device admission decisions are only useful as evidence if they are logged, kept for a defined period and reviewed. Many organizations enable 802.1X or certificate checks but never export the logs, or let them roll over before an assessment. Close the gap by forwarding authentication and firewall logs to a central store, setting a retention period in the logging standard, and assigning someone to review rejected admissions. Logging and review obligations sit mainly in the audit and accountability family, so cross-check them there. Evidence: retained admission logs, the review record with its date and reviewer, and the escalation trail for rejected devices.
Questions about device identification and authentication cost and effort
What does device identification and authentication require from our internal team?
Your team owns the decisions and the evidence. Someone must define which devices or device types must be uniquely identified and authenticated before they connect, because 03.05.02 leaves that list to the organization as its one organization-defined parameter. Your team also needs to know how devices are enrolled, who approves exceptions, and how certificates or device credentials are issued, renewed and revoked. Expect time from identity, network and endpoint staff to answer questions, produce the device inventory and walk an assessor through the design. Confirm in your own environment who currently holds those responsibilities and whether the device list already exists.
Can a small team implement device identification and authentication in-house?
A small team can do it in-house if it already runs a directory, a certificate process and network access control, and if the device population is small and well defined. The harder part is usually not the technology but the consistency: every device type in scope needs a documented identity method, an owner and evidence that the method works. Teams without a certificate authority, a network access control point or an inventory of connecting devices often find the gap takes longer than the configuration. Ask yourself whether anyone on staff has built this before and can maintain it after the initial work.
What drives the cost and time of device identification up or down?
The main drivers are the number and variety of device types, whether identity systems already exist, and how much evidence the assessment will require. Each additional device type adds a credential method, a test and a documented procedure. Existing directory and certificate infrastructure lowers the cost, while greenfield work on identity, network access and inventory raises it. Integration with legacy or operational technology that cannot present certificates may require compensating controls and extra documentation. Confirm the device inventory, the systems that must integrate and the current state of certificate management before you estimate effort.
How does an implementation partner differ from the assessor for this requirement?
An implementation partner plans, configures, documents and tests the device identification mechanisms and prepares the evidence, while the organization keeps ownership of its controls. An assessor or certification body reviews that evidence against the assessment procedure and is the only party that issues a finding, report or certificate. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Ask any partner to put in writing which deliverables are configuration and documentation and which decisions remain with your staff.
Does self-hosted open source avoid license spend for device authentication, and what does it still cost?
Self-hosted open-source components can remove recurring license fees for the identity, certificate and network access tools, but the work and the operating cost remain. Options such as FreeIPA, which includes an integrated certificate authority based on Dogtag, and OpenBao's PKI secrets engine can issue device certificates, while OPNsense can enforce network rules. You still pay for infrastructure, for skilled staff to deploy and patch these systems, for integration with your endpoints, for backups, and for the assessor's time. Confirm each license terms and support model with the project or vendor before you rely on them.
How should we ask a partner for a fixed-scope quote on this work?
Ask for a written quote tied to a defined scope, because most engagements are fixed-scope and the scope drives the price. Your request should list the device types in scope, the identity method for each, the systems that must integrate, the number of environments, the documentation and evidence to be produced, and any testing expected. Ask the partner to state which items are one-time work and which are recurring, such as certificate renewals, patching and retainers for ongoing support. Also ask what you must provide, such as access, staff time and the device inventory, because delays in those inputs commonly extend the timeline.
How DeployOpen scopes and prepares device identity evidence
DeployOpen plans, implements and documents the device identification and authentication setup for 03.05.02 inside your own infrastructure, using self-hosted open-source platforms. We prepare the systems and evidence an assessor will examine, while your organization owns the control and an independent assessor makes any determination.
How we scope
- Engagements are fixed-scope, with the device types requiring unique identification agreed in writing before work starts.
- We list which device types connect to CUI systems and where the organization-defined parameter value is recorded.
- Scope covers the policy, procedures, system design documentation and device inventory an assessor would examine for 03.05.02.
How we build
- We configure device authentication such as IEEE 802.1X with EAP or RADIUS with EAP-TLS, or Kerberos, where the design calls for it.
- Certificate issuance for devices can be set up with FreeIPA's integrated certificate authority or OpenBao's PKI secrets engine, based on the design agreed with you.
- Network access points are configured so unidentified devices cannot establish a connection, with OPNsense rules logged for review.
How we hand over
- You receive documentation mapping each device type to its identification method, certificate lifecycle and owner.
- Test records show that a device without valid credentials is refused before a system connection is established.
- Handover includes the evidence set an examiner would request, so your staff can explain it during an assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover certificate renewal reviews and changes when new device types join the CUI environment.
- Assessor questions are answered with your team, but the organization makes its own compliance determinations and any independent assessment is performed by an assessor.
