SC.L2-3.13.13 Mobile code: requirements and evidence

What SC.L2-3.13.13 mobile code requires and why assessors check it

A defense contractor that handles CUI must control which mobile code runs on its systems and monitor how that code is used. Mobile code here means active content that a system downloads and executes without a separate installation step, such as scripts, browser plugins, macros and similar components. If your CUI systems run any of these, SC.L2-3.13.13 expects you to decide which technologies are acceptable, restrict the rest, and be able to show that the restrictions are watched. The risk is straightforward: unvetted active content can run with the user's privileges, reach data it should not touch, and pull in code from sources you never reviewed. The requirement is worth 1 point under the CMMC scoring model, but it is still part of the 110 Level 2 requirements and assessors test it in full.

NIST SP 800-171A breaks the requirement into two assessment objectives: the organization controls the use of mobile code, and it monitors that use. An assessor will ask for the list of acceptable and unacceptable mobile code technologies, the authorization records behind that list, and the usage restrictions and procedures that apply to them. They will then look for system monitoring records or audit records showing that use is actually checked. What usually makes this hard is not the policy sentence but the inventory: teams often cannot name every script engine, browser extension or macro-enabled tool in use, and authorization records drift as software changes. Monitoring is the other gap, because the CMMC Assessment Guide accepts monitoring through boundary devices, audit logs, or tools such as mobile device management and advanced endpoint protection, and you need to show which of these covers which systems.

Before you plan work around this control, confirm current assessment timing with your contracting officer. On 13 July 2026 the Department of War suspended CMMC Phase II, which had covered Level 2 C3PAO certification for applicable contracts, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so the mobile code evidence still matters for your self-assessment and for any contract that requires it. Ask your contracting officer which assessment applies to your contracts and whether the requirement is currently in scope for your SPRS score.

Which systems, teams and third parties fall under mobile code control

Mobile code control for SC.L2-3.13.13 applies wherever code can be downloaded and run inside the CUI environment, not only on servers. The decisions below determine what the assessor will sample, and each one has a different owner, so agree them in writing before the evidence is collected.

CUI-processing endpoints and servers

Every workstation, server and virtual machine that stores, processes or transmits CUI is inside the requirement. Scripts, macros, plug-ins and runtime components that these hosts fetch or execute are the core of the control. Ask the system owner to list which script engines (for example PowerShell, Python, or Java runtimes) are installed and which are permitted to run unsigned or downloaded content. Confirm that the list matches the system security plan boundary.

Browsers and email clients

Browsers and mail clients are the most common route for active content to reach CUI systems. Decide which browser extensions, ActiveX-style components, PDF scripting and macro settings are allowed, and who approves exceptions. IT operations usually owns the settings through group policy or device management, while the security team owns the approved list. Scope often expands when a user installs a browser extension that nobody inventoried.

Mobile devices that touch CUI

Phones and tablets that receive CUI email, access CUI file shares or run line-of-business apps are part of the scope even when they are personally owned. The control question is which mobile code technologies, such as web views, embedded scripting in apps and app store installs, the device policy permits. Mobile device management is the usual place to enforce this. Confirm with HR and IT whether bring-your-own-device enrollment brings these devices into the assessed environment.

Web applications that serve active content

Internal and customer-facing web applications that send JavaScript, WebAssembly or embedded components to users are a mobile code source the organization may own directly. The development team usually controls the code, but the security team should define which content types are acceptable and how third-party scripts are reviewed before release. Review content security policy settings and script sources with the application owner, and record the decision in the application's documentation.

Third-party and cloud services that deliver code

Content delivery networks, analytics tags, SaaS widgets, managed service provider remote tools and cloud collaboration plug-ins can push code into the environment without any change request. Procurement and the system owner should jointly list each service that delivers executable content to CUI users, and check whether the service is inside or outside the system boundary. Scope commonly expands here when a business unit adds a new SaaS tool with a tracking script.

Ownership and drift checks

Assign one accountable owner for the mobile code authorization list, usually the system security officer, with named technical owners for each platform. Review the list after every change to the boundary, new software deployment or new vendor onboarding. Ask the assessor's evidence list to show who approved each entry and when it was last reviewed, since an unowned list is the most common reason an assessor cannot mark the objective as met.

How an assessor tests the two 3.13.13 objectives

This table compares the two assessment objectives for SC.L2-3.13.13, the evidence an assessor asks for under each, and the findings that most often stop a requirement from being marked MET. Read each row as a question the assessor will ask, then check that your own records answer it in final form.

Test point	Control objective: use of mobile code is controlled	Monitoring objective: use of mobile code is monitored
What the assessor checks	That the organization defined which mobile code technologies are acceptable, which are unacceptable, and who may authorize exceptions, then enforced those decisions on systems in scope.	That the organization can see mobile code running on in-scope systems and keeps records that show the monitoring actually happened over time.
Evidence usually requested	Mobile code usage restrictions and procedures, the list of acceptable and unacceptable technologies, and signed authorization records for any technology allowed by exception.	System monitoring records, audit records, and the boundary device, log or endpoint tool configuration that produced them, covering the review period.
Where the assessor compares sources	The approved list against what is actually installed or enabled on endpoints, browsers and servers in the assessment scope.	Monitoring configuration against retained output, for example scheduled queries or policy results with timestamps, not a screenshot of the tool setup.
Common finding: list mismatch	The approved list names a browser plugin or scripting runtime that is not on the endpoint, while a different runtime is present and never assessed.	Monitoring covers only some device groups, so mobile code on unmanaged or offline endpoints goes unseen.
Common finding: authorization gaps	Authorizations exist but carry no review date, no named owner, and no statement of the conditions under which the exception still applies.	Monitoring findings are generated but no one records how they were reviewed or what action followed.
Common finding: configured but not producing records	Blocking rules exist in policy but the enforcement logs are not retained, so the assessor cannot confirm the control worked during the period.	Monitoring is configured on paper, yet the query schedule is paused, the log forwarder is broken, or retention is shorter than the review cycle.
Evidence form the assessor expects	Current, dated documents approved by the owner, with version history. Drafts do not count toward MET.	Records generated in the assessment period, kept in a form the assessor can sample. Drafts do not count toward MET.
Effect on the requirement	Both objectives must be satisfied for SC.L2-3.13.13 to be MET, so a gap in either one leaves the requirement unmet.	Both objectives must be satisfied for SC.L2-3.13.13 to be MET, so monitoring with no retained records fails the requirement even when the list is complete.

Evidence that passes for mobile code control and how to keep it current

An assessor testing SC.L2-3.13.13 looks for two things: a documented decision about which mobile code is allowed, and proof that the organization watches for it. The cards below cover the artifacts that show both, and the recurring work that keeps them accurate between assessments.

Mobile code usage standard and procedure

This is the written rule set: which mobile code types the organization permits (for example, scripts, macros, applets or web-delivered components), where they may run, and who approves exceptions. Assessors use it to confirm that the control is defined before they look at systems. Check that it names the in-scope systems, assigns an owner, and states how a blocked technology is handled. Review it on a set schedule and after major changes to browsers, office suites or plugin policies, and record each review with a date and approver.

Dated register of acceptable and unacceptable technologies

The register lists each mobile code technology with its status, the systems it applies to, and the date it was last confirmed. It is the reference that makes the standard testable, since an assessor can compare it against what runs in the environment. Keep one row per technology, including browser plugins, macro settings and scripting engines. Version the file, so an auditor can see what was approved at the time of assessment rather than only today's list.

Signed authorization records

Each exception to the register needs a signed authorization that states the business reason, the compensating controls, the named approver, the expiry date and the systems covered. Without this record, a permitted technology looks like an unmanaged one. Review open exceptions on a recurring schedule, and close any whose justification has lapsed. Confirm that approvals are signed by someone with authority over the system, not by the person who requested the exception.

Monitoring configuration exports

Exports show how monitoring is actually set up: firewall or proxy rules that block or log mobile code downloads, endpoint policies that restrict script execution, and collection queries that report on mobile code in use. The CMMC Assessment Guide for Level 2 points to boundary devices, audit logs, and tools such as mobile device management and advanced endpoint protection as ways to monitor. Export these configurations on a schedule and store them with timestamps, so the configuration shown to the assessor matches the one that was running during the period under review.

Sample alerts and query results

Sample output proves that monitoring produces findings and that someone acts on them. Examples include a scheduled osquery query listing browser plugins or running script interpreters across the fleet, a Fleet policy result showing which devices fail a mobile code policy, or a Wazuh configuration assessment finding with its remediation record. Save representative results from each reporting period, and keep the ticket that shows how each failing device was resolved. A query with no saved output is hard to defend.

Retained audit records

Audit records show that monitoring ran over time, not only on the day of the assessment. Retain logs from boundary devices, endpoint tools and the monitoring platform itself, and confirm that they cover the whole assessment period with synchronized timestamps. Decide the retention period with the contracting office and your own policy, and confirm it with the assessor before you rely on it. Test restoration of archived logs at least once, because an export nobody can open does not satisfy the requirement.

Implementing SC.L2-3.13.13 in six steps

This sequence turns the mobile code requirement into a documented, enforced and monitored practice, so an assessor can see who decided which technologies are acceptable, how the organization blocks the rest, and what the monitoring records show over time.

Inventory mobile code technologies in use
Start by listing every place mobile code runs in the system boundary: browser scripts and plugins, macros in office documents, Java or ActiveX-style components, PowerShell and other scripts that move between systems, and mobile apps on managed devices. Pull the list from endpoint and browser management consoles, software inventories and interviews with system owners, not from memory. The output is a dated inventory with each technology, where it runs, who uses it and whether it is needed for a business function. Confirm the scope with your assessor's expectations before you treat the inventory as final.
Write mobile code usage restrictions
Draft a usage restriction document that states which categories of mobile code are permitted, under what conditions, and which users or device classes may run them. Name the owner who approves exceptions and the procedure for requesting one. Keep the language tied to your system, because SP 800-171A lists usage restrictions and procedures as potential evidence. The output is an approved policy or standard with a version number, an owner and an approval date, stored where the system security plan can reference it.
Build the authorized and unauthorized technology lists
Convert the restrictions into two lists: acceptable mobile code technologies, with the configuration or version constraints that apply, and unacceptable technologies that are blocked outright. For each acceptable entry, record the authorization decision, the approver, the business reason and the review date. Assessors look for authorization records that match what is actually running, so reconcile these lists against the inventory from step one. The output is a signed authorization record for each technology and a short list of blocked items.
Configure enforcement and monitoring controls
Implement the decisions in the tools you already run. Boundary devices such as firewalls and web proxies can block or inspect certain content types. Endpoint management and advanced endpoint protection can disable plugins, restrict script hosts and block macro execution. Audit logs record what ran and where it was blocked. Confirm each setting against the authorization list and document the configuration as a baseline. Open-source options such as osquery can query running processes, browser plugins and loaded modules across a fleet, Fleet policies can report which devices pass or fail a yes or no check, and Wazuh configuration assessment can flag misconfigured endpoints. Verify that each tool's capabilities match your environment before you rely on it. The output is a configuration record and a monitoring source for each control.
Set a recurring review cycle
Define how often the inventory, authorization lists and monitoring results are reviewed, and who signs off. Include triggers that force an earlier review, such as a new browser release that changes plugin behavior, a new business application or an alert that shows unauthorized mobile code. Record each review with its findings, the changes made and the people who approved them. This step shows the control is maintained, not set once. The output is a review schedule in the system security plan and dated review records that match the cycle you defined.
Collect evidence in final form
Gather the artifacts an assessor will test against the two assessment objectives for 3.13.13, controlling use and monitoring use. Typical evidence includes the approved restriction document, the signed authorization records, configuration exports, samples of monitoring output or log entries showing blocked or flagged mobile code, and the review records. Confirm that each item is final, approved and dated, because draft documents do not satisfy an objective under the CMMC scoring rules. Map each artifact to the objective it supports and store them in one controlled location. The output is an evidence package that can be shown to an assessor without further explanation.

Open-source tools that produce mobile code monitoring evidence

Mobile code monitoring evidence usually comes from endpoint visibility, not from a single product. The four self-hosted tools below answer different questions an assessor may ask about what runs on managed endpoints and how the organization detects unauthorized mobile code. Confirm each fit with your own environment and with your assessor before relying on it as evidence.

Fleet-wide queries with osquery

osquery exposes running processes, loaded kernel modules, browser plugins, open network connections and file hashes as SQL tables. The osqueryd daemon schedules these queries across an entire fleet, so you can show which hosts run browser extensions or scripted components that fall outside your authorized list. Confirm which tables and query schedules your assessor expects, and retain the results as monitoring records. The license is Apache-2.0 OR GPL-2.0-only, so confirm which license your organization will rely on for distribution.

Yes or no policies with Fleet

Fleet policies are yes or no questions written as osquery queries, such as whether an approved browser extension list is in place or whether an unapproved runtime is installed. The policies page shows which devices in each fleet pass or fail, which gives you a dated record of the authorization check itself. Ask your assessor whether a policy result plus a documented exception process satisfies the monitoring objective. Fleet is MIT licensed, so license review is usually simple, but confirm your hosting and support model with the vendor.

Artifact hunts with Velociraptor

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts across groups of systems. Offline machines are scheduled to collect when they reconnect, and each hunt gets a notebook for analyzing combined results. This supports investigation and retrospective review when you need to show what mobile code was present on which systems at a given time. Velociraptor is licensed AGPL-3.0-only, which can carry network-use obligations if you modify and expose it, so have counsel review the terms before deployment.

Configuration checks with Wazuh

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and checks files, directories, registry keys and running processes. You can add custom policies that flag specific browser settings, script hosts or blocked technologies, and the results include remediation guidance. Use the scan output as recurring evidence that the authorized technology list is enforced. Wazuh is GPL-2.0-only, so confirm how your organization distributes any modified components before you depend on them.

Cost to meet SC.L2-3.13.13 mobile code in money and effort

This table breaks down the cost components of meeting SC.L2-3.13.13 with self-hosted open-source tooling, who is paid for each one, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request and to separate license spend from infrastructure, staffing and assessor effort. The main takeaway is that open-source tooling removes license cost but not the engineering, standard writing and evidence upkeep that the requirement actually demands.

Cost component	Who is paid	One-time or recurring	What drives it
Tooling and licenses	Software vendors, or no license fee for open-source tools	Recurring if commercial, otherwise none	Open-source tools such as osquery, Fleet or Wazuh remove license spend but not hosting or staffing
Hosting and infrastructure	Your cloud provider or data center team	Recurring	Number of endpoints reporting, log volume and retention period
Monitoring configuration	Internal engineers or an implementation partner	One-time, with periodic changes	Number of browsers, plugins and mobile code technologies to detect and block
Mobile code inventory and standard	Internal security and compliance staff, or a consultant	One-time, then updated on change	Count of approved and prohibited mobile code technologies and the number of user groups affected
Boundary and log integration	Network or SIEM administrators	One-time, with recurring review	Number of CUI boundary devices and existing SIEM coverage that can ingest their logs
Evidence upkeep and review cycles	Internal compliance staff	Recurring	Frequency of authorization reviews, policy changes and monitoring report sign-off
External readiness review or testing	Independent consultant or security testing firm	Optional, usually one-time before assessment	Scope of the review and whether it tests monitoring coverage on live endpoints
Assessor effort	Independent assessor (C3PAO) under contract	One-time per assessment cycle	Quality and completeness of evidence in final form, and how many objectives must be shown

In-house team, implementation partner or auditor: who does what for mobile code

The organization owns the requirement. Under SC.L2-3.13.13 it must control and monitor mobile code, which means it has to decide which mobile code technologies are acceptable, who may approve them, and how the decisions are reviewed. No outside firm can make those decisions on the organization's behalf, and an assessor will expect to see that the people named in the records actually made them.

Mobile code policy: Write and approve the usage restrictions that define acceptable and unacceptable mobile code technologies for systems that handle CUI.
Authorization decisions: Record who approved each technology, when, and under what conditions, and keep those records current.
Periodic review: Schedule and document reviews of the acceptable list and of monitoring results, with the reviewer named.
Exception handling: Decide how business exceptions are requested, justified and time-limited, and keep the approvals on file.
Final evidence: Sign off the evidence package so that it reflects the organization's own decisions, not a draft.

Before engaging anyone, confirm internally who holds each of these roles and whether the policy already exists in your system security plan.

Where organizations fall short on mobile code control and how to close it

Most organizations have a mobile code policy on paper, but assessors look for proof that the policy matches what runs on endpoints today. The gaps below cluster around five things: the technology list, the authorization records, monitoring coverage, log history and the scope of the policy itself.

Technology list lags behind endpoints

The acceptable and unacceptable mobile code list is often written around browser scripting and never updated for what endpoints actually run, such as office macros, browser extensions, PDF scripting, PowerShell and Java runtimes. Assessors compare the list against real configurations, so an outdated list fails the first objective of SC.L2-3.13.13 Mobile code. Close it by inventorying the mobile code types present on managed devices, then having the owner sign off on the list with a review date.

Authorizations that never expire

Authorizations for specific mobile code technologies are frequently granted once and never revisited, so a plugin approved for a project years ago still runs across the fleet. Each authorization should name the technology, the approving owner, the business purpose and the systems it covers. Close it by setting a recurring review cycle and removing any authorization the owner cannot justify at review.

Monitoring that covers some endpoints

Monitoring is often deployed to laptops in the corporate office while remote endpoints, servers and virtual machines fall outside the query scope. An assessor will ask for the population of devices covered and for proof that coverage is complete. Close it by reconciling the monitoring agent inventory against the asset inventory and reporting the gap as a tracked exception.

Logs too short to show history

Mobile code monitoring records are sometimes kept only in the local console or overwritten within days, which leaves no history for an assessor to sample. Evidence of ongoing monitoring needs records covering the assessment period, not a single screenshot taken for the review. Close it by confirming with the platform owner how long query results and alerts are retained, then setting retention to match your contract and assessment cycle.

Policy stops at the browser

Many policies address web browsers and ignore plugins, macros in office files, scripts on mobile devices and code delivered through managed applications. A policy that names only browsers leaves the other mobile code channels uncontrolled and unmonitored. Close it by listing every execution path on each device class, including mobile devices, and assigning a control and monitoring method to each one.

Questions buyers ask about SC.L2-3.13.13 cost, effort and outside help

How much effort does SC.L2-3.13.13 take compared with other SC requirements?

It is one of the lighter System and Communications Protection requirements in effort terms, because it is worth 1 point and asks for two things: control over which mobile code technologies are used, and monitoring of that use. The heavier SC requirements, such as boundary protection and FIPS-validated encryption, involve network design, cryptographic module selection and configuration across many systems. For 3.13.13, the work is mostly a short list of acceptable and unacceptable mobile code technologies, an authorization record for each, and evidence that the monitoring you chose actually runs. Effort rises when the environment has many browsers, plugins, scripting engines or user-installed tools, because each one needs a decision. Ask any partner to show the inventory they will build before agreeing to a price.

Can SC.L2-3.13.13 go on a POA&M if we are not ready?

It can, under the CMMC scoring rules. Under 32 CFR 170.24 this requirement is worth 1 point, and it is not on the exclusion list in 32 CFR 170.21, so it may sit on a plan of action and milestones (POA&M) if your score is at least 88 of 110 (0.8). Closeout of the POA&M item is due within 180 days. Confirm the current status of these rules before relying on them, because the Department of War has suspended CMMC Phase II. A POA&M is a stopgap, not a plan to skip the control. Many organizations should close this item before an assessment, since a monitoring tool and an authorization list are inexpensive compared with the cost of a rushed closeout. Use the POA&M only where the score threshold is met and the closeout plan is realistic.

Can we meet SC.L2-3.13.13 ourselves with open-source tools?

Often yes, because the monitoring options are open source. The CMMC Assessment Guide for Level 2 points to boundary devices such as firewalls, audit logs, and security utilities such as mobile device management and advanced endpoint protection. Open-source tools can support the monitoring part: osquery can query running processes, loaded kernel modules, browser plugins and file hashes across hosts, Fleet policies can show which devices pass or fail a yes or no check, and Wazuh configuration assessment can check files, directories and processes. The control itself, the decision about which mobile code is acceptable, is a policy the organization owns. Staff with endpoint and logging experience can usually build this in-house. Organizations without that skill often bring in an implementation partner to prepare the tools and evidence, while the organization keeps ownership of the decisions.

What does this requirement need from our IT and security staff?

It needs a small set of named people who own three things: the list of mobile code technologies, the authorization decisions, and the monitoring records. Typically this means an endpoint or IT administrator who can deploy and maintain query or policy tooling, a security lead who approves or rejects technologies and signs the authorization records, and a compliance owner who keeps the evidence in final form. Expect the work to touch browser and plugin management, scripting runtime settings and any mobile device management platform already in use. Staff should also agree how exceptions are recorded and reviewed. Ask any partner to name which of your roles they expect to need, and how many hours per week, in writing as part of the scope.

How long does SC.L2-3.13.13 take to implement?

The duration depends on your environment, including the number of endpoints, how many mobile code technologies are in use, whether monitoring tools already exist, and how quickly approvals move through your governance process. Nothing in the supplied facts gives a fixed duration for this requirement, so do not accept a generic figure. Ask the partner for a written scope that lists the inventory, the authorization process, the monitoring deployment, the test of each assessment objective and the evidence to be collected, each with a schedule. A well-defined scope lets you compare offers on the same basis and shows where delays are likely.

What should we confirm about the current CMMC assessment schedule?

Confirm which phase applies to your contracts and whether a certification assessment or a self-assessment is required. The Department of War announced on 13 July 2026 that it suspended CMMC Phase II, which had been scheduled to start 10 November 2026, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO page also says implementation may only require self-assessments at Levels 1 and 2, while the eCFR text still reflects the original schedule. Check the contracting officer's requirements in writing, and check the current status of the review before planning around any date.

How DeployOpen scopes and prepares mobile code evidence

DeployOpen works on SC.L2-3.13.13 Mobile code as a fixed-scope engagement inside your own environment. We help you define the mobile code technologies you allow, document the authorizations behind them, and prepare the monitoring records an assessor will ask to see, while your organization keeps ownership of the control and the independent assessor issues any findings.

How we scope

Inventory the mobile code technologies in use across browsers, email, documents and internal applications.
Agree in writing which technologies are acceptable, restricted or prohibited, and who approves each one.
Confirm the boundary devices, logs and endpoint tools that will serve as monitoring points for the written scope.

How we build

Configure endpoint and browser policies that enforce the acceptable mobile code list in your environment.
Deploy query-based monitoring, such as osquery or Fleet policies, to detect unapproved mobile code on managed hosts.
Set up log forwarding from boundary devices and endpoints so monitoring records are retained and reviewable.

How we hand over

Deliver the mobile code usage restrictions, procedures and authorization records as documents your staff own.
Provide sample monitoring outputs and dashboards that show how each approved technology is checked.
Walk your assessment team through where each piece of evidence lives and how to retrieve it in final form.

How we support

Review the authorization list and monitoring queries when your technology stack or assessment scope changes.
Offer ongoing support, upgrades and continuous testing under a retainer agreed in writing.
Confirm with your assessor or C3PAO which evidence formats they accept before the assessment begins.