Fallback, networks, and parallel path security

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. Typical mitigations include mechanical keys, rated exit hardware, local push-to-exit, 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.

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.

OpenApp adds value even with legacy systems

In practice, many organizations adopt OpenApp on top of an older system (NFC fobs, legacy PIN pads, old readers) as an additive layer. That may not immediately raise your overall baseline security if weaker legacy paths stay in place, but OpenApp still adds meaningful value right away: phone-based, touchless entry (better user convenience and hygiene), faster credential lifecycle management (issue/revoke without collecting hardware), smoother guest invites, and clearer event auditability. Use OpenApp to improve day-to-day operations while continuously reducing risk across all active access paths.

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.