What should happen when a smart building loses its internet connection?

Very little that matters. When the external connection drops, the building itself should carry on safely: plant continues under local control, doors keep working, alarms still reach someone and data is buffered, not lost. What stops should be confined to functions you have knowingly accepted as cloud-dependent, such as remote dashboards or portfolio analytics. Getting there depends on two things: deciding the intended behaviour of every function before the design is finished, and then testing it by actually disconnecting the building.

A question older buildings never had to ask

Older building systems ran entirely on site. Newer services often rely on external connections: cloud analytics, remote monitoring, mobile credentials, licence checks, firmware services, guest apps, time synchronisation and supplier support. Each is useful, and each creates a dependency that may stay invisible until the connection fails.

NIST's guide to OT security (SP 800-82) recommends designing operational technology to degrade gracefully, stepping down from full automation to modes with more operator involvement and finally to manual operation, so that nothing fails all at once. NIST also notes that losing network communications can trigger fail-safe behaviour, and that organisations should define the thresholds at which components can keep operating with reduced capability. CISA's CI Fortify guidance, written for critical infrastructure, makes a point that applies equally to commercial buildings: recovery planning should cover communication dependencies such as licensing servers and business network connections, and manufacturers should explain how highly connected components behave when telecommunications fail.

Must continue, may degrade, may stop

A simple three-way classification, agreed between the operator, the controls designer and each supplier, makes the intended behaviour explicit.

Every service should be placed in one of the three classes, and contracts and acceptance tests should then reflect the classification.

The dependencies nobody remembers until they fail

Licences and authentication are a common surprise. Some software checks a licence or authenticates users against an online service, and if that check fails the local operator workstation may lock users out. Ask each supplier what happens after one hour, one day and one week offline.

Mobile keys and cloud-managed access control can work very well, but you need to know what happens to new credentials, revocations and the door controllers' cached permissions when the cloud service cannot be reached. Alarm routing is another weak point: if critical alarms reach the duty engineer only through a cloud notification service, an outage silences them, so there should be a local path, such as an on-site alarm panel or workstation, or an alternative route.

Time is easily overlooked. Schedules, logs and trend data all depend on it being correct, so someone has to decide where devices get their time when external sources are unavailable. Remote support creates a subtler dependency. If all diagnosis relies on the supplier logging in, an outage that coincides with a fault leaves the site without help, and on-site engineers need the access and documentation to operate and recover systems themselves. And where schedules, setpoints or sequences are edited in a cloud platform and pushed to site, the last valid configuration must stay active locally.

The data has to survive too

When the connection returns, data platforms should receive what happened in the meantime. The specification should say how long local devices or gateways buffer data, in what order it is sent on reconnection, how gaps are flagged and how duplicates are avoided. Without that, energy reports and fault records can show false gaps or misleading spikes.

Building resilience in from brief to operation

The brief is where it starts. It should include a failure-behaviour schedule listing each function, its class, its expected behaviour offline and on reconnection, and the supplier responsible. In procurement, suppliers should be asked to state which features of their own product depend on external connections and how the product behaves without them. The CI Fortify guidance points out that contractual and licensing conditions can stop operators preparing for isolation, so licences and service terms need checking for exactly that.

The network design may justify a second external connection for essential services, from a different provider or over a different physical route. That reduces the likelihood of an outage; it does not remove the need for local operation.

Commissioning is where claims become evidence. The building's external connections should be disconnected in a planned test, every "must continue" and "may degrade" behaviour verified, and then recovery verified as well. A supplier's statement is not evidence; a witnessed test is. In operation, the test should be repeated periodically, especially after significant software changes or new integrations, and current configuration backups and installation media kept on site, so that recovery does not itself depend on the connection that has failed.

Five questions for the owner

• Do we have a written list of every function that depends on an external connection?
• For each, have we decided whether it must continue, may degrade or may stop?
• Have we tested a full disconnection, and when did we last repeat it?
• Can our on-site team operate and recover essential systems without a supplier logging in?
• Do critical alarms have a path that does not depend on the internet?