SC.L2-3.13.12 Collaborative device control: evidence and assessment

What SC.L2-3.13.12 collaborative device control requires

SC.L2-3.13.12 requires two things: no one can switch on a collaborative device such as a camera or microphone remotely, and anyone physically present must be able to tell when such a device is in use. If a CMMC Level 2 assessment is coming and your environment includes conference room systems, webcams, microphones or smart displays with sensors, assume an assessor will ask where those devices are, who can activate them, and how someone standing in the room would know they are live. The requirement comes from NIST SP 800-171 Rev. 2, and the CMMC Level 2 version carries it as a 1-point requirement. Under NIST SP 800-171A, an assessor tests three objectives: identify the collaborative computing devices in use, provide users an indication when a device is in use, and prohibit remote activation. Each objective needs evidence, so a policy statement alone will not satisfy it.

The risk is straightforward. A device that a remote party can switch on can capture a room where CUI is discussed without anyone knowing. Assessors therefore test this at the device and room level, not only in policy. In practice that means checking the configuration of each conferencing system and camera class, confirming that remote wake or remote enablement is disabled or controlled, and walking a room to see whether a visible LED, on-screen indicator or other clear signal shows when the microphone or camera is active. Many organizations miss this because the video platform, the room controller and the device firmware each have separate settings, and the policy owner rarely checks all three. Screen sharing is outside this requirement's intent. Sharing a window or desktop from a laptop does not activate a collaborative computing device, although it may be covered by other controls.

Confirm the device inventory first, including personal devices that employees bring into controlled spaces, and ask your managed conferencing or endpoint team for the remote-enablement and indicator settings in writing. Where a device cannot signal that it is in use, the CMMC Assessment Guide Level 2 accepts manual means such as paper notices on entryways or locking the entryway while the device runs. Record which approach applies to each room, since the assessor will ask for that record. Open-source endpoint tools can help produce evidence. Fleet policies, written as osquery queries, can show which managed endpoints pass or fail a check, and osquery can list running processes and hardware events so you can see whether a camera or microphone is active on a managed host. Confirm with each tool's documentation which devices and events it can actually observe before you rely on it.

Which devices and teams fall under collaborative device control

Scope for SC.L2-3.13.12 follows the CUI system boundary, not the building floor plan. Any collaborative device that sits inside that boundary, or can capture discussions held near CUI, needs an owner, a documented state and evidence that it meets the requirement.

Endpoints that touch CUI

Laptops, desktops and thin clients that process, store or display CUI are inside the boundary, and their built-in webcams and microphones come with them. Confirm which endpoints are assessed as in scope in the system security plan, then check each model's camera and microphone controls against the requirement. Ask whether the operating system or management tool can disable remote activation and show a visible indicator when the device is in use. Note that the built-in camera on a CUI laptop is in scope even if no one plans to use it.

Conference rooms with CUI on screen

A meeting room becomes in scope when CUI is presented, shared or written on a whiteboard there, or when a video system connected to a CUI network is installed in it. Facilities and IT should jointly list rooms that host CUI discussions. For each room, record the camera, microphone and codec, who can start a call remotely, and what visible or manual indicator users see when capture is live.

Standalone collaboration systems

Dedicated video bars, room codecs, smart displays and speakerphones often run their own operating systems and firmware, and sometimes their own cloud accounts. Each one that connects to a CUI network or stores CUI must appear in the asset inventory with an owner and a configuration baseline. Confirm that remote activation can be turned off, that firmware is updated under change control, and that the administrative interface is not reachable by general users.

Ownership across IT, facilities and executive support

IT usually owns the network path and the device configuration, facilities owns room layouts, signage and manual indicators, and executive support often buys and manages boardroom equipment outside normal channels. Write down who approves a new collaborative device, who configures it, and who answers for it during an assessment. Gaps often appear where a department buys equipment that IT never reviews.

Shared and visitor spaces

Lobbies, shared offices, co-working areas and client suites can place visitors near CUI discussions or screens. Visitors do not have to be malicious to matter, since an active camera in a shared room can capture what is on a nearby display. Decide whether CUI may be discussed or displayed in those spaces at all, and if not, document the restriction and the physical controls that enforce it. Where a device cannot signal use, the CMMC Assessment Guide describes manual means such as paper notices or locked entryways while the device is in use.

Confirming scope with the boundary

Start from the system boundary diagram and the list of assets that process CUI, then add collaborative devices that connect to those assets or sit in those rooms. Remove devices that have no network path to CUI only after the reasoning is written down and reviewed. Ask your assessor or consultant to confirm the scope decision before you rely on it, because the assessor makes the final call on what is in scope.

How an assessor tests collaborative device control

An assessor tests SC.L2-3.13.12 against the three assessment objectives that *NIST SP 800-171A* sets for requirement 3.13.12: identifying the collaborative computing devices in the system, providing users an indication when those devices are in use, and prohibiting remote activation. The assessor starts with the written policy and procedures for collaborative computing, then checks the access control policy and procedures and reviews audit records. The organization should expect the assessor to ask for the policy that names which devices are covered, such as built-in cameras, microphones and attached conferencing equipment, and the configuration that enforces it on each device class.

Next, the assessor builds the device population. Because the organization must identify every collaborative device before it can control one, the assessor compares the organization's own inventory with what discovery tools report on endpoints and meeting room systems. The assessor then samples devices from that list and tests each sampled device directly: can remote activation be turned on from outside the room or the user's session, and does the device show a visible indication when it is in use? Where a device cannot signal use electronically, the CMMC Assessment Guide Level 2 accepts manual means such as paper notices on entryways or locking entryways during use, so the organization should decide in advance which approach covers each location.

Evidence must be in final form to count. A requirement is MET only when every applicable objective is satisfied with evidence that is complete and approved, so draft policies, unsigned procedures and screenshots without dates will not carry the requirement. Organizations should confirm with their assessor or C3PAO which evidence format they accept before the assessment, and should not treat screen-sharing controls as a substitute for this requirement, because the requirement is aimed at cameras, microphones and similar devices.

What assessors ask for and where findings come from

This table compares the three SP 800-171A assessment objectives for SC.L2-3.13.12, the evidence an assessor expects for each, how the assessor tests it, and the findings that appear most often. Read each row as a question the assessor will put to you, then check that your evidence answers it in final form.

Assessment objective	Evidence an assessor expects	Test approach and common findings
Collaborative computing devices are identified	A current inventory of cameras, microphones and similar devices in the assessment scope, tied to the system boundary and asset records	Assessor compares the inventory with a walkthrough or scan of endpoints and meeting rooms. Common finding: undocumented devices such as built-in webcams on laptops or conference hardware missing from the list
Users are given an indication when a device is in use	Documented method for signaling use, such as an indicator light or on-screen notice, plus configuration screenshots or test records showing it works	Assessor observes a device being activated while a user is present. Common finding: no indication at the device, or a software indicator that is disabled by default
Remote activation is prohibited	Configuration baselines or policy settings that disable remote activation, change records, and endpoint or management tool reports showing the setting is applied	Assessor checks settings on sampled systems and tests whether a remote session can turn on a camera or microphone. Common finding: remote activation left enabled in conferencing or management software
Manual means where a device cannot signal use	Written procedure and physical notices, such as paper notices at entryways, or documented locking of entryways while the device is in use	The CMMC Assessment Guide Level 2 allows manual means where a device cannot signal it is in use. Common finding: no manual procedure exists for devices without indicators, so the requirement is not met
Policy and procedures	Policy stating which devices are permitted, who may enable them and how users are notified, plus records that staff were told	Assessor reads the policy against the three objectives and checks that procedures match what staff actually do. Common finding: a policy that does not mention remote activation at all
Screen sharing is excluded from scope	Documentation that records how screen sharing was assessed and why it is outside the intent of this requirement	Assessor confirms that screen sharing alone does not satisfy or fail the requirement. Common finding: screen sharing evidence offered in place of camera and microphone evidence

How to implement collaborative device control step by step

This sequence turns SC.L2-3.13.12 into a documented, tested control: every collaborative device in scope is found, given a specific control, verified, flagged to users where needed, and recorded so an assessor can trace each device from inventory to test result.

Inventory every collaborative computing device in scope
Start with the system boundary and list every camera, microphone, and similar collaborative device that sits on, or is connected to, in-scope systems. Include laptops with built-in webcams and microphones, conference room units, USB peripherals, and devices in shared spaces. The owner of this step is usually IT operations with input from facilities. It is done when the inventory names each device, its location, the system it connects to, and who uses it, and the list is reviewed against asset records so nothing is missing.
Decide the control for each device
For each inventoried device, record which control applies: a technical setting that disables remote activation, a physical cover or disconnection, or a manual means where the device cannot signal use. Decisions should follow the device type and where it is used, and each should be signed off by the system owner. The output is a decision register with one row per device or device class, stating the control, the reason, and the owner. Keep the reasons in plain terms so an assessor can follow them.
Configure and verify the remote activation setting
Apply the chosen technical setting through the device management or operating system policy in use, such as a managed configuration profile, group policy, or a conference system administration console. Then test it: attempt remote activation from a session that should be blocked and confirm the device does not start. Record the setting name, the policy version, the test date, and the result. The step closes when the test passes on a representative sample of each device class and the evidence is saved.
Add user indicators or manual notices where needed
Where a device cannot show that it is in use, add a manual means. The CMMC Assessment Guide Level 2 describes paper notices on entryways or locking entryways while a device is in use as examples of such means. Place the notices where people present will see them, and where the device does signal use, confirm the indicator is visible to the user at the device. The output is a photographed or documented placement record for each location, which shows the control exists in the physical environment.
Document the collaborative computing procedure
Write the procedure that tells administrators and users how collaborative devices are controlled, who may enable them, how users are told a device is in use, and how exceptions are approved. Link it to the system security plan and the access control and configuration baseline where it applies. The procedure is complete when the system owner approves it, it is version-controlled, and users in scope have been told where to find it.
Monitor and retest on a set cycle
Set up recurring checks so the setting stays in place. Endpoint tools can help: Wazuh Security Configuration Assessment can check configuration items against YAML policies on monitored endpoints, and Fleet policies can ask yes or no questions of devices as osquery queries, showing which devices pass or fail. Confirm with your tool vendor that the specific setting you rely on can be checked before you depend on it. Retest after operating system updates, device replacements, and policy changes. Each retest adds a dated record to the test log.
Keep test records and evidence for the assessor
Keep a single test record that ties each device to its control, the configuration evidence, the physical notice evidence, the procedure, and the dated test results. Assessors examine objectives against evidence in final form, so keep signed, dated versions rather than working drafts. Velociraptor hunts or osquery queries can gather proof from many endpoints at once when assessors ask. The step is done when a reviewer can pick any device in the inventory and trace it through to a passing test.

Evidence that passes for collaborative device control

An assessor testing SC.L2-3.13.12 looks for proof of three things: which collaborative devices exist, that remote activation is prohibited, and that people present at a device can see when it is in use. The cards below cover the artifacts that show each of those points, plus the dated records that keep them credible between assessments.

Collaborative device inventory

Start with a current list of every camera, microphone, and other collaborative computing device in the assessed environment, including conference room systems, webcams on laptops, and docking stations with built-in audio. Record the asset owner, location, and whether the device is managed by the organization. An assessor will compare this list against what they see on a walkthrough, so a missing webcam on a managed laptop is a common finding. Reconcile the inventory against endpoint management data at least each assessment cycle and keep the reconciliation dated.

Remote activation configuration baselines

Export the configuration settings that disable remote activation of cameras and microphones on managed endpoints and conference systems, and show they match the approved baseline. The evidence should show the setting, its value, and the system it applies to. Wazuh Security Configuration Assessment can check endpoint configuration against YAML policies and report failures, and you can add custom policies for settings your baseline requires. Keep scan results dated so you can show the setting was enforced over time, not only on the day of the assessment.

In-use indicator test records

Document tests showing that a device in use gives a visible indication to the person at the device, such as an indicator light or on-screen notice. Capture dated screenshots or short test notes that name the device, the application, and the observed result. Repeat the test after operating system updates, driver changes, or conference software upgrades, because those changes can alter the indicator behavior. Where the indicator is set by a vendor product, confirm the behavior with the vendor and keep their documentation with your test record.

Manual notices and photos

Where a device cannot signal that it is in use, the CMMC Assessment Guide Level 2 describes manual means, such as paper notices on entryways or locking entryways while the device is in use. Keep dated photos of posted notices, the placement of each notice relative to the device, and any procedure that tells staff how to lock the room. Review the photos when rooms are refitted or furniture moves, since a notice that no longer faces the entry is not evidence of anything.

Procedures and access control policy

Keep the written procedure for remote activation and device use, and the access control policy that governs who may change camera and microphone settings. The assessment objectives expect procedures and policy to exist, be approved, and be followed, so link each device class in the inventory to a named procedure. Record the approval date, the owner, and the review date. When a procedure changes, retain the prior version so you can show what applied during the period under review.

Dated audit and fleet query records

Retain audit records and periodic query results that show remote activation settings were checked and that anomalies were handled. Fleet policies answer yes or no questions about devices, and its policies page shows which devices pass or fail each policy, which gives a dated pass or fail history. osquery can schedule queries across a fleet of hosts, and Velociraptor hunts can collect artifacts from groups of systems. Retain the query definitions, schedules, and results together, because an assessor will ask who reviewed failures and when.

What meeting SC.L2-3.13.12 costs in money and effort

This table breaks down the cost components of meeting SC.L2-3.13.12, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a scope and to frame the questions you ask in a quote, since no figures are published for this requirement.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and how to keep it down
Device configuration effort	Internal IT staff or an implementation partner configuring camera, microphone and conferencing settings	One-time, with periodic re-checks	Number of device models and conferencing platforms. Standardize on one approved configuration per device type.
Endpoint management or licensing	Software vendor or internal platform team, for any tool used to query or enforce settings	Recurring license fees where a commercial tool is used	Whether existing endpoint management or osquery-based tooling already covers the fleet. Confirm current licensing before buying anything new.
Physical notices or hardware changes	Facilities staff for signage, or hardware team for camera covers, indicator or shutter changes	One-time for signage and shutters, recurring for replacements	Number of rooms with collaborative devices and whether devices can signal use. Fewer, well-documented rooms cost less to maintain.
Engineering and facilities time	Internal engineers and facilities staff, or a fixed-scope implementation partner	One-time for design, recurring for changes to rooms and devices	Mix of managed and unmanaged devices and whether conference rooms are shared with other systems. Ask the partner to scope by room and device list.
Evidence upkeep	Internal compliance or security staff, and any partner who prepares evidence	Recurring, tied to each assessment cycle	Whether configuration records and policy statements are kept current. Versioned records and a single device inventory reduce rework.
Assessor sampling	Independent assessor or certification body, paid by the organization under its own engagement	Recurring at each assessment	How many rooms and devices the assessor selects and how quickly evidence can be produced. Prepare a sample-ready evidence set in advance.

Who owns collaborative device control and who can help

Your organization owns the control. The obligation to prohibit remote activation of collaborative computing devices and to show users present an indication when a device is in use sits with the organization that operates the system. That means your team decides which devices count as collaborative computing devices in your environment, writes the rules for them, and answers for them during an assessment. Ownership does not transfer to a consultant or a platform vendor.

Device inventory: Identify every webcam, microphone, conference room system and other collaborative device that can reach the CUI environment, including those built into laptops and displays.
Activation policy: Decide whether each device may be activated remotely at all, and document the answer with the business reason.
Use indicators: Confirm which devices show a light, icon or other visible signal when in use, and where manual notices are needed for devices that cannot signal.
Procedures and training: Write the procedures that staff follow for meetings, visitors and shared rooms, and record who has been trained on them.
Self-assessment record: Your Affirming Official and assessment lead are accountable for the score and the System Security Plan entry for this requirement.

Before you engage anyone, confirm with your own assessment lead which device classes sit in your CUI boundary.

Questions about collaborative device control and CMMC assessments

Does screen sharing count as a collaborative computing device under SC.L2-3.13.12?

No. Screen sharing is outside the intent of SC.L2-3.13.12, which is aimed at devices such as cameras, microphones and similar peripherals that can be activated remotely and capture people or rooms. The requirement asks whether the system prevents remote activation of those devices and gives users present an indication when they are in use. Your assessor will still look at how screen sharing is governed under other controls, such as access control and session management, so document that decision in your system security plan rather than assuming it is out of view.

What should we do when a device cannot show that it is in use?

The CMMC Assessment Guide Level 2 says that if a device cannot signal it is in use, the organization should provide manual means. Examples in that guidance include paper notices on entryways and locking entryways while the device is in use. Record which devices fall into this category, the manual control applied to each, and who is responsible for enforcing it. Assessors will test whether the manual means exists and works in practice, so keep evidence such as photographs of posted notices, room procedures and records of the controls being followed.

Can SC.L2-3.13.12 go on a POA&M if we are not fully compliant?

It can, under the conditions in 32 CFR 170.21 and the scoring rules in 32 CFR 170.24. SC.L2-3.13.12 is worth 1 point and is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), so it may be placed on a plan of action and milestones for Conditional Level 2 status if your score is at least 88 of 110 (0.8). Closeout is due within 180 days. Confirm the current status of the CMMC phase schedule and the Department of War's review before relying on this route, and read the POA&M rules in the eCFR text linked from the pillar before you commit to a timeline.

How much effort does meeting SC.L2-3.13.12 usually take?

For most organizations the effort is modest, but it is not zero. The work splits into three parts: inventorying collaborative devices in every space that handles CUI, configuring or disabling remote activation where the platform allows it, and documenting the indicator or manual means for each device. Effort rises with the number of meeting rooms, endpoints with built-in cameras and microphones, and mixed fleets. Fleet-wide visibility tools can answer inventory questions, but the policy decisions and physical controls still need a person to own them. Ask any partner to show the inventory and the evidence trail before agreeing to a scope.

Can open-source tools produce evidence for this requirement?

They can help with parts of it. osquery exposes running processes and hardware events as SQL tables, and its osqueryd daemon can schedule queries across a fleet of hosts. Fleet policies ask yes or no questions of devices, such as whether a camera or microphone is enabled, and show which devices pass or fail. Wazuh Security Configuration Assessment checks endpoints against YAML policies and can be extended with custom checks. Velociraptor can collect artifacts across groups of systems. Confirm with each vendor whether a specific check exists for your operating system, because none of these tools will decide whether a manual indicator is adequate.

Should we hire a partner to help with this requirement?

Hire help when you lack staff who can map the requirement to your rooms, endpoints and documentation, or when you want an independent check before an assessment. DeployOpen implements, configures and hardens self-hosted open-source platforms in your own environment, and prepares systems and evidence for compliance assessments under a fixed-scope written agreement. DeployOpen does not issue reports or certifications; an independent C3PAO or other authorized assessor does that. Ask any provider for a written scope listing the devices covered, the evidence delivered and who signs the affirmations.

What evidence will an assessor expect to see for this requirement?

Assessors use the three assessment objectives in NIST SP 800-171A: identifying collaborative computing devices, providing users an indication of devices in use, and prohibiting remote activation. In practice that means a current device inventory, configuration records showing remote activation is blocked where possible, indicator or manual-means procedures, and access control and audit records that support the procedures. Evidence must be in final form, not drafts. Keep dated records so the assessor can see the control operating over time, not only on the day of the review.

How DeployOpen prepares collaborative device control evidence

DeployOpen plans and implements the technical and documentary evidence for SC.L2-3.13.12 Collaborative device control inside the client's own environment. The organization owns the control and its assessment decisions, while an independent assessor makes the judgment on whether the requirement is met.

How we scope

Inventory every collaborative device in scope, such as cameras, microphones and attached peripherals, across managed endpoints and meeting rooms.
Confirm which assessment objectives for 3.13.12 apply to each device type and location in the system security plan boundary.
Agree the written scope, deliverables and timeline before work starts, since engagements are fixed-scope.

How we build

Configure endpoint policies that prevent remote activation of cameras and microphones and document the settings used.
Deploy in-use indicators where devices support them, and define manual notices for devices that cannot signal use.
Test the remote activation controls and indicator behavior, then record results so an assessor can repeat the checks.

How we hand over

Deliver configuration baselines, policy exports, test records and screenshots mapped to the three objectives in SP 800-171A.
Document the manual procedures and physical notices for areas where automated indication is not possible.
Hand over all artifacts in final form with an owner for each item, so the organization can present them to its assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement ends.
Review device inventories and endpoint policy drift when new meeting hardware or endpoints are added to the boundary.
Confirm with the organization's assessor which evidence format they accept before final handover, since assessor requirements vary.

SC.L2-3.13.12 Collaborative device control