CMMC Level 2 Practice 3.13.12: Prohibit remote activation of collaborative computing devices and provide indication of

To meet CMMC Level 2 Practice 3.13.12, you must configure webcams, microphones, smart displays, and other collaborative computing devices so they cannot be turned on remotely and so users receive a clear, reliable indication when those devices are active. Operationalize this with device hardening standards, managed configuration (MDM/GPO), and evidence that settings are enforced across the CUI environment. ¹

Key takeaways:

• Disable or block remote wake/enable for cameras, mics, and collaboration peripherals in the CUI environment.
• Ensure user-visible indicators (LED/on-screen) are enabled and cannot be suppressed by software settings.
• Keep assessor-ready evidence: standard builds, enforced configuration baselines, and test results mapped to 3.13.12.

“Collaborative computing devices” are a quiet failure point in many CMMC Level 2 programs because they sit at the intersection of endpoint configuration, conferencing software, and user behavior. Practice 3.13.12 targets a specific threat: covert surveillance or inadvertent disclosure through cameras, microphones, or smart conferencing equipment that can be activated without the user’s knowledge. The operational goal is simple: if a device can capture audio/video or share content, it should not be possible for a remote party, service, or admin tool to turn that capability on without local user action, and the user must have an unambiguous signal when capture is occurring. ²

For a CCO, Compliance Officer, or GRC lead, the fastest path is to treat 3.13.12 like a configuration-control requirement with three deliverables: (1) a defined scope of device types inside the CUI boundary, (2) enforced technical settings that prevent remote activation, and (3) recurring evidence that settings remain in place. CMMC assessments reward clarity: clear scoping, clear baselines, and proof the control operates in production. ³

Regulatory text

Requirement (framework mapping): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.12 (Prohibit remote activation of collaborative computing devices and provide indication of).” ¹

Operator interpretation: You must (a) prevent remote activation of collaborative device functions (especially audio/video capture and similar collaboration features) and (b) ensure users get an indication that the device is active. Treat “remote activation” broadly: activation through network calls, remote admin tools, conferencing platforms, drivers, or cloud management features counts if it results in a camera/mic turning on without local user intent. ²

---

Plain-English interpretation (what the assessor expects)

Assessors typically look for two things:

1. Technical prohibition: Remote parties or remote management mechanisms cannot silently enable microphones/cameras/screensharing hardware in the CUI environment.
2. User indication: When those functions are active, the end user can tell through a hardware light, OS indicator, or similarly reliable signal.

This is not satisfied by policy alone. You need enforceable configuration on endpoints and dedicated conference room gear, plus proof it is deployed and stays deployed. ¹

---

Who it applies to (entity + operational context)

Entities: Defense contractors and other federal contractors that handle CUI and must meet CMMC Level 2. ⁴

Operational scope (where to apply):

• Endpoints in the CUI boundary: laptops/desktops used for CUI processing, meeting-room PCs used for CUI discussions, VDI/thin clients where local peripherals can capture audio/video.
• Collaborative peripherals connected to those endpoints: webcams, headsets, speakerphones, conference bars.
• Smart room systems if they handle CUI discussions, recordings, or conferencing within the CUI environment.

If a collaboration device is outside your CUI boundary and cannot access CUI discussions or systems, you can scope it out, but document that boundary decision. Assessors will challenge vague scoping. ⁵

---

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

1) Build and approve a “collaborative device” inventory for the CUI environment

Create a list by device class and model, mapped to where it’s used:

• Endpoints (Windows/macOS/Linux, VDI endpoints)
• Peripherals (USB webcams, Bluetooth headsets)
• Conference room systems (room bars, DSPs, microphones)
• Software clients that can control hardware (meeting apps)

Output: a scoped inventory report and an owner for each device class (IT, UC/telephony, Facilities/AV). Evidence matters more than perfection; show you control what’s in scope. ⁵

2) Define the technical “prohibit remote activation” standard

Write a short standard that answers:

• What remote activation means in your environment (examples: remote enable of camera/mic; remote wake of a room system into a listening state).
• The approved prevention mechanisms by platform:
  • Endpoint configuration (OS privacy controls, driver settings, conferencing app settings)
  • Device firmware settings (disable auto-answer, disable remote management features that can start capture)
  • Network controls (block inbound management from untrusted networks; restrict management planes)

Keep it testable: every statement should map to a setting you can verify. ²

3) Implement enforced configuration baselines (MDM/GPO/config management)

Put the standard into enforcement:

• Endpoints: enforce camera/microphone privacy settings and prevent users from disabling indicators where the OS supports it.
• Conference apps: disable “auto-answer,” “join before host,” remote control features that can trigger device activation, and any setting that allows silent activation where supported by the platform.
• Room systems: disable auto-answer and remote activation features; restrict management access to an admin subnet/VPN; require authenticated management.

Document exceptions with compensating controls (for example, a secure room system that must be remotely administered but cannot activate audio/video capture without a local physical action). ²

4) Ensure “indication of” is user-visible and reliable

Decide what counts as an acceptable indicator for each device class:

• Hardware LED on camera/mic
• OS-level on-screen microphone/camera indicator
• Device screen “recording/live” indicator for room systems

Then verify two properties:

• The indicator triggers whenever capture is active.
• Users cannot trivially suppress it via software settings in the managed CUI environment.

If you rely on OS indicators, confirm they work in the actual operating mode (for example, full-screen presentations, VDI sessions, or kiosk modes). ²

5) Validate by testing (and keep the results)

Run a simple control test plan:

• Pick representative endpoints and room devices.
• Attempt activation scenarios:
  • Remote admin attempt (IT tool)
  • Conferencing app scenario (remote participant tries to trigger camera/mic)
  • Device auto-answer scenario
• Confirm activation is blocked or requires local user action, and the indicator appears when active.

Save screenshots, configuration exports, and a short test memo. This is high-value evidence in a CMMC assessment because it proves operation, not just design. ⁵

6) Operationalize: change control + monitoring + recurring evidence capture

Add to steady-state operations:

• Configuration baseline review when conferencing software updates roll out.
• A joiner/mover process that ensures new endpoints inherit the baseline.
• Periodic checks (reports from MDM, configuration compliance dashboards, device management portals).

If you use Daydream to run assessment readiness, map 3.13.12 to your endpoint and collaboration baselines and schedule recurring evidence pulls (policy version, baseline export, compliance report, and a quarterly spot test) so you do not rebuild evidence at audit time. ⁵

---

Required evidence and artifacts to retain

Keep evidence that answers: “What did you configure, where is it enforced, and how do you know it remains enforced?”

Suggested evidence package (minimum set):

• Policy/standard: Collaborative Device Remote Activation & Indicator Standard (approved, versioned).
• Scope evidence: CUI boundary statement and in-scope device inventory extract.
• Configuration baselines: MDM/GPO profiles, configuration scripts, room system configs (exported).
• Technical proof: screenshots of enforced settings, privacy controls, and indicator behavior.
• Test results: dated test plan and results for representative devices.
• Exception register: approvals, duration, compensating controls, and revalidation notes.
• Ongoing compliance: device compliance reports or configuration compliance dashboards.

Map each artifact to practice 3.13.12 in your SSP and POA&M (if gaps exist). ¹

---

Common exam/audit questions and hangups

Assessors and internal auditors tend to focus on these friction points:

• “Define collaborative computing devices.” If your definition is fuzzy, your scope will look incomplete.
• “Show me it’s prohibited, not discouraged.” They will ask for enforced settings, not a user policy.
• “How do you handle conference rooms?” Room systems are often unmanaged compared to laptops.
• “What’s the indicator?” A statement like “users can tell” fails without a specific indicator per device class.
• “Can an admin tool still activate the mic?” Remote management capability must not equal remote activation capability.

Prepare a one-page “assessor walk-through” that shows inventory → baseline → enforcement report → test proof. ⁵

---

Frequent implementation mistakes (and how to avoid them)

1. Relying on conferencing app settings only. App settings change frequently and vary by platform. Anchor the control in OS/device configuration, then harden apps. ²

2. Ignoring peripherals. USB webcams and Bluetooth headsets can bypass built-in laptop controls. Track and restrict approved peripherals for CUI endpoints.

3. No proof that indicators can’t be disabled. If users can suppress the indicator, document why your chosen indicator remains trustworthy or shift to hardware indicators where feasible.

4. Room systems outside IT management. If Facilities/AV owns them, bring them into your configuration management and evidence process.

5. Vague exceptions. “Executive exception” will not survive assessment scrutiny. Write a compensating control that still blocks remote activation and preserves indication.

---

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so focus on assessment risk: weak evidence for 3.13.12 often becomes a finding because it is easy to ask, “Show me on a machine right now.” The operational risk is straightforward: covert audio/video capture can disclose CUI during meetings, screen shares, or calls, even if your networks and access control are otherwise strong. ⁶

---

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + baseline)

• Assign owners (Endpoint, UC/Collaboration, AV/Facilities, Security/GRC).
• Define “collaborative computing device” for your environment and publish scoping rules for the CUI boundary.
• Inventory in-scope endpoints, peripherals, and room systems.
• Draft and approve the remote activation + indicator standard mapped to 3.13.12. ⁵

By 60 days (enforce controls + close obvious gaps)

• Implement MDM/GPO baselines on endpoints to block remote activation paths you can control.
• Harden conferencing platforms (auto-answer off; remote control restrictions as applicable).
• Lock down room system configuration and management access.
• Start an exception register with compensating controls for anything you can’t remediate quickly. ²

By 90 days (prove operation + make it repeatable)

• Run and document the test plan on representative endpoints and rooms.
• Produce an evidence bundle: baseline exports, compliance reports, and indicator proof.
• Update SSP control narrative and POA&M entries if any gaps remain.
• Set recurring evidence capture (for example, after major app/OS updates and on a regular cadence) so assessment prep is a packaging task, not a scramble. Daydream can track the mapping and prompt evidence collection tied to 3.13.12. ⁵

Frequently Asked Questions

What devices count as “collaborative computing devices” for 3.13.12?

Treat any device that can capture audio/video or support interactive conferencing as in scope when it’s used in the CUI environment. Include endpoints plus peripherals and conference room systems if CUI is discussed or displayed there. ²

Does disabling remote desktop tools satisfy “prohibit remote activation”?

Not by itself. You need to prevent remote activation of cameras/mics through all practical paths, including conferencing apps, device firmware features (like auto-answer), and management planes for room systems. ²

Are OS camera/microphone indicators acceptable, or do we need hardware LEDs?

The requirement is “provide indication,” so either can work if it’s reliable in your operating mode and cannot be easily suppressed in the managed CUI environment. Document your indicator choice by device class and test it. ²

What if a room system needs remote administration for patching and support?

Remote administration is not automatically remote activation. Restrict management access (network segmentation and authentication) and configure the system so remote actions cannot silently enable capture without local user action, then document and test. ²

How do we show evidence quickly during a CMMC assessment?

Prepare a small evidence packet: inventory extract, baseline export (MDM/GPO), a compliance report showing enforcement, and a dated spot test showing activation is blocked and indicators work. Map each item to 3.13.12 in your SSP. ⁵

Can we scope this out if we never use cameras or microphones for CUI work?

You can scope out capabilities that are truly absent or disabled in the CUI environment, but you must document the boundary and the technical basis (for example, no devices have cameras, or cameras are physically removed/disabled and enforced). Expect assessors to verify on actual systems. ⁵

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance; 32 CFR Part 170

4. 32 CFR Part 170; DoD CMMC Program Guidance

5. DoD CMMC Program Guidance

6. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170