SC-18: Mobile Code

To meet the sc-18: mobile code requirement, you must define which mobile code technologies are allowed or prohibited in your environment, then enforce those rules through technical controls and documented procedures. Operationalize SC-18 by building an inventory of mobile code entry points, setting default-deny rules, and retaining evidence that controls work in production ¹.

Key takeaways:

• Define “acceptable vs. unacceptable” mobile code by technology, source, and execution context, not generic statements ¹.
• Enforce the definition with prevent/detect controls at endpoints, browsers, email/web gateways, and CI/CD pipelines.
• Keep assessor-ready evidence: policy, configuration baselines, exceptions, monitoring, and a current inventory of where mobile code can run.

SC-18 is one of those controls that looks short on paper and becomes messy in real environments. “Mobile code” shows up through browsers (JavaScript, WebAssembly), documents (macros), packaged apps (Electron), scripts (PowerShell, Python), and third-party plugins. If you treat SC-18 as a single policy statement, you will fail the operational test: can you prove you know where mobile code executes, which types you allow, and that you block or constrain everything else?

The requirement is fundamentally about reducing risk from code that arrives from outside a system’s normal change process, then executes locally or in a user context. That includes code fetched at runtime (web content), embedded content (documents), and code delivered through third parties (extensions, ad tech, analytics tags, npm packages, SaaS scripts). Your job as the compliance owner is to force specificity: define what’s allowed, define what’s forbidden, define the decision authority for exceptions, and show technical enforcement plus monitoring.

This page gives you requirement-level implementation guidance you can assign to IT, security engineering, and application teams, and then verify with evidence that stands up to an assessor ².

Regulatory text

Requirement excerpt: “Define acceptable and unacceptable mobile code and mobile code technologies; and” ¹

What the operator must do:
You must publish a clear, enforceable definition of (1) which mobile code technologies you allow and (2) which you prohibit, with enough detail that system owners can implement controls and an assessor can test them. Treat “and” as a prompt to complete the operational loop: define the rules, then implement enforcement and exception handling so the definition is real in production ¹.

---

Plain-English interpretation

SC-18 requires you to decide what “code that can run without a traditional install/change process” is allowed to execute in your environment, under what conditions, and from which sources. Then you must make that decision actionable.

In practice, SC-18 is satisfied when you can answer these questions quickly:

• What mobile code is permitted on corporate endpoints, servers, and within sanctioned SaaS/browser contexts?
• Where can mobile code execute (browsers, office documents, CI runners, developer laptops, VDI, kiosks)?
• What enforces the rule (configuration baselines, allowlisting, macro controls, extension controls, gateway filtering, runtime controls)?
• How are exceptions approved, time-bounded, and monitored?

---

Who it applies to

SC-18 is commonly scoped to:

• Federal information systems and any in-scope subsystems where code execution risk matters ².
• Contractor systems handling federal data, including environments supporting contracts that inherit or map to NIST SP 800-53 controls ².

Operational contexts where SC-18 becomes testable:

• End-user computing: browsers, productivity suites, local scripting, endpoint controls.
• Application delivery: web apps pulling third-party scripts, tag managers, CDNs, remote libraries.
• Dev and build: CI/CD fetching packages, build scripts, container entrypoints, Infrastructure as Code.
• Third-party access: support tools, remote management agents, plugins, browser extensions.

---

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

1) Define “mobile code” for your environment (don’t leave it implicit)

Create a short definition section that names concrete examples you actually see:

• Browser-executed code (JavaScript, WebAssembly)
• Document-embedded code (Office macros, PDF JavaScript where applicable)
• Interpreted scripts (PowerShell, Python, bash) when executed outside approved pipelines
• Extensions/plugins (browser extensions, IDE plugins)
• Third-party web tags and embedded widgets

Keep it pragmatic: SC-18 is about controlling code execution paths that bypass normal software approval and change control ¹.

2) Build an “Acceptable / Unacceptable” decision matrix

Publish a one-page table that teams can use without calling compliance.

Example decision matrix (edit to fit your stack):

Mobile code type	Default stance	Allowed when	Owner
Office macros	Restricted	Signed macros from approved publishers; business justification documented	Endpoint Security
Browser extensions	Deny by default	Only from corporate allowlist; monitored inventory	IT / Endpoint
Third-party web scripts	Restricted	Only from approved vendors/domains; change-reviewed	AppSec / Web Eng
PowerShell scripts	Restricted	Signed scripts; executed via managed tooling	SecOps
CI/CD package installs	Allowed with controls	Pinned versions; integrity checks; approved registries	DevOps

Your matrix is the core SC-18 artifact. It is also what assessors will test against configs and observed behavior.

3) Identify enforcement points (where you can actually block or constrain)

Create a simple inventory of control planes that can enforce your definition:

• Endpoint configuration (OS hardening, application control, macro policies)
• Browser management (extension allowlisting, enterprise policies)
• Email and web gateways (blocking risky attachments, script-bearing file types, known bad categories)
• Network controls (egress allowlists for script CDNs where feasible)
• CI/CD guardrails (approved registries, integrity verification, build isolation)
• Web app controls (CSP, SRI, tag governance for third-party scripts)

You do not need perfect coverage on day one. You do need a defensible story: high-risk paths get priority controls, and the rest are on a roadmap with owners.

4) Implement “default deny + exception” where feasible

For at least the highest-risk mobile code categories, set a default-deny posture and allow by exception:

• Deny unknown browser extensions; allow approved list.
• Block macros from the internet; allow signed macros or controlled repositories.
• Restrict scripting engines on non-admin endpoints; allow via managed admin workstations or signed execution.

Write the exception workflow so it can run without heroics:

• Request intake (ticket)
• Risk review criteria (data sensitivity, user population, compensating controls)
• Approval authority (control owner, not the requester)
• Time bounds and review triggers (role change, vendor change, renewal)
• Monitoring requirements (logging enabled, inventory tracked)

5) Add monitoring that proves the control works

Assessors often fail SC-18 implementations because controls exist but nobody can prove they operate. You want routine evidence like:

• Reports of blocked macro executions
• Browser extension inventory diffs
• Alerts for unsigned scripts running
• Web app scans detecting new third-party scripts/domains

Tie monitoring outputs to your decision matrix categories. If you can’t measure it, you can’t defend it.

6) Map ownership and recurring evidence

Assign one accountable owner per category and require recurring evidence artifacts. This is the minimum “control mechanics” that keeps SC-18 from decaying. If you use Daydream, set SC-18 to a named owner, attach the decision matrix, and schedule evidence requests (policy review, config exports, monitoring snapshots) so you are not rebuilding proof during an audit.

---

Required evidence and artifacts to retain

Keep evidence that matches the requirement language (“define acceptable and unacceptable”) and proves enforcement.

Core artifacts

• SC-18 standard/policy section defining mobile code, plus the Acceptable/Unacceptable matrix ¹.
• Documented exception process with approval criteria and authority.
• Current inventory of mobile code execution surfaces (browsers, productivity tools, scripting runtimes, CI/CD, web apps).

Operational evidence (pick what matches your tooling)

• Configuration baselines or exports showing macro controls, script controls, and browser extension policies.
• Allowlists (approved extensions, approved script domains/vendors, approved registries).
• Tickets for exceptions with approvals and expirations.
• Monitoring outputs (blocked events, detections, periodic inventories) tied to the categories in your matrix.

---

Common exam/audit questions and hangups

What auditors ask

• “Show me your definition of acceptable vs unacceptable mobile code.” (They want specificity, not a paragraph.)
• “Where is it enforced?” (They will pick one endpoint and one web app and test.)
• “How do you prevent users from installing extensions/running macros?” (They expect deny-by-default or strong constraints.)
• “Show exceptions.” (They expect documented approvals and evidence of review.)
• “How do you address third-party scripts in web apps?” (They expect governance, not just developer discretion.)

Where teams get stuck

• No single owner across endpoint, browser, and application layers.
• Definitions that don’t map to technical settings (“we restrict mobile code” with no list).
• Exceptions granted informally, then never revisited.

---

Frequent implementation mistakes and how to avoid them

1. Writing a policy that names no technologies.
   Fix: publish the decision matrix and keep it under change control.

2. Treating browser JavaScript as “out of scope.”
   Fix: explicitly address third-party scripts, tag managers, embedded widgets, and CDNs in your acceptable/unacceptable definitions.

3. Allowing “temporary” exceptions with no expiry.
   Fix: require expiration plus a re-approval trigger tied to vendor renewals or system changes.

4. No evidence that controls run in production.
   Fix: define recurring evidence (config exports + monitoring snapshots) and store it centrally per system or control family.

5. Forgetting third parties.
   Fix: require third-party-provided code (agents, plugins, scripts, SDKs) to go through the same acceptability decision and inventory tracking.

---

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SC-18 primarily as an assessment-readiness and breach-risk control rather than a “find a case and mirror it” exercise. The risk is straightforward: mobile code paths are common initial execution vectors, and they often bypass standard software deployment controls. SC-18 reduces that exposure by forcing explicit rules, technical gating, and evidence that gating is active ².

---

Practical 30/60/90-day execution plan

First 30 days (establish the rulebook + owners)

• Name a control owner and backups for endpoint, browser, CI/CD, and web application mobile code categories.
• Draft the Acceptable/Unacceptable matrix and get sign-off from Security and IT.
• Identify top mobile code entry points (macros, extensions, scripts, third-party web tags) and document current state.
• Stand up an exception workflow in your ticketing system and require approvals + expiration.

By 60 days (enforce on the high-risk paths)

• Implement deny-by-default controls where feasible: extension allowlisting, macro restrictions, script execution constraints.
• Create initial allowlists and publish request procedures for additions.
• Start collecting operational evidence (config exports and monitoring snapshots) in a single audit-ready repository.

By 90 days (prove operation + close gaps)

• Run an internal spot check: sample endpoints, a CI pipeline, and a production web app. Confirm the controls match the matrix.
• Review exceptions: validate business need, remove stale approvals, and document compensating controls where full enforcement isn’t possible.
• Formalize recurring evidence cadence in Daydream (or your GRC system): policy review, allowlist review, config verification, monitoring review.

---

Frequently Asked Questions

What counts as “mobile code” for SC-18 in a modern enterprise?

Treat mobile code as code that can be delivered dynamically or embedded and executed without your standard software deployment lifecycle. In most environments that includes browser scripts, macros, extensions, and common scripting runtimes ².

Do we have to block all mobile code to satisfy SC-18?

No. The requirement is to define what is acceptable and unacceptable, then enforce that definition ¹. Most programs allow common technologies but restrict them by source, signing, and administrative control.

How do we handle third-party web scripts and tag managers under SC-18?

Put them explicitly in your decision matrix, require an approval path for new third-party script sources, and maintain an inventory of approved domains/vendors. Back it with technical controls where possible and monitoring that detects new or changed scripts.

What evidence is usually most persuasive to an assessor?

A clear matrix of allowed/prohibited technologies, configuration outputs showing enforcement, and a small set of monitoring reports that demonstrate blocking or detection events. Include exception tickets with approvals and expiration dates.

Our developers need scripting (PowerShell/Python). How do we restrict it without breaking work?

Separate developer/admin use cases from general user endpoints. Allow scripting in managed contexts (approved machines, signed scripts, controlled repositories) and restrict it elsewhere, with exceptions documented and monitored.

How does Daydream help with SC-18 execution?

Daydream is effective when you use it to assign owners per mobile code category, store the decision matrix and exception records, and automate recurring evidence collection (config exports, inventories, monitoring snapshots) so SC-18 stays continuously audit-ready.

Footnotes

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

2. NIST SP 800-53 Rev. 5