SC-15 collaborative computing devices: evidence and audit

What SC-15 collaborative computing devices requires in plain terms

SC-15 asks you to stop cameras, microphones and similar devices from being switched on remotely, and to show people in the room when those devices are in use. An assessor or customer who asks how remote activation is controlled wants to see two things: a documented prohibition with any allowed exceptions named, and a technical or procedural way for a person physically present to see that a sensor is active. The control appears in all three SP 800-53B security baselines (low, moderate and high), so it applies to most systems that handle federal or regulated information, and it is assessed as a system-implemented control rather than a purely administrative one. The first part of the requirement is a prohibition with a short list of exceptions. Your organization must define what counts as a collaborative computing device or application in its environment, typically video conferencing clients, room systems, networked whiteboards, smart displays and any peripheral with a microphone or camera. The second part is an explicit indication to users present, such as a visible light, an on-screen icon or a hardware shutter state that cannot be faked by software. The risk is covert audio and video capture: a device that a remote party or malicious code can turn on without anyone in the room knowing. This is hard in practice because each source enables sensors differently. Device defaults often leave microphones enabled for voice assistants. Meeting software may request camera access on launch and keep it after the meeting ends. Networked peripherals, such as conference speakerphones or room cameras, may accept remote control commands over the network. Start by inventorying every device class and application that can reach a sensor, then record for each one whether remote activation is disabled, which exceptions apply and how users are told the sensor is live. Confirm these settings with your vendors and in your own test environment, since default behavior varies by model and software version.

Which devices and applications SC-15 covers in your system

SC-15 reaches further than laptop webcams, so scoping starts with an inventory of every device and application that can turn on a camera, microphone or similar sensor. The cards below separate the decisions that change the work, and each one names who should confirm the list before assessment begins.

Endpoints with built-in cameras and microphones

Laptops, desktops and thin clients with integrated cameras and microphones are the most common SC-15 scope item. The control asks whether remote activation is prohibited, and whether the user can see that a device is in use. Ask the endpoint team to confirm which models in the fleet have sensors, which operating system settings or management profiles disable remote activation, and whether those settings are enforced rather than left to users. A fleet query or configuration baseline usually provides the evidence an assessor will sample.

Conference room systems and whiteboards

Room systems, video bars and networked whiteboards are collaborative computing devices that often stay powered on and are reachable from the network. Facilities and IT should confirm which rooms hold these devices, whether they are on the system boundary or a separate network, and who can start a session remotely. Assessors will look at system design documentation and configuration settings for each device class, so an accurate room inventory is the starting point.

Collaboration applications requesting device access

Meeting and messaging applications request access to cameras and microphones, and some can be started or joined by someone outside the user's control. The scoping question is which applications are approved on the system, which permissions they hold, and whether the organization can block remote activation through application policy. The application owner and the security team should agree the list, since the approved set changes what the assessor tests.

Managed mobile devices

Phones and tablets that access the system carry cameras and microphones that can be activated by applications or by remote session tools. Confirm with the mobile management owner whether these devices are inside the system boundary, which policies restrict sensor use, and how the organization shows users when a sensor is active. Devices outside mobile management often fall outside the evidence set, so the boundary decision should be written down.

Contractor and third-party owned devices

Devices owned by contractors, vendors or visitors that connect to the system may have sensors the organization does not manage. Decide whether these devices are allowed on the system at all, and if they are, whether usage restrictions and network access rules keep them from reaching system resources. Procurement and the contract owner should confirm which devices are permitted and how the agreement treats their sensors, since the organization owns the control even when it does not own the device.

Baselines and shared evidence

SC-15 applies in the low, moderate and high SP 800-53B baselines, so the scoping list is required at every impact level. The related controls AC-21 and SC-42 often draw on the same device inventory, configuration settings and audit records, so one well-maintained list can serve all three. Ask the compliance lead to confirm which system owner signs the inventory and how often it is reviewed.

How an assessor tests whether SC-15 is met

This table links the examine, interview and test methods in SP 800-53A Release 5.2.0 to the two SC-15 determination statements, which cover blocking remote activation and showing users when a device is in use. Read it as a preparation checklist, and confirm the exact procedure wording in SP 800-53A before relying on it. The main takeaway is that an assessor needs both the documented decision and the device settings that prove it.

Method or object	What the assessor does	Evidence requested	Common findings
Examine: system design documentation	Reads how the system prohibits remote activation and where exceptions are approved.	Design documents listing in-scope devices and applications, plus any allowed exceptions.	Design text that is silent on cameras, microphones or networked whiteboards.
Examine: configuration settings and documentation	Compares documented device settings with the configuration actually applied.	Exported settings, policy files and the documents explaining each setting.	Settings that differ between device groups with no documented reason.
Examine: system audit records	Checks whether changes to device settings and exceptions are logged and traceable.	Change logs, approval records and audit entries for settings and exceptions.	Exceptions granted without an approval record or a review date.
Interview: system owners and administrators	Asks how remote activation is blocked and how users are told a device is in use.	Named owners who can explain the control and point to the evidence for it.	Staff unaware that a device group is exempt from the rule.
Test: prohibition of remote activation	Attempts or observes remote activation on sampled devices in each group, where the procedure allows.	Test results for each device group, with the settings in force at the time.	Remote activation possible on a group that the design says is blocked.
Test: user indication of active use	Checks that a visible or audible indication appears when a device or application is in use.	Screenshots, recordings or test notes showing the indication on sampled devices.	No indication on some device types, or indication users can disable silently.

How to implement SC-15 step by step

This sequence turns SC-15 into a documented, tested state: every sensor-capable device and application is known, remote activation is blocked except for approved exceptions, users can see when sensors are in use, and the settings are checked on a recurring basis.

Inventory every sensor-capable device and application
The system owner, with help from endpoint management and facilities teams, lists every device and application that can activate a camera, microphone, or networked whiteboard. Include conferencing clients, meeting room hardware, browser-based collaboration tools, and personal devices allowed on the system. Record the make, model, software version, owner, location, and the system boundary each one belongs to. The step is done when the inventory is reconciled against asset records and the system security plan, and gaps are assigned to an owner.
Define allowed remote activation and document exceptions
The organization decides whether any remote activation is permitted, since SC-15 allows it only where the organization authorizes it. Security, the business owner, and the authorizing official approve each exception in writing, with the device, the purpose, the users, the conditions, and the review date. Anything not on the approved exception list is treated as prohibited. The output is an approved exception list signed by the accountable owner. If no exceptions are needed, the document states that remote activation is prohibited across the system.
Configure devices and applications to block remote activation
Administrators set each inventoried device and application to refuse remote activation of its sensors, following the approved list. This is done through device management policies, application administration settings, room system configuration, or firmware options, depending on the product. Where a product cannot block remote activation, the team records the limitation, applies a compensating measure such as physical disablement or removal from the system, and gets it into the exception register. The output is a configuration baseline per device class that names each setting and its value.
Implement a visible or audible indication of active use
Teams confirm that every permitted collaborative device gives users present an explicit indication when its camera, microphone, or similar sensor is in use. The indication may be a status light, an on-screen icon, or an audible tone, and it must not depend on the user noticing a subtle change. Engineers document how each device signals use and where the indication could fail, such as when a sensor is in use by an application that does not report it. The step closes when the indication behavior is written into the configuration baseline.
Test blocking and indication behavior
Testers attempt remote activation from the approved management paths and from unapproved sources, and they check that each attempt is refused and that no sensor starts silently. They also confirm the indication appears for every permitted use. Each test records the device, the attempt, the expected result, the actual result, and the evidence captured, such as screenshots, logs, or configuration exports. Failed tests go into the plan of action and milestones with an owner. The output is an indication test results record that an assessor can trace back to the baseline.
Set up recurring checks and monitoring queries
The team converts the configuration baseline into a set of checks that run on a schedule, comparing each device and application against its approved setting. Queries look for unapproved sensor activity, configuration drift, and new devices that appear in the environment without an inventory entry. Results go to the security operations team, and drift is handled through the change control process. The output is a monitoring query set with a named owner, a review cadence set by the organization, and a record of how findings are closed.
Review the exception list and inventory on a set cycle
The control owner reviews the inventory, the exception list, and the configuration baseline on the review cycle the organization defined in its SC-1 policy and procedures. New devices, retired devices, expired exceptions, and changes in collaboration tools are reflected in the records. The review confirms that each exception still has a documented purpose and approval. The step is complete when the review record is signed, and the updated artifacts are available to the independent assessor who will test SC-15.

Evidence that passes an SC-15 assessment

An assessor testing SC-15 wants proof in three forms: what collaborative devices exist, how remote activation and visible indication are configured and enforced, and how exceptions and operating records stay current. The six artifacts below connect those three forms, and each one is only convincing when it matches the others.

Device and application sensor inventory

This is the list of every camera, microphone, networked whiteboard, conferencing app and similar collaborative device or application in the system boundary, including room systems and BYOD endpoints where they connect. SC-15 testing starts here, because an assessor cannot confirm that remote activation is blocked on a device nobody recorded. Check that the inventory is generated from discovery or endpoint queries rather than typed by hand, that each item has an owner and location, and that it is reconciled against asset records each review cycle. Ask whether unmanaged devices are detected or only listed.

Design document for blocking remote activation

The design document explains how the system prevents remote activation of collaborative devices and applications, and how users are shown when a device is in use. It should name the technical mechanisms, such as disabled remote wake or activation settings, hardware switches, application policies or network controls, and state which devices fall under each one. Assessors compare this narrative against the configuration evidence, so any mismatch becomes a finding. Keep the document tied to the current system version and review it whenever a new collaborative platform is added.

Endpoint and room system configuration exports

Configuration exports show the settings in force on endpoints and room systems, such as whether camera and microphone access for remote activation is disabled and whether indicator behavior is enforced. An assessor will sample these exports against the design document and the inventory. Use an agent that checks settings on the device itself, and confirm which settings your platform can read natively before promising coverage. Refresh exports on a schedule and keep the timestamp and hostname with each file so the sample can be traced.

Approved exception register

Some organizations need a collaborative device to stay active for a documented purpose, such as an emergency conference bridge or a monitored classroom. SC-15 allows remote activation only where the organization permits it, so each exception must be recorded with its business justification, approving authority, named owner, compensating controls and expiry date. The register is what turns an unexplained exception into an accepted risk. Check that every device found in configuration exports either appears in the register or is non-compliant, and that expired entries are reviewed rather than left open.

Indication test records

Indication test records show that users present at a device are explicitly told when a camera, microphone or similar device is in use. The test should be run on each device type and documented with the date, tester, device, expected indication and observed result. Assessors look for a repeatable procedure and for failures that were logged and fixed, not only a single clean pass. Repeat tests after firmware or application updates, because an update can silently change indicator behavior.

Audit records and query results over time

Audit records and recurring query results show that the controls operated across the assessment period, not only on the day of testing. Scheduled osquery or endpoint policy results, change logs for collaborative settings and alert history demonstrate continuity. Confirm that retention covers the whole period an assessor will sample, and that the query results show both passing and failing devices with their remediation. Keeping these records current between audits is what allows an assessor to accept a sample instead of re-testing every device.

What meeting SC-15 costs in money and effort

This table lists the cost components of meeting SC-15, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a scoped quote, since no price or duration is published for this control and the real figures depend on your device estate and collaboration platforms.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up and how to keep it down
Device and application inventory	Internal engineers or an implementation partner	One-time, then refreshed on change	Rises with device count, room systems and shadow collaboration apps. Keep it down by scoping the inventory to managed endpoints and conference room systems first, then adding exceptions.
Configuration of camera, microphone and whiteboard settings	Endpoint or platform engineers	One-time per device image, recurring on new builds	Rises with the number of operating system images and vendor-specific room systems. Keep it down by applying settings through a single managed baseline rather than per device.
Endpoint management or compliance tooling licenses	Tool vendor (commercial) or none for self-hosted open source	Recurring if commercial, usually per device or per seat	Rises with device count and the number of tools needed. Self-hosted open-source options such as Fleet (MIT) and osquery can remove this license line, though hosting and staffing still apply. Ask vendors for written licensing terms.
Testing of active-indication behavior	Internal QA or an implementation partner	One-time for each platform, then retest on updates	Rises with the number of collaboration platforms, browsers and firmware versions. Keep it down by testing a representative set and retesting only when a platform or firmware changes.
Exception handling and approvals	Security governance owner and device owners	Recurring	Rises with exception volume, such as executives needing remote-controlled room systems. Keep it down by approving a small, documented exception list with a stated business reason and review date.
Recurring evidence upkeep	Compliance lead and system administrators	Recurring, at each assessment cycle	Rises with how often policy results are captured and how many systems must be shown. Keep it down by scheduling automated policy checks and retaining their outputs in a single evidence store.
External review and independent assessment	Independent assessor or auditor, and internal staff preparing samples	Recurring, tied to the assessment cycle	Rises with the number of sampled devices and the depth of testing the assessor performs. Only the independent assessor issues findings. Ask any assessor for a written, scoped quote before work begins.
Auditor sampling time	Independent assessor, with internal staff supplying records	Recurring, per assessment	Rises when evidence is scattered or undocumented, forcing repeated requests. Keep it down by keeping the device inventory, configuration records and exception list current and easy to sample.

Open-source tools that produce SC-15 evidence

SC-15 asks for evidence that remote activation of collaborative devices is blocked and that users can see when a device is in use. The open-source tools below can produce configuration and per-device results that support those checks, but each one needs a policy or query written for the specific device behavior in scope.

Wazuh configuration assessment

Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and reports misconfigurations with remediation advice. It can check files, directories, registry keys and running processes, so it can show whether an endpoint's settings disable or restrict camera and microphone access where your baseline requires it. Confirm that a shipped policy checks the setting you need, or write a custom policy for your device configuration. Wazuh is licensed under GPL-2.0-only, so review the license terms with your legal team before distributing modified agents or policies.

Fleet policies for device checks

Fleet policies ask yes or no questions of enrolled devices, written as osquery queries, and the policies page shows which devices pass or fail each one. A policy can ask whether a collaborative device driver or application is present or disabled on each endpoint, which gives you a per-device record an assessor can sample. A passing result only proves what the query tests, so a policy that checks installed software does not show that remote activation is blocked. Fleet is licensed under MIT, which places few restrictions on internal use.

osquery scheduled queries

osquery exposes running processes, loaded kernel modules, open network connections, hardware events and file hashes as SQL tables. The osqueryd daemon can run those queries on a schedule across an entire fleet, which lets you record whether conferencing or capture processes are running and whether devices show unexpected hardware activity. Use the results to test SC-15 indications of use, such as a process that should appear when a camera or microphone is active. osquery is dual-licensed under Apache-2.0 OR GPL-2.0-only, and you may choose the license that fits your use.

Velociraptor hunts for artifacts

Velociraptor collects forensic artifacts defined in VQL from endpoints, and its hunts gather one or more artifacts across a group of systems. Offline machines are scheduled to collect when they reconnect, and each hunt gets a notebook for analyzing the combined results. This suits an assessor's request to see evidence across a sample of devices, or an investigation of a suspected remote activation event. Velociraptor is licensed under AGPL-3.0-only, so confirm that your use, including any hosted or network-accessible deployment, meets the license obligations before you rely on it.

Who does what for SC-15: your team, a partner and the auditor

Your organization owns SC-15. The control asks that remote activation of collaborative computing devices and applications, such as cameras, microphones and networked whiteboards, be prohibited except where you explicitly allow it, and that users present get an explicit indication when a device is in use. Those decisions belong to you because they depend on your mission, your user population and the rooms and systems where sensors sit. Your security and facilities staff must make the calls that a partner or auditor cannot make for you.

Device inventory: Maintain the authoritative list of cameras, microphones, conferencing systems and networked whiteboards across endpoints and meeting spaces, including owner and location.
Exception decisions: Record which devices or applications may be remotely activated, who approved each exception, the business reason and the review date.
User indication policy: Define how users are told a device is active, such as a visible indicator or a required status display, and who owns that standard.
Procurement and configuration rules: Decide which products may enter the environment and which default settings they must ship with, and apply them through change control.
Governance and review: Keep the policy, exception register and system documentation current and approved by the people accountable for the system.

Before any assessment, confirm that someone internal can answer for every inventory item and every exception without relying on a vendor's account of its own product.

Where organizations usually fall short on SC-15

SC-15 is easy to state and easy to assume is handled, which is why gaps tend to sit in the places nobody looks. The cards below cover where programs usually break down, what closing each gap looks like, and the evidence an assessor would expect to see.

Meeting platforms missing from inventory

Conference room systems, smart whiteboards, video bars and the meeting client installed on laptops often sit outside the asset inventory because they are not servers. SC-15 applies to any collaborative device or application the system can activate remotely, so each one needs an entry. Check the inventory against what the meeting rooms and endpoints actually run, including devices bought by facilities teams. Evidence is an inventory extract that lists each device, its owner, and whether remote activation is permitted.

Vendor defaults accepted without testing

Many collaboration tools ship with cameras and microphones enabled for remote control or auto-join. Accepting those defaults means the organization has not decided whether remote activation is allowed, which is the decision SC-15 asks for. Test each default on a sample device, record the setting, and change it where remote activation is not needed. Evidence is the configuration baseline and a dated test result showing the device refuses remote activation when it should.

Undocumented exceptions to the prohibition

Executives or clinical teams often need a camera to stay available for a specific call, and the exception is granted verbally. SC-15 allows remote activation only where the organization permits it, so each exception needs a written justification, an approver, and an expiry date. Ask for the exception register and check that each entry matches a device still active on the network. Evidence is the signed exception record and the configuration showing the scoped permission.

No visible indication of sensor use

SC-15 expects users present to get an explicit indication when a camera or microphone is in use. Many rooms and laptops show an LED only for the built-in camera, and external microphones or ceiling units often show nothing. Walk through the common room types and endpoint models and note which devices give no indication. Evidence is a test record with photographs or screen captures for each device class, plus a remediation plan for any device that fails.

One-time screenshots as evidence

A single screenshot of a configured device proves the setting once and tells an assessor nothing about the next month. Continuous evidence is stronger: scheduled queries across endpoints, configuration checks against a baseline, and alerts when a device drifts. Osquery can run scheduled queries across a fleet, and Wazuh can check endpoint configuration against policy. Confirm with your assessor which recurring evidence they accept and how often they expect it to be refreshed.

No owner for new collaboration tools

Collaboration tools arrive through departments, trials and acquisitions, and nobody is named to assess whether each one can activate sensors remotely. Assign an owner for the collaboration tool list, with a rule that no tool is approved until its sensor settings are reviewed. Check for tools installed outside the approved list, and confirm the owner reviews the list on a set schedule. Evidence is the approved tool register with the named owner, the review date, and the sensor review result for each entry.

SC-15 questions buyers and practitioners ask before hiring help

Is SC-15 required in the low baseline?

Yes. SP 800-53B assigns SC-15 to the low, moderate and high baselines, so a system categorized at any impact level carries the base control. None of its enhancements is assigned to a baseline, which means the work is the base requirement: prohibit remote activation of collaborative devices and applications except where explicitly allowed, and show users present when a device is in use. Confirm the categorization of your system and the baseline your authorizing official or contract references, because the tailoring decisions belong to the organization. Also check whether a FedRAMP Rev5 class or another overlay adds parameter values that your documentation must reflect.

How much effort does SC-15 take to meet?

Effort depends mostly on how many collaborative devices and applications your systems include and how many of them can be activated remotely. SC-15 has one organization-defined parameter, so the organization must decide which exceptions are allowed and document them. Effort usually concentrates in three places: inventorying cameras, microphones, networked whiteboards and conferencing clients across managed endpoints and meeting rooms, configuring them to block remote activation, and collecting configuration evidence. The work is largely one-time, with recurring effort when new devices or applications are added. Ask any partner to show how they will count endpoints and rooms before they give you a number.

Can we meet SC-15 without an outside partner?

Often yes, if you have engineers who can administer endpoints and meeting-room systems and a compliance lead who can write the policy and evidence package. The organization owns the control, so the decision on allowed exceptions and the indication behavior must come from your side. An implementation partner can help with configuration, scripted checks and evidence collection, but it does not decide whether the control is satisfied. Only an independent assessor reaches that conclusion during an assessment. Teams usually bring in help when the device estate is large, when the device owners are spread across business units, or when the assessment date is fixed.

What do our engineers and device owners need to provide?

Engineers need administrative access to endpoint management, conferencing platforms and any room systems that expose camera or microphone settings. Device owners, such as facilities and business unit managers, need to confirm which devices are in use, where they sit and who approves exceptions. Collect system design documentation, configuration settings with their documentation, and audit records that show changes over time, since these are the objects an assessor examines for SC-15. Engineers should also confirm which indication behavior each application provides, such as a visible light or on-screen icon, and record any gap as a risk item.

How long does SC-15 work take?

Timing depends on scope: the number of devices, rooms and applications, how many teams own them, and whether the configuration is already centrally managed. No duration applies to every environment, so ask for a schedule built from a written inventory rather than a generic estimate. A fixed-scope engagement usually agrees deliverables and dates in writing before work starts. Ask whether the schedule covers the policy and exception decisions, not only the technical changes, because those decisions often take the longest.

How do AC-21 and SC-42 relate to SC-15?

SC-15 is one of three related controls in the catalog for this topic, along with AC-21 and SC-42. SC-15 covers remote activation of collaborative devices and applications and the indication to users. SC-42 covers sensor capability and data more broadly, including cameras, microphones and GPS, and it is not in any SP 800-53B baseline. AC-21 concerns information sharing decisions, which can overlap when shared content is captured or transmitted by collaborative tools. Plan one inventory that serves all three, and confirm with your assessor how they want overlapping evidence mapped, because the mapping is their decision.

What should we ask for in a written quote for SC-15?

Ask the provider to state the scope in writing: which devices, rooms, applications and operating systems are included, which baseline and any FedRAMP class applies, and which SC-15 parameter values they will propose for your review. The quote should list deliverables such as configuration baselines, scripted checks, exception records and an evidence package mapped to the examine objects. Ask who performs each task, what you must provide, what recurs after handover and what happens if the inventory changes. Ask also what the provider does not do. DeployOpen prepares systems and evidence for assessments and does not issue reports or certifications; an independent assessor does that. A DeployOpen quote follows from written scope.

Which open-source tools can show SC-15 evidence?

Several self-hosted tools can gather evidence about endpoint state, which is useful for SC-15 checks on managed computers. Wazuh's Security Configuration Assessment runs YAML policies against endpoints and reports misconfigurations with remediation advice, and it can be extended with custom policies. Fleet policies ask yes or no questions of devices as osquery queries and show which devices pass or fail, while osquery exposes running processes and hardware events through SQL tables. Velociraptor collects artifacts across groups of systems through hunts. Each tool checks what it is configured to check, so confirm that your policies cover the camera, microphone and application settings you have decided to control.

How DeployOpen scopes and prepares SC-15 evidence

DeployOpen works on SC-15 as part of a self-hosted implementation inside your own infrastructure. We prepare the configuration, monitoring and documentation that show how collaborative devices and applications are restricted and indicated, while your organization keeps ownership of the control and an independent assessor issues any findings.

How we scope

Written scope names the systems, endpoints, meeting platforms and device classes covered by the SC-15 review.
Scope records which remote activation paths are prohibited and which exceptions your organization has approved.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.

How we build

We configure endpoint policies that check camera and microphone settings against the approved baseline on each device.
Open-source monitoring such as osquery and Fleet can report which hosts pass or fail each yes or no policy.
Test results are reviewed with your team so the evidence reflects the behavior your users actually see.

How we hand over

Handover includes configuration settings, policy definitions and query results mapped to the SC-15 determination statements.
Documentation explains how the system design prevents remote activation and how users are shown when a device is in use.
Your team receives the material to present to an independent auditor, who decides whether the evidence meets the requirement.

How we support

Ongoing support and upgrades are available as a retainer, including updates to policies after device or software changes.
Periodic checks confirm that exceptions remain approved and that the evidence still matches the running configuration.
Confirm with your assessor which evidence formats and sampling they expect before the handover is finalized.