Mobile Code

To meet the FedRAMP Moderate mobile code requirement, you must define what mobile code is allowed and prohibited in your environment, then enforce that decision through technical controls that authorize, monitor, and control mobile code execution across endpoints, browsers, servers, and cloud workloads. Document the rules, implement guardrails, and keep evidence that the controls work. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• You need a clear allow/deny standard for mobile code technologies, not a vague “managed case-by-case” statement. (NIST Special Publication 800-53 Revision 5)
• “Authorize, monitor, and control” translates to enforceable configuration, logging/telemetry, and exception handling tied to owners. (NIST Special Publication 800-53 Revision 5)
• Auditors look for proof of enforcement: policy plus technical settings, plus logs and sampled validations. (NIST Special Publication 800-53 Revision 5)

“Mobile code” is one of those requirements that can sound dated until you map it to modern cloud and endpoint reality. In practice, SC-18 is about controlling code that is delivered or executed dynamically: scripts in a browser, macros in documents, installers and packages, downloadable components, and code fetched at runtime by applications. The risk is straightforward: mobile code is a common route for unauthorized execution, data exfiltration, and persistence if you don’t set clear rules and enforce them consistently.

For FedRAMP Moderate, you are expected to do two things well: (1) define acceptable and unacceptable mobile code and mobile code technologies, and (2) authorize, monitor, and control mobile code within the system. (NIST Special Publication 800-53 Revision 5) This is not only an endpoint problem. It touches user workstations, VDI, application servers, CI/CD pipelines, SaaS admin consoles, and cloud workloads that pull dependencies or run scripted automation.

The goal of this page is to help a Compliance Officer, CCO, or GRC lead translate SC-18 into implementable decisions, assign ownership, and collect evidence that stands up in a FedRAMP assessment.

Regulatory text

Requirement (SC-18): “Define acceptable and unacceptable mobile code and mobile code technologies; and authorize, monitor, and control the use of mobile code within the system.” (NIST Special Publication 800-53 Revision 5)

Operator meaning: you must (a) publish a decision about what mobile code is permitted and prohibited, and (b) implement technical and procedural controls so that mobile code execution is approved, observed, and constrained in your FedRAMP boundary. A policy alone is not enough; you need enforceable configuration and evidence of monitoring. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation (what SC-18 is really asking)

Mobile code is any code that can be introduced into a system and executed with limited friction, often delivered through content, downloads, packages, or runtime fetching. Think:

• Browser scripts and active content
• Document macros and embedded objects
• Installers, packages, and plug-ins
• “User-supplied” scripts executed by apps (for example, admin consoles, data tooling, automation runbooks)
• Code downloaded at runtime (dependencies, containers pulling layers, build steps fetching packages)

SC-18 expects you to decide what you allow, then make that decision real through controls: allowlists, execution policies, code signing requirements, endpoint protections, browser hardening, and monitoring for blocked or suspicious execution. (NIST Special Publication 800-53 Revision 5)

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating systems in a FedRAMP Moderate context. (NIST Special Publication 800-53 Revision 5)

Operational scope (where it shows up):

• End-user endpoints and VDI: browsers, office suites, PDF readers, local scripting engines, downloaded binaries.
• Admin workstations (“privileged endpoints”): high-value target; stricter rules expected in practice because these machines can change cloud configuration.
• Servers and workloads: OS scripting (PowerShell, Bash), application runtimes that load modules, containers and orchestration pulling images and artifacts.
• CI/CD and build systems: dependency download, post-install scripts, build steps that execute fetched code.
• Third-party software in your boundary: packaged tools that run scripts or interpreters, or that fetch updates/plugins dynamically.

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

Step 1: Define “mobile code” for your environment

Write a short definition that matches how your system operates. Keep it operational, not academic. Include examples relevant to your stack: browser scripting, macros, installers/packages, runtime dependency retrieval, and scripting engines. (NIST Special Publication 800-53 Revision 5)

Deliverable: Mobile Code Standard (policy or standard) with a definition section.

Step 2: Create an allow/deny decision matrix for technologies

Build a table that lists mobile code types and your decision: allowed, restricted, or prohibited. Tie each decision to enforcement points.

Example decision matrix (edit to match your stack):

Mobile code technology	Default stance	Enforcement point(s)	Notes / exceptions
Browser scripting (JavaScript)	Allowed, restricted by browser policy	Browser config, secure web gateway	Block known risky categories; log policy violations
Browser plug-ins/extensions	Restricted, allowlist only	MDM/endpoint management, browser enterprise policy	Require business justification and owner approval
Office macros	Prohibited by default	Office policy, endpoint controls	Allow signed macros only by exception
PowerShell/Bash scripting	Restricted	OS policy, EDR	Limit on endpoints; allow on servers with admin controls
Downloaded executables/installers	Restricted	App control, EDR	Prefer approved software catalog
Runtime package downloads (pip/npm/etc.)	Restricted	CI/CD controls, egress controls	Use internal repositories and integrity controls

You are not required to pick “deny everything.” You are required to be explicit and enforce your choices. (NIST Special Publication 800-53 Revision 5)

Deliverable: Mobile code allow/deny matrix with owners for each line item.

Step 3: Establish authorization rules (who can approve what)

Define who can authorize:

• A new browser extension
• A new scripting tool on endpoints
• Macro enablement for a business unit
• A new runtime dependency source
• A new installer/package for the approved software list

Authorization should include: business justification, security review, scope (which users/systems), expiry/renewal conditions, and required logging. (NIST Special Publication 800-53 Revision 5)

Deliverables: Exception/approval workflow, documented approvers, ticket templates.

Step 4: Implement technical controls to “control” execution

Pick controls that match your architecture. The auditor expectation is not a specific product; it is evidence that execution is constrained.

Typical control patterns:

• Application allowlisting / execution control: prevent unknown binaries/scripts from running on endpoints and privileged workstations.
• Macro controls: disable macros by default; allow only signed macros (if you permit any).
• Browser hardening: enterprise policies for extensions, downloads, and active content handling.
• Script enforcement: restrict script interpreters on user endpoints; require admin context or signed scripts where feasible.
• Network controls: restrict outbound access from build systems; prefer internal artifact repos to reduce uncontrolled runtime downloads.
• Cloud/workload guardrails: restrict user-supplied code execution features unless explicitly needed, then isolate and monitor.

Map each matrix item from Step 2 to a concrete configuration baseline and a change-control process. (NIST Special Publication 800-53 Revision 5)

Deliverables: Configuration baselines, screenshots/exports of settings, and change records.

Step 5: Implement monitoring (detect attempts and drift)

“Monitor” means you can see mobile code-related events and investigate them:

• Blocked execution attempts (what, where, by whom)
• Policy violations (attempted macro enablement, unknown binary execution)
• Drift from baseline (extensions installed outside policy, scripting enabled on unauthorized endpoints)

Set alerting thresholds based on your risk tolerance, but always retain logs and demonstrate review. (NIST Special Publication 800-53 Revision 5)

Deliverables: Logging configuration, sample alerts, incident tickets, review records.

Step 6: Validate and keep it current

Build a lightweight test plan:

• Sample endpoints: verify macro settings, script restrictions, extension allowlist enforcement
• Sample servers/build agents: verify dependency source restrictions and egress controls
• Attempt a controlled policy violation in a test environment to confirm logs and alerting

Update your mobile code matrix whenever you introduce new runtimes, admin tools, browsers, or CI/CD patterns. (NIST Special Publication 800-53 Revision 5)

Required evidence and artifacts to retain

Auditors typically want proof in three categories: governance, enforcement, and monitoring.

Governance artifacts

• Mobile Code Policy/Standard defining acceptable and unacceptable mobile code (NIST Special Publication 800-53 Revision 5)
• Mobile code decision matrix (allowed/restricted/prohibited) with named owners
• Exception process and approval criteria
• System boundary mapping notes: where mobile code could execute

Enforcement artifacts

• Configuration baselines (endpoint, browser, office suite, server) mapped to the matrix
• Exports/screenshots of key settings that enforce restrictions
• Approved software catalog entries for restricted tools
• Change tickets showing controlled rollout and approvals

Monitoring artifacts

• Log sources and retention configuration relevant to execution controls
• Sample detections: blocked script, blocked macro, blocked unsigned executable, unauthorized extension attempt
• Evidence of periodic review (tickets, meeting notes, or sign-offs tied to alerts)

If you use Daydream to operationalize this, store the mobile code matrix, exception tickets, and evidence exports in one control record so assessments don’t turn into a scavenger hunt.

Common exam/audit questions and hangups

• “Show me your definition of mobile code and what’s prohibited.” Auditors expect a crisp list, not broad statements. (NIST Special Publication 800-53 Revision 5)
• “How do you authorize exceptions?” They will ask for examples: who approved, what scope, and how it was time-bounded or revalidated. (NIST Special Publication 800-53 Revision 5)
• “Demonstrate enforcement.” Be ready to show configs and a live or recorded validation on a sample endpoint/server.
• “How do you monitor and respond?” Expect requests for logs, alert rules, and incident or investigation records tied to mobile code events. (NIST Special Publication 800-53 Revision 5)
• “What about third-party software that fetches code?” Have a stance for auto-updaters, plug-in ecosystems, and package managers inside your boundary.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance. A written standard without enforced settings fails the “control” expectation. Pair every rule with a technical enforcement point. (NIST Special Publication 800-53 Revision 5)
2. No explicit “unacceptable” list. “We manage risk” is not a decision. Write down what is prohibited by default and why. (NIST Special Publication 800-53 Revision 5)
3. Ignoring build pipelines. CI/CD that pulls code at runtime is mobile code exposure. Treat artifact sources as part of your control scope. (NIST Special Publication 800-53 Revision 5)
4. Unmanaged browser extensions. Extensions are executable code. If you allow them, enforce an allowlist and log violations.
5. Exceptions without expiry. Permanent exceptions become the baseline. Require renewals and attach monitoring requirements to exceptions.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied sources, so this page does not cite specific actions. Practically, SC-18 failures tend to surface during assessments as: (a) inconsistent endpoint hardening, (b) inability to prove settings are enforced, or (c) lack of monitoring evidence. The risk is unauthorized code execution that bypasses preventive controls, especially on privileged endpoints and build systems. (NIST Special Publication 800-53 Revision 5)

Practical 30/60/90-day execution plan

First 30 days (get to clear decisions and basic enforcement)

• Draft the Mobile Code Standard and define mobile code for your environment. (NIST Special Publication 800-53 Revision 5)
• Build the allow/deny matrix for browsers, macros, scripting, installers, and CI/CD dependency retrieval.
• Identify enforcement owners: endpoint team, IAM, SOC, cloud/platform, CI/CD.
• Implement quick wins: macro default restrictions, browser extension controls, and endpoint execution controls for privileged admin workstations where feasible.

Day 31–60 (expand coverage and make monitoring real)

• Roll enforcement baselines across in-scope endpoints and server classes; document configuration evidence.
• Stand up monitoring views/alerts for blocked execution and policy violations; define triage ownership and ticketing.
• Launch the exception workflow with required fields (justification, scope, owner, expiry, monitoring).

Day 61–90 (prove it works, reduce exceptions, prepare for assessment)

• Run validation sampling and record results; remediate drift.
• Stress-test one or two common violation scenarios in a test environment to confirm logs and response.
• Tighten CI/CD controls around artifact sources and runtime downloads; document the “allowed sources” stance.
• Package artifacts in Daydream (or your GRC system) into a single SC-18 evidence set: policy, matrix, configs, logs, samples, and exceptions.

Frequently Asked Questions

Does “mobile code” only mean Java in a browser?

No. SC-18 is broader: any code delivered or executed dynamically, including scripts, macros, plug-ins/extensions, downloaded executables, and runtime-fetched dependencies. Your definition must match what actually runs in your environment. (NIST Special Publication 800-53 Revision 5)

We need JavaScript for our app. How can we be compliant?

Allow JavaScript but restrict the risky parts: manage browsers with enterprise policy, control extensions, and monitor for policy violations. Document the decision in your matrix and show the enforcement settings. (NIST Special Publication 800-53 Revision 5)

Are Office macros automatically prohibited under SC-18?

SC-18 does not mandate a specific technology choice. It requires you to define what’s acceptable and then authorize, monitor, and control it. Many teams prohibit macros by default and allow signed macros by exception because it is easier to enforce consistently. (NIST Special Publication 800-53 Revision 5)

How do we handle third-party tools that download plug-ins or updates?

Treat plug-ins and dynamic updates as mobile code. Require a documented approval, limit allowed sources where possible, and monitor execution and installation events tied to the tool. Keep evidence that the setting is enforced and reviewed. (NIST Special Publication 800-53 Revision 5)

What evidence is most persuasive in an audit?

A tight set: your mobile code standard, the allow/deny matrix, configuration exports proving enforcement, and monitoring artifacts showing detection and review of attempted violations. Tie exceptions to tickets with approver, scope, and expiry. (NIST Special Publication 800-53 Revision 5)

Can we satisfy SC-18 with EDR alone?

EDR helps with monitoring and response, but auditors still expect explicit definitions of acceptable/unacceptable mobile code and enforceable controls that limit execution. Pair EDR telemetry with configuration baselines and an authorization workflow. (NIST Special Publication 800-53 Revision 5)