An access-control system has to decide whether to open a door, and that decision has to happen somewhere. Where it happens determines what kind of system you have. If the lock itself holds the credentials and the rules, the system is offline (on-device). If every unlock request is sent to a server that returns an allow or deny, it is cloud-based. The two approaches trade off resilience, security, speed and remote manageability in very different ways.
Offline: the decision lives on the device
In an offline system, each lock or reader stores its own credential database and policy. You present a card or a fingerprint, the device verifies it locally and actuates the bolt, and a server is never asked for permission. You see this pattern in battery-powered smart locks, standalone door controllers, most hotel locks and offline elevator controllers.
The defining property is resilience. The door keeps making correct decisions through a network outage, a server crash or a power cut (for battery locks), with no round-trip to introduce delay and nothing leaving the device for the network to intercept. The price of that independence is manageability: changing a policy across hundreds of doors means syncing the new rules down to each one.
Cloud-based: the decision lives on the server
In a cloud-based system the reader is thin. It captures a credential, sends it to a server, and the server checks the policy and replies — the door opens only if the server says yes. This is the shape of IP-based enterprise access control, cloud-connected office systems and some high-security turnstiles.
The defining property is centralised control. A single policy change propagates everywhere instantly, and every decision is logged in one place. The price is dependence: if the network or the server is down, the door stops making correct decisions unless a failover cache is built in.
Where they actually differ
| Dimension | Offline (on-device) | Cloud-based (server) |
|---|---|---|
| Authorisation location | On the lock or reader | On the server |
| Network required to open | No | Yes |
| Works during outage | Yes | No (unless failover cache) |
| Speed | Sub-second, local | Adds a network round-trip |
| Centralised policy changes | Slower (must sync to devices) | Instant |
| Tamper resilience | High (no single server to attack) | Depends on server hardening |
| Best for | Doors, hotels, rentals | Enterprise, many-reader rollouts |
The table fixes the dimensions in place, but the trade-offs are clearer in scenarios. The core tension is resilience against manageability. Offline keeps the door working through a network outage. The cloud is faster when a policy has to move across five hundred doors at once. And for a door that must let people through during a fire or a blackout, offline is the safer default. On security, a cloud system puts the authorisation server in one place, which makes it a concentrated target, while an offline system spreads that target across every lock — a single compromised lock exposes only itself. Speed is rarely in dispute: local decisions are sub-second, and a cloud round-trip adds latency you can feel at a high-traffic door. Cost and complexity also differ — cloud needs servers, network infrastructure and IT staff, while offline needs a sync path (often a gateway) to stay current.
The hybrid: on-device auth, cloud for management
The best modern access control — including how Sciener locks are designed — is a deliberate hybrid. Authorisation stays on the device: credentials and rules are synced to the lock ahead of time, so it verifies and decides locally, in well under a second, even when the internet is gone (for how that decision actually happens inside the lock, how smart locks work covers it). Management lives in the cloud: adding users, issuing codes, changing schedules and reading audit logs all happen through a cloud platform and push down to the devices. A gateway bridges the two, relaying cloud commands to the lock and pushing lock events back up — but it sits outside the decision path for an unlock, so the door still opens when the gateway is offline.
The point of doing it this way is to keep what is good about each side. The door has the resilience and speed of offline authorisation, and the management side has the reach and visibility of the cloud.
Why "offline by design" matters for safety
What matters most for a door is that it keeps making the right decision under stress. A lock that refuses to open during a network outage can trap people; a lock that opens to anyone during an outage is worse. "Offline by design" means the authorisation logic is engineered to fail safe and fail correct — the door opens for authorised people and stays shut for unauthorised people, with or without a network. That is why life-safety codes and hospitality best practices both lean towards on-device authorisation, and the same logic underpins the wider access-control security best practices worth reviewing alongside this.
Pure cloud makes sense when reliable network infrastructure is a given and centralised policy is worth the outage risk — typically large enterprise campuses. For almost everything else — homes, hotels, rentals, branch offices and elevators included — the hybrid model fits: the door stays fast and resilient, and management happens from anywhere.