03.13.13 Mobile code: requirements and evidence

What 03.13.13 mobile code requires and why it is hard to evidence

If you are preparing for an assessment, the core question for 03.13.13 Mobile code is simple to state: your organization must define which mobile code and mobile code technologies are acceptable, then authorize, monitor and control how that code is used. Mobile code is software that runs without an explicit installation step. The most common examples are JavaScript and HTML5 content that a browser loads from a web page, along with Java applets, VBScript and WebGL, all of which NIST names as mobile code technologies in the Rev. 3 discussion. The risk is that a user can receive and execute this code simply by visiting a page or opening a document, so malicious or unapproved code can reach systems holding CUI without passing through the software approval process that governs installed applications.

The requirement is hard to evidence for two practical reasons. First, browsers fetch and run script content constantly, often from third-party sites, advertising networks and embedded widgets, so the volume of mobile code in use is large and changes daily. Second, mobile code rarely appears in a software or asset inventory, because nothing is installed. An assessor will therefore look for the policy and procedures that define acceptable mobile code, the processes that authorize and monitor it, and evidence that those processes operate. Within the 03.13 family, this requirement sits alongside boundary protection and network controls, and the assessment for it combines examining documents, interviewing the people who manage mobile code and testing the authorization, monitoring and control processes. Confirm early with your assessor how they expect to test each process, since the test method applies to this requirement.

Which browsers, scripts and mobile code paths fall in scope for 03.13.13

Mobile code reaches a CUI system through more paths than a single application, so scope starts with the systems that process or store CUI and then follows every route by which executable content can reach them. Each decision below changes who must be involved, what must be documented and which technical controls must be shown to work.

CUI systems and the browsers that reach them

Start by listing every system that processes, stores or transmits CUI, then every browser and browser profile a user can open to reach it. If a browser can load scripts or HTML5 content from a CUI application, that browser sits inside the 03.13.13 boundary. Record the browser versions in use, whether users can install extensions, and who approves each one. The mobile code policy must name the acceptable browser configuration, and your evidence should show that unapproved browsers cannot reach CUI resources.

Web applications and intranet pages

Internal web applications and intranet pages that deliver JavaScript or HTML5 to users in the CUI environment are mobile code in the sense of this requirement, even when the organization wrote them. For each one, identify which scripts load on page render, which load from third-party domains, and which run only after a user action. Decide which of these are acceptable, then document that decision and the process for adding a new script source. Changes to these pages should pass through the same change control as other system software.

Mobile code delivered by third-party services

Analytics tags, chat widgets, embedded maps, payment iframes and hosted fonts often deliver executable code from a vendor's domain each time a page loads. Inventory these embeds for each CUI-facing page, record the vendor and the domain, and decide whether the vendor's code is authorized. Where a policy requires mobile code to be digitally signed by a trusted source, ask each vendor how signing is provided and whether subresource integrity or a similar mechanism is available. Confirm these details with each vendor, since capabilities differ.

Identity providers and single sign-on pages

Sign-in pages from an identity provider often run scripts that the organization does not host and may not control. Whether a single sign-on page falls in scope depends on whether it executes on a device that accesses CUI and whether it can be reached from that device without a separate approval step. Ask the identity provider which scripts its login pages load, whether tenant administrators can restrict script sources, and how the provider notifies customers of changes. Your mobile code records should reflect the answers.

Managed endpoints and browser policy

Mobile code is only controlled if the endpoint enforces the decisions the policy makes. Managed endpoint providers and device management tools can set browser policies, block unapproved extensions, and restrict script behavior on managed devices. Ask who holds administrative rights over those policies, how changes are approved and logged, and whether unmanaged or personal devices can reach CUI resources at all. Gaps in device enforcement are a common reason an otherwise sound mobile code policy fails assessment.

SaaS vendors that deliver code to users

Software as a service products used alongside CUI systems often push updates to the browser client without an installation step. Each such product that a CUI user opens is a mobile code path. Identify the SaaS vendors whose clients run in the browser, record how the organization learns of client-side changes, and confirm whether the vendor offers controls to pin versions, limit features or restrict script sources. Where a vendor cannot support the policy, the organization must decide whether to accept the risk, restrict access or select another product.

How an assessor tests mobile code authorization and monitoring

This table compares the three assessment methods SP 800-171A Rev. 3 uses for 03.13.13, showing what the assessor examines, asks and tests, the evidence requested and where findings usually arise. Read each row as one slice of the five determination statements. The main takeaway is that a written policy alone rarely passes: the assessor expects the authorization and monitoring processes to be running and provable.

Assessment method	What the assessor examines or asks	Evidence requested	Common findings
Examine	System and communications protection policy and procedures, mobile code procedures and the mobile code implementation policy, checked for defined acceptable mobile code technologies such as JavaScript, HTML5, Java applets, VBScript and WebGL	Approved mobile code policy, procedure documents with version and approval dates, list of permitted technologies and their authorized uses	Policy names technologies but does not state who approves exceptions or how often the list is reviewed
Examine	Records showing which mobile code is authorized for use, and any signing requirements the organization set for mobile code from trusted sources	Authorization records, signing or trust-source rules, change history for the approved list	Authorization list exists but does not match what is actually running on endpoints
Interview	Personnel who manage mobile code, asked how they decide whether new scripts or browser technologies are allowed and how exceptions are handled	Named owners, approval workflow description, sample tickets or requests showing the decision path	Staff describe an informal practice that is not written down or applied consistently
Interview	Personnel with information security responsibilities, asked how mobile code activity is monitored and what happens when unauthorized code is found	Monitoring responsibilities in role descriptions, escalation steps, examples of responses taken	Security staff cannot name the monitoring source or the response owner
Test	The processes for authorizing, monitoring and controlling mobile code, observed working on sample systems through live demonstration	Configuration exports, endpoint policy results, monitoring reports and records of blocked or flagged mobile code	Monitoring is configured on paper but reports show no coverage of some endpoint groups

Order of work to define, authorize and monitor mobile code

This sequence turns 03.13.13 from a policy statement into a working control: the team knows which mobile code runs on CUI systems, has written rules for what may run, enforces those rules on endpoints and browsers, and can show an assessor the records that prove it.

Inventory mobile code technologies on CUI systems
Start by listing every mobile code technology that can run on systems that store, process or transmit CUI. NIST's discussion names Java applets, JavaScript, HTML5, VBScript and WebGL as examples, but the list should come from your own environment, including browser extensions, embedded web views in business applications and scripts delivered through email or collaboration tools. Engineering and endpoint administrators usually own this work, with the security team reviewing it. The output is a dated inventory that names each technology, where it runs, which user groups reach it and which business applications depend on it. The step is done when the inventory has been checked against a sample of real endpoint images and browser configurations, not only against documentation.
Write the acceptable mobile code definition
Draft the organization-defined statement of which mobile code technologies are acceptable, which are prohibited and which need case-by-case approval. The definition should state the sources it accepts code from, the systems it applies to and the conditions under which code may run without explicit installation. Because 03.13.13 asks for the definition explicitly, the policy must be written, approved by the accountable owner and stored with the other system and communications protection policy and procedures that an assessor will examine. The output is a versioned mobile code policy with an approval record and a named owner.
Set the approval path for new mobile code
Define the procedure for requesting, reviewing and approving a new mobile code technology or a new source of mobile code. The request should describe the technology, the business need, the systems affected, the data the code can reach and the controls that will apply. The security team decides whether the request fits the policy, and the approver records the decision. This procedure also feeds change control for the systems involved, so approvals and configuration changes stay connected. The output is an approval workflow, a request template and a decision log, which give the assessor evidence for the authorizing part of the requirement.
Decide whether mobile code must be digitally signed
Decide whether your policy requires mobile code to be digitally signed by a trusted source before it runs. NIST's discussion says policies may require this, so the choice is yours to make and document. If you require signing, list the trusted signers, define how signatures are verified on endpoints and state what happens to unsigned code. If you do not require signing, record the reason and the compensating controls, such as allowlisting of approved origins. The output is a signed-code rule or a documented decision not to require it, with the trusted signer list where applicable. Confirm the rule against the technologies in your inventory, since some technologies cannot be signed in the same way as others.
Configure enforcement on endpoints and browsers
Apply the policy in configuration. Browser and endpoint settings should block or restrict the technologies the policy prohibits, limit the approved technologies to the approved origins and enforce the signing rule where you set one. Platform administrators usually make these changes through their management tools, and each setting should trace back to a line in the policy. The output is a configuration baseline or set of policy exports that show the enforced state, along with a note of exceptions and who approved them. This record is what a test of the controlling part of the requirement will examine.
Monitor compliance with scheduled queries
Set up a recurring check that confirms endpoints are running only permitted mobile code and that the configuration from the previous step has not drifted. Open-source tools can run these checks across a fleet. Wazuh's Security Configuration Assessment evaluates endpoints against YAML policies that can be extended with custom checks, and osquery can schedule SQL queries that inspect running processes, browser plugins and file hashes across hosts. A platform such as Fleet can express each rule as a yes or no policy and show which devices pass or fail. The output is a monitoring query or policy set, its schedule and a log of results with the response taken for each failure. Confirm that the chosen tool can inspect the technologies in your inventory before you rely on it.
Investigate and respond to violations
Define what happens when monitoring finds unauthorized mobile code: who receives the alert, how the affected device is isolated or remediated and how the event is recorded. Where a device is offline when the check runs, make sure the result is captured when it reconnects. For incidents that need deeper analysis, forensic collection tools such as Velociraptor can gather artifacts from many systems at once and keep the results together for review. The output is a response procedure, a ticket or incident record for each violation and a closure note that states the root cause and any policy change. Coordinate this with the incident response plan so the two sets of records match.
Review the policy and monitoring on a set cycle
Schedule periodic reviews of the mobile code policy, the inventory, the approval log and the monitoring results. Each review should check whether new technologies have appeared, whether approvals are still valid and whether the monitoring still covers every system in scope. The review frequency should be set in your own policy, and the reviewer should be someone other than the person who maintains the configuration. The output is a signed review record that lists findings, the changes made and the date of the next review. Keep these records with the system security plan so they can be produced during an assessment.

Evidence that satisfies 03.13.13 and how to keep it current

An assessor testing 03.13.13 checks whether the organization defined which mobile code it accepts, authorized it, monitored it and handled exceptions. The six artifacts below connect those steps, and each one needs a named owner, a review date and a sign-off that stays current between assessments.

Mobile code policy and procedures

This is the first document an assessor examines. It should name the mobile code technologies the organization accepts, such as JavaScript, HTML5, WebGL, VBScript and Java applets, and state which are prohibited and why. Each technology should tie to a business use and an owner. The companion procedures should describe how the policy is applied to browsers, endpoints and web content. Refresh the document whenever the approved list changes and at the review cycle the policy sets. The CISO or information security lead signs it, and the system owners acknowledge the procedures in writing.

Authorization record and approved list

The assessor will test whether mobile code is authorized before use. Keep a register that lists each approved technology, the systems or user groups it covers, the authorizing official, the justification and the date of approval. Assign a named owner to each entry and set a review date for it. When a team asks to add a technology, the request and decision should be recorded in the same register. Refresh the register at each scheduled review and whenever a new technology is requested. The authorizing official signs each entry, and the information security lead signs the register at each review.

Signing and trusted-source rule

Where the policy requires mobile code to be digitally signed by a trusted source, the rule itself becomes evidence. Document which signers are trusted, how signatures are verified before code runs, and what happens when verification fails. Include the list of trusted publishers and the process for adding or removing one. Confirm with your assessor whether your organization's policy sets this requirement, since the rule applies only where the policy calls for it. Review the trusted-publisher list at the same cadence as the authorization register. The security engineering lead signs the rule, and the change owner signs each publisher addition.

Browser and endpoint configuration baselines

Baselines show that the approved mobile code settings are enforced on endpoints, not just written down. Capture the browser and endpoint settings that control script execution, plugin use and content types, and record which setting enforces each rule in the approved list. Wazuh's Security Configuration Assessment can check files, directories, registry keys and running processes against YAML policies, and you can extend those policies with custom checks for your own mobile code rules. Export the policy results as evidence. Refresh baselines after each configuration change and at each review. The system owner signs the baseline and the configuration management lead signs the change record.

Monitoring output for blocked or flagged code

An assessor will ask for evidence that unapproved mobile code is detected or blocked. Collect dated output from your monitoring tools that shows which devices run which browser plugins or scripts and which devices fail the policy. Fleet policies, which are yes or no osquery questions, can show passing and failing devices across a fleet, and osquery can report running processes and browser plugins. Keep the queries as well as their results, so the assessor can see what was tested. Review the output on a recurring schedule and record the follow-up on each failure. The security operations lead signs the monitoring reports at each review.

Exception and review records

Every departure from the approved list needs a record. Document who requested the exception, the business reason, the compensating controls, the approver and the expiry date. Keep the closed exceptions as well as the open ones, since the assessor will sample both. Tie each exception to the monitoring output that shows whether the exception is being used as approved. Set a review date for each one and retire it when it expires or the technology is authorized. Refresh the exception log at each review cycle and whenever an exception is granted or closed. The information security lead approves each exception, and the risk owner signs the periodic review.

What meeting 03.13.13 costs in money and effort

This table breaks down the cost of meeting 03.13.13 Mobile code into components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a written scope and to compare quotes on like-for-like terms. The main takeaway is that open-source tooling removes license spend but not the engineering, policy and evidence work that drives most of the effort.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Tooling and licenses	Tool vendor or none for self-hosted open source	Usually one-time setup, recurring hosting	Self-hosted GPL, MIT and Apache tools remove license fees, but hosting and storage in the enclave still cost money
Engineering to configure enforcement	Internal staff or implementation partner under a written scope	One-time, with later changes	Number of browsers, applications and mobile code technologies in scope, and whether blocking or signing is enforced at endpoints
Monitoring and query design	Internal security engineering or partner	One-time build, then recurring tuning	Number of endpoints, query frequency and how many policies check mobile code settings
Policy and approval work	Organization, with legal, compliance and system owners	One-time, revisited on change	Count of allowed mobile code technologies, signing rules and exception process for business applications
Evidence upkeep	Organization staff, with partner support if retained	Recurring between assessments	Frequency of policy reviews, exception records and scan exports kept for the assessor
External review or testing	Independent tester or assessor, under separate engagement	Periodic	Whether the system sits in an enclave, the depth of browser and script testing, and the assessment method used
Assessor fees	Assessor or certification body for the formal assessment	Per assessment cycle	Scope of the system boundary and how many 03.13.13 determination statements the assessor must test

Using Wazuh, Fleet, osquery and Velociraptor for mobile code evidence

Mobile code evidence for 03.13.13 comes down to showing which mobile code technologies run on endpoints, which are approved, and whether the approved rules hold on every device. The four tools below each answer a different part of that question, from configuration checks to live queries and forensic collection. None of them decides what is acceptable for your organization, and each needs to be confirmed against your own environment before you rely on its output.

Wazuh configuration checks for browsers

Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies that check files, directories, registry keys and running processes, and it recommends remediation. Its policies are shipped mostly based on CIS benchmarks and can be extended with custom policies. For 03.13.13, a custom policy can check whether the browser settings that govern script execution, plugin use or content signing match the approved mobile code list. Wazuh is licensed under GPL-2.0-only, so review the license terms if you plan to modify its code rather than only its policies. Confirm that a policy exists or can be written for each browser and runtime in your fleet.

Fleet policies as yes or no checks

Fleet policies ask each device a yes or no question written as an osquery query, and the policies page shows which devices in each fleet pass or fail. This suits 03.13.13 well because you can express a rule such as "Is the approved script runtime the only one installed?" and see the result across all enrolled hosts. Fleet is licensed under MIT. Confirm which operating systems and browsers your Fleet version can query, and test each policy on a sample device before you treat a passing result as evidence.

osquery tables for mobile code inventory

osquery exposes running processes, loaded kernel modules, open network connections, browser plugins and file hashes as SQL tables. Those tables let you inventory which mobile code technologies are present and active, and hash the files that implement them so you can compare them against an approved list. The osqueryd daemon schedules these queries across an entire fleet of hosts, which produces repeatable records over time. osquery is dual-licensed under Apache-2.0 OR GPL-2.0-only. Confirm that the browser plugin table covers each browser in your environment, because coverage varies by platform.

Velociraptor hunts for unapproved code

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that collect one or more artifacts across a group of systems. Hunts are useful when you need to find where an unapproved mobile code technology was used, for example after a finding or an incident. Offline machines are scheduled to collect when they reconnect, and each hunt gets a notebook for analyzing the combined results. Velociraptor is licensed under AGPL-3.0-only, which carries network-use obligations if you modify and host it for others. Confirm that the artifacts you need exist for your operating systems and that your retention rules allow the collected data to be kept.

Who does what for mobile code: your team, a partner and the auditor

Your organization owns the mobile code decisions. Under 03.13.13 you must define which mobile code and mobile code technologies are acceptable, then authorize, monitor and control their use. Those are management decisions, so they stay with your security leadership and the system owners whose systems run the code. Your team also decides whether mobile code must be digitally signed by a trusted source, a choice NIST's discussion notes that policies may require.

Policy and acceptable technologies: Write the mobile code policy that names permitted technologies such as JavaScript, HTML5, WebGL or VBScript, and states which are prohibited.
Approved list and signing rules: Maintain the list of approved sources and decide whether signing from a trusted source is required.
Authorization decisions: Approve exceptions, record who signed off and why, and retire technologies that no longer meet the policy.
Monitoring ownership: Assign people to review alerts and misconfiguration findings and to act on them.
Interview readiness: Make sure the people who manage mobile code can explain the process when an assessor interviews them.

Check that each decision has a named owner, a date and a record that an assessor can examine.

Where mobile code controls usually fall short

03.13.13 asks for two things that auditors check separately: a defined position on acceptable mobile code, and evidence that the organization authorizes, monitors and controls it in practice. The gaps below are where organizations most often hold a policy on paper but cannot show the decisions, inventory and records behind it.

Policy names no technologies

A policy that says mobile code is controlled but never names JavaScript, HTML5, Java applets, VBScript or WebGL leaves staff and administrators guessing what is covered. Assessors look for a definition of acceptable mobile code and the technologies it covers, so check that the policy lists each technology in use and states which ones are permitted, restricted or prohibited. Add a sentence on where each rule applies, such as browsers, email clients and document viewers.

Browsers missing from the inventory

Mobile code usually runs in browsers, yet many organizations inventory servers and endpoints but not the browser versions, extensions and plugins on each device. Without that list, nobody can say which endpoints run which mobile code engines or whether authorization decisions apply to them. Build the inventory from endpoint queries so it reflects installed browsers and browser plugins, and reconcile it against the configuration baseline each quarter.

No decision on signing

NIST's discussion notes that a policy may require mobile code to be digitally signed by a trusted source. Many organizations never decide whether signing is required, so unsigned scripts run by default. Record the decision explicitly: either require signatures from named trusted sources for specified technologies, or document why signing is not required and what other control applies. Assessors will ask which option was chosen and for the records that show it is enforced.

Monitoring with no reviewable record

Endpoint tools may detect blocked or unexpected script activity, but the alerts never reach a person who reviews them or they are overwritten after a short period. The requirement covers monitoring, so the organization must show that mobile code activity is observed and that someone acts on it. Confirm who reviews the output, how often, what gets escalated, and where the review results are kept for the assessment period.

Exceptions with no owner or expiry

Business applications often need an exception to a mobile code restriction, and those exceptions tend to outlive the project that justified them. An exception with no named owner, no documented risk acceptance and no end date means the organization has not authorized the use in any meaningful sense. Keep a register that records the technology, the system, the approver, the compensating control and a review date, and remove expired exceptions.

Evidence gathered only at assessment

Teams often collect screenshots of policy and configuration in the weeks before an assessment, then let the evidence go stale. Authorization decisions, inventory reports and monitoring reviews should be produced on a schedule so that the evidence reflects the current state at any point. Set a recurring export of the endpoint query results and approval records into the evidence store, and test that a sample from several months earlier can still be retrieved.

Common questions about 03.13.13 cost, effort and scope

How much effort does 03.13.13 take compared with other requirements in the family?

03.13.13 is one of the narrower requirements in the System and communications protection family, because it covers one topic: defining acceptable mobile code and controlling its use. Its effort comes mostly from policy and inventory work rather than engineering. The main drivers are how many browsers, plug-ins and web-based applications your users run, how many unmanaged or bring-your-own devices reach CUI, and whether mobile code controls already exist in your endpoint and web filtering tools. Requirements such as 03.13.08 or 03.13.10 usually involve more system changes. Ask any provider to split its estimate by policy, technical enforcement and evidence collection so you can compare scopes directly.

Can we meet 03.13.13 in-house without outside help?

Yes, many organizations do this work internally, and the requirement does not require an outside firm. Your team must define acceptable mobile code and technologies, authorize and monitor their use, and control them on systems that handle CUI. Internal staff who already administer endpoints and web controls can often do the configuration. Outside help is most useful when no one on staff has time to build the inventory, when the policy must be written to match a system security plan, or when you want an independent check of the evidence before an assessment. Whichever path you choose, the organization owns the decision and the result.

What does the work need from our team?

Plan for three roles. A policy owner must approve which mobile code technologies, such as JavaScript, HTML5, Java applets, VBScript and WebGL, are allowed, under what conditions, and whether signing by a trusted source is required. An endpoint administrator must enforce those rules through browser policies, application control or endpoint queries, and must keep the inventory current. An assessment contact must gather the examine, interview and test evidence that SP 800-171A Rev. 3 expects and answer questions from the assessor. In small organizations, one person may hold more than one role. Confirm named owners before work starts, because open items usually delay sign-off.

How long does it take to be ready for 03.13.13?

No fixed duration applies, because readiness depends on the starting point. The main drivers are whether a written mobile code policy already exists, how complete your device and browser inventory is, how many systems touch CUI, and whether monitoring tools already report on web content and scripts. Organizations with current endpoint management and a documented policy usually move faster than those building both from scratch. Ask a provider to show the milestones it expects, such as policy approval, control rollout, monitoring setup and evidence review, and to tie each milestone to a dated deliverable in the written scope.

Does self-hosted open source reduce our license spend for this requirement?

It can reduce license spend for the monitoring layer, but it does not remove other costs. Wazuh, Fleet, osquery and Velociraptor are open-source projects with their own licenses, so you avoid per-seat fees for those tools. You still pay for infrastructure to host them inside your environment, for staff time to write policies and queries, for configuration and hardening, and for ongoing upkeep. Check the license terms of each component against how you plan to use it, and include support contracts or retainers in any comparison. Ask for a quote that lists recurring and one-time costs separately.

How do Rev. 2 and Rev. 3 differ for 03.13.13?

The requirement is substantively the same, and NIST's change analysis classifies the change as minor. Rev. 3 numbers it 03.13.13, while Rev. 2 numbered it 3.13.13. CMMC Level 2 still uses Rev. 2, so it assesses the practice as SC.L2-3.13.13, which carries 1 point in the 32 CFR 170.24 scoring methodology. Because a DoD contract may currently point to Rev. 2 while a proposed FAR rule would point to Rev. 3, keep one set of evidence that maps to both numbering schemes. Confirm which version your contracting officer or agreement names before you plan the work.

What can a partner not do for us on 03.13.13?

A partner cannot issue the assessment result. Organizations own their controls and their compliance decisions, and a partner prepares systems, configurations and evidence. Only the assessing body, such as the government assessor for a DoD contractor or another independent assessor where the contract allows, can issue a score or determination. A partner also cannot guarantee that an assessor will accept your evidence. When you request a quote, ask what evidence will be delivered, who approves the policy, and how the handover to your assessor will be documented.

How DeployOpen scopes and prepares 03.13.13 evidence

DeployOpen plans, implements and documents the mobile code controls for 03.13.13 Mobile code inside your own infrastructure. Your organization still owns the policy, the authorization decisions and the risk acceptance, while DeployOpen prepares the systems, configuration baselines and evidence that an independent assessor will examine, interview about and test.

How we scope

We confirm which browsers, endpoints and systems in the CUI boundary run JavaScript, HTML5, Java applets or other mobile code.
We agree in writing which mobile code technologies your policy will permit, restrict or block for each system in scope.
We identify which owner records approvals and exceptions, and which personnel must be interviewed for the assessment.

How we build

We configure browser and endpoint policies so that only approved mobile code sources and technologies run inside the CUI boundary.
We set up osquery and Fleet policies that check browser settings, installed plugins and running processes on managed devices.
We configure Wazuh Security Configuration Assessment checks for endpoint hardening that supports the mobile code restrictions.

How we hand over

We deliver the written mobile code policy, approval workflow and procedures for managing mobile code, mapped to the 03.13.13 determination statements.
We provide test results from authorization, monitoring and control checks, with exported Fleet and Wazuh reports showing passing and failing devices.
We document the configuration baseline, known exceptions and remediation records so your assessor can examine them directly.

How we support

Ongoing monitoring, policy updates and periodic re-testing of mobile code controls are available as a retainer after handover.
We can review changes to browsers, allowed sources or endpoint tooling against the written mobile code policy before they reach CUI systems.
Confirm with your assessor which evidence format and retention period they expect before the scope is finalized, since they make the determination, not DeployOpen.