03.04.12 high-risk travel configuration in NIST 800-171

What 03.04.12 requires for high-risk travel devices

03.04.12 requires you to issue specially configured systems or components to people who travel to high-risk locations, and to apply defined security measures to those devices when the travelers come back. If you are a compliance lead or engineer, the practical question is how you show an assessor that this happens for every trip, not just in policy. The requirement has two organization-defined parameters (ODPs). The first is the configuration a traveling device must have. The second is the set of security requirements applied when the device returns. NIST does not assign either value. Your organization must define both, document them, and then show they are followed.

The requirement is new in Rev. 3. NIST's change analysis lists it among the 19 requirements added in this revision, and its source control is CM-2(7) from SP 800-53 Rev. 5, which was added to the SP 800-53B moderate baseline that Rev. 3 tailors. No Rev. 2 requirement maps to it. That matters because CMMC Level 2 assesses the 110 Rev. 2 requirements and has no matching requirement ID, so an assessment scoped only to CMMC may not ask for this evidence. Confirm with your contracting officer or assessor which revision governs your contract before you plan the work, since the federal rules on Rev. 2 and Rev. 3 are changing.

The difficulty is that the control is only as strong as the definitions behind it. Write a travel build standard that names the operating system image, the encryption and authentication settings, the permitted software and the data that may and may not go on the device. Then define the return measures: for example, reimaging, checking the device against its baseline, reviewing logs from the trip, and reissuing credentials. Your evidence is the approved parameter values, the issuing and return records, and the results of the return checks. Only an independent assessor can judge whether your definitions and records meet the requirement. Your job is to make that judgment straightforward by keeping the records complete.

Which travelers, devices and teams fall under 03.04.12

Requirement 03.04.12 only works once the organization decides who travels, which devices leave the controlled environment, and who answers for each step. The cards below set out the decisions that determine how much work the requirement creates. Several of them must be agreed with the federal agency that sets the scope of the contract, so confirm those early.

Defining high-risk destinations

03.04.12 does not name any countries or regions, so the organization must define which destinations trigger the requirement and document that list. Ask who approves additions, such as the security office, legal counsel or the contracting agency, and how often the list is reviewed as conditions change. A short list covering a few regions creates far less recurring work than a broad rule covering every international trip. Confirm the definition with the contracting agency where its scope is set.

Laptops, phones and removable media

Laptops and phones are the devices most likely to hold CUI and be issued for travel, so they form the core of the scope. Removable media and hardware security tokens also need a decision, because they can carry CUI or authentication material across a border. Record each device class, whether it is issued as a loaner or a dedicated travel build, and whether it is returned and reimaged. Each added device class adds inventory, imaging and verification work.

Personal devices and cloud systems

Personal devices used for work and cloud-hosted systems with CUI access can fall into the same travel risk as issued equipment. Decide whether travelers may use personal phones or laptops to reach CUI at all, and if so, whether those devices must be enrolled and checked when travelers return. Cloud workspaces accessed from abroad need the same decision, because the risk comes from the endpoint as much as from the storage. Excluding personal devices usually reduces the work but requires policy and access controls that block them.

Shared ownership across teams

IT usually builds and images travel devices, security sets the configurations and return checks, HR and travel administration supply traveler lists and trip dates, and the system owner signs off on exceptions. The requirement fails in practice when travel administration books trips that IT never hears about. Write a responsibility matrix that names one accountable owner for issuing devices and one for return checks, and state how travel data reaches the security team. Confirm the split with the contracting agency and the organization's own policies.

Agreeing scope with the contracting agency

Where the contracting federal agency sets the scope, the agency's expectations on destinations, device classes and return checks should be written into the system security plan or contract terms before work begins. Ask the agency whether it has defined its own organization-defined parameters for 03.04.12 or expects the nonfederal organization to set them. A scope agreed late tends to force rework on devices already issued. Record every agreed decision so an assessor can trace it to the requirement.

How an assessor tests 03.04.12 and what they ask to see

This table walks through how an assessor tests 03.04.12 under SP 800-171A Rev. 3, which combines two determination statements with two checks that the organization-defined parameters are set. Read each row as a question the assessor will ask, the people or records they will go to, and the gap that most often stops a requirement from passing.

Assessment element	What the assessor examines or asks	Evidence that passes	Common finding
Examine: configuration management policy and procedures	Whether written policy and procedures cover issuing specially configured devices to travelers and applying return security measures	Dated policy with a named owner and a travel-device procedure that references both ODP values	Policy covers baseline configuration in general but says nothing about high-risk travel
Examine: configuration management plan	Whether the plan assigns responsibility for travel configurations and for the return check	Plan section naming the roles that approve, issue, and re-verify travel devices	Plan predates the travel requirement and was never updated
Examine: baseline configuration procedures	Whether the travel configuration is a documented baseline, separate from the standard build	Travel baseline document with settings, approved software, and the approval record	Travel devices are reimaged from the standard build with no documented difference
Examine: component installation and upgrade procedures	How travel devices are built, patched, and checked before they leave the organization	Build records showing the travel configuration was applied and verified before issue	No record that the device was checked before it left
Examine: system component inventory	Whether each travel device is listed, with its assignee, travel dates, and return status	Inventory entries linking each device to a traveler and a return date	Loaner laptops appear in no inventory, so returns cannot be tracked
Interview: configuration management personnel	How the configuration set for travel is chosen, approved, and changed	Consistent answers that match the baseline and approval records	Staff describe a process that differs from the written procedure
Interview: information security personnel	How the return security measures are chosen and who checks that they ran	Named security owner and the measures applied on return, matching the ODP value	Security staff cannot name the return measures or the person who verifies them
Interview: system administrators	What they do when a device returns, step by step, and what they record	Administrators describe the same return steps as the procedure and show completed checks	Administrators say returns are handled informally and no record exists
Test: processes for managing baseline configurations	Whether an issued travel device actually has the defined configuration, and whether the return measures were applied	Sampled device showing matching settings and a completed return check record with date and tester	Sampled device drifts from the travel baseline, or no return check record exists

Implementing 03.04.12 in the order an assessor will check it

This sequence takes an organization from undefined travel rules to a documented, tested process that an assessor can trace from the requirement's two organization-defined parameters through to the records that show the process ran. Each step produces an artifact that a later step depends on.

Define and document the two ODP values
Before anything is built, the organization sets the two organization-defined parameters for 03.04.12: the configuration of the systems or components issued to people traveling to high-risk locations, and the security requirements applied when those people return. Where a federal agency or contracting officer specifies these values, record that source. Where none is specified, the organization assigns them and must be able to justify them. Confirm with the contracting agency or the applicable DoW guidance which values are binding for your contracts. The output is a signed ODP table that names each value, its owner and the contract or policy it traces to.
Build and baseline the travel image
The team builds a travel-specific system or component image that matches the issued configuration defined in the first step. Start from the existing hardening baseline (03.04.01 and 03.04.02), remove data that is not needed on the road, and record the resulting configuration as its own baseline under configuration control. Open-source tools such as Wazuh Security Configuration Assessment or osquery queries can check the image against its policies. The output is a versioned travel baseline with a configuration report showing the image passes its checks.
Set up checkout and return records tied to inventory
Each travel device is recorded in the system component inventory (03.04.10) with its asset identifier, assigned traveler, destination category, checkout date and expected return date. The checkout form confirms the device carries only the travel baseline. The return record captures the date of return, the condition check result and the sign-off of the person who performed it. The output is a populated inventory with linked checkout and return entries that an assessor can trace device by device.
Define the return measures and who performs them
Write the return procedure that applies the second ODP values when a traveler returns. The procedure names the role responsible for each measure, such as reimaging, credential rotation, integrity checks or review of logs, and states the order in which they happen. Assign the security staff who perform the checks and the system administrators who execute them, and confirm that they are trained on the procedure. Where the device is not returned to the organization, document what the traveler must do and how the organization verifies it. The output is an approved return procedure with named roles and a completion checklist.
Run a pilot trip and review the records
Before the procedure is relied on for real travel, the team runs a pilot checkout and return with a device that is not carrying sensitive data. The reviewer checks that the inventory entry, checkout record, baseline configuration, return checks and sign-offs all exist and agree with each other. Any gap found in the pilot is corrected in the procedure and the affected record is re-tested. The output is a pilot record showing the full chain from checkout to return, plus a list of corrections and their closure. Assessors often ask to see this kind of end-to-end walkthrough.
Write the procedure into the configuration management plan
The approved procedure, the ODP table, the travel baseline and the record templates are incorporated into the configuration management plan and the system security plan so that they are governed by the same change control as the rest of the system. The plan names an owner who reviews the travel procedure and the ODP values on a defined schedule and after any change to the contract or the baseline. Confirm with your assessor how they expect the plan to reference the procedure. The output is a revised plan with version history and a documented review owner.

Evidence that passes a 03.04.12 review

An assessor testing 03.04.12 looks for proof that travel configurations were defined, that devices were issued and checked against them on return, and that the organization reviews those choices on a schedule. The six artifacts below connect the two ODPs to the records that show they are followed. The organization owns each control and signs off on its own records; an independent assessor decides whether the evidence is sufficient.

Approved travel configuration baseline

This is the document that fills in the first ODP: the configurations for systems or components issued to people traveling to high-risk locations. It should list the operating system build, disk encryption state, account and privilege settings, permitted software, network settings and what is removed before issue. Keep it under configuration control with a version history, and tie it to the baseline configuration for the general fleet so assessors can see where the travel build differs. The approver should be the person accountable for configuration management, not the travel team that uses the devices.

Issuance and return log by asset ID

This log shows which device went to which traveler, when it left, when it came back and which configuration it carried. Each entry should reference a component inventory asset ID so the device can be traced to the inventory record required by 03.04.10. Gaps in the log, such as a returned device with no return entry, are the first thing an assessor will test. Ask whether the log is kept in the asset management system or in a spreadsheet, and who can edit it.

Return-check results with reviewer and timestamp

For each returning device, record the checks defined by the second ODP, such as reimaging, credential rotation, firmware verification and scans for changes against the travel baseline. Each result needs a timestamp and the name of the person who reviewed it, so that a reviewer cannot be replaced by a generic queue. Where a scanner is used, retain its output with the check record. Confirm the checks are defined before travel starts, not decided after a device returns.

Exception and reimage records

Some devices will not pass a return check, or a traveler will need a deviation from the issued build. Record each exception with the reason, the risk accepted, the approver and an expiry date, and record each reimage with the method and the result. These records show the organization handles deviations under control rather than informally. Assessors commonly test a sample of exceptions to confirm each one was approved before the device was used.

Procedure and training records for travel staff

The 03.04.12 assessment includes interviews with personnel who manage configuration and information security, so the people who issue and receive devices must know the procedure. Keep the written procedure, its version and the training records showing each issuing and reviewing staff member completed it before handling devices. Refresh the record when the travel baseline or the ODP values change, and ask who in your organization owns that trigger.

Review cycle showing the ODPs are current

Both ODPs need a defined review frequency and a dated record showing the baseline, the return checks and the high-risk location criteria were reviewed. The review should compare recent travel and return results with the defined values and record any change. The review is signed by the accountable security owner and, where the organization is a federal contractor, shared with the agency that assigns ODP values. Confirm with the agency or contracting officer whether it has specified these values, because if it has not, the organization must assign them itself.

What meeting 03.04.12 costs in money and staff time

This table breaks the cost of 03.04.12 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written scope and to ask each vendor or partner for the same line items so quotes can be compared. No price figures are given because none are supplied for this requirement.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up and how to reduce it
Travel image engineering	Internal platform or endpoint team, or an implementation partner under a fixed-scope agreement	One-time, with periodic rebuilds	Drives up: number of destination profiles and device types. Reduce: a small number of standard hardened images that cover most trips.
Device management tooling	Vendor for commercial licenses, or internal staff for self-hosted tools	Recurring if licensed, one-time setup if self-hosted	Drives up: per-device license terms and fleet size. Reduce: self-hosted open-source tooling such as Fleet or osquery removes per-seat license spend, though hosting and upkeep remain.
Checkout and loan records	Service desk or IT asset staff	Recurring with each trip	Drives up: number of trips and loaner devices in circulation. Reduce: a single ticketed workflow that records which configuration left and when it returned.
Return checks per device	Security engineers or endpoint administrators	Recurring with each return	Drives up: manual checks per device and the number of security requirements applied on return. Reduce: scripted compliance queries that run automatically when a device reconnects.
Defining and reviewing ODP values	Internal security and compliance leads, possibly an external reviewer	One-time, then reviewed periodically	Drives up: number of destination risk categories and how often values change. Reduce: group destinations into a short, documented set of risk tiers.
Evidence upkeep	Compliance lead and system administrators	Recurring	Drives up: number of trips to record and the depth of return-check logs. Reduce: export logs and checkout records to the system security plan folder on a fixed schedule.
Assessor sampling and interviews	Independent assessor, paid by the organization or its contracting customer	Recurring at each assessment	Drives up: number of trips sampled and staff interviewed. Reduce: keep one consistent, documented process so fewer distinct cases must be explained.
Quote request items	Ask each provider to price each line above separately	Mark each as one-time or annual	Request: fixed scope with image count, device count, expected trips per year, number of return-check steps, license terms and hosting assumptions.

Which self-hosted open-source tools can run the return checks

The return check is the part of 03.04.12 that an assessor will ask to see working, so the organization needs a repeatable way to confirm that a returned device still matches its approved configuration and to keep the result as evidence. Manual inspection by a single administrator is hard to repeat and hard to prove. Several self-hosted open-source tools can run these checks inside the organization's own infrastructure, but each covers a different part of the job, and none of them decides on its own what the organization's approved configuration is. That decision belongs to the organization and its configuration management plan.

Wazuh Security Configuration Assessment (GPL-2.0-only) is the most direct fit for a configuration-compliance check. It scans monitored endpoints for misconfigurations using YAML policies, most of which are based on CIS benchmarks, and it checks files, directories, registry keys and running processes and recommends remediation. Organizations can extend it with custom policies that encode their own approved build for a travel device. Fleet policies (MIT) take a different approach: each policy is a yes or no osquery question asked of enrolled devices, and the policies page shows which devices in each fleet pass or fail. That pass or fail view suits a short list of return conditions, such as disk encryption enabled or a specific security agent running. osquery (Apache-2.0 OR GPL-2.0-only) provides the underlying data, exposing processes, kernel modules, network connections and file hashes as SQL tables that the osqueryd daemon can run on a schedule across hosts. Fleet is built on osquery, so the two are often evaluated together.

Velociraptor (AGPL-3.0-only) fits cases where the return check needs forensic depth, such as collecting specific artifacts from a device that was out of contact during travel. Its hunts can schedule collection for offline machines so that they run when the device reconnects, and each hunt gets a notebook for analyzing the combined results. The AGPL-3.0-only licence carries network-use obligations for modified versions, so the legal team should review whether that terms fit how the organization plans to deploy and change it. Whichever tool is chosen, the team should confirm that it can express every check on its return list, that the results can be exported as evidence, and that the tool's current documentation matches the version it plans to deploy.

Who owns 03.04.12, who prepares evidence and who issues the finding

Your organization owns the control. Under 03.04.12, you decide which configurations travelers receive and which security requirements apply when devices come back, and you must document those choices as organization-defined parameters. NIST does not assign these values, so if no federal agency specifies them, your organization must. Your security and management staff also carry the judgment calls that no vendor can make for you, such as which destinations count as high risk and who may travel with a managed device.

ODP values: Define the travel configuration and the return security requirements in writing, approved by someone accountable for CUI protection.
Travel approval: Decide which destinations and individuals trigger the requirement, and record each approval.
Device custody: Assign who issues, holds and tracks loaner devices, and who may request an exception.
Return decisions: Decide whether a returned device is cleared for the network, reimaged, or held for further review, and who signs off.
Scope of the policy: Confirm the requirement matches the travel policy and the system security plan.

Before engaging anyone, confirm that these decisions are written down and approved, because an implementation partner can only build what you have specified.

Where 03.04.12 programs usually fall short

03.04.12 asks for two things that are easy to describe and hard to keep running: a defined travel configuration issued to people going to high-risk locations, and defined security measures applied when those devices come back. The gaps below cluster around the same weakness, which is that the decisions behind the requirement live in people's heads rather than in records an assessor can examine.

ODP values never written down

Both organization-defined parameters for 03.04.12, the configurations to issue and the security requirements to apply on return, are often left to whoever is available on the day. Because the organization must assign these values itself when no federal agency specifies them, an assessor will look for written values that match the requirement. Check that each ODP has a documented, approved value and that the values appear in the configuration management plan.

Travel configuration held as tribal knowledge

Many teams can describe a loaner laptop from memory but cannot point to a baseline for it. The travel configuration should be a named, versioned baseline with its own settings, covering what software is installed, what is removed and which accounts are present. Ask for the document, confirm it is under configuration control, and confirm that the IT staff who build these devices work from it rather than from habit.

Return checks done but not recorded

Inspecting or reimaging a device after a trip is common practice, yet the result is often a verbal sign-off or an unlabeled ticket. The return measures from 03.04.12 need evidence: which checks ran, who ran them, the date the device came back and the outcome. Without that record, the organization cannot show the measures were applied to the specific device that travelled.

Devices issued without inventory IDs

A loaner that leaves the building without a unique identifier is hard to connect to a traveler, a trip or a return check. Assign each travel device an asset tag or inventory ID before issue, and record the issue and return events against that ID. This makes it possible to show which devices were configured for travel and which were checked on return.

No link to inventory and information location

Travel devices often sit outside the component inventory required by 03.04.10 and outside the information location records required by 03.04.11. If a device carries CUI while abroad, the organization should know what CUI it holds and where that data went. Confirm that each travel device appears in the inventory and that its CUI locations are documented before it leaves.

Procedures written for IT, not travelers

Return and issue procedures frequently assume the IT team will handle every step, while travelers receive no instructions on what to do with the device or when to hand it back. The traveler should receive a short written rule set covering use, connectivity and return, and should acknowledge it. Check that the acknowledgment is kept with the issue record so the procedure reaches the people who actually carry the devices.

Questions buyers ask about 03.04.12 cost, effort and scope

Does 03.04.12 apply to every employee who travels?

No. The requirement applies to individuals who travel to locations the organization has defined as high-risk, and only where those individuals take systems or components that handle CUI. Requirement 03.04.12 asks the organization to issue configured systems or components for that travel and to apply defined security measures when the devices come back. Who counts as a traveler, which destinations are high-risk, and which devices are in scope are decisions the organization makes and documents in its system security plan. Ask your agency or assessor how they expect the scope to be written before you size any work. Organizations that already restrict travel with company devices usually have a shorter scoping exercise than those that do not.

How long does it take to define the ODP values and the travel image?

The duration depends on how many destinations, device types and user roles fall into scope, and on how quickly decision-makers agree on the values. Requirement 03.04.12 has two organization-defined parameters: the configurations to issue to travelers and the security requirements to apply when devices return. NIST does not assign these values, and if the contracting agency does not specify them, the organization must. No researched figure is available for typical durations, so ask any partner to break the estimate into scoping, drafting the travel build, testing the build, and writing the return procedure, with a named owner for each step. Confirm the agency's expectations before work begins, because a change in those expectations can change the scope.

Can an in-house team implement 03.04.12 without outside help?

Often yes, if the team already runs a hardened build process, manages device inventory and controls endpoint configuration. The work is mostly policy and engineering: defining the ODP values, building a locked-down travel image, keeping a loaner pool under inventory control, and writing a return procedure that checks and resets each device. Teams that lack a configuration baseline or endpoint management tooling usually need that groundwork first, which is a larger effort than the requirement itself. An outside implementation partner can help with the build and the evidence, but the organization owns the decisions and the controls. Only an independent assessor issues the results of an assessment.

What does the work need from our side?

The engagement needs decisions, access and sign-off from named people. Decisions cover the high-risk destinations, the traveler population, the device types, and the values for both ODPs. Access covers the existing configuration management tools, the device inventory, the endpoint management platform and a test device set. Sign-off covers the travel build, the return procedure and the evidence list, given by people who own security policy and the system security plan. Expect that some of these approvals need legal, HR or travel policy input, because the requirement touches employee devices and travel rules. Agreeing these owners at the start usually prevents the largest delays.

How does 03.04.12 interact with the contracting agency's ODP guidance?

The agency's guidance decides the ODP values when it provides them, and the organization must follow it. NIST notes that if a federal agency does not specify ODP values, the nonfederal organization must assign them to complete the requirement. Federal rulemaking on this topic is moving. A FAR overhaul proposed rule published on 23 June 2026 would require contractors handling CUI to comply with SP 800-171 Rev. 3 using ODP values published by the DoW CIO, but it was not final as of October 2026. A DoW Class Deviation signed 3 September 2026 names SP 800-171 Revision 2 explicitly, which has no 03.04.12 requirement. Confirm with your contracting officer which revision applies to your contract before you scope the work.

What should we ask a partner for in a fixed-scope quote?

Ask for a written scope that names the systems, device types, traveler groups and destinations covered, plus the two ODP values as proposed drafts. The quote should list deliverables such as the travel build specification, the return procedure, the test records and the evidence package, with the client decisions and access each step needs. It should state what is one-time, such as the build and the procedure, and what recurs, such as reimaging loaner devices, reviewing the travel list and keeping inventory current. Ask who performs each task, what the client must provide before work starts, how changes to scope are priced, and what the partner will not do, including issuing any assessment result. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides a quote from that written scope.

How DeployOpen works on this

DeployOpen prepares the systems, configurations and evidence that support 03.04.12 System and component configuration for high-risk areas inside your own environment. We scope the travel-device process in writing, build and document the configurations and post-travel checks you define, and hand over material your assessor can examine, interview against and test. The organization owns its controls and its ODP values, and only an independent assessor issues a result.

How we scope

Agree in writing which traveler populations, device types and high-risk destinations the 03.04.12 process covers.
Confirm with your organization the two organization-defined parameters: the travel configurations and the post-return security requirements.
Identify which systems, accounts and endpoint fleets are in the assessment boundary and where travel devices are tracked.

How we build

Build the issued travel configuration as a documented baseline that the organization approves before any device leaves.
Configure endpoint policy checks for returned devices, such as configuration assessment scans and yes or no compliance queries, mapped to the agreed post-return requirements.
Test the return workflow end to end, including collection of results from devices that reconnect after travel, and record the outcome.

How we hand over

Deliver the written travel configuration baseline, the post-return procedure and the configuration management policy and procedures they reference.
Provide evidence mapped to the SP 800-171A examine, interview and test objects for 03.04.12, such as baseline records, inventory entries and check results.
Walk your assessor and system administrators through the evidence so the organization can answer interview questions accurately.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Update the travel configuration and post-return checks when your ODP values, destinations or device standards change.
Confirm with your assessor which evidence format and retention period they expect before the assessment begins.