Collaborative Computing Devices and Applications is the requirement that keeps cameras, microphones, and conferencing tools from being turned on remotely without the user knowing. It is part of the System and Communications Protection (03.13) family, and it addresses the risk that a collaborative device could be activated to eavesdrop. Collaborative Computing Devices and Applications (03.13.12) has two (2) parts: prohibit the remote activation of collaborative computing devices and applications except for defined exceptions, and provide an explicit indication of use to users who are physically present at the devices. Per the NIST discussion, collaborative computing devices include white boards, microphones, and cameras, and notebook computers, smartphones, display monitors, and tablets with cameras and microphones are included when conferencing software is in use.
A common difficulty with this requirement is allowing conferencing software to activate cameras or microphones remotely with no defined exceptions, or providing no clear indication when a device is in use. R3 makes the defining of allowed exceptions an explicit objective, and for Department of Defense (DoD) contractors those exceptions are tightly constrained. A setup that permits remote activation without documented, justified exceptions leaves the requirement unmet.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.13.12 Collaborative Computing Devices and Applications. Only the formatting has been adjusted for readability. This requirement has two (2) lettered parts:
The source control is SC-15 from NIST 800-53. The bracketed assignment in part a is the Organization-Defined Parameter (ODP): the exceptions where remote activation is allowed. Per the NIST discussion, indication of use includes notifying users when devices are activated, such as a pop-up stating that recording is in progress or that the microphone has been turned on, and solutions to prevent device usage include webcam covers and buttons to disable microphones. You can read the requirement directly at NIST 800-171 R3, 03.13.12 (p. 62).
One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.
The value below comes from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
NIST 800-171A R3 breaks 03.13.12 into three (3) assessment objectives: one (1) Organization-Defined Parameter (ODP) and two (2) determination statements. These AOs are:
The objectives are defining the allowed exceptions (ODP[01]), prohibiting remote activation outside those exceptions (a), and providing an explicit indication of use to users present at the device (b). If you are a DoD contractor, the ODP is specified. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, remote activation is allowed only as enumerated and justified in the System Security Plan (SSP) before such remote activation occurs, only when there are no other options, and only when the remote activation is operationally critical. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.13.12 (p. 81).
Examine: system and communications protection policy and procedures; procedures for collaborative computing; access control policy and procedures; system configuration settings; system design documentation; system audit records; system security plan.
Interview: personnel with responsibilities for managing collaborative computing devices; personnel with information security responsibilities; system developers; system administrators.
Test: mechanisms for supporting or implementing the management of remote activation of collaborative computing devices; mechanisms for providing an indication of use of collaborative computing devices.
03.13.12 maps from NIST 800-171 R2 requirement 3.13.12 (prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device):
Mapped against the three (3) AOs, two (2) are direct (minimal effort) and one (1) has no clear mapping (significant effort). Prohibiting remote activation and providing indication of use carry forward, while the requirement to define and justify the allowed exceptions is the new work. Note also that the R2 objective to identify collaborative computing devices (3.13.12[a]) has no corresponding R3 objective. Document your exceptions rather than assuming a blanket prohibition satisfies the defining objective.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.13.12 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about exceptions and indication of use, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.13.12 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.13.12 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.13.12 recording the ODP values you adopted.
With two (2) AOs mapping directly and one with no clear mapping, 03.13.12 is a moderate lift centered on defining exceptions. A realistic sequence:
What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.13.12? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.13.12.a: only as enumerated and justified in the System Security Plan before such remote activation occurs, and only when there are no other options, and the remote activation is operationally critical.
How many assessment objectives does NIST 800-171 R3 03.13.12 have? NIST 800-171A R3 breaks 03.13.12 into three (3) assessment objectives: one (1) Organization-Defined Parameters (ODPs) and two (2) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.13.12 come from? SC-15.
Where does NIST 800-171 R3 03.13.12 sit in the NIST 800-171 R3 Kill Chain? Phase 12, Secure Baseline Configurations (SBC). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.13.12 Collaborative Computing Devices and Applications prohibits remote activation of collaborative computing devices and applications except for defined exceptions and provides an explicit indication of use to users present at the device. It maps from R2 3.13.12 with the prohibition and indication objectives transitioning directly, while defining the allowed exceptions is the new work. The recurring problem is permitting remote activation with no documented, justified exceptions. Define exceptions narrowly (for DoD, only as justified in the System Security Plan), prohibit remote activation by default, and make device use visible to people in the room.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
