SC-42 Sensor capability and data: requirements and evidence

What SC-42 sensor capability and data requires

If your organization has been told SC-42 applies to its devices or facilities, the short answer is that it requires three things: keeping sensing devices out of defined facilities, limiting whether sensors can be switched on remotely, and giving defined users an explicit indication when a sensor is in use. The control is organization-defined, so the facilities, the permitted remote activation cases and the users who must be notified are decisions your organization makes and documents. The first part is a prohibition on environmental sensing capability in the places you designate, such as secure meeting rooms or classified work areas. The second part bans remote activation of those sensors except where you have allowed it. The third part requires an explicit indication to defined users that a sensor is active, so that nobody is recording without knowing it.

The risk behind SC-42 is covert capture: a camera, microphone or location sensor that records audio, video or position without the knowledge of the people nearby or the organization that owns the room. This matters most where sensitive discussions happen, and where a compromised device could be turned into a listening post. The control is hard in practice because sensors are not confined to one class of equipment. They are built into laptops, phones, tablets, conference room systems, smart displays and badge readers, and those assets are often bought and managed by different teams, some of them outside central IT. A useful first step is an inventory of every device class in scope, with the sensors it carries and whether they can be activated remotely.

No SP 800-53B baseline selects SC-42, so the control applies only when your organization adds it through tailoring or an overlay, typically because a risk assessment or a sensitive system requires it. Confirm with your authorizing official or compliance lead whether SC-42 is in your selected control set and, if so, which facilities and users the parameters name. The NIST publication page for SP 800-53 Rev. 5 is the place to read the control text and its related controls, while the SP 800-53B baselines confirm that it is absent from the standard low, moderate, high and privacy sets.

Which systems and facilities SC-42 reaches

SC-42 does not name the devices or rooms it covers. The organization defines the parameters, so each scope element is a written decision that an assessor can trace to documentation and configuration. The cards below cover the decisions that most often need a written answer.

Laptops and mobile endpoints

Laptops, tablets and phones carry cameras, microphones and location sensors that staff use daily. Decide which device classes fall under the sensor rules, and whether remote activation of those sensors is prohibited, allowed for defined purposes, or limited to specific users. Record the decision in the system security plan and check that the endpoint configuration matches it. Ask whether camera and microphone access can be switched off centrally or only per application, because that determines what evidence you can produce.

Conference room and collaboration systems

Conference room displays, room cameras and microphone arrays are the sensor-heavy devices most organizations forget to scope. Identify each room system, whether it is always on, and who can start a call or recording remotely. Set the indication requirement for users in the room, such as a visible light or on-screen notice, and document how that indication is tested. Confirm that the collaboration platform's own settings match the parameters you wrote.

Facilities where sensing devices are prohibited

SC-42 lets the organization name facilities where devices with environmental sensing capabilities are prohibited. Typical examples are secure rooms, classified work areas, executive meeting spaces or data center floors, though each organization defines its own list. Write the list with room identifiers, floor plans or access zones, then state how personal devices are checked at entry. Ask whether your physical security team will enforce the rule with signage, screening or both, since an assessor will look for both the rule and its enforcement.

Remote activation paths

Sensors can be turned on from places other than the device itself: management consoles, mobile device management, collaboration platforms and remote support tools. List each path that can activate a camera, microphone or location service, and decide which paths are permitted and for which users. Remote support sessions are a common gap because they can reach a device without the user noticing. Test each path and keep the results as evidence, including the denied cases.

Users who must receive the indication

The indication requirement depends on who is affected. Decide whether the indication goes to the device user only, to everyone in the room or area where the sensor is active, or to both. Remote participants on a call are often overlooked even though they are the people most likely to be recorded. Document the audience for each sensor type and the form the indication takes, then confirm that the audience can actually see or hear it.

Third-party devices and managed services

Vendor-managed devices, managed print and meeting room services and third-party IoT products may activate sensors under the provider's control. Include them in scope where they reach your systems, and write the sensor rules into the contract or service terms, including remote activation limits, indication behavior and notice of changes. Ask each provider to state which sensors the device has and how they can be disabled. Confirm the terms with your legal and procurement teams before the device enters service.

How an assessor tests SC-42

This table maps the two SP 800-53A determination statements for SC-42 to the examine methods, evidence requests and common findings an assessor encounters. Read it as a preparation checklist: the organization owns the controls, and the independent assessor decides what passes and reports the findings.

Assessment element	Evidence the assessor requests	Common findings
Determination statement 1: devices with defined environmental sensing capabilities are prohibited in defined facilities, or their remote activation is prohibited except where allowed	Written list of the sensor-capable device types in scope, the defined facilities, the prohibition rule and the documented exceptions for remote activation	Organization-defined parameters left undefined, so the assessor cannot tell which devices or facilities the rule covers
Examine: system design documentation	Design documents showing where cameras, microphones, GPS and similar sensors sit in the system and which features can activate them remotely	Design describes sensors in general terms, with no link to the facilities or device classes named in the policy
Examine: system configuration settings and associated documentation	Exported device or endpoint settings showing sensors disabled or restricted, plus change records for those settings	Settings are not documented for each device group, or the export does not match the documented configuration
Examine: system audit records	Logs of remote sensor activation attempts, approvals for permitted activations and alerts raised when a prohibited activation occurred	No sampled evidence for remote activation, so the assessor cannot confirm that prohibited activations were blocked or reviewed
Determination statement 2: defined users are given an explicit indication of sensor use	Description of the indicator (for example a light or on-screen notice), the defined user groups and records showing the indicator is shown	Indication of use not verified for every user group, often because shared or kiosk devices were left out of testing
Interview and test methods	Staff walkthroughs and, where the assessor observes behavior, a live check of a sensor activation and the indicator shown to a user	Staff describe the indicator from memory, and the assessor cannot observe the behavior during the assessment window

How to implement SC-42 in order

This sequence turns SC-42 from a selected control into documented settings, visible indications and retained evidence that an assessor can examine, so the organization can show that sensor restrictions are chosen deliberately and enforced on the devices in scope.

Confirm whether SC-42 is selected and record why
Start by checking whether SC-42 is in your selected control set. SP 800-53B does not assign it to any baseline, so it appears only through tailoring, an overlay or a contractual or regulatory requirement that names it. Record who made the decision, which system boundary it covers and the reason, such as a facility rule or a sensitive meeting space. The output is a short tailoring entry in the system security plan that an assessor can read without asking you to explain it. If the control is not selected, record that decision and the reason too.
Define the organization-defined parameters
SC-42 leaves several choices to the organization. Decide which facilities are covered, which device classes with environmental sensors (such as laptops, phones, tablets, conference room systems and smart displays) fall in scope, which remote activation cases are allowed as exceptions and who must receive the indication of sensor use. Have the system owner, facilities lead and security lead approve the values together, because each value sets what the configuration must enforce. The output is a signed parameter list mapped to the device inventory, with exceptions justified in writing.
Configure devices and management platforms to restrict activation
Translate the parameters into device settings. Depending on your estate, this can mean mobile device management policies that disable camera or microphone use in defined locations, operating system settings that block remote activation, hardware switches or physical covers in restricted rooms, or removal of sensor-equipped devices from areas where they are prohibited. Document each setting by device class, owner and management tool. Confirm the exact settings with your device vendors and management platform, since capabilities differ by operating system and hardware. The output is a configuration record for each device class in scope.
Configure indication of sensor use for defined users
Where sensors are permitted, make sure the defined users receive an explicit indication that a sensor is active. Confirm with each device or application owner how the indication appears (for example, a status light, an on-screen icon or a notification) and test that it shows to the users you named in step two. Record the indication method, the users it reaches and any devices that cannot provide it, along with the compensating action for those devices. The output is a tested indication for each device class, with gaps recorded and assigned.
Verify configuration with scans and queries
Check that the settings work on real endpoints. Open-source tools can help: Wazuh Security Configuration Assessment checks monitored endpoints against YAML policies that can be extended with custom checks, Fleet policies ask yes or no questions of devices as osquery queries and show which devices pass or fail, and osquery can expose running processes, loaded kernel modules and hardware events across a fleet. Velociraptor hunts can collect artifacts across a group of systems and include offline machines when they reconnect. Use these to confirm that restricted devices cannot activate sensors and that the indication is present. Investigate failures and record them. The output is a dated verification report with pass and fail results per device class.
Retain records for the assessor
Gather the evidence an assessor will examine under SP 800-53A, which lists system design documentation, system configuration settings with their documentation and system audit records as examine objects for SC-42. Keep the parameter list, tailoring decision, configuration records, indication tests, scan and query outputs, exception approvals and change history in one controlled location with versions and owners. Set a review point so the records are updated after device refreshes, facility changes or policy changes. The output is an evidence package that an independent assessor can test without reconstructing the configuration from memory.

Evidence that passes SC-42

SC-42 is tested largely through documentation and configuration, so the evidence has to show where sensors are prohibited, how remote activation is controlled, and how users learn that a sensor is in use. Each artifact below should be kept current between assessments, not rebuilt when an assessor arrives.

Approved system design documentation

The system design documentation should show which devices carry environmental sensing capabilities, where those devices are allowed, and which defined facilities prohibit them. Assessors use this document to confirm the boundary of the control before they test anything. Keep a sensor inventory linked to the design, and update the diagram when a new device class enters a facility. Check that the prohibited facilities listed here match the organization-defined parameters.

Sensor and remote activation configuration exports

Configuration exports show the settings that enable or disable cameras, microphones, location services and remote activation on managed devices. Export them on a schedule and store each export with a date and the device group it covers. Compare each export against the last approved baseline, so a silent change to remote activation is visible. Confirm the export captures the settings your device management platform enforces, not only the policy text.

Organization-defined parameters and exceptions record

This record states which facilities, device types and sensing capabilities the organization defined, and which remote activation cases are allowed. Every exception should name an approver, a business reason, a scope and an expiry date. Review exceptions at each change window and close any that no longer apply. An assessor will compare exceptions against the system design, so the two documents must agree.

Indication-of-use configuration and user notice

Assessors expect defined users to receive an explicit indication when a sensor is in use. Keep screenshots or configuration records of the indicator (for example, a status light or on-screen icon) and the written notice users acknowledge. Test the indicator on each device model in scope, because indicator behavior often differs by hardware and operating system version. Record the test date and the tester.

Sensor-related audit records

Audit records of sensor enablement, disablement and remote activation attempts show whether the control operated in practice. Confirm that logs capture the device, the user or process, the time and the outcome. Review them on a defined cadence and retain them for the period your audit policy requires. Ask your security team to confirm which events the endpoint and management tools generate by default before relying on them.

Periodic verification results

Periodic checks confirm that sensor settings still match the approved baseline on live endpoints. Scheduled queries or configuration assessments can flag devices that drift, and each failure should open a tracked remediation item. Record the check frequency, the scope, the pass and fail counts, and the closure date for each finding. Verification results are the evidence that the control is maintained between assessments, not only at the time of testing.

What meeting SC-42 costs in money and effort

This table compares the cost components of meeting SC-42 for sensor capability and data, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Read it as a checklist for a written quote: the drivers column shows which scope decisions move each line item most.

Cost component	One-time or recurring	What drives it	What to ask for in a quote
Licenses or tooling	Recurring if commercial; none for open-source tools	Number of device classes in scope and whether a commercial MDM or endpoint platform is already licensed	A line-item list of every tool, its license model and whether any component is commercial
Engineering time to configure devices and indicators	One-time, with later changes recurring	Number of device classes with cameras, microphones or GPS, and how many need a visible indicator of use	Hours by device class, with separate estimates for policy design, configuration and testing
Policy and exception handling	Recurring	Number of facilities where sensors are prohibited and volume of approved exceptions for remote activation	A description of how exceptions are requested, approved, recorded and reviewed, and who signs them
Evidence upkeep	Recurring	Frequency of fleet queries, number of facilities and how often device inventories change	The evidence schedule, retention period and the format of exported compliance reports
External testing or review of configurations	Recurring or per engagement	Number of device images, MDM profiles and whether tests cover remote activation paths	Written scope for configuration review, the test cases covered and deliverables with dates agreed in advance
Auditor sampling	Set by the auditor per assessment	Number of devices and facilities the assessor selects and how well evidence is organized	Confirm with the auditor the sample method, evidence requested and whether the auditor charges per test day

Self-hosted open-source tools that produce SC-42 evidence

SC-42 asks for two kinds of proof: that prohibited sensing devices are kept out of defined facilities, and that users can see when sensors are in use. The tools below can show part of that picture from endpoints and configuration, but the organization still owns the policy, the device decisions and the indication design.

Wazuh configuration assessment

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and checks files, directories, registry keys and running processes. Write custom policies for the sensor settings your SC-42 decisions define, such as a camera service that must not run on restricted endpoints. Confirm that each setting you need is visible to the agent on your platforms. Licensed GPL-2.0-only, so review how your distribution and modifications are handled.

Fleet policies for yes or no checks

Fleet policies are yes or no osquery questions asked of each device, such as whether a prohibited sensor driver or application is present. The policies page shows which devices pass or fail, which gives a per-device record an assessor can sample. Write each policy from a written sensor rule so the question traces back to the SC-42 requirement. Fleet is MIT licensed. Confirm that the query can read the sensor state on each operating system you run.

osquery inventory and scheduled queries

osquery exposes running processes, loaded kernel modules, hardware events and browser plugins as SQL tables, and osqueryd schedules those queries across a fleet. Use it to collect evidence of sensor-related hardware and software over time, not just a single snapshot. Its Apache-2.0 OR GPL-2.0-only licensing gives you a choice of terms. Confirm which tables expose the camera, microphone and location hardware you care about, because table coverage varies by platform.

Velociraptor for sensor investigations

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts across groups of systems. Use it when a sensor finding needs investigating, such as tracing which devices activated a microphone outside an approved window. Offline machines collect when they reconnect, and each hunt gets a notebook for the combined results. It is AGPL-3.0-only, so network use of a modified version can trigger source disclosure duties. Check that your artifacts can read the sensor state you need.

Who does what for SC-42

Your organization owns the control. Whether SC-42 belongs in a system's baseline is a decision you make through tailoring or an overlay, because SP 800-53B does not assign it to any baseline. Once selected, you define the organization-defined parameters, meaning which facilities and device types are restricted, which remote activations are allowed, and which users receive the indication of sensor use. You also approve exceptions and operate the device fleet, since only your staff can confirm which devices with cameras, microphones or location sensors are actually present.

Selection decision: Record whether SC-42 is selected, the tailoring rationale and the system it applies to in the security plan.
Parameter values: Set the restricted facilities, sensor types and permitted exceptions, and document who approved them.
Exception approval: Decide and record each case where remote sensor activation is allowed, with a named owner and review date.
Fleet operation: Keep the device inventory current and run the day-to-day restrictions and user indications.

Before assessment, check that the parameter values in your documentation match the settings the partner and auditor will examine.

Questions buyers ask about SC-42

How much effort does SC-42 take in a typical environment?

The effort depends less on the control text than on how many device types and facilities fall under the requirement. SC-42 asks you to define which devices with environmental sensing capabilities are prohibited in which facilities, whether remote activation of sensors is blocked or allowed by exception, and how users are told that a sensor is in use. The main drivers are the size of the device fleet, how many sensor-capable device classes exist (laptops, phones, conference room hardware, IoT sensors, vehicles), how many facilities have restrictions, and whether existing mobile device or endpoint management already reports camera and microphone state. Ask any provider to break its quote into policy definition, device inventory, configuration work and evidence collection, and to say which of those recur after the first assessment.

Is SC-42 required in any NIST SP 800-53 baseline?

No. SP 800-53B does not assign SC-42 to the low, moderate or high security baseline or to the privacy baseline. It applies only when your organization selects it through tailoring or when an overlay or a contract requires it. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the system. In practice, the question to settle first is whether your system has sensing devices in scope at all. A data center with no cameras, microphones or GPS-capable endpoints in its boundary may document that the control is not applicable, but the reasoning belongs in your system security plan and should be reviewed by your assessor. FedRAMP's Rev5 baselines also do not require SC-42 at Class B, C or D.

Can our own team implement SC-42 without an outside partner?

Often yes, for a small and well-inventoried environment. A security or endpoint team can write the device policy, configure management tooling to report sensor state and document the user indication method. The harder parts are usually the inventory of sensor-capable devices, agreement on which facilities restrict them, and producing evidence that an assessor can examine. An outside implementation partner can help with the configuration and evidence work, but the organization keeps ownership of the policy and the decisions it encodes. Whichever route you choose, confirm that someone internal can answer for the control during assessment interviews and can explain the system design documentation and configuration records that the assessment procedure examines.

How long does an SC-42 engagement take?

No general duration can be given that applies across environments. The timeline follows from the written scope: how many device classes and facilities are covered, whether existing management tooling can already report sensor state, how many approvals the policy needs, and whether the work is a one-time readiness exercise or includes ongoing support. Fixed-scope engagements at DeployOpen are agreed in writing before work starts, so the schedule, deliverables and milestones are stated in that document rather than estimated here. Ask for the schedule to be tied to specific dependencies, such as device inventory completion and sign-off on the policy, so that delays on your side are visible.

What does the work need from our side?

Most of the work depends on decisions and access that only your organization can provide. Expect to supply:

A named owner who can decide which devices and facilities are restricted and what exceptions for remote activation are allowed
Read access to device management, identity and endpoint records so the sensor state of devices can be checked
Approval of the user indication method, such as how users are shown that a camera or microphone is in use
Access to system design documentation and configuration settings that an assessor will examine
Time for interviews with the people who operate the devices and facilities

If any of these are missing, the schedule and the evidence will both be affected, so confirm them before the scope is signed.

What can an implementation partner not do for SC-42?

An implementation partner cannot issue the assessment result. DeployOpen plans, configures and documents controls and prepares evidence, but it does not issue audit reports, attestations or certifications. The determination on whether SC-42 is satisfied comes from your independent assessor or authorizing official, following the procedures in SP 800-53A. Your organization also remains accountable for the control itself, including the decisions to prohibit or allow sensors, the exceptions it grants and the ongoing operation of the controls after handover. A partner can make it easier for an assessor to test SC-42, but it cannot promise a particular outcome of that test.

How DeployOpen scopes and prepares SC-42 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares the systems and evidence an assessor would examine for SC-42 Sensor capability and data. The organization owns its control decisions, and only an independent assessor or auditor issues reports or certifications.

How we scope

Confirm in writing whether SC-42 is selected through tailoring or an overlay, since no SP 800-53B baseline assigns it.
Record which facilities, device types and sensor functions the defined prohibitions and remote activation rules must cover.
Agree the fixed scope, deliverables and timelines in writing before any work starts, with ongoing support available as a retainer.

How we build

Configure the defined sensor prohibitions and user indication settings on endpoints in the agreed scope using the client's own tooling.
Build osquery queries and Fleet policies that show, as yes or no answers, whether sensor restrictions hold on each device.
Test the configured controls against the two SP 800-53A determination statements and record the results for the assessor.

How we hand over

Deliver system design documentation and configuration records that match the examine objects the SP 800-53A procedure names.
Provide audit records and query output showing sensor status over time, in a form the client can retain and review.
Document the control implementation in the client's system security plan so the organization's owners can maintain it.

How we support

Offer a retainer that re-runs sensor checks after device changes, upgrades or reconfiguration, with results shared with the client.
Review evidence gaps with the client's compliance lead before an assessment, without issuing any assessment conclusion.
Keep the scope and documentation current when the client's tailoring decisions or NIST release changes affect SC-42.

SC-42 Sensor capability and data