An industrial IoT sensor allows one number to serve several purposes. At the site, gas concentrations and equipment status are used to decide whether to stop work or inspect ventilation. In management and carbon accounting, the same records are used as evidence for long-term trends, energy efficiency, and reduction activities. One device and network therefore become a shared input for Safety and Carbon.

This structure is efficient, but mixing the responsibilities is dangerous. Safety detection and environmental or carbon monitoring may have different requirements for response time, measurement range, installation criteria, calibration, certification, and behavior upon failure. The presence of a carbon-analysis sensor must not be assumed to satisfy statutory or site safety requirements. Conversely, instantaneous readings intended for safety alarms alone cannot be used to calculate long-term carbon performance. Cybersecurity must connect the two purposes while preserving their functional boundaries.

First misconception: security is an IT team’s data-breach problem

The consequences of a security incident involving industrial sensors are not limited to a leak of personal data. If an attacker raises an alarm threshold, a hazardous concentration may appear normal; if the attacker disrupts a ventilation-control signal, the physical environment may change. Conversely, repeated false alarms can cause unnecessary evacuations and process shutdowns and desensitize workers to genuine alarms. This is why NIST SP 800-82 considers performance, reliability, and safety together in OT security.

On the Carbon side, measured values, time, device status, and correction factors can all be compromised. Reductions may be overestimated or underestimated, data gaps may become impossible to explain, and reports that have already been issued may need to be reviewed. In other words, the same vulnerability manifests as an immediate physical hazard on one side and as a risk to claims accumulated over time on the other.

The differences between the two areas also matter. Safety can be highly sensitive to delays of only a few seconds and to false negatives, whereas Carbon is sensitive to completeness, lineage, and reproducibility across an entire period. Assessing both purposes with one security KPI can leave critical risks unnoticed. Shared controls should be operated together, but purpose-specific performance indicators and acceptance criteria must be established separately.

How one compromised account produces two consequences

Suppose a remote maintenance provider uses the same account for gateways at several farms. If that account is compromised, an attacker can change sensor settings and delete logs. In the Safety path, altered alarm thresholds or relay integration can delay workers’ response. In the Carbon path, changes to the sampling interval and correction values can alter the before-and-after trend.

Recovery also differs. For site safety, the first steps are to isolate the device, check the atmosphere with independent equipment, and establish a safe operating state. For carbon data, the affected period, devices, calculation results, and reports supplied externally must be identified. Restoring safety does not automatically restore trust in historical data. Conversely, restoring historical records cannot demonstrate that the current gas conditions at the site are safe.

An incident-response matrix must therefore ask two questions at the same time: “Are people and equipment safe now?” and “Which period of carbon evidence was affected?” The responsible teams, isolation criteria, alternative measurements, data holds, external notifications, and persons authorized to approve resumption must be designated in advance.

Eight controls that both areas must share

The first is asset identification. Inventory sensors, gateways, firmware, communication modules, cloud services, and maintenance laptops, and mark how each is used for Safety and Carbon. CISA’s baseline performance goals also recommend regularly updating inventories of IT and OT assets. A device absent from the inventory cannot be properly managed for patches, calibration, certificates, or end of support.

The second is unique accounts and least privilege. Change manufacturers’ default passwords and avoid shared accounts across farms, providers, and devices. Separate the permissions to change safety thresholds, change carbon correction factors, view data, and deploy firmware. Apply multiple approvals and strong authentication to high-risk changes, and generate an immediate alert whenever an emergency account is used.

The third is network segmentation. Do not place office PCs, guest Wi-Fi, sensor networks, control networks where safety-control functions exist, and cloud connections on the same flat network. Permit only the necessary communication paths and ports, and control remote access through an intermediary point, approved access windows, and session records. Segmentation reduces the extent to which an intrusion can spread to other farms and controllers.

The fourth is secure updates. Verify the source and integrity of update files and allow only authorized entities to install them. Test compatibility and resource consumption before deployment, and ensure that the device can return to a safe version if the update fails. For devices that affect Safety, make changes during a planned shutdown and with alternative monitoring rather than forcing live patching during operation. Check the end-of-support date and the channel for vulnerability notices at the procurement stage as well.

The fifth is data protection and logging. Protect data in transit and at rest, and send the histories of configuration, calibration, permissions, updates, and reboots to a central or separate repository. If a field device is compromised, its local logs may also be deleted. Synchronize log timestamps to a common reference and record clock error itself as a status.

The sixth is security-state awareness. The system should show not only whether a device is “online,” but also whether it is running approved firmware, whether its configuration matches the baseline, whether its certificate is valid, and whether log transmission is working normally. NIST IR 8259A includes among its core baseline capabilities the ability of an IoT device to report its own cybersecurity state and to allow access only by authorized entities.

The seventh is backup and recovery testing. Regularly back up gateway configurations, device inventories, certificate-management information, rules and models, and data schemas, and test their recovery. NIST SP 1339 stresses that OT backups should be linked to change management and reviewed in recovery exercises. If backups remain permanently connected to the production network using the same credentials, the risk of both being damaged increases, so isolation and access controls should be considered.

The eighth is supply-chain accountability. Contracts should specify who—among the sensor manufacturer, installer, telecommunications provider, platform operator, and verification body—is responsible for vulnerability notifications, patches, account decommissioning, log provision, and incident response. IEC 62443-2-4 addresses security processes for providers that integrate and maintain industrial automation and control systems. Rather than requesting only the name of a standard, verify the actual scope of service and the evidence.

Reflect purpose-specific separation in the technical architecture

Safety alarms should retain the necessary site functions locally wherever possible, so that a cloud failure does not disable the alarm itself. Changes to the safety layer should be restricted by validated procedures and permissions. Carbon analytics should read a copy of the raw data for long-term aggregation but have no authority to change safety settings. Even when both results appear on one screen, there is no need to combine the back-end permissions and failure paths as well.

Indicate the purpose in the data model too. Distinguishing measurement_purpose, safety_status, carbon_quality_status, and calibration_context makes it possible to explain which decisions a given value is suitable for. It reduces errors such as directly averaging out-of-range values from a safety device in a carbon analysis or reusing readings from a low-concentration carbon sensor as a safety alarm.

Physical fallback measures are also necessary. Prepare independent portable detectors, manual site procedures, local alarms, and communication arrangements for use when the network or platform is suspect. For carbon data, the corresponding measures are a quarantine queue, read-only originals, and the ability to place report issuance on hold. Resilience depends on people being able to intervene safely when automation fails.

KPIs do not end with a single patch-rate figure

Shared security KPIs can include the percentage of managed devices identified, percentage of default accounts removed, proportion of firmware still supported, log collection coverage, time to remediate high-risk vulnerabilities, and backup-recovery success rate. For Safety, add alarm-path availability, the number of unauthorized threshold changes, and time to switch to alternative monitoring. For Carbon, add time to identify the affected period, the number of integrity-verification failures, the number of data holds and corrections, and lineage completeness.

High figures do not automatically guarantee safety or carbon performance. For example, even with a 100% patch rate, a faulty firmware release deployed to every device can create a hazard. A KPI is a signal that asks whether a control is working; it does not replace risk assessment and field testing. In particular, “0 incidents” is not evidence that no incident went undetected, so log coverage and response exercises must be considered together.

Implementation checklist

  • Has each sensor and dataset been marked to show whether it is used for Safety, Carbon, or both?

  • Has anyone mistakenly treated carbon measurements as satisfying safety-certification or alarm requirements?

  • Are safety-setting permissions separated from carbon-analysis permissions, with dual approval for high-risk changes?

  • Have boundaries been defined among the sensor network, safety-control network, office network, and remote-support network?

  • Have manufacturers’ default accounts and providers’ shared accounts been removed?

  • Are there procedures to verify firmware provenance, test it in advance, roll it back, and respond to end of support?

  • Are device online status and security status monitored separately?

  • Are Safety recovery and the Carbon data impact assessment performed as separate procedures?

  • Are fallback measures available, such as independent detection, manual procedures, and a hold on data publication?

  • Do supplier contracts specify responsibility for vulnerability notifications, patches, logs, and incidents?

  • Have backups actually been restored and tested through safe restart?

  • Do purpose-specific KPIs actually measure site risk and evidence quality?

Conclusion: protect the shared foundation together and separate responsibility for decisions

The security of industrial IoT sensors is not an optional feature between Safety and Carbon. If accounts, firmware, time, settings, networks, or logs are compromised, decisions about people and equipment are undermined on one side, and confidence in reduction performance on the other. Asset management, least privilege, segmentation, secure updates, logging, and backups should therefore be operated as a shared foundation.

The two purposes must not, however, be merged into one. The procedure for confirming a safe current state differs from the procedure for assessing the impact on historical carbon data. Device certification, range, and response requirements may also differ. When the shared infrastructure is protected together while purpose-specific decisions and failure boundaries remain separate, cybersecurity becomes an operational capability that protects safety and carbon at the same time.

Sources