- Loaner devices with minimal data and travel-only credentials are the clean pattern; a small organization can keep one or two prepared laptops rather than building a program.
- Decide the return protocol in advance — what gets examined, what gets wiped, which credentials rotate — and record that it happened for each trip.
- Define which destinations trigger the process, informed by export-control and threat guidance, so the decision is not improvised per trip.
03.04.12OFFICIAL TITLEPENDING NIST SME REVIEW
03.04.12 — System and Component Configuration for High-Risk Areas
03.04 Configuration Management · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires issuing systems or system components with organization-defined configurations to individuals traveling to locations the organization deems to be of significant risk, and applying organization-defined security requirements to those systems or components when the individuals return.
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
A laptop that travels to a high-risk country is treated as exposed the moment it lands. Devices for such trips are issued deliberately configured — minimal data, hardened settings — and on return they get a defined once-over: inspection, credential rotation, often a reimage.
Across revisions
New in Rev. 3 with no Rev. 2 counterpart, drawn from SP 800-53's CM-2(7): device handling for travel to high-risk locations was previously left to policy discretion.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- The travel-device configuration standard and the destination trigger list
- Issuance and return records for trips that invoked the process
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this came from in Rev. 2
No direct Rev. 2 counterpart — this requirement is new in Rev. 3. Open the transition crosswalk →
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |