CMMC Level 2 Practice 3.13.13: Control and monitor the use of mobile code

CMMC Level 2 Practice 3.13.13 requires you to control and monitor “mobile code” so it can’t execute in your CUI environment without authorization, visibility, and guardrails. Operationally, you need an allow/deny decision, technical enforcement (endpoint, browser, email, and application controls), and monitoring evidence that proves the control runs day to day. ¹

Key takeaways:

• Define what “mobile code” means in your environment, then set an explicit allow/deny policy for each class (scripts, macros, HTML, containers, installers).
• Enforce the policy with technical controls on endpoints, browsers, email, and application allowlisting; don’t rely on training alone.
• Keep assessor-ready evidence: configurations, logs, alert triage, and exception approvals mapped to 3.13.13. ¹

“Mobile code” is one of those requirements that gets waved off as “we have antivirus,” then fails in assessment because nobody can explain what is allowed, what is blocked, and where monitoring happens. For CMMC Level 2, you need to show that your organization can prevent unapproved code from executing and can detect when mobile code is introduced or runs in the environment that stores, processes, or transmits CUI. This practice maps to NIST SP 800-171 Rev. 2 control 3.13.13, so assessors will look for both control design (policy and configuration) and control operation (logs, alerts, and response) across the actual CUI boundary. ¹

From an operator standpoint, the fastest path is to treat this like an allowlisting and monitoring problem, not a “security awareness” problem. You inventory where code can execute, pick the few approved pathways you can defend (managed software installs, signed scripts, controlled macros, sanctioned SaaS), and then instrument everything else to block or alert. Your goal is simple: no unknown or untracked execution routes in the CUI environment, and proof that you monitor the routes you do allow. ¹

Target keyword

cmmc level 2 practice 3.13.13: control and monitor the use of mobile code requirement

Regulatory text

Excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.13 (Control and monitor the use of mobile code).” ¹

What the operator must do (plain reading):

• Decide which forms of mobile code are allowed to run in the environment handling CUI.
• Put technical controls in place to enforce that decision.
• Monitor for execution or attempted execution, and retain evidence that you detect and respond. ¹

Authoritative program context: CMMC requirements are implemented under the DoD CMMC Program and codified in the CMMC Program rule. ^{2 3}

Plain-English interpretation (what counts as “mobile code”)

Mobile code is executable content delivered through common user or application workflows rather than traditional software installation. In assessments, it usually includes:

• Scripts: PowerShell, Bash, Python, JavaScript, VBScript.
• Office macros and add-ins: VBA macros, Excel add-ins.
• Web-delivered code: active web content and browser-executed scripts.
• Email-borne content: HTML email, attachments that execute or trigger execution.
• Packaged executables and installers: MSI/EXE, self-extracting archives.
• Containers and “portable runtimes”: container images, unsigned binaries shipped with projects.

Your scope is the CUI environment boundary. If your enterprise has a segmented CUI enclave, focus controls and evidence there first, then address any pathways that can bridge into it (email, file shares, remote access, developer pipelines). ¹

Who it applies to

Entities: Defense contractors and other federal contractors that handle CUI and must meet CMMC Level 2 requirements. ^{3 2}

Operational context: Any system, endpoint, server, cloud workload, or application environment that stores, processes, or transmits CUI, plus the delivery paths that feed that environment (email, browsers, file transfer, CI/CD, remote administration). ¹

Owners you’ll need involved:

• CISO/IT Security: endpoint security, EDR, email security.
• IT Ops/Workplace: device management, patching, software distribution.
• App owners: macro policy, SaaS configuration.
• Engineering/DevOps (if applicable): script signing, pipelines, artifact repositories.
• Compliance/GRC: documentation, exceptions, evidence mapping.

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

Step 1: Set your mobile code policy decision (allow/deny matrix)

Create a short, enforceable standard that answers: “What code is allowed to run, where, and under what controls?”

A practical matrix (example structure):

• Category: PowerShell scripts
  • Default: Block unsigned scripts on workstations in the CUI environment
  • Allowed: Signed scripts from approved repo; admin-only execution
  • Monitoring: EDR alert on script execution + centralized logs
• Category: Office macros
  • Default: Block macros from the internet; disable by default
  • Allowed: Signed macros from trusted locations
  • Monitoring: Alerts on macro execution attempts

Keep it short enough that system owners can implement it and helpdesk can support it.

Step 2: Inventory execution pathways in the CUI environment

You can’t control what you haven’t enumerated. Build an inventory covering:

• Endpoints: Windows/macOS/Linux in the CUI enclave.
• Browsers: managed browsers and extensions.
• Email: attachment types, link handling, sandboxing.
• File transfer: SMB shares, SharePoint/OneDrive, SFTP, removable media.
• Admin tooling: RMM tools, remote shells, scripting frameworks.
• Developer tooling (if applicable): package managers, pipeline runners, artifact stores.

Output: a “mobile code surfaces list” tied to in-scope assets.

Step 3: Implement technical enforcement (block by default where feasible)

Focus on controls assessors can observe and you can produce evidence for:

• Endpoint management: restrict local admin rights; control software installation sources.
• Application allowlisting / execution control: allow approved binaries; block unknown executables in the CUI environment.
• Script controls: enforce script signing where practical; restrict interpreters on non-admin endpoints.
• Macro controls: disable macros by default; allow signed macros or trusted locations only.
• Browser controls: restrict extensions; block downloads of executable content; enforce safe browsing settings.
• Email controls: block high-risk attachment types; detonate/sandbox where available; strip active content where appropriate.

Your goal is consistent: “If code runs, we intended it to run, and we can show why.”

Step 4: Implement monitoring that proves ongoing control operation

Monitoring is the second half of the requirement. Define:

• Log sources: EDR events, Windows event logs, email security logs, web proxy logs, application allowlisting logs.
• Detections: blocked execution attempts, suspicious script engines, macro execution events, unknown executable launches, abnormal child process behavior.
• Triage workflow: who reviews, what severity rules exist, how false positives are handled, and what constitutes an incident.

Keep the workflow lightweight but real. A written SOP plus a few completed tickets is stronger than a long policy nobody follows.

Step 5: Build an exceptions process (and make it hard to abuse)

Mobile code controls often break legitimate business processes (finance macros, engineering scripts, vendor installers). Don’t let that turn into permanent “temporary exceptions.”

Require:

• Business justification
• Scope (device group, user group, time window)
• Compensating controls (increased monitoring, restricted execution path)
• Approval (system owner + security)
• Review/expiry

Step 6: Map control operation and evidence capture to 3.13.13

Turn the practice into a repeatable evidence routine:

• Monthly (or other set cadence): export a sample of blocked/allowed execution events, plus triage outcomes.
• After changes: retain change records for policy/config updates.
• Per exception: keep approval and expiry evidence.

If you use Daydream, treat 3.13.13 as a living requirement page: link the policy decision matrix, configurations, and recurring evidence pulls so your assessment package is assembled continuously instead of at the end.

Required evidence and artifacts to retain (assessor-ready)

Keep artifacts in a single “3.13.13 evidence” folder (or GRC system record) with clear dates and owners.

Design evidence (what you planned):

• Mobile code policy/standard with allow/deny matrix.
• CUI boundary scope statement: what systems are in scope for enforcement.
• Exceptions procedure and approval roles.

Implementation evidence (what you configured):

• Endpoint configuration baselines (screenshots/exports) for macro/script settings.
• Application control/allowlisting policy exports.
• Email security policy showing attachment controls and sandboxing rules (if used).
• Browser management policies (extensions, downloads).

Operational evidence (what you monitored and did):

• SIEM/EDR detections or dashboards for script/macro/executable events.
• Sample alerts with investigation notes and closure.
• Change tickets for updates to allowlists and policies.
• Exception approvals with expiry/review records. ¹

Common exam/audit questions and hangups

Assessors and internal auditors tend to press on these points:

1. “Define mobile code for your environment.” If your policy says “we control mobile code” but doesn’t list what you mean, expect follow-ups.
2. “Show me what’s blocked.” They will want proof that unapproved scripts/macros/executables are prevented or at least detected.
3. “Where do you monitor, and who reviews it?” A SIEM feed without ownership and tickets reads as shelfware.
4. “How do exceptions work?” If exceptions are informal (email approvals, no expiry), you’ll struggle to show control.
5. “Is this applied to the CUI enclave specifically?” Broad enterprise policies are fine only if you can prove they apply to in-scope assets. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails in assessment	How to avoid
“Antivirus covers this.”	AV alone rarely demonstrates control over scripts/macros/active content	Add explicit policy decisions and execution controls; keep configuration exports
Allowlisting exists, but no monitoring	3.13.13 requires control and monitoring	Define detections and retain triage tickets
Too many permanent exceptions	Exceptions become the real policy	Add expiry, review, and compensating monitoring
Policy is generic (“no malicious code”)	Not testable	Write a category-based allow/deny matrix tied to systems
Controls implemented outside CUI scope	Evidence doesn’t match boundary	Tag in-scope assets; produce scoped reports for those assets

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific case outcomes.

Risk still matters operationally. Mobile code is a common delivery mechanism for credential theft, lateral movement, and ransomware-like behaviors because it rides normal workflows (documents, scripts, browser sessions). For CMMC Level 2, the practical risk is twofold:

• Security risk: untracked execution paths into the CUI environment.
• Assessment risk: inability to produce objective evidence that control and monitoring are operating as required by the mapped NIST practice. ^{1 2}

A practical 30/60/90-day execution plan

You asked for speed. This plan prioritizes controls that produce clear assessor evidence quickly.

First 30 days (stabilize scope and decisions)

• Confirm the CUI boundary and in-scope asset list for enforcement and reporting.
• Publish the mobile code standard with your allow/deny matrix.
• Pick “must-control” pathways to start: Office macros, common script engines, executable downloads, email attachments.
• Stand up a simple exception workflow with approvals and expiry.

By 60 days (enforce and generate evidence)

• Deploy endpoint policies for macros and scripting controls in the CUI environment.
• Implement application control/allowlisting (or equivalent execution controls) for in-scope endpoints and key servers.
• Route EDR/email/web logs to your monitoring platform and define a small set of detections.
• Produce your first evidence packet: configs + sample events + triage tickets mapped to 3.13.13. ¹

By 90 days (operate, tune, and harden)

• Reduce exceptions by fixing root causes (signed scripts, approved macro repositories, controlled software distribution).
• Add monitoring for additional pathways you identified (admin tooling, developer runners, removable media if applicable).
• Document a repeatable evidence cadence and assign named owners.
• Run a tabletop test: “macro-based payload attempt in CUI enclave” and retain the ticket trail as operational evidence.

Daydream fits well here when you want one place to map 3.13.13 to your policy, configurations, and recurring evidence pulls so you can answer assessor questions without scrambling at the end.

Frequently Asked Questions

What exactly counts as “mobile code” for 3.13.13?

Treat it as any code that can execute through common delivery paths without a traditional, controlled install, including scripts, macros, active web content, and executable attachments. Define your categories explicitly in your standard so your implementation and evidence line up. ¹

Do we have to block all scripting in the CUI environment?

The requirement is to control and monitor, not necessarily to ban. Many teams allow scripts only when signed, run by admins, or executed from an approved repository, then alert on everything else.

How do we prove “monitoring” to a CMMC assessor?

Show log sources (EDR/email/web), detections or dashboards for mobile-code events, and a handful of closed investigations or tickets that demonstrate review and disposition. Make sure the evidence is scoped to the CUI environment. ¹

Our finance team needs Excel macros. How do we stay compliant?

Create a controlled macro pathway: signed macros, trusted locations, and a documented exception if needed while you transition. Pair it with monitoring for macro execution attempts and periodic review of approved macro sources.

What if a third party support team needs to run scripts for maintenance?

Require an approved remote access method, pre-approved scripts (or signed scripts), and session logging, then treat any deviation as an exception with expiry. Ensure the activity is visible in your monitoring tooling and retained as evidence. ¹

Can we meet 3.13.13 with policy only if we’re a small shop?

A policy without technical enforcement and operational evidence is usually weak in assessment because it’s hard to show control and monitoring in practice. Start with a narrow CUI scope and implement enforceable controls there first. ¹

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170