SC-18(5): Allow Execution Only in Confined Environments

To meet the sc-18(5): allow execution only in confined environments requirement, you must ensure any permitted “mobile code” (scripts, macros, downloaded executables, browser-based code) runs only inside a confined virtual machine (VM) or equivalent isolated runtime, not directly on user endpoints or production hosts. Operationalize it by defining what mobile code is allowed, routing execution into hardened sandboxes, and retaining proof that controls are enforced. ¹

Key takeaways:

• Permit mobile code only through an approved, isolated execution path (confined VM/sandbox).
• Enforce with technical controls (application control, browser isolation, VDI/sandboxing) plus clear exceptions handling.
• Keep assessor-ready evidence: architecture, configs, allowlists, and logs that show code executed in the confined environment. ¹

SC-18(5) is a control enhancement under the NIST SP 800-53 “System and Communications Protection” family that targets a common intrusion path: code that arrives dynamically and executes in places you did not intend. In practice, “mobile code” covers more than Java applets. It includes scripts, macros, browser-delivered code, downloaded binaries, and other code that can be pulled from external or semi-trusted sources and run on endpoints or servers.

The operational goal is simple: if you allow it, you confine it. That means creating a narrow set of approved execution methods (for example, a hardened sandbox VM, browser isolation, or VDI) and blocking all other execution paths. You will also need to show an assessor that the control is real: documented scope, enforced technical policy, monitored exceptions, and repeatable evidence.

This page gives requirement-level implementation guidance you can hand to control owners (endpoint, infrastructure, security engineering) and quickly turn into tickets, guardrails, and audit artifacts, aligned to NIST SP 800-53 Rev. 5. ²

Regulatory text

Requirement (verbatim): “Allow execution of permitted mobile code only in confined virtual machine environments.” ¹

What the operator must do:

1. Decide what “mobile code” you permit (and under what conditions).
2. Ensure permitted mobile code can execute only inside a confined VM environment (or equivalent isolation boundary that you can defend as “confined” to your assessor).
3. Prevent execution outside that confined environment through enforceable technical controls, not policy-only statements. ¹

Plain-English interpretation

If your workforce or systems need to run code that originates from outside your tightly controlled software supply chain (web-delivered code, documents with macros, scripts pulled from collaboration tools, ad-hoc utilities), SC-18(5) expects you to force that execution into an isolated environment. The isolation should meaningfully reduce blast radius: limited filesystem access, limited network egress, limited credential access, and easy reset/rollback.

A “permit list” approach fits this requirement best: you explicitly allow certain mobile code categories and execution methods, and everything else is blocked or routed into the confined VM.

Who it applies to (entity and operational context)

Typical in-scope entities

• Federal information systems and programs implementing NIST SP 800-53 controls. ²
• Contractors and other third parties handling federal data where 800-53 controls are contractually flowed down (common in government procurement and regulated supply chains). ²

Typical in-scope environments

• End-user computing (Windows/macOS/Linux endpoints) where users can download files, run scripts, or open macro-enabled documents.
• Enterprise browsers where untrusted web content runs active code.
• Jump hosts and administrative workstations that interact with production systems.
• Any enclave where users or processes might execute externally sourced code (developer tooling can be a special case, but it still needs confinement if permitted).

What you actually need to do (step-by-step)

1) Define “mobile code” for your environment

Create a short, assessor-friendly definition and examples list. Keep it concrete:

• Browser-executed code (active web content)
• Office macros and embedded scripts
• OS scripts (PowerShell, Bash, Python) obtained outside controlled repositories
• Downloaded executables/tools run ad hoc
• Code launched from email/IM/file-sharing content

Deliverable: “Mobile Code Standard” (one pager is fine) that names allowed categories and explicitly disallows everything else by default.

2) Set the permitted use cases (the allowlist)

Most teams fail here by saying “mobile code is allowed for business purposes.” That will not survive an assessment.

Write allowlist statements that specify:

• Who may run it (role/group)
• What may be run (file types, signed publishers, approved sources)
• Where it may run (named confined VM/sandbox platforms)
• When exceptions apply (time-bound, documented, approved)

Deliverable: Mobile code allowlist matrix (see template below).

Example allowlist matrix (adapt to your tools)

Mobile code type	Allowed?	Where it may execute	Enforcement control	Exception owner
Internet web content	Yes	Remote browser isolation / hardened sandbox VM	Web proxy + RBI policy	Security Eng
Office macros	Limited	Confined VM for high-risk docs; signed macros on managed endpoints	Macro policy + app control	Endpoint Eng
PowerShell scripts	Limited	Confined VM / signed scripts only	Constrained Language Mode + signing	IT Sec
Downloaded executables	Rare	Malware detonation/sandbox VM only	App allowlisting	SOC

3) Choose a confinement pattern you can defend

SC-18(5) is explicit about “confined virtual machine environments.” Your implementation should map to one (or more) of these common patterns:

• Dedicated sandbox VM pool for risky execution (reset after session; no shared credentials).
• VDI / non-persistent desktops for web and document handling that needs active code.
• Remote Browser Isolation (RBI) where browser execution happens in an isolated container/VM and only pixels/events reach the endpoint.
• Detonation/sandbox pipeline for unknown files (execute in sandbox, release only after analysis).

Pick the smallest number of patterns that cover your use cases. Document why they qualify as “confined” (isolation boundary, restrictions, reset behavior, credential handling).

4) Enforce: block direct execution paths

Policy does not meet SC-18(5) without technical enforcement. Put controls in place so users cannot easily bypass confinement:

• Application control / allowlisting: prevent unknown executables and scripts from running on endpoints and sensitive servers.
• Macro controls: block internet-origin macros; require signed macros; route high-risk documents into the confined VM workflow.
• Browser controls: force internet browsing through RBI or VDI for designated populations; restrict downloads; mark files with origin metadata and enforce “open in sandbox.”
• Privilege controls: remove local admin rights where feasible; restrict script interpreters and admin tooling on standard endpoints.

Your endpoint and network team should be able to show “deny” behavior for out-of-path execution attempts.

5) Build an exceptions workflow that does not become the default

Assessors look for uncontrolled exceptions. Set minimum exception requirements:

• Business justification
• Risk review
• Compensating controls (extra logging, limited duration, extra monitoring)
• Expiration and re-approval

Daydream can help here by mapping SC-18(5) to a named control owner and generating a recurring evidence schedule so exceptions do not sprawl without review. ¹

6) Monitor and prove ongoing operation

You need telemetry that shows:

• Mobile code executed in the confined environment (session logs, broker logs, VM pool access logs)
• Blocks/denies on endpoints for prohibited execution paths
• Exceptions granted and expired

Make this reviewable by the SOC and auditable by GRC.

Required evidence and artifacts to retain

Keep evidence that proves design and operation:

Design artifacts

• Mobile Code Standard (definition + scope)
• Allowlist matrix (permitted mobile code and where it runs)
• Architecture diagram showing confined VM environment and traffic flow
• Risk assessment or rationale for why the confinement is sufficient (short memo is acceptable)

Operational artifacts

• Configuration exports/screenshots:
  • Application control policies (allow/deny rules)
  • Macro policies and browser isolation/VDI enforcement settings
  • Sandbox VM hardening baseline (network restrictions, clipboard/file transfer constraints, persistence settings)
• Logs and reports:
  • Sandbox/VDI/RBI access logs
  • Endpoint blocks for prohibited execution
  • Exception tickets with approvals and expiry
• Training/communications:
  • User guidance that explains “open/run in sandbox” workflow

GRC mapping artifacts

• Control narrative for SC-18(5): owner, tooling, enforcement points, monitoring
• Evidence collection cadence and responsible parties (so it’s repeatable)

Common exam/audit questions and hangups

Expect these:

1. “Define mobile code in your environment.” If you cannot name concrete types and sources, you will struggle to prove scope control.
2. “Show me enforcement.” Auditors want config evidence and a test: attempt to run mobile code outside the confined VM and show it’s blocked.
3. “What is ‘confined’ about your VM?” Be ready to explain isolation, restrictions, and reset behavior.
4. “How do you prevent credential theft or lateral movement from the confined VM?” Show network segmentation, limited egress, and credential handling decisions.
5. “How are exceptions approved and time-bounded?” Produce the workflow and recent examples.

Frequent implementation mistakes and how to avoid them

Mistake: Treating “mobile code” as only browser plugins or legacy Java.
Fix: Include scripts, macros, and ad-hoc tools in scope. Write examples into the standard.

Mistake: Allowing execution on endpoints and claiming EDR is “confinement.”
Fix: EDR is detective/response. SC-18(5) wants execution inside a confined VM environment for permitted mobile code. Use EDR as monitoring, not as the confinement boundary. ¹

Mistake: Confined VM exists, but users can bypass it.
Fix: Force routing (browser policies, download handling, application control). Validate with negative tests and retain results.

Mistake: “Confined VM” is persistent and becomes another workstation.
Fix: Prefer non-persistent sessions, controlled file transfer, and clear rules for what data can enter/exit the confined environment.

Mistake: No evidence schedule.
Fix: Put SC-18(5) on a recurring evidence calendar (policy/config/log samples). Daydream-style control mapping helps keep ownership and artifacts consistent across quarters. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source materials for this requirement, so treat enforcement risk as indirect: SC-18(5) gaps commonly surface during assessments after malware events, phishing campaigns involving document payloads, or red-team exercises that use scripts/macros for initial access.

Operationally, failure modes are predictable:

• Endpoint script execution becomes a lateral movement path.
• Macros from external documents run with user context and access enterprise data.
• Browser-delivered payloads exploit runtime or extensions.

Confinement reduces the blast radius and makes reset/containment faster because the environment is designed to be disposable.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign a control owner (endpoint or security engineering) and a GRC owner for evidence collection.
• Publish a mobile code definition and preliminary allowlist (even if conservative).
• Inventory current execution paths: browsers, macro settings, script interpreters, VDI/sandbox tools already in place.
• Pick the confinement pattern(s) you will standardize on and document the “confined” attributes.

By 60 days (Near-term)

• Implement enforcement for the highest-risk paths:
  • Macro restrictions and internet-origin handling
  • Browser isolation/VDI routing for in-scope populations
  • Application control for downloaded executables/scripts on endpoints in scope
• Stand up the exception workflow with expiration and tracking.
• Produce initial evidence pack: configs + sample logs + one negative test.

By 90 days (Operationalize)

• Expand coverage to remaining in-scope groups and systems based on risk.
• Add monitoring and periodic review:
  • Monthly sample of sandbox execution logs
  • Review exceptions and close expired ones
  • Validate enforcement with repeatable test cases
• Finalize your control narrative and evidence cadence so audits do not become a fire drill.

Frequently Asked Questions

What counts as “mobile code” for SC-18(5)?

Treat it as code that arrives dynamically and can execute without going through your normal software release controls, including scripts, macros, active web content, and ad-hoc downloaded tools. Define it explicitly in your standard so scope is auditable. ¹

Does a container count as a “confined virtual machine environment”?

The text specifies confined VM environments, so a VM-based sandbox is the cleanest interpretation. If you use containers, document the isolation boundary and be prepared to justify equivalence to a confined VM to your assessor. ¹

Can I meet SC-18(5) with EDR and logging alone?

No. EDR helps detect and respond, but SC-18(5) requires allowed mobile code to execute only inside a confined VM environment. You still need a forced execution path and blocks outside it. ¹

How do I handle Office macros without breaking the business?

Start with signed macros for known publishers and block internet-origin macros by default. For high-risk documents or external sources, route opening/execution into a confined VM/VDI workflow and document exceptions.

What evidence do auditors ask for most often?

They ask for the control narrative, proof of enforcement (policy/config exports), and logs showing execution occurred in the confined VM rather than on endpoints. They also ask for exception records with approvals and expiry.

We’re a contractor. Does this apply to third parties in our ecosystem too?

It applies to your system boundary and how your workforce executes permitted mobile code within that boundary. If a third party administers or operates parts of your environment, flow down the confined-execution requirement through contracts and access standards where relevant. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5