Collaborative Computing Devices and Applications

To meet the Collaborative Computing Devices and Applications requirement, you must prevent remote activation of cameras, microphones, screen-sharing, and similar collaboration features unless you’ve formally defined and approved exceptions, and you must give a clear, user-visible indicator when those features are active. Your job is to turn that rule into enforceable configuration, monitoring, and evidence across endpoints, meeting rooms, and cloud collaboration apps. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Define what counts as a “collaborative computing device/application” in your environment, then block remote activation by default. (NIST Special Publication 800-53 Revision 5)
• Document narrow exceptions (who, why, and how controlled) and implement them with technical guardrails, not policy-only language. (NIST Special Publication 800-53 Revision 5)
• Ensure “explicit indication of use” is real-world visible (LED, on-screen banner, audible tone) and test it like a control, not a feature. (NIST Special Publication 800-53 Revision 5)

SC-15 shows up in FedRAMP work because collaboration tools blur a boundary auditors care about: a device in a physical space can be activated from somewhere else. The control is designed to reduce covert surveillance risk (camera/mic activation), reduce surprise data exposure (screen sharing, recording), and make sure users physically present have unambiguous notice when collaboration capabilities are in use. (NIST Special Publication 800-53 Revision 5)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SC-15 as an operational rule with two parts: (1) a default prohibition on remote activation, with explicitly defined exceptions, and (2) an explicit indication of use to people in the room with the device. You will need Security/IT to implement configuration baselines across endpoints and meeting-room systems, and you will need procurement/third-party risk coverage because many collaboration capabilities are delivered by third parties (UCaaS, conferencing hardware, device management). (NIST Special Publication 800-53 Revision 5)

This page gives requirement-level implementation guidance you can hand to system owners and then audit against.

Regulatory text

Requirement (SC-15): “Prohibit remote activation of collaborative computing devices and applications with organization-defined exceptions; and provide an explicit indication of use to users physically present at the devices.” (NIST Special Publication 800-53 Revision 5)

Operator interpretation:

• You must block remote activation by default for collaboration functions that could observe or capture content in a physical space (camera, microphone, recording) or expose content (screen share), unless you define an exception and control it. (NIST Special Publication 800-53 Revision 5)
• You must ensure people physically present get an explicit, hard-to-miss indicator when collaboration features are active (for example, camera LED, microphone active indicator, “recording” banner, screen-sharing overlay). (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation (what the requirement is really asking)

SC-15 is an anti-surprise control. If someone can remotely “turn on” a meeting room camera, start recording, or silently join a session, your organization needs (a) a default technical barrier, (b) narrowly governed exceptions, and (c) a visible indicator so occupants know the device/app is active. (NIST Special Publication 800-53 Revision 5)

This applies to devices (room systems, laptops, conference phones, smart displays) and applications (video conferencing, virtual desktop collaboration features, screen sharing, recording modules) as long as they enable collaborative interactions and can be activated or controlled remotely. (NIST Special Publication 800-53 Revision 5)

Who it applies to

Entity types in scope: Cloud Service Providers and Federal Agencies operating systems aligned to FedRAMP Moderate that implement NIST SP 800-53 Rev 5 controls. (NIST Special Publication 800-53 Revision 5)

Operational contexts where SC-15 becomes real:

• Conference rooms and huddle spaces with dedicated video bars, room PCs, speakerphones, or integrated panels.
• Employee endpoints (laptops/desktops) with webcams and microphones used for conferencing.
• VDI and remote support tools that can enable audio/video redirection or start sessions that expose screens.
• UCaaS/conferencing platforms and admin consoles that can push configuration or initiate device behaviors.
• Third-party-managed meeting spaces (shared offices, managed facilities) where you don’t own the full stack but still inherit risk.

What you actually need to do (step-by-step)

Step 1: Define the scope in one page (so engineers can implement consistently)

Create a short “SC-15 Scope & Definitions” document that names:

• Collaborative computing devices: meeting room endpoints, webcams, conference phones, smart displays, room PCs.
• Collaborative computing applications: conferencing clients, web conferencing, screen share modules, recording features, remote control plugins.
• “Remote activation” events you care about: enabling camera/mic, starting a recording, initiating screen share, auto-answer/join behavior, remotely enabling peripherals. (NIST Special Publication 800-53 Revision 5)

Deliverable: a scoped inventory list or tagged CMDB category that lets you say, “These are the assets this control applies to.”

Step 2: Set the default posture: prohibit remote activation

Translate “prohibit” into specific technical rules your IT/Sec teams can implement:

• Disable auto-answer / auto-join meeting room behaviors unless required for operations.
• Require local user action to enable camera/mic where the platform supports it (for example, user consent prompts).
• Restrict admin capabilities in UCaaS/admin portals that can silently start recording or enable devices.
• Harden endpoint privacy settings (OS/app permissions) so camera/mic access is not silently granted to apps.
• Control remote support tools so they cannot enable audio/video capture without an interactive session and explicit user notice. (NIST Special Publication 800-53 Revision 5)

Your acceptance criterion should be testable: a privileged admin sitting in a console should not be able to switch a room device from “inactive” to “camera/mic active” without meeting the defined exception path.

Step 3: Define “organization-defined exceptions” as a governed list

Exceptions are allowed, but only if you define them. Write them like an auditor will read them:

Exception template (use consistently):

• Exception name: e.g., “Mission support kiosk in secured lab”
• Business justification: why remote activation is necessary
• Scope: which devices/apps, which locations, which users
• Authorization: role(s) allowed to use the exception
• Guardrails: MFA, just-in-time access, approval workflow, logging, time bounds
• User notice method: what explicit indication appears and how you verified it
• Review trigger: change in location, device model, platform features, or incident review outcome (NIST Special Publication 800-53 Revision 5)

Avoid “exceptions by convenience” (for example, “admins may activate as needed”). If you cannot explain the guardrails, it’s not an exception, it’s a gap.

Step 4: Implement explicit indication of use (and test it in the room)

“Explicit indication” must work for the humans in the space, not just an admin dashboard. Validate for each device/app type:

• Camera active: hardware LED or persistent on-screen indicator.
• Microphone active: mic LED and/or OS-level mic-in-use icon that is visible on the display in typical use.
• Recording: recording banner or audible tone at start, plus persistent “recording” indicator.
• Screen sharing / remote control: clear on-screen overlay stating that sharing/remote control is active. (NIST Special Publication 800-53 Revision 5)

Testing method that auditors accept: a short, repeatable procedure with screenshots/photos showing the indicator.

Step 5: Add monitoring and auditability

SC-15 becomes defensible when you can prove “we would know.”

• Log administrative actions in collaboration admin consoles (enable/disable recording policies, device control actions) where available.
• Log endpoint permission changes for camera/mic where your EDR/MDM supports it.
• Centralize events in your SIEM with a simple detection objective: unexpected recording start, policy changes, or device activation actions outside approved workflows.
• Record exception usage and periodically review it for appropriateness. (NIST Special Publication 800-53 Revision 5)

Step 6: Cover third parties in contracts and due diligence

If a third party provides conferencing hardware management, UCaaS, or managed meeting rooms, you still need SC-15 outcomes. Add due diligence questions and contract terms that require:

• Prohibition of remote activation except approved exceptions
• Explicit user indication behavior
• Admin activity logging and access controls
• Notification obligations if remote activation features are introduced/changed (NIST Special Publication 800-53 Revision 5)

Where Daydream fits naturally: use Daydream to standardize third-party security questionnaires and contract addenda around SC-15 themes (remote activation controls, logging, user notice), track exception approvals, and retain evidence packages by system/third party for audits.

Required evidence and artifacts to retain

Keep artifacts that map directly to the two clauses of SC-15. (NIST Special Publication 800-53 Revision 5)

Policy/standard

• SC-15 policy statement and scoped definitions
• “Organization-defined exceptions” register with approvals

Technical configuration

• MDM/endpoint configuration profiles showing camera/mic permission posture
• UCaaS/conferencing admin policy exports (recording controls, device controls, auto-answer settings)
• Meeting room device configuration baselines

Validation and testing

• Test scripts and results showing remote activation is blocked (or routed through an approved exception)
• Photos/screenshots demonstrating explicit indication of use for each device/app class

Monitoring

• Sample logs of admin actions and relevant alerts
• Access review evidence for privileged roles with the ability to change collaboration settings

Common exam/audit questions and hangups

• “Show me how you prevent remote activation of a conference room camera.” Expect a live demo request or configuration export review. (NIST Special Publication 800-53 Revision 5)
• “What are your organization-defined exceptions?” Auditors will check the list is finite, approved, and implemented with guardrails. (NIST Special Publication 800-53 Revision 5)
• “How does a user physically present know they’re being recorded?” They will expect persistent indicators, not a buried UI element. (NIST Special Publication 800-53 Revision 5)
• “Which collaboration tools are in scope?” If you can’t produce an inventory, the auditor may assume broad scope and test opportunistically.

Frequent implementation mistakes (and how to avoid them)

1. Relying on policy only. Fix: tie the prohibition to MDM/IdP/UCaaS settings and show exports. (NIST Special Publication 800-53 Revision 5)
2. Exception sprawl. Fix: require a named business owner, narrow scope, and a periodic review trigger for every exception. (NIST Special Publication 800-53 Revision 5)
3. Indicators that are technically present but practically invisible. Fix: test in real lighting, real room layouts, and typical display states; document results with photos. (NIST Special Publication 800-53 Revision 5)
4. Ignoring “applications.” Fix: include screen sharing, recording, and remote control features in your control statements and tests, not just physical devices. (NIST Special Publication 800-53 Revision 5)
5. Third-party blind spots. Fix: add SC-15 requirements into third-party onboarding and renewals, and retain their attestations and configuration evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, SC-15 failures create high-impact incidents: covert audio/video capture, unapproved recordings, and exposure of sensitive information during screen shares. Treat it as both a privacy and security control, and prioritize it anywhere you have shared physical spaces or remotely managed room systems. (NIST Special Publication 800-53 Revision 5)

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and defaults)

• Publish SC-15 scope/definitions and identify in-scope devices/apps in inventory.
• Set default configuration targets: no auto-answer, restricted recording initiation, tightened camera/mic permissions, least-privilege admin roles.
• Stand up an exception register and an approval workflow owned by the system owner plus security. (NIST Special Publication 800-53 Revision 5)

By 60 days (implement and prove)

• Roll out MDM/UCaaS configuration changes to prioritized populations (meeting rooms first, then endpoints).
• Implement explicit indication validation: capture screenshots/photos per platform, store them with the system control evidence.
• Begin centralized logging for admin actions and policy changes in collaboration platforms where supported. (NIST Special Publication 800-53 Revision 5)

By 90 days (operationalize and audit-ready)

• Run a control test: attempt remote activation paths and document block/exception behavior.
• Review privileged access for collaboration admin roles; document approvals and access removal.
• Extend SC-15 requirements to relevant third parties via due diligence updates and contract language; store evidence and approvals in your GRC system (Daydream can hold the exception register, third-party evidence, and audit packages by system). (NIST Special Publication 800-53 Revision 5)

Frequently Asked Questions

Does SC-15 mean we must disable webcams and microphones entirely?

No. It requires you to prohibit remote activation except for defined exceptions, and to provide explicit indication of use to people physically present. Users can still activate devices locally for normal meetings. (NIST Special Publication 800-53 Revision 5)

What counts as “remote activation” in practice?

Any action initiated remotely that turns on or begins use of a collaboration capability, such as enabling a room camera/mic, starting a recording, or forcing screen sharing. Define the list for your environment and test against it. (NIST Special Publication 800-53 Revision 5)

Are cloud conferencing platforms “applications” under SC-15?

Yes, if they provide collaborative functions and allow remote actions that could activate audio/video/recording/sharing. Treat admin console capabilities as part of the risk surface. (NIST Special Publication 800-53 Revision 5)

Can we allow remote activation for IT support?

Only as an organization-defined exception with guardrails like strong authentication, constrained roles, logging, and a clear user-visible indicator. Document why it’s necessary and how you prevent abuse. (NIST Special Publication 800-53 Revision 5)

What is an “explicit indication of use” auditors accept?

Something the person in the room can reasonably notice, such as a hardware LED, a persistent on-screen banner, or an audible recording tone where supported. Capture evidence (photo/screenshot) and keep it with control testing results. (NIST Special Publication 800-53 Revision 5)

How do we handle third-party-managed meeting rooms?

Put SC-15 outcomes into the third party’s obligations: no remote activation without approved exceptions, explicit user indication, and logs of admin activity. Confirm by reviewing their configuration evidence and access model during due diligence and renewals. (NIST Special Publication 800-53 Revision 5)