Mobile Code SC-18

System and Communications Protection · Moderate baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds SC-18 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, System and Communications Protection family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

SC-18 (Mobile Code) is about deciding which kinds of downloadable, auto-running code your systems will and will not allow, then keeping that decision enforced. Mobile code is software that travels across a network and runs on the receiving machine without the user deliberately installing it — think JavaScript, Java applets, ActiveX, or macros inside a document. The control has two parts: define which mobile code technologies are acceptable and which are not, and then authorize, monitor, and control their use within the system. It is a Moderate-baseline control.

What good looks like

Write down which mobile code is allowed (for example, signed scripts from a trusted source) and which is not (for example, unsigned macros or legacy ActiveX).
Authorize before use — a new mobile code technology should be reviewed, not adopted by default.
Monitor and control where mobile code can run, especially in browsers and email clients that pull code from the internet.
Prefer signed code so you can tell approved code from tampered or unknown code.
On a server, the strongest control is to not run interpreters or browsers you do not need in the first place.

Framework mapping

NIST CSF 2.0 — DE.CM-09 — Hardware, software, and runtime environments are monitored to find potentially adverse events
CIS Controls v8 — Control 9 — Email and Web Browser Protections

How to move it toward Implemented

Inventory the interpreters and runtimes present (which node python3 perl php java) and remove or restrict any the server does not need.
If a browser or email client is installed on the server, confirm it is a supported version and strip unneeded extensions — that is where mobile code usually enters.
Where scripts are required, prefer signed code and lock down who may write to script directories using file permissions.
Write the one-page acceptable-mobile-code list (allowed technologies, disallowed technologies, and who approves changes), saved as a dated file.
Attach that inventory and acceptable-code list as hardening evidence on the asset, naming SC-18 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.