If occupancy data is processed in the cloud, then an internet outage stops the building’s occupancy-driven automation. HVAC and ventilation revert to fixed schedules, which is the exact behavior occupancy control was installed to replace. The fix is architectural: process the live sensor-to-BMS pipeline inside the building, and keep the cloud for analytics, configuration and lifecycle management.
Every cloud-only occupancy platform carries the same latent single point of failure. It rarely appears in an evaluation, because it does not show up in a demo and it does not show up in a pilot. It shows up on the day the WAN link drops.
This article covers what actually happens during that outage, why regulated organizations have started rejecting cloud-only architectures at security review, and what a resilient design looks like.
Architectural background: What Is On-Premise Occupancy Intelligence?
What happens when the connection drops
To see why that matters, it helps to follow the data path through a cloud-only deployment.
A sensor measures a room. The reading goes out over the building’s internet connection to a cloud platform. The platform processes it, resolves it to a space, and makes it available. An integration layer pulls it back down and writes it into the BMS as a point the control sequence reads.
Now the internet connection drops.
The sensor still measures. The BMS still runs. But the path between them is broken in the middle, and the occupancy point in the BMS stops updating.
What the control sequence does next depends on how it was written, and none of the options are good:
— It holds the last value. The building conditions itself according to a room that was occupied at 2:14pm and has been empty since.
— It flags the point unreliable and falls back to schedule. Occupancy-driven control is now schedule-driven control, and the entire investment is dormant.
— It fails to a safe default. Usually full occupancy, so the building ventilates for design capacity regardless of who is in it.
For a dashboard, an outage is an inconvenience someone notices later. For a control input, it is the feature not working for as long as the outage lasts, and the building carries the cost the whole time in energy it did not need to spend.
Why building automation was designed this way
It is worth understanding why a BMS is so unforgiving about this, because it is not conservatism.
Building automation was built for deterministic local control. A BMS assumes a local network, expects sub-second responses to a change-of-value subscription, and has zero tolerance for “wait, let me check the cloud” as an answer to “is this room occupied right now.”
That was a deliberate engineering decision, and it was correct. Buildings have to keep running when the outside world does not cooperate. Fire systems, ventilation and life safety cannot be contingent on an ISP.
Some of the largest names in building automation are now moving their own platforms toward the cloud, and that direction is not wrong. But there is always a lag between what market leaders ship and what the bulk of the market actually runs.
Buildings turn over on ten-year cycles, sometimes longer. The BMS installed in most commercial buildings today was specified years ago and will still be there years from now, long after the newest cloud-native platforms have shipped. That installed base is the reality occupancy data has to work with. For most of it, the control loop still needs to survive an outage on its own, regardless of where the software layer above it eventually moves.
The security review nobody passes
Resilience is the argument that makes sense to a facilities team. Security is the one that decides the deal in regulated industries.
Banking, government, pharmaceutical and critical infrastructure organizations run operational technology security reviews that a purely cloud-dependent architecture does not clear. This is not about encryption strength. The cryptography is usually fine.
The review is asking two questions:
Does automation-critical data have to leave the building to be usable? If occupancy data must transit the public internet and return before the BMS can act on it, the building’s control behavior is now dependent on an external service. That is a dependency an OT security team has no way to assure.
Can anything reach in from outside? Any architecture requiring inbound connections to a device on the building systems network is a much harder conversation than one that does not.
The practical test tends to be a single question: what happens to the BMS integration when the WAN link is unplugged for testing? An architecture without a good answer does not get past procurement. This is not a negotiation, and no amount of commercial flexibility changes it.
What a resilient architecture looks like
The answer is not to abandon the cloud. A fully disconnected occupancy platform can be calibrated, configured and patched. It just has to be done by hand, on site, building by building. Firmware becomes a truck roll. A floorplan change becomes a maintenance window. A failed sensor is found when someone notices the data stopped rather than when an alert fires. That is sustainable for one secure facility. Across a portfolio it is an operating cost that scales with every sensor you install, and it means the estate slowly falls behind the software the same hardware could be running.
The correct description is cloud-resilient, not cloud-independent.
Resilient, not independent.
The split follows one principle: the right workload in the right place.
Runs locally, survives an outage:
— Live sensor data ingestion and processing
— Space-level occupancy resolution across multiple sensors
— Output as BACnet/IP objects and UDMI messages
— Publication to the BMS or smart building platform
— Local caching during a disconnection
Runs in the cloud, requires connectivity:
— Historical analytics, reporting and portfolio benchmarking
— Sensor calibration, space mapping and zone configuration
— Firmware and security patching
— Sensor health monitoring
— Synchronization of buffered data once the connection returns
During an outage, the building keeps responding to occupancy because nothing in that path needs the internet. What pauses is analytics, configuration changes and updates, which is exactly the right set of things to pause.
Be direct about what this does not mean. It is not air-gapped. Configuration changes made during an outage will not apply until connectivity returns. Security patches cannot be delivered. Historical data stops flowing to the platform until sync resumes. Those are real constraints and any vendor should state them plainly rather than claim total independence.
This requires hardware, not just architecture
Hybrid is easy to put on a diagram. The part that decides whether it works is physical.
If the occupancy signal has to survive a WAN outage, the thing producing it has to sit on the building’s side of the break. That is definitional, and no software design in a cloud platform changes which side of a severed link it is on. Resilience here means a dedicated, always-on device inside the building: an on-premise occupancy gateway, or an appliance where the vendor manages it for you.
It cannot run on the sensors themselves. Sensors process their own coverage area at the edge, but resolving many sensors into accurate space-level occupancy means stitching coverage across a floor and deduplicating people seen by more than one device. That needs a view of the whole floor.
It cannot run intermittently. Hosting a BACnet server means being a persistent device on the local network with a stable device instance, a discoverable object list and a COV subscription table that survives restarts. A BMS expects a response in well under a second.
And it has to clear an OT security review as a device, which means no inbound connections, no local CLI or SSH, mutual TLS to the sensors, network isolation, and alignment to IEC 62443 and IEEE 802.1x.
Worth testing during evaluation: whether the on-premise component is a managed appliance or a software image handed over for your team to run on your own server. The second option satisfies the diagram and moves the problem. Patching, hardening and lifecycle management become your obligation, on a device sitting on your building systems network. That is usually where a security review reopens.
Where UDMI fits
If the building runs a smart building operating system rather than a traditional BMS alone, the delivery format is increasingly UDMI rather than BACnet.
UDMI, the Universal Device Management Interface, is an open specification for describing building IoT devices consistently over MQTT. It carries not just the telemetry but the device identity, its BIM location and its health state.
The resilience argument applies identically. If UDMI messages are published from a cloud service, the smart building platform loses its occupancy feed during an outage. If they are published by an on-premise occupancy gateway to a local MQTT broker, the feed continues. Deployments specifying UDMI v1.5.2 today are a leading indicator of where the wider market goes next, and the same architectural question applies.
What to ask a vendor
Five questions. The answers are usually revealing.
1. Where is occupancy data processed, physically?
2. During a WAN outage, does the BACnet point in my BMS keep updating? For how long?
3. What exactly stops working during an outage, and what keeps working?
4. Does anything require an inbound connection to a device on my building systems network?
5. What standards does the on-premise component align to? IEC 62443 for building and industrial automation security, IEEE 802.1x for network access control.
If a vendor cannot answer question three crisply, they have not designed the boundary. They have just put a server in the building and hoped.
Frequently asked questions
What happens to occupancy sensors when the internet goes down?
The sensors keep sensing. Whether anything can use the data depends on where it is processed. In a cloud-only architecture, the data cannot reach the building management system, so occupancy-driven automation stops and the building reverts to fixed schedules. In a hybrid architecture with local processing, the BMS integration continues uninterrupted.
Is on-premise occupancy data air-gapped?
No. A well-designed on-premise occupancy system still requires cloud connectivity for calibration, configuration, analytics, sensor health monitoring and security patching. What it does not require is connectivity for the live sensor-to-BMS control path. This is best described as cloud-resilient rather than cloud-independent.
Why do regulated industries reject cloud-only occupancy platforms?
Operational technology security reviews in banking, government and pharmaceutical environments ask whether automation-critical data has to leave the building to be usable, and whether anything can reach in from outside. A cloud-only architecture answers the first badly. The standard test is what happens to the integration when the WAN link is disconnected.
Does an on-premise occupancy device need inbound network access?
It should not. A well-designed appliance initiates outbound connections only, with no inbound connections, no local CLI and no SSH access. This is normally a hard requirement for deployment on an OT network.
How long can an on-premise occupancy system run without cloud connectivity?
The live BMS integration continues indefinitely, because that path does not touch the internet. What degrades over time is everything else: configuration changes cannot be applied, security patches cannot be delivered, and analytics stop updating until synchronization resumes. It is a resilience mechanism for outages, not a permanent operating mode.
Related reading:
— What Is On-Premise Occupancy Intelligence?
— Occupancy Sensor BACnet Integration: The Complete Guide
