Trust Boundary in a Legacy Occupancy-Sensor Fleet
A facilities team has deployed 480 battery-powered occupancy and CO2 sensors across 12 floors of a leased office building. The sensors use a vendor-specific 802.15.4 profile with no TLS and no field-upgradable firmware; updates are possible only through the building gateway. The gateway terminates the sensor radio network, normalizes data and forwards it to a cloud analytics service for HVAC optimization and space utilization. The vendor states the sensors have a ten-year battery life and should not be reflashed in place. HR has now asked for per-desk occupancy reports to support a hot-desking policy. The building has shared tenant areas, and the lease requires the landlord to give 30 days' notice before changing any data processing. The security team must decide where the trust boundary sits, what controls compensate for the constrained sensors, and whether the HR request is acceptable.
1. Define the trust boundary for this deployment and justify the placement. Which controls should be applied at the gateway and in the cloud to compensate for the sensors' lack of TLS and updatability?
Read the worked answer
Reasoning. The sensors cannot authenticate or encrypt, so the first point where the system can enforce cryptographic identity, logging and update control is the gateway. That makes the sensor-to-gateway radio link the untrusted zone and the gateway the trust boundary-but not a magic shield: data is plaintext at the gateway, so physical and logical protection of the gateway matters.
Controls at the gateway: per-device join credentials or keys; radio-network authentication of sensor IDs; join monitoring and isolation; secure boot and integrity measurement; host hardening; allow-listed outbound TLS with mutual authentication to cloud; local buffering and replay protection; tamper detection. In the cloud: tenant isolation, least-privilege access, encryption at rest, audit logs, anomaly detection for spoofed occupancy, retention limits.
Conclusion. Place the trust boundary at the gateway, document the residual risk of spoofing and jamming on the radio link, and do not claim the sensors are trusted endpoints.
2. HR's per-desk occupancy request: assess it against privacy principles and ISO 27400 guidance. What conditions would make it acceptable?
Read the worked answer
Reasoning. Per-desk occupancy is employee behavioural data, not just building telemetry. Privacy principles point to purpose limitation, data minimisation, transparency, lawfulness and fairness, and accountability. The HVAC purpose does not automatically justify individual monitoring.
Conditions for acceptability: (1) documented necessity and proportionality, with aggregate floor-level data considered first; (2) transparency and consultation with employees or a works council, plus a legal basis under employment law; (3) pseudonymised desk IDs, restricted access and short retention; (4) an explicit ban on using the data for performance evaluation; (5) a DPIA and landlord notice under the lease. If those conditions cannot be met, refuse the per-desk request and provide aggregate utilisation.
Conclusion. The request is not acceptable as stated; it becomes defensible only with a separate purpose, transparency, minimisation and governance.
3. The vendor cannot supply a firmware update for a newly found radio-protocol flaw. What lifecycle and risk-treatment options are consistent with ISO 27400?
Read the worked answer
Reasoning. An unpatched radio-protocol flaw is a software and supply-chain risk that cannot be eliminated on the sensor. Risk treatment allows avoid, mitigate, transfer and accept, but acceptance must be owned and reviewed.
Options: mitigate with gateway filtering, join anomaly detection, radio isolation and physical access control; avoid by replacing the sensor model or reducing deployment in sensitive areas; transfer through contractual warranties and vendor disclosure obligations; accept only with a documented risk owner, review date and incident playbook. Because the fleet has a ten-year life, the organisation also needs a migration plan and procurement changes requiring secure boot, signed firmware and a vulnerability-disclosure commitment. The gateway is a compensating control, not a fix.
Conclusion. Do not simply wait for the vendor; combine short-term monitoring with a funded replacement or migration decision.