Quick-reference card
| Field | Value |
|---|---|
| Control ID | SC-15 |
| Control name | Collaborative Computing Devices and Applications |
| Framework | NIST SP 800-53, Revision 5 |
| Control family | System and Communications Protection |
| Baselines | LOW, MODERATE, HIGH |
| Relevance | System (First Party and Third Party) |
| Risk severity | Medium |
What this control requires
SC-15 requires organizations to block the remote activation of collaborative computing devices and to provide a visible indicator whenever those devices are in use. That means cameras, microphones, networked whiteboards, and remote meeting applications can’t be turned on without someone physically present knowing about it. The control is defined within the NIST SP 800-53 framework, which catalogs security and privacy controls for federal information systems.
In practice, you need two things in place. First, a policy and technical controls that prevent anyone from remotely enabling a device’s camera or microphone without explicit authorization. Second, a mechanism that alerts users in the room when a collaborative device is active, whether that’s an LED indicator, an on-screen notification, or an audible tone. The control does allow exceptions, but those exceptions must be formally documented and approved rather than left as unmanaged defaults.
This requirement sits within the System and Communications Protection family, which focuses on safeguarding the confidentiality and integrity of data in transit and at rest. SC-15 exists because collaborative computing devices create a direct path into physical spaces. Without restrictions on remote activation and without visible use indicators, these devices become surveillance vectors rather than productivity tools.
Why it matters
Most organizations treat collaborative computing devices as productivity infrastructure and overlook their security implications entirely. Conference room cameras, always-on meeting displays, and smart whiteboards sit on the corporate network with default configurations that allow remote activation, and no one audits whether they should.
Failure to maintain SC-15 introduces audit risk and may result in certification withdrawal or regulatory findings. For organizations pursuing FedRAMP authorization or working under FISMA requirements, a gap in collaborative device controls creates a documented deficiency that assessors will flag. The control applies at all three baselines, so there’s no exemption regardless of system categorization.
Beyond audit risk, uncontrolled collaborative devices create exposure that adversaries actively target. The convergence of remote work and hybrid meeting infrastructure has expanded the attack surface these devices represent.
What attackers exploit
- Default-enabled remote activation on conferencing hardware. Many enterprise video conferencing systems ship with remote management features enabled by default. Attackers who gain network access can silently activate cameras and microphones to conduct surveillance of physical spaces.
- Unpatched firmware on IoT meeting devices. Networked whiteboards, conference phones, and room controllers often run embedded operating systems that receive infrequent updates. Known vulnerabilities in these devices provide a foothold for lateral movement.
- Misconfigured meeting application permissions. Collaboration platforms that auto-join meetings or allow screen sharing without explicit consent create pathways for unauthorized observation.
- Lack of visible use indicators. When devices don’t signal that they’re active, occupants of a room have no way to detect unauthorized recording. This gap allows both external attackers and insider threats to operate without detection.
How to implement
The most common failure mode with SC-15 isn’t a lack of policy. It’s a disconnect between the policy that exists and the actual device configurations deployed across conference rooms, huddle spaces, and individual workstations.
For your organization
Start by inventorying every collaborative computing device on your network. This inventory should cover conference room systems, USB webcams, built-in laptop cameras and microphones, networked whiteboards, smart displays, and any remote meeting applications deployed across endpoints. You can’t enforce restrictions on devices you haven’t cataloged.
Specifically, disable remote activation by default on all conferencing hardware. Most enterprise systems from vendors like Cisco, Poly, and Zoom Rooms include administrative settings that control whether a device can be powered on or have its camera and microphone activated remotely. Set these to require local physical interaction unless you’ve documented a specific, approved exception.
The second requirement is visible and audible indicators that activate whenever a camera or microphone is in use. Hardware-level LED indicators are preferable to software-only notifications because they can’t be suppressed by malware. For software-based meeting applications, configure them to display persistent on-screen indicators during active sessions.
Where this gets missed most often is exception management. If your organization requires remote activation for specific use cases, such as remote IT troubleshooting of conference room equipment, record each exception with a justification, approval authority, and review cadence. These documented exceptions become critical evidence during assessments.
Common mistakes include relying solely on group policy for camera and microphone controls without verifying hardware-level enforcement, and overlooking personal devices that employees connect to the corporate network. Endpoint detection and response (EDR) tools and attack surface management platforms can help you identify devices that fall outside your managed inventory.
For your vendors
When assessing vendor compliance with SC-15, focus on whether the vendor has implemented both halves of the requirement: remote activation restrictions and explicit use indicators.
Request the vendor’s system and communications protection policy and look for specific language addressing collaborative computing devices. Organizations aligning with ISO 27001 information transfer controls should verify that vendor policies also cover collaborative device restrictions. A policy that covers “information systems” generically without mentioning cameras, microphones, or meeting applications is a red flag. The policy should enumerate device categories and define which remote activation scenarios, if any, are permitted.
In practice, configuration evidence matters more than policy language alone. Request screenshots or exports of device management console settings showing that remote activation is disabled by default. For cloud-based meeting platforms, ask for tenant-level configuration documentation that demonstrates restricted remote access to device features.
Take use indicators a step further by requesting photographic or video evidence of hardware indicators on conferencing equipment, along with documentation of software-level notification configurations. If the vendor claims hardware indicators are present but can’t demonstrate them, that’s a gap.
Include these questions in your vendor security questionnaires:
- Does your organization maintain an inventory of collaborative computing devices, including cameras, microphones, and meeting applications?
- Are remote activation capabilities disabled by default on all collaborative devices?
- What documented exceptions exist for remote activation, and how are those exceptions reviewed?
- What visible or audible indicators alert physically present users when collaborative devices are active?
A vendor risk management platform can help you track these responses across your vendor portfolio and flag vendors whose evidence doesn’t meet SC-15 requirements.
Evidence examples
| Evidence type | Example artifact |
|---|---|
| System and communications protection policy | Policy document defining restrictions on remote activation of collaborative devices, approved exceptions, and indicator requirements |
| Collaborative computing procedures | Standard operating procedures for configuring, deploying, and maintaining conferencing equipment with remote activation disabled |
| Device inventory and configuration documentation | Asset register of all collaborative computing devices with configuration baselines showing remote activation settings and indicator status |
| Access control policy and procedures | Access control documentation defining who can authorize remote activation exceptions and under what conditions |
| System design documentation | Architecture diagrams showing how collaborative devices connect to the network and where enforcement points for activation restrictions are applied |
| Audit records | System logs capturing remote activation attempts, indicator status changes, and exception usage for collaborative devices |
| System security plan | SSP sections documenting SC-15 implementation details, including the list of approved exceptions and compensating controls |
Cross-framework mapping
| Framework | Control(s) | Coverage |
|---|---|---|
| ISO 27001:2022 | 5.14 Information transfer | Partial |
| NIST SP 800-171 Rev 3 | 03.13.12 Collaborative Computing Devices and Applications | Partial |
Related controls
- AC-21 Information Sharing describes how organizations control the sharing of information across system boundaries, which intersects with SC-15 when collaborative devices transmit data between participants in different authorization domains.
- SC-42 Sensor Capability and Data addresses the broader category of sensor-equipped devices, including the data collection and use-restriction policies that complement SC-15’s specific focus on collaborative computing devices.
Frequently asked questions
What is NIST SP 800-53 SC-15
SC-15 is the National Institute of Standards and Technology (NIST) control that requires organizations to block remote activation of collaborative computing devices and provide an explicit indication of use to anyone physically present. The control covers cameras, microphones, networked whiteboards, and remote meeting applications. It applies at all three security baselines and mandates that any exceptions to the remote activation restriction be formally documented.
What happens if SC-15 is not implemented
Without SC-15 controls in place, collaborative computing devices can be remotely activated without the knowledge of people in the room, creating a surveillance risk. Assessors evaluating systems against NIST SP 800-53 will document the absence of remote activation restrictions and use indicators as a control deficiency. For organizations pursuing FedRAMP authorization, this gap can delay or block the authorization process. Regulatory bodies may also cite the deficiency in audit findings if the system falls under federal information security requirements.
How do you audit SC-15
Auditing SC-15 starts with verifying that the organization’s system and communications protection policy explicitly addresses collaborative computing devices and defines which remote activation exceptions are permitted. Assessors then examine device configuration settings to confirm that remote activation is disabled by default and that hardware or software indicators are functional. The audit should also review system logs for any unauthorized remote activation attempts and verify that documented exceptions include proper justification and approval.
What are collaborative computing devices in NIST 800-53
Collaborative computing devices are networked hardware and software used for real-time communication and collaboration, including video conferencing systems, cameras, microphones, networked whiteboards, and remote meeting applications. NIST specifically calls out these devices because they can capture audio, video, and visual data from physical spaces. The explicit indication of use requirement exists because occupants of a room need to know when these devices are actively transmitting, whether that’s through an LED light, on-screen notification, or audible signal.