03.13.12 Collaborative computing devices guide

What 03.13.12 collaborative computing devices requirement asks for

The requirement asks you to stop collaborative computing devices from being switched on remotely, except where you have defined a specific exception, and to make sure people physically in the room can tell when a device is in use. For a compliance lead responsible for a CUI environment, the practical question is whether a camera, microphone or whiteboard in a meeting room could start capturing a discussion of CUI without anyone in that room knowing. The concern is silent audio or video capture: a device that records or transmits while the people present believe it is off. Under 03.13.12 your organization owns the decision about which devices are in scope and which exceptions apply, and it must be able to show that the controls match those decisions.

NIST's discussion names whiteboards, microphones and cameras as the collaborative computing devices this requirement is aimed at. It excludes dedicated video conferencing systems that rely on a participant calling in to activate them, so do not assume the requirement covers every conferencing product in the building. Read that exclusion closely against your own room inventory: a device that a remote party can wake up without any local action is the case the requirement targets, and a system that only connects when someone in the room dials it may fall outside the discussion. The requirement has one organization-defined parameter, the exceptions where remote activation is allowed. NIST does not set those exceptions for you, so the decision and its written justification are yours. Confirm the exact wording of the parameter against the current SP 800-171 Rev. 3 publication before you record it in your system security plan.

Meeting this in practice is harder than the wording suggests. Many room devices run vendor firmware with remote management features turned on by default, and settings may differ between device models, firmware versions and cloud management consoles. Shared rooms add a second problem, because a device used by several teams may be reconfigured by people who never read the policy. Start with an inventory of every collaborative device that can accept remote commands, record its default and current activation settings, and disable remote activation unless an approved exception applies. Then decide how the in-room indication will work, such as a visible light or on-screen notice, and test that it shows when a remote session starts. Keep the inventory, configuration records and test results, because an assessor will expect evidence that the settings were checked, not only that a policy exists.

Which rooms, devices and applications fall under 03.13.12

Before any configuration work starts, the organization has to decide which spaces, devices and applications sit inside the CUI boundary. Each decision below changes who owns the control, what the assessor will sample and how much evidence has to be produced for 03.13.12.

Rooms and labs that handle CUI

Start by mapping every physical space where CUI is viewed, discussed or displayed, including engineering labs, program offices and secure rooms. A room that only holds a shared printer is different from one where CUI appears on a screen during a design review. Record each room in the system security plan so the assessor can trace which collaborative devices must follow the requirement. Confirm the list with the people who actually hold meetings in those spaces, because calendars often reveal rooms that facilities records do not.

Conference room hardware

Wall-mounted displays, conference phones and room codecs often include cameras and microphones that can be activated from the network. Inventory each unit, its firmware version and whether it accepts remote activation by default. A room system that is used only for internal CUI meetings still falls under the requirement if it can be started by someone outside the room. Ask the vendor to document the activation options, since the default settings may not match what the organization needs.

USB and network-attached cameras and microphones

Webcams plugged into a workstation and IP cameras mounted on a ceiling both capture what happens in a room. A USB camera is usually controlled by the host operating system, while a network camera may accept remote commands from any host that can reach it. Decide whether each device is inside the boundary, then confirm which network segment it sits on and who can reach it. Devices that cannot be disabled or restricted should be documented as exceptions in the system security plan.

Network-connected whiteboards

Modern whiteboards can save, stream and share what is drawn on them, and some connect to cloud services. NIST's Rev. 3 discussion names whiteboards among the collaborative computing devices, so a board that captures CUI sketches is in scope even though it looks like furniture. Check whether the board stores images locally, syncs to a vendor account or can be started by a remote user. Document where captured content goes, since that location may also bring media protection requirements into play.

Collaboration applications that start devices remotely

Meeting and chat applications can turn on a camera or microphone when a remote participant places a call or sends a request. Identify which applications run on managed endpoints, which are approved for CUI discussions and which accept remote activation by design. Dedicated video conferencing systems that rely on a participant calling in are excluded from the Rev. 3 discussion, so the scoping decision depends on how each application is configured. Record the configuration baseline for each approved application and test whether a remote request can start a device.

Boundary and devices owned by others

Facilities teams, building managers and third-party providers often install and maintain room equipment that the IT team never sees. Ask whether each device sits inside the CUI system security plan boundary, and if it does, agree in writing who configures it, who patches it and who produces its evidence. A managed service provider that operates a device in scope may need to be named in the plan and covered by the same requirements. Without that agreement, the organization owns the requirement but cannot show the assessor how it is met.

How an assessor tests 03.13.12 and what they ask to see

This table compares the three SP 800-171A Rev. 3 assessment methods and the ODP check for 03.13.12, showing what an assessor examines, interviews and tests, and what evidence they expect. Read each row as a question the assessor will ask, and use the evidence and findings columns to prepare before the assessment starts.

Assessment element	What the assessor examines or tests	Evidence the assessor typically requests	Common findings
Examine: determination statements	System and communications protection policy and procedures, collaborative computing procedures, and access control policy and procedures that cover remote activation	Approved policy and procedure documents, a dated revision history, and evidence of review by the policy owner	Policy says collaborative devices are restricted but no procedure describes how remote activation is blocked or checked
Interview: personnel	Staff who manage collaborative computing devices and personnel with information security responsibilities	Named owners for cameras, microphones and whiteboards, and a description of how changes to device settings are approved	Staff cannot say which rooms have always-on microphones or who approves an exception
Test: mechanisms	Settings and controls that govern remote activation of cameras, microphones and whiteboards on managed endpoints and room systems	Configuration exports, screenshots of settings, and test results showing remote activation is blocked unless an approved exception applies	A conferencing client or room device accepts remote activation of its camera or microphone with no exception on record
Explicit indication of use	Whether people physically present at a device get a clear indication when it is in use	Documented indicator design (for example, a visible light or on-screen status), and test records showing the indicator operates	A device activates remotely with no visible or audible indication to people in the room
ODP check: exceptions defined	Whether the organization has defined the exceptions where remote activation is allowed, as the requirement's one organization-defined parameter	A written, approved list of permitted exceptions, the reason for each, and the approver	The exception list is blank, vague ('as needed') or was never approved, so the ODP is not defined
Determination statements and scope	The two determination statements for 03.13.12 and the ODP definition check, applied to every device in the system security plan boundary	A device inventory that lists each collaborative device, its location, and whether it is in scope	Devices in meeting rooms or shared spaces are missing from the inventory, so they are never assessed

Implementing 03.13.12 in order, from device inventory to signed-off exceptions

This sequence turns the 03.13.12 requirement into a documented, tested state: every collaborative device inside the boundary is known, remote activation is blocked unless an approved exception applies, people in the room can see when a device is in use, and staff know how to keep it that way.

Inventory collaborative devices and applications
Start by listing every collaborative computing device and application inside the system boundary. Include cameras, microphones, whiteboards, and conferencing applications installed on endpoints or room systems. NIST's discussion names whiteboards, microphones and cameras as examples and excludes dedicated video conferencing systems that rely on a participant calling to activate, so record those separately and note how each one is classified. The engineer owns the inventory, and the compliance lead reviews it. It is done when every device has an owner, a location, a make and model, and a note on whether it can be activated remotely.
Define the organization-defined exception list
03.13.12 has one organization-defined parameter: the exceptions where remote activation is allowed. The system owner proposes each exception with a business reason, the users and rooms it covers, and the controls that apply while it is in use. The compliance lead checks each proposal against the system security plan. Ask the assessor early how they expect exceptions to be recorded, because the ODP value must be defined for the assessment to pass. The output is an approved exception register that names each exception, its scope, its approver, and its review date.
Record who approves each exception
For each entry in the register, capture the approver's name and role, the date of approval, and the signed decision. Separate the person requesting an exception from the person approving it, and keep approvals with the system security plan so an assessor can trace them. The output is a signed-off register with an approval record for every line. Entries without an approver stay blocked until someone with the right authority signs them.
Configure devices to block remote activation
Apply a configuration baseline that disables remote activation on every device and application in the inventory, except those listed in the approved register. Typical settings sit in device management, room system administration, or the conferencing platform's policy controls, and the exact setting names vary by product, so confirm them with the vendor documentation for each platform. Where a platform cannot disable remote activation, document the compensating control or retire the device. The output is a configuration baseline that maps each device to its setting and to the exception it serves, if any.
Add a clear indication of use in the room
Requirement 03.13.12 expects people physically present at the device to receive an explicit indication that it is in use. Choose an indicator that suits each space, such as a visible status light, an on-screen banner, or an audible tone when a camera or microphone activates. Confirm with the system owner that the indicator is visible to everyone in the room, not only the person operating the device. The output is a documented indicator for each device type and a photo or screenshot showing it working.
Test activation attempts from remote sessions
Test each device from a remote session, outside the room, to confirm that activation is blocked unless the device is on the approved register. Repeat the test for permitted exceptions to confirm the indication appears in the room. Record the test date, the tester, the device, the attempted action, and the observed result. Keep failed tests in the record along with the fix and the retest. The output is a test record that an assessor can examine, since the test method is part of how SP 800-171A Rev. 3 assesses this requirement.
Write and communicate the staff procedure
Write a short procedure that explains how staff request an exception, how they use a permitted device, what the in-room indicator means, and who to contact when a device behaves unexpectedly. Link the procedure to the register and the configuration baseline so that changes to one trigger a review of the others. Confirm that staff who manage collaborative devices and those with information security responsibilities have read it. The output is an approved procedure with a version number, an owner, and a record of who acknowledged it.

Evidence that passes 03.13.12 and how to keep it current

An assessor testing 03.13.12 looks for proof that remote activation is blocked, that exceptions are deliberate and owned, and that people in the room can tell when a device is in use. The artifacts below connect those three points, and each one needs a named owner and a trigger that refreshes it between assessments.

Collaborative device inventory

A current list of every camera, microphone, whiteboard, display with a capture function and similar device, with its room, owner, network status and whether it is managed. This is the starting point for every other artifact, because an assessor will pick devices from the list and ask to see their settings. Check it against the asset inventory used for 03.04 so that a device found in a room is also a device in the record. An unlisted device is the most common gap.

Approved exception register

A register of each place where remote activation is allowed, with the business reason, the named owner, the approval date and a review date. The 03.13.12 requirement allows exceptions only where they are defined, so an exception without an approval record is a finding. Review the register each quarter, and remove any exception whose reason no longer applies.

Configuration baseline per device class

A documented baseline for each class of collaborative device, such as conference room cameras, room microphones and networked whiteboards, that states the setting that blocks remote activation and the value it must hold. Keep the baseline under configuration change control so that a firmware update or a new device model triggers a review before it reaches a room.

Settings exports and screenshots

Exported configuration files or dated screenshots showing that remote activation is blocked on each device class, with the device identifier visible. Store them with the baseline and replace them after every firmware or platform change. An assessor will compare what was exported with what the device currently does, so the export must come from the device itself rather than from a template.

Remote activation test records

Dated records of attempts to activate a camera, microphone or application remotely from outside the room, with the result for each attempt and the tester's name. Repeat the tests after any change to the device, the network or the meeting platform. Tests that cover only the default configuration do not show that exceptions are enforced correctly, so include at least one approved exception in the test set.

In-room indication design evidence

Photos or a written specification showing the signal that tells people physically present that a device is in use, such as a lit indicator, an on-screen banner or a physical shutter state. Record which devices carry the signal and confirm it is visible from every seat in the room. Update the specification when a room layout changes, because a camera moved behind a partition may no longer show its indicator.

Procedure and training records

The written procedure for adding a device, requesting an exception and testing remote activation, with signed or logged training records for the staff who run those steps. Set a change-control trigger so that adding a new room or device starts the procedure, and log each completed step. Training records show that the procedure is followed in practice, and they are often the first thing an assessor requests when an inventory and a test record disagree.

What meeting 03.13.12 costs in money and effort

This table breaks down the cost components of meeting 03.13.12 for collaborative devices, who is paid for each one, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written scope and to compare quotes on like-for-like terms. No prices or durations are given because none are supplied; request them from each vendor or partner against your own room count and device inventory.

Cost component	One-time or recurring, and who is paid	What drives it up and what keeps it down
Device configuration and engineering time	One-time for the initial build of remote-activation blocks and indicators on each device class. Paid to internal staff or an implementation partner.	Up: many device models, unmanaged cameras and microphones, per-room custom setups. Down: a small set of standard device classes and one baseline configuration applied centrally.
Tooling and licenses	Open-source monitoring tools named for this topic (Wazuh, Fleet, osquery, Velociraptor) carry no license fee, but deploying and running them still consumes staff time. Recurring for hosting and upkeep.	Up: adding a separate tool per device type, or commercial platforms that lock you to one vendor's room hardware. Down: reusing one agent and one policy set across endpoints and room systems where the device supports it.
Exception list management	Recurring. Owned by the organization, with staff review of each approved exception for remote activation.	Up: long lists of rooms or applications allowed to activate remotely with no expiry. Down: short, documented exceptions with owners and periodic re-approval.
Evidence upkeep	Recurring. Owned by the organization, with help from the partner if the engagement includes it. Covers policy and procedure records, configuration exports and policy pass or fail reports.	Up: manual screenshots, unversioned configuration, devices added without records. Down: scheduled exports from the monitoring platform and change records tied to each device.
External testing or review	Recurring or per engagement. Paid to a security testing provider or independent reviewer who checks that remote activation is actually blocked.	Up: large numbers of rooms and device types to sample, and hard-to-reach remote activation paths. Down: a clear test plan limited to documented device classes and exceptions.
Assessor time	Per assessment cycle. Paid to the independent assessor or the contracting authority's assessor, who examines records and interviews staff.	Up: scattered evidence, undocumented exceptions, staff who cannot explain the indication of use. Down: one organized evidence set and trained staff who can describe the in-room indicator.

Which open-source tools can support 03.13.12 evidence

Assessors testing 03.13.12 look for configuration settings that block remote activation and for proof that people in the room are told when a collaborative device is in use. The four tools below read endpoint state, so they can show whether those settings are in place across a fleet. None of them is documented here as covering camera or whiteboard settings, so each needs a test in your environment before it goes into an assessment plan.

Wazuh configuration assessment checks

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and reports misconfigurations with remediation advice. It checks files, directories, registry keys and running processes, so a policy can confirm that a collaborative application is absent from startup or that a related setting holds its expected value. Custom policies let you write checks for the specific device software your organization uses. Wazuh is licensed under GPL-2.0-only, which governs how you distribute modified code, so confirm with counsel before embedding it in a product you ship. Verify that a custom check can read the exact registry key or file that controls your camera or microphone defaults.

Fleet policies for yes or no checks

Fleet policies are yes or no questions asked of devices as osquery queries, such as whether a collaborative application is running or whether a specific setting is enabled. The policies page shows which devices in each fleet pass and which fail, which gives an assessor a readable record of coverage. Fleet is released under the MIT license, a permissive license with few distribution obligations. Confirm that the question you write returns a reliable answer on each operating system you support, because a query that returns nothing can look like a pass.

osquery tables for running applications

osquery exposes running processes, open network connections, hardware events and other host data as SQL tables. A scheduled query run by osqueryd can report which devices have a camera or microphone application active, or which hosts show an open connection that suggests a remote session. Results can be collected across the whole fleet at a set interval, which supports periodic evidence rather than one snapshot. osquery is dual-licensed under Apache-2.0 OR GPL-2.0-only, so you can choose the license that fits your use. Confirm that your operating systems expose the specific device setting you need, since process and connection tables do not show every hardware preference.

Velociraptor hunts for activation evidence

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that gather one or more artifacts across a group of systems. Hunts suit a point-in-time review, such as checking every meeting room device after a policy change. Offline machines are scheduled to collect when they reconnect, and each hunt gets a notebook for analyzing the combined results, which helps document the review. Velociraptor is licensed under AGPL-3.0-only, which applies network-use obligations to modified versions, so review those terms before you offer it to users over a network. Confirm that a VQL artifact can read the device setting or process list you intend to test.

Who owns the controls, the build and the assessment

The organization owns the requirement itself. NIST's FAQ is clear that application and implementation of SP 800-171, and any compliance issues, rest with the federal agency that holds the contract or agreement, and in practice the nonfederal organization must still decide how the requirement is met inside its own environment. For 03.13.12 that means deciding which collaborative devices exist in the CUI boundary, which exceptions allow remote activation, and what the in-room indication of use looks like.

Exception decisions: The organization decides which, if any, remote activation exceptions apply, such as a dedicated video conferencing system that needs a participant to call in. Record each exception and its business reason.
ODP values: The single organization-defined parameter for this requirement must be defined. If the federal agency does not specify it, the organization must assign it to complete the requirement.
CUI boundary: The organization defines which rooms, endpoints and collaborative applications sit inside the scope where CUI is discussed or displayed.
Policy and procedures: The organization owns the system and communications protection policy and the procedures for collaborative computing that assessors examine first.
Final accountability: The organization signs off on its system security plan and answers to the contracting agency for the outcome.

Check that the ODP value, the exception register and the room inventory are approved by a named owner before any partner work begins.

Where 03.13.12 findings usually come from

Most 03.13.12 findings are not about missing technology. They come from an undefined exception list, default device settings nobody reviewed, and no record that anyone checked the result. The cards below pair each common gap with the fix an assessor would expect to see, so the organization can show both the decision and the proof behind it.

No defined exception list

The requirement lets the organization define exceptions where remote activation is allowed, and that value is an organization-defined parameter (ODP). If the exception list is blank, the requirement cannot be completed, and an assessor will check that the ODP is defined before testing anything else. Write the list in the system security plan, name each permitted device or application, and record the business reason and the approver. An empty list is a valid answer only if it is written down and approved.

Vendor default remote activation

Many conference devices, smart displays and room systems ship with remote activation or auto-answer enabled. Those defaults can persist after installation because nobody compares the device to a documented baseline. Check each device's administrative settings, disable remote activation for anything not on the exception list, and capture a configuration export as evidence. Repeat the check after firmware updates, since updates can reset settings.

No visible indication of use

The requirement expects people physically present at a camera, microphone or whiteboard to receive an explicit signal when the device is in use. A meeting room where a microphone can be live with no light, icon or audible tone fails that expectation. Confirm that each device in scope shows a clear status indicator, or add a physical indicator such as a tape-covered lens with a sign or a status light. Document how the indication works for each device type.

Shared rooms outside the boundary

Collaboration devices in lobbies, shared offices or partner-hosted rooms often sit outside the system boundary that the assessment covers. Assessors test what the boundary contains, so a camera that can be activated from a room in the scope area but is documented as out of scope creates an inconsistency. Inventory every collaborative device that can reach CUI systems, mark each as in or out of scope, and keep the inventory aligned with the system security plan.

Applications that open microphones

Meeting, chat and whiteboard applications may request microphone or camera access when they start, sometimes without a policy that says whether that is allowed. The requirement covers applications as well as devices. Set application policies that disable automatic device access where the exception list does not permit it, and test a clean session on a managed endpoint to confirm that the microphone stays closed until a user acts. Keep the policy file and the test result together.

No evidence of testing

A written policy without tests will not satisfy the test method in SP 800-171A, which calls for mechanisms that implement remote activation management to be examined. Schedule a recurring check that confirms devices and applications match the approved settings, and retain the output with dates and the name of the tester. Interview the staff who manage collaboration equipment so that they can explain the process. Where fleet tooling is used, a policy that reports pass or fail for each device gives the tester a repeatable result.

Questions buyers ask about 03.13.12 effort, timing and outside help

How much effort does meeting 03.13.12 take, and what drives it up?

The control itself is narrow: block remote activation of cameras, microphones and whiteboards unless an exception is defined, and show people in the room when a device is in use. The effort sits in the surrounding work. Most of the time goes to inventorying which collaborative devices and applications exist across meeting rooms, endpoints and shared spaces, deciding which exceptions the organization will allow, configuring the blocking and indication mechanisms, and writing the procedures that an assessor will examine. Effort rises with the number of rooms, device models and collaboration applications, with how many teams can change settings, and with how much the organization relies on dedicated video conferencing systems that need separate treatment. Ask any quote to break out inventory, configuration, testing and documentation as separate line items.

How long does 03.13.12 take to implement, and what does the timeline depend on?

No duration is set for this control, so the timeline has to come from your own environment. Confirm with your assessor and your sponsoring agency how they expect the evidence to look, then estimate from the inventory. The main variables are the number of collaborative devices, whether applications are centrally managed or set per user, how many organization-defined exceptions leadership wants to approve, and how quickly change control can approve configuration changes in production meeting spaces. Ask a prospective partner for a written schedule tied to the agreed scope, with the dependencies on facilities and IT change windows listed, before work starts.

Can our own team implement 03.13.12 without outside help?

Often yes, for a small and well-documented environment. A team with access to endpoint management, room system administration and facilities contacts can inventory devices, set remote activation controls and write the procedures. The harder part is defining the organization-defined exceptions and keeping evidence consistent over time, because an assessor will ask who approved each exception and how it is reviewed. If your staff lack experience writing assessment-ready evidence or testing controls in meeting spaces, an implementation partner can prepare the configuration and evidence while your organization keeps ownership of the control and its decisions.

What does 03.13.12 need from our IT, facilities and security staff?

Each group owns a different part of the control. IT administrators manage endpoints, room systems and collaboration application settings, and they need to confirm which features can be disabled remotely. Facilities or workplace teams know where devices are installed and who uses the rooms, and they can flag equipment that cannot be changed centrally. Security staff own the policy, define the exceptions, and examine the test results. Assign a named owner for the control and a reviewer for exceptions before work begins, because the assessor will expect a documented decision trail that links each allowed remote activation to an approved reason.

Can a consultant or implementation partner issue the 03.13.12 assessment result?

No. An implementation partner can prepare the configuration, inventory and evidence for 03.13.12, but only an independent assessor can assess the requirement and report on it. For a DoD contract, the assessment result that counts is produced under the DoD assessment process and recorded in SPRS by the organization. Your partner's role is to make the control ready to assess and to explain the evidence. Keep that separation clear in the statement of work so that no one mistakes preparation for certification or assessment.

How does 03.13.12 affect our CMMC or DoD scoring?

CMMC Level 2 assesses this practice as SC.L2-3.13.12 and assigns it one point under the 32 CFR 170.24 scoring methodology. That makes it a small weight in the total, but it is still a finding that must be met or documented for a passing result. Note that CMMC Level 2 uses the Rev. 2 requirement numbering, so the 3.13.12 identifier maps to the Rev. 3 requirement 03.13.12 for this topic. Confirm which revision your contract currently requires, because DoD contract clauses and the proposed FAR rule are changing how Rev. 2 and Rev. 3 apply.

How DeployOpen scopes and prepares 03.13.12 evidence

DeployOpen works on 03.13.12 by first agreeing in writing which collaborative devices and applications sit inside the assessed system, and which remote activation exceptions the organization has defined. We then configure, test and document the controls so the organization can show an assessor how remote activation is blocked and how people in the room are told a device is in use.

How we scope

Inventory cameras, microphones, whiteboards and other collaborative devices inside the assessed boundary, including meeting rooms and shared workspaces.
Confirm with the organization which exceptions to remote activation, the organization-defined parameter for 03.13.12, it has defined or must define.
Agree the scope in writing before work starts, since engagements are fixed-scope and ongoing support is available as a retainer.

How we build

Configure endpoints and room systems to block remote activation of collaborative devices except for the approved exceptions.
Set up a visible, explicit indication of use for people physically present at each device, and document how that indication works.
Use osquery queries and Fleet policies to check device settings across the fleet, and Wazuh configuration checks to flag drift from the baseline.

How we hand over

Deliver the policy and procedure documents for collaborative computing that an examiner would ask to see, mapped to the determination statements in SP 800-171A Rev. 3.
Provide test records showing remote activation attempts were blocked and that the in-use indication appeared, with the exceptions documented.
Hand over the evidence package to the organization, which owns its controls and decides what to share with its independent assessor.

How we support

Review the 03.13.12 settings after changes to room systems, meeting software or endpoint images, through a retainer if the organization wants ongoing support.
Rerun fleet queries and configuration checks on a schedule the organization agrees, and report deviations for remediation.
Confirm with the organization's assessor or contracting officer which evidence format and assessment method apply to its contract before finalizing the package.