A complete walkthrough showing System Security Plan development, policy creation, and monitoring procedures that satisfy assessors

---

Mobile code appears twice in NIST SP 800-171 Rev 3. Two separate requirements with six assessment objectives between them.

Most implementers struggle with these requirements because mobile code is widely misunderstood. They think it means cell phones. They try to disable everything. They write procedures for one-time configurations.

This article walks through proper implementation using the same methodology that passed DIBCAC assessment.

What Mobile Code Actually Means

Mobile code isn’t about smartphones or app stores. It’s code that executes inside a different trusted application.

Office macros executing in Microsoft Word. JavaScript running in Chrome. PowerShell scripts executing in the Windows shell. PDF scripts running inside Adobe Reader.

This code is dangerous because normal security controls don’t work. Your operating system trusts Chrome. If your antivirus blocked Chrome entirely, you’d say “this computer is useless” and get a different one.

Same with Microsoft Office, PowerShell, command line. Your IT department uses these tools constantly. You can’t just disable them.

Mobile code requires different control methods because you can’t block the applications that execute it.

Start with Assessment Objectives

Before writing anything, read the assessment objectives. These tell you what assessors will actually verify.

For the first mobile code requirement (3.13.13A in Rev 3):

1. Acceptable mobile code is defined
2. Acceptable mobile code technologies are defined
3. Antivirus programs are configured to prevent or restrict mobile code

For the second requirement (monitoring and control):

1. The use of mobile code is authorized
2. The use of mobile code is monitored
3. The use of mobile code is controlled

These objectives drive your implementation decisions.

Defining Acceptable Mobile Code

How do you define every acceptable JavaScript on every website your users might visit? Every Office macro they might encounter? Every PowerShell script your IT team might write?

You can’t. It’s impossible.

Here’s the trick: define unacceptable mobile code instead.

Unacceptable mobile code maliciously alters the computer. Attempts privilege escalation. Exfiltrates data. Installs malware.

Therefore, acceptable mobile code is anything that doesn’t do those things.

This approach satisfies the assessment objective without requiring impossible documentation.

Track Authorized Mobile Code Technologies

Mobile code executes inside applications. Track authorizations at that level.

Create a software inventory database. For each authorized application, list which mobile code technologies it can run.

Google Chrome: Authorized for JavaScript and PDF. Microsoft Office: Authorized for macros in specific scenarios. PowerShell: Authorized for administrative scripts.

This gives you evidence. When assessors ask what mobile code technologies are authorized, point to the database.

Write Policies for Longevity

Policies should survive personnel rotation. They tell future IT staff what needs to happen even after current employees leave.

Three policies cover mobile code effectively:

Software inventory policy: We maintain records of authorized software and the mobile code technologies each can use.

Antivirus policy: All antivirus programs must be configured to evaluate mobile code and block suspected malicious execution.

Secure build policy: Disable mobile code technologies not listed as authorized in the software inventory database when building new systems.

These policies create lasting control even as staff changes.

Don’t Write Unnecessary Procedures

CMMC Version 1 required step-by-step procedures for every assessment objective, no matter how illogical. Companies wrote 20-page procedures describing every click required to create a single group policy.

CMMC Version 2 eliminated that requirement. Now you need logical implementation.

For mobile code, technical controls work better than procedures. You configure antivirus policies once. You set attack surface reduction rules once. They keep working.

Writing a procedure for how to write a PowerShell script is silly. Keeping a copy of the script as baseline documentation is smart.

The distinction: baseline documentation shows what’s configured. Procedures explain repeatable processes performed regularly.

Tag Assessment Objectives in Your SSP

When writing System Security Plan statements, tag which assessment objectives each statement addresses.

Example: “Our antivirus programs are configured to block suspected malicious mobile code. [Assessment Objective 3.13.13A(01)]”

Assessors love this. They can quickly verify your SSP covers every objective. During assessment when everyone is stressed and sleep-deprived, you can find relevant statements immediately.

Demonstrate Monitoring Capability

Assessment objectives about monitoring require more than policies. You need to demonstrate capability.

Create an audit log procedure documenting exactly how to pull monitoring information. Include:

• Menu paths to reach monitoring interfaces
• Copy-paste queries to run
• Screenshots showing expected results

For mobile code monitoring, queries might include:

PowerShell execution monitoring through Microsoft Defender for Endpoint advanced hunting.

Subprocess execution from browsers showing JavaScript activity.

Antivirus alerts showing blocked mobile code.

During assessment, pull up these procedures, paste the queries, run them, show results. This gives assessors confidence you know what you’re doing.

Control Doesn’t Mean Disable

A common mistake: reading “control mobile code” as “disable all mobile code.”

That’s not the requirement. Control means manage appropriately.

Your computers likely have JavaScript enabled. PowerShell is available. PDFs can execute scripts. That’s acceptable if:

• Those technologies are documented as authorized
• Your antivirus monitors and controls them
• Your policies require future systems to maintain these controls

Match your documentation to actual implementation. Don’t claim you disable JavaScript when Chrome allows it. That discrepancy fails assessments.

Better to document what your systems actually do and show you control it appropriately.

Address External Service Providers

Mobile code requirements apply to your systems and your cloud providers.

Microsoft 365 backend servers execute code. Your cloud provider’s infrastructure runs scripts. Those environments also need mobile code controls.

The gold standard approach: Request your cloud provider’s FedRAMP package. Review their System Security Plan. Verify they address mobile code requirements.

Then in your SSP: “Our Microsoft 365 cloud performs this practice per their FedRAMP authorization. Reference SSP control SC-18.”

Make the cloud provider’s SSP available to assessors if they want verification.

Most companies skip this entirely. They ignore cloud considerations. Sometimes assessors don’t notice. Sometimes companies get findings.

Proper documentation addresses it explicitly through inheritance.

FedRAMP Equivalent Reality

Some cloud providers claim “FedRAMP equivalent” status without actually performing the security controls.

Real FedRAMP equivalent means:

• Performing all 325+ security controls from 853 moderate baseline
• Having third-party assessment verification
• Making System Security Plans available to customers

It does NOT mean skipping security while claiming equivalence.

Before trusting a cloud’s “equivalent” claim, request the third-party audit report. If they can’t provide one, they’re probably using the wrong definition of equivalent.

Implementation Checklist

For complete mobile code implementation:

✓ Define acceptable mobile code by defining unacceptable ✓ Track authorized mobile code technologies in software inventory ✓ Create policies for software inventory, antivirus, and secure builds ✓ Configure antivirus and attack surface reduction for mobile code ✓ Document exact menu paths and configurations in SSP ✓ Tag all assessment objectives in SSP statements ✓ Create audit log procedures with copy-paste queries ✓ Verify you can demonstrate monitoring live during assessment ✓ Address cloud provider mobile code controls through inheritance ✓ Match documentation to actual implementation

Getting Implementation Right

The methodology demonstrated here comes from the Kieri Compliance Documentation and Kieri Reference Architecture. These are the same documents Kieri used to pass their own DIBCAC assessment.

The KCD provides policies, procedures, and SSP templates for all CMMC Level 2 requirements. The KRA adds Microsoft 365 GCC-High technical implementation with exact configurations.

Mobile code is just one requirement. The same methodology applies across all 110 practices.

Download the KCD brochure at kieri.com/kcd to see complete documentation examples.

Download the KRA datasheet at kieri.com/kra for technical implementation details.

Schedule a consultation to discuss whether the KCD fits your compliance needs: kieri.com/schedule-consultation

---

Kieri Solutions is one of 54 authorized C3PAOs in the United States. The implementation methodology shown here passed DIBCAC assessment and is now available to defense contractors through the KCD and KRA packages.

Ready for Assessment? Visit kieri.com/assess to learn about CMMC Level 2 certification services.