SC-18: Mobile Code

Quick-reference card

What this control requires

SC-18 requires organizations to define which mobile code technologies are acceptable, which aren’t, and then authorize, monitor, and control their use across every system. Most security teams treat mobile code as a development concern, but NIST SP 800-53 frames it as a communications protection problem because mobile code travels across network boundaries and executes on remote systems.

In practice, this control means you need two things. First, a documented policy that classifies mobile code technologies, such as JavaScript, Java applets, HTML5, WebGL, and VBScript, into approved and prohibited categories. Second, you need technical and procedural controls that enforce those classifications on both servers and endpoints, including notebooks and smartphones.

The rationale is straightforward. Mobile code can be embedded in emails, documents, and websites, then executed on a target system without the user’s full awareness. Without a formal classification and enforcement mechanism, your organization has no defensible position when an auditor asks how you govern code that crosses trust boundaries. SC-18 sits within the System and Communications Protection family because the risk originates from the movement of executable content across your network perimeter.

Why it matters

Mobile code governance failures rarely produce headline breaches, but they consistently produce audit findings that stall compliance certifications and delay business outcomes. For organizations pursuing MODERATE or HIGH baselines under NIST SP 800-53, SC-18 is a control that auditors expect to see documented and enforced, not just acknowledged.

The core risk isn’t a single catastrophic exploit. It’s the cumulative exposure that builds when executable content flows into your environment without classification, authorization, or monitoring. Every browser session, every email attachment with embedded macros, and every third-party web application that loads dynamic scripts represents a trust decision your organization is making, whether it knows it or not.

Where this control becomes a practical problem is in scope. Mobile code doesn’t live in one place. It runs on servers, workstations, laptops, and mobile devices. Organizations that limit their mobile code policy to desktop browsers leave entire device classes ungoverned, and that gap is exactly what auditors flag.

Failing to implement SC-18 also weakens the effectiveness of related controls. Without mobile code classifications, your baseline configurations (CM-02) and configuration settings (CM-06) lack a reference point for what code should and shouldn’t be running. Your malicious code protections (SI-03) can’t distinguish between authorized and unauthorized executable content.

What attackers exploit

• Malicious JavaScript injected through cross-site scripting (XSS) vulnerabilities in web applications, allowing code execution in users’ browsers
• Weaponized email attachments containing embedded macros or VBScript that execute when opened
• Drive-by downloads from compromised websites that deliver executable content through browser plugins or HTML5 features
• Supply chain attacks through third-party scripts loaded from external content delivery networks, where a compromised upstream library runs code in your environment
• WebGL and HTML5-based exploits that leverage browser rendering engines to execute unauthorized operations on endpoints

How to implement

The biggest implementation challenge with SC-18 is that mobile code is everywhere. It’s in the web applications your teams use daily, in the documents they receive, and in the third-party services integrated into your workflows. Building governance around something this pervasive requires a phased, risk-based approach rather than an attempt to catalog every script on day one.

For your organization

Start by conducting an inventory of mobile code technologies currently in use across your environment. Identify which technologies are actively deployed, where they run, and what business functions depend on them. This inventory becomes the foundation for your acceptable and unacceptable mobile code lists.

Draft a mobile code policy that explicitly classifies technologies into approved, restricted, and prohibited categories. Approved technologies should have documented business justifications. Restricted technologies should require case-by-case authorization with compensating controls. Prohibited technologies should be blocked at the technical level, not just forbidden in policy.

Implement technical enforcement mechanisms to support your policy classifications. Browser security policies, application allow-listing, and endpoint protection tools can restrict which mobile code technologies execute on workstations and servers. Group Policy Objects (GPOs) and mobile device management (MDM) solutions extend these restrictions to laptops and smartphones. Your attack surface management program should include visibility into externally-facing applications that serve or consume mobile code.

Establish an authorization process for exceptions. When a business unit needs a restricted mobile code technology, require a formal request that documents the use case, risk assessment, and compensating controls. Maintain authorization records that link each exception to a specific system and approver.

Set up monitoring and logging to detect unauthorized mobile code execution. Your event logging (AU-02) and audit record generation (AU-12) capabilities should capture mobile code-related events, including blocked execution attempts and policy violations. Review these logs regularly to identify patterns that suggest policy gaps or enforcement failures.

A common mistake is writing a mobile code policy that lists technologies but doesn’t define what “acceptable use” means for each one. Your policy should specify not just which technologies are allowed, but under what conditions, on which systems, and with what safeguards.

For your vendors

When assessing third-party compliance with SC-18, you’re looking for evidence that the vendor has thought about mobile code governance, not just inherited default browser settings. Start your assessment with targeted questions.

Ask vendors to provide their mobile code policy, including their lists of acceptable and unacceptable technologies. Request documentation of how those lists were developed and how often they’re reviewed. A vendor that can’t produce a current mobile code classification list likely doesn’t have meaningful governance in place.

Examine how the vendor enforces mobile code restrictions. Request evidence of technical controls such as content security policies, application allow-listing configurations, and browser restriction policies. Ask for recent system monitoring records that show mobile code-related events are being captured and reviewed.

Verify that the vendor has an authorization process for mobile code exceptions. Request sample authorization records to confirm that exceptions are formally documented with risk assessments and approver sign-offs. The absence of any exception records may indicate that the vendor either has no process or applies blanket approvals.

Red flags to watch for include vendors who can’t distinguish between their acceptable and unacceptable mobile code lists, vendors whose policies haven’t been updated to address current technologies like WebGL or HTML5, and vendors who have no monitoring data to demonstrate active enforcement.

Use the Vendor Risk platform to track vendor responses to mobile code governance questionnaires and maintain a continuous view of third-party compliance status. Document your verification approach so you can demonstrate to auditors that your vendor assessment process covers SC-18 requirements.

Evidence examples

Cross-framework mapping

Related controls

• AU-02 — Event Logging: provides the logging foundation needed to capture mobile code execution events and policy violations
• AU-12 — Audit Record Generation: generates the audit trails that demonstrate ongoing monitoring of mobile code activity
• CM-02 — Baseline Configuration: defines the approved system configurations that should include mobile code technology restrictions
• CM-06 — Configuration Settings: enforces specific settings that restrict or allow mobile code technologies on endpoints and servers
• SI-03 — Malicious Code Protection: detects and blocks malicious mobile code that bypasses policy-based governance controls

Frequently asked questions

What is NIST SP 800-53 SC-18

SC-18 is the NIST SP 800-53 control that requires organizations to define acceptable and unacceptable mobile code technologies, then authorize, monitor, and control their use within systems. Mobile code includes any program or content that can be transmitted across a network and executed on a remote system, such as JavaScript, Java applets, HTML5, WebGL, and VBScript. The control applies to code running on servers, workstations, laptops, and smartphones. It falls within the System and Communications Protection family and is required for MODERATE and HIGH baselines.

What happens if SC-18 is not implemented

Without SC-18, your organization lacks a defensible governance framework for executable content that crosses network boundaries, which creates direct audit risk for MODERATE and HIGH baseline certifications. Auditors will look for your mobile code classification lists and authorization records, and the absence of these artifacts typically results in a finding that must be remediated before certification can proceed. The gap also undermines related controls like baseline configurations (CM-02) and malicious code protections (SI-03), since neither can effectively govern code that hasn’t been classified as acceptable or unacceptable.

How do you audit SC-18

Auditing SC-18 starts with verifying that the organization has documented lists of acceptable and unacceptable mobile code technologies, along with a policy that defines usage conditions for each category. From there, you examine authorization records to confirm that mobile code use is formally approved, and review system monitoring records to verify that execution events are being captured and analyzed. Technical evidence should include browser security policies, application allow-listing configurations, and endpoint protection settings that enforce the documented classifications across all device types.

What are examples of mobile code technologies

Mobile code technologies include JavaScript, Java applets, HTML5, WebGL, and VBScript, which are all programs or content capable of being transmitted across a network and executed on a remote system. These technologies range from widely used web standards like JavaScript and HTML5 to legacy formats like VBScript and Java applets that many organizations now classify as prohibited. Your mobile code policy should address each technology individually, specifying whether it’s approved, restricted, or prohibited based on your organization’s risk tolerance and the systems where it operates.

Start a free trial to see how UpGuard helps organizations manage compliance and reduce cyber risk across their attack surface and vendor ecosystem.