Cloud Access Control During an Internet Outage: What Continues and What Must Wait?

Find where the access decision is made

A Reddit developer asked for a reader that would send each credential to a remote web server for authorization. Commenters questioned the resulting outage dependency. This is an architecture question, not a reported performance test of a commercial cloud platform.

For a proposed installation, identify what the controller or reader stores locally and what must reach an external service. Keep internet loss separate from loss of local networking or electrical power. The selected equipment may support more than one fallback path, each with different conditions.

Source: proximity card reader that connect to cloud

Verkada documents a last-known configuration

Verkada’s offline-operation documentation says its controller continues using the last cloud configuration it received and stores events locally. After connectivity returns, it receives the current configuration and sends stored events to the cloud. The document’s example distinguishes an existing employee badge from a new badge issued while the controller is offline: the new grant arrives after reconnection.

The operational implication is that a change saved centrally needs delivery to that controller before the new configuration can be assumed effective. For a revocation during an outage, confirm the platform-supported procedure and obtain controller-level enforcement evidence. This inference from the documented configuration model is not a promise that every credential type or emergency workflow behaves identically.

Source: Verkada: Offline Operation and Last Known Configuration

Kisi documents several different fallback paths

Kisi describes reader caching based on recent credential use, a controller-cache path for specified third-party-reader arrangements, and a phone-based path. The phone path requires the phone to reach Kisi’s service to obtain an authorization certificate while the reader and controller remain connected locally. Offline at the building therefore does not always mean every component is offline.

Its reader-cache documentation requires relevant rights already in the cache and warns that newly added or inactive users may not be included. Verify the installed configuration’s current cache limits and synchronization behavior rather than assuming every enrolled credential will work. The documentation contains different timing statements for synchronization, so obtain product-specific clarification and test consequential grant or revocation timing.

Source: Kisi: Reader, Controller and Phone Offline Support

Test a changed permission as well as a familiar badge

Use authorized temporary credentials to compare existing access, a new grant and a revocation under the agreed communication failure. Record the event time, central status, local result and result after restoration. A familiar badge opening the door demonstrates only that credential’s tested path.

Before the exercise, define who handles a consequential change that cannot yet be confirmed at the opening. The property’s authorized security team must select any interim measure without compromising required exit. Do not promise instant global revocation when the selected architecture has not demonstrated it.

Retain property-controlled administration and recovery

Name authorized administrators, account recovery, support access and subscription responsibility. Request the vendor’s supported export and recovery options. Access to a cloud dashboard held only in an installer’s personal account leaves an avoidable administrative dependency.

After reconnection, verify configuration delivery, relevant event records and the actual temporary credential result. Remove the test permissions and retain the test record securely. The acceptance result belongs to the tested hardware, firmware and network arrangement, not to the phrase cloud access control in general.

Put it into practice

A decision table to keep handy