SC-15: Collaborative Computing Devices and Applications

SC-15 requires you to prevent remote activation of collaborative computing devices and applications (for example, cameras, microphones, screen sharing, and conferencing features) except for defined, approved exceptions. To operationalize it quickly, you need an inventory of collaborative tech, baseline configurations that block remote activation, a narrow exception process, and recurring evidence that settings stay enforced. ¹

Key takeaways:

• Treat “remote activation” as a configuration and permissions problem: default-deny, then approve exceptions explicitly.
• Scope includes endpoints and apps: built-in device peripherals plus collaboration software features.
• Audit success depends on durable evidence: configuration baselines, enforcement via MDM/EDR, and exception records tied to mission need. ²

The sc-15: collaborative computing devices and applications requirement shows up in assessments when auditors worry about covert monitoring, unauthorized recording, or surreptitious collaboration sessions initiated without a user’s knowledge. The control is simple in concept: stop remote parties (admins, attackers, or third parties) from turning on collaboration capabilities unless you have explicitly approved circumstances where it is necessary.

Operationalizing SC-15 usually fails for two reasons. First, teams scope it too narrowly (only “webcams”), missing microphones, screen sharing, remote assistance tools, and conferencing app permissions. Second, they implement it as a one-time setting change with no way to prove it remains in place.

This page gives requirement-level implementation guidance you can execute as a CCO, Compliance Officer, or GRC lead working with IT/SecOps: what systems are in scope, how to define allowable exceptions, how to enforce the prohibition at scale, and what evidence to retain to pass an assessment against NIST SP 800-53. ²

Regulatory text

Excerpt (SC-15): “Prohibit remote activation of collaborative computing devices and applications with the following exceptions: {{ insert: param, sc-15_odp }} ; and” ¹

Operator interpretation of the text:

• “Prohibit remote activation” means your default configuration must prevent collaboration capabilities from being turned on by a remote actor (administrator, remote support, another user, a service, or a system process) without an allowed basis.
• “With the following exceptions” means you must explicitly define the conditions where remote activation is permitted, document those conditions, and implement technical controls so only those conditions work in practice. ²

Practically, your job is to (1) define what “collaborative computing” means for your environment, (2) set default-deny configurations across endpoints and applications, (3) create a controlled exception path, and (4) retain evidence that enforcement is continuous.

Plain-English requirement interpretation

SC-15 expects that a remote party cannot silently enable collaboration features such as audio/video capture, conferencing, screen sharing, or similar capabilities. If your mission requires remote activation in limited cases (for example, a managed conference room system or approved remote support workflow), you must define those exceptions and tightly control who can invoke them, from where, and with what logging.

Think of SC-15 as a privacy and anti-surveillance control with security benefits: if malware or a malicious admin can remotely turn on microphones/cameras or initiate screen sharing, you have a confidentiality incident even if no data “file” was exfiltrated.

Who it applies to (entity and operational context)

Entities most commonly scoped:

• Federal information systems.
• Contractor systems handling federal data. ²

Operational contexts where SC-15 is commonly assessed:

• Enterprise endpoints: laptops, desktops, VDI clients, hardened workstations.
• Mobile devices: phones/tablets with conferencing apps and microphones/cameras.
• Conference rooms: integrated A/V systems, smart displays, meeting bars.
• Collaboration apps: conferencing, chat, whiteboarding, remote assistance, screen sharing plugins.
• Privileged admin tooling: remote management platforms that can toggle device settings.

Systems/roles you must involve:

• Endpoint engineering (MDM, OS configuration baselines).
• Identity and access management (who can grant permissions, admin roles).
• Security operations (EDR telemetry, alerting, investigations).
• Collaboration/UC admins (tenant settings, meeting policies).
• GRC (exception governance, evidence, assessment mapping).

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

1) Define “collaborative computing” for your environment (scope statement)

Create a short scope statement that lists the categories you will control:

• Device peripherals: camera, microphone, speakers, Bluetooth audio, screen capture APIs.
• Application functions: meeting join/host, screen share, remote control, recording, live captions if they capture content, remote assistance.
• Shared-space devices: conference room systems, kiosk devices, shared tablets.

Deliverable: SC-15 scope statement in your control narrative and/or system security plan. ²

2) Identify collaborative devices and applications (inventory + ownership)

Build or extend an inventory list with:

• Endpoint types and OS versions.
• Installed collaboration applications and versions (where you manage them).
• Conference room device models and management plane.
• Remote support tools in use (internal and third party).
• Control owners for each platform (MDM owner, UC owner, room systems owner).

Tip that helps in audits: map each item to its enforcement method (MDM profile, tenant policy, local GPO, hardened image, network control). Auditors care less about the tool name and more about “how do you prevent remote activation and prove it stays prevented?”

3) Decide your default position: “remote activation prohibited”

Write an enforceable rule set. Examples of default-deny statements you can adopt:

• Cameras and microphones cannot be enabled remotely by administrators or software processes without an approved exception.
• Screen sharing requires local user initiation or a clearly approved workflow.
• Remote support sessions cannot start silently; they require user consent and visible notification unless an exception applies.

Keep the language measurable. Avoid “should” and “where feasible.”

4) Define the exceptions (the “ODP” in the text)

The regulatory excerpt references an organization-defined parameter for exceptions (the placeholder in the excerpt). You must supply your own list of allowed exceptions, approved by the right authority, and keep it tight. ¹

A workable exception framework:

• Exception categories: mission-essential conference rooms; call center recording under a defined policy; approved remote assistance for managed kiosks; accessibility accommodations.
• Constraints required for any exception: named systems, named roles, approved locations/networks, required user notice (where applicable), mandatory logging, and periodic review.
• Approval authority: system owner + security + privacy (if you have a privacy office), then documented in a register.

5) Implement technical enforcement (where SC-15 is won or lost)

Implement controls at multiple layers so a single misconfiguration does not break compliance:

Endpoint layer (MDM/GPO/baseline):

• Enforce camera/microphone privacy settings where the OS supports it.
• Restrict which apps can access microphone/camera.
• Block silent permission grants by standard users; constrain admin permission changes via privileged access workflows.

Application/tenant layer (collaboration admin console):

• Set meeting policies that prevent automatic recording or prevent joins/starts without host.
• Control screen-sharing defaults (for example, “share = disabled by default” and “only host can share” in higher-risk groups).
• Restrict who can start remote control or remote assistance features.

Remote support tooling:

• Require user consent and visible notification for session start.
• Disable “blank screen” or “stealth” modes unless specifically approved as an exception.
• Ensure sessions are tied to ticketing or case IDs, with logs retained.

6) Add detection and monitoring tied to the prohibition

SC-15 is easier to defend when you can show monitoring for violations:

• Logs for camera/microphone access events (where available).
• Collaboration app audit logs for recording start/stop, meeting policy changes, admin actions.
• Remote support session logs (who initiated, target device, timestamps, reason code).

Decide what triggers an incident review: unauthorized remote activation attempt, policy change by an unapproved admin role, or use outside exception constraints.

7) Operationalize governance: exception workflow + periodic review

Put the exception process on rails:

• Intake: what is being requested, why, which systems, duration, compensating controls.
• Review: security + system owner (and privacy where applicable).
• Approval: documented decision, implementation ticket, validation step.
• Review cadence: periodically reconfirm the exception is still needed and still constrained.

If you use Daydream for control operations, this is where it earns its place: you can assign SC-15 ownership, attach the scope statement, track exceptions as structured records, and maintain recurring evidence artifacts in one control workspace without chasing screenshots across teams.

Required evidence and artifacts to retain

Keep evidence that proves three things: scope, enforcement, and governance.

Minimum evidence set (practical):

• SC-15 control narrative: definition of collaborative computing, what “remote activation” means internally, and the default-deny rule. ²
• Inventory extract: in-scope device classes and collaboration apps, with owners.
• Configuration baselines:
  • MDM/GPO profiles showing camera/microphone/app permission restrictions.
  • Collaboration tenant policy exports (meeting/recording/screen sharing/admin settings).
  • Remote support tool policy settings (consent, notifications, logging).
• Validation evidence:
  • A test procedure and results showing remote activation is blocked under normal conditions.
  • Spot checks for a sample of endpoints/rooms.
• Exception register:
  • Approved exceptions, constraints, approvers, implementation tickets, and review outcomes.
• Logging evidence:
  • Example audit logs for collaboration admin actions and remote support sessions.
  • Alert/runbook showing what happens when an event indicates possible unauthorized activation.

Common exam/audit questions and hangups

Expect these questions and prepare crisp answers with artifacts attached:

1. “What devices and apps are in scope for SC-15?”
   Show your scope statement and inventory, not a verbal answer.

2. “How do you prevent a remote admin from turning on a camera or microphone?”
   Demonstrate baseline settings and privileged workflow constraints.

3. “What are your exceptions, and who approved them?”
   Produce the exception register and at least one implemented example.

4. “How do you know the settings stayed in place?”
   Show policy-as-code exports, MDM compliance reports, and periodic validation results.

5. “What logs exist for collaboration activity and remote support sessions?”
   Provide log samples plus retention and access controls.

Frequent implementation mistakes and how to avoid them

• Mistake: treating SC-15 as “webcams only.”
  Fix: include microphones, screen sharing, remote control, and recording features in your scope statement and testing.

• Mistake: allowing broad admin roles to change collaboration policies without governance.
  Fix: restrict admin roles, require change tickets, and retain policy export diffs as evidence.

• Mistake: exceptions that read like blanket permissions.
  Fix: write exception constraints that are testable (named systems, roles, networks, logging, review).

• Mistake: no proof of ongoing enforcement.
  Fix: schedule recurring exports/reports and store them as time-stamped evidence (Daydream can track these artifacts against SC-15 ownership and audit requests).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SC-15, so treat this as an assessment-driven control rather than a penalty-cited item in this guidance. ¹

Risk still matters:

• Unauthorized audio/video activation can trigger confidentiality incidents, internal investigations, and reporting obligations depending on the data discussed or captured.
• Remote support “silent sessions” create insider-risk and third-party risk exposure, especially if a third party support provider can initiate access without user awareness.
• Weak collaboration tenant governance often leads to cascading failures: a single permissive policy can apply to many users quickly.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + stop obvious gaps)

• Assign a single SC-15 control owner and identify platform owners (endpoint, UC, remote support).
• Publish the SC-15 scope statement and the default-deny rule.
• Pull current-state configurations: MDM profiles, collaboration tenant policies, remote support settings.
• Draft the exception categories and required constraints; start an exception register.

Days 31–60 (enforce + prove)

• Implement baseline changes for endpoints and collaboration tenant settings that directly block remote activation pathways.
• Tighten admin roles and change control around collaboration policies.
• Implement or confirm remote support consent/notification requirements and session logging.
• Write a simple validation procedure and run initial tests; store results as evidence.

Days 61–90 (operationalize governance + recurring evidence)

• Run the first exception review cycle and remediate any overly broad exceptions.
• Set up recurring evidence capture (policy exports, MDM compliance reports, sample-based checks).
• Add detection/alerting for admin policy changes and remote support session starts outside approved constraints.
• Package the audit-ready evidence set in a single repository or control system (Daydream if you want structured mapping, tasks, and artifacts tied to SC-15).

Frequently Asked Questions

Does SC-15 mean users can never use cameras, microphones, or screen sharing?

No. SC-15 targets remote activation. You can allow collaboration features while still requiring local user initiation or tightly controlled, approved exceptions. ²

What counts as “remote activation” in practice?

Any scenario where a remote actor or service can enable collaboration capabilities without the local user initiating the action under your approved workflow. Define it explicitly in your SC-15 control narrative so testing is consistent. ²

Are conference rooms in scope?

If the room system includes collaborative capabilities (A/V capture, conferencing, screen sharing), treat it as in scope. Many room systems are centrally managed, which makes “remote activation” risk more likely if not governed. ²

Can we allow remote support tools that can access a user’s screen?

Yes, but constrain the workflow: require user consent/notification by default, log every session, and use an exception process for any scenario that bypasses consent. Keep those exceptions narrow and review them periodically. ²

What evidence is most persuasive to auditors for SC-15?

Configuration baselines (MDM/tenant policies), an exception register with approvals, and validation results showing remote activation fails under normal conditions. Add logs that show remote support sessions and admin policy changes are recorded. ¹

How do we operationalize SC-15 across multiple collaboration apps?

Start with a single policy standard (“remote activation prohibited except…”) and then map each app to its enforcement point (tenant settings, OS permissions, or CASB controls). Track owners and recurring evidence per app so gaps are visible. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5