Mobile Code is the requirement that governs code your users never chose to install. It sits in the System and Communications Protection (03.13) family, and it addresses software that arrives from somewhere else and runs locally without anyone deliberately executing it. Mobile Code (03.13.13) has two (2) parts: define acceptable mobile code and mobile code technologies, and authorize, monitor, and control the use of mobile code. Per the NIST discussion, mobile code includes software programs or parts of programs that are obtained from remote systems, transmitted across a network, and executed on a local system without explicit installation or execution by the recipient, and mobile code technologies include Java applets, JavaScript, HyperText Markup Language 5 (HTML5), VBScript, and Web Graphics Library (WebGL).
A common difficulty with this requirement is never writing down what counts as acceptable mobile code. R3 splits the definition into its own objectives, and those are the new work: you have to say which mobile code and which mobile code technologies are acceptable before the authorize, monitor, and control objectives mean anything. Teams also underestimate the scope, since JavaScript running in every browser session is mobile code.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.13.13 Mobile Code. Only the formatting has been adjusted for readability. This requirement has two (2) lettered parts:
The source control is SC-18 from NIST 800-53. There are no Organization-Defined Parameters (ODPs). Per the NIST discussion, decisions regarding the use of mobile code are based on the potential for the code to cause damage to the system if used maliciously, and mobile code policies and procedures address the actions taken to prevent the development, acquisition, and use of unacceptable mobile code within the system, including requiring mobile code to be digitally signed by a trusted source. You can read the requirement directly at NIST 800-171 R3, 03.13.13 (p. 62).
None (0). Requirement 03.13.13 contains no bracketed assignment, so there is no organization-defined value to select and nothing for the DoD to specify. The requirement applies as written.
Your System Security Plan (SSP) narrative for 03.13.13 therefore records how the requirement is implemented rather than a parameter you chose.
NIST 800-171A R3 breaks 03.13.13 into five (5) determination statements, and it has no Organization-Defined Parameters (ODPs). These AOs are:
Note that mobile code (a[01]) and mobile code technologies (a[02]) are separate defining objectives, and authorizing, monitoring, and controlling are three more. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.13.13 (p. 82).
Examine: system and communications protection policy and procedures; procedures for mobile code; mobile code implementation policy and procedures; list of acceptable mobile code and mobile code technologies; authorization records; system monitoring records; system audit records; system security plan.
Interview: personnel with responsibilities for managing mobile code; personnel with information security responsibilities; system administrators.
Test: processes for authorizing, monitoring, and controlling mobile code; mechanisms for supporting or implementing the management of mobile code; mechanisms for supporting or implementing mobile code monitoring.
03.13.13 maps from NIST 800-171 R2 requirement 3.13.13 (control and monitor the use of mobile code):
Mapped against the five (5) AOs, three (3) are direct (minimal effort) and two (2) have no clear mapping (significant effort). Controlling and monitoring mobile code carries forward, and R3 adds authorizing as an explicit objective alongside them. The new work is the pair of defining objectives: stating what acceptable mobile code is and what acceptable mobile code technologies are. Write those definitions down rather than assuming your browser and endpoint settings imply them.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.13.13 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about the definitions and the breadth of scope, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.13.13 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.13.13 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.13.13.
With three (3) AOs mapping directly and two with no clear mapping, 03.13.13 is a moderate lift centered on the definitions. A realistic sequence:
How many assessment objectives does NIST 800-171 R3 03.13.13 have? NIST 800-171A R3 breaks 03.13.13 into five (5) assessment objectives. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.13.13 come from? SC-18.
How many Organization-Defined Parameters (ODPs) does NIST 800-171 R3 03.13.13 have? None (0). The requirement contains no bracketed assignment, so there is no organization-defined value and nothing for the DoD to specify.
Where does NIST 800-171 R3 03.13.13 sit in the NIST 800-171 R3 Kill Chain? Phase 12, Secure Baseline Configurations (SBC). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.13.13 Mobile Code defines acceptable mobile code and mobile code technologies, then authorizes, monitors, and controls its use. It maps from R2 3.13.13 with controlling and monitoring transitioning directly, while the two defining objectives are new work and authorizing is now explicit. The recurring problem is never writing the definitions down. Say what mobile code and which technologies are acceptable, authorize their use, and back it up with endpoint and browser configurations that monitor and control what runs.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
