Fallback, networks, and parallel path security
Fallback when phones and networks fail
Section titled “Fallback when phones and networks fail”Design for cases where a user has no phone, the battery is dead, OpenApp or the network is unreachable, or credentials cannot be presented. Exit is not an OpenApp path. Occupants must leave through mechanical keys or levers, listed panic / exit hardware, hardwired request-to-exit, or a listed local special-locking arrangement with fire-alarm and power-fail release — independent of the cloud. Typical inbound fallbacks include intercom/reception or vendor cloud / on-device schedules where appropriate. Spell out who can open what when your primary app path is down—this is both safety and operations. See Life safety and egress.
Security: the weakest parallel path wins
Section titled “Security: the weakest parallel path wins”Adding another access method—keypad, shared PIN, held-open button—can lower overall security if that path is weaker or easily shared. Intuitively, parallel entry paths behave like parallel circuits for attacker choice: practical security follows a minimum function across paths (and, in plain terms, the weakest link in the chain), not the maximum. A strong OpenApp flow does not fix a guessable PIN taped next to the reader. Model total risk when you stack methods.
For non-exhaustive integration starting points by pattern (many doors, Wi‑Fi, cellular, DIY), see Suggested directions (non-exhaustive).
See also: Choosing access control architecture for price, connectivity, door count, and physical locking hardware.