Verify door state after network loss

What you should be able to do

Distinguish an interrupted host connection from loss of device power, compare expected offline behavior with an isolated trainer's actual door functions, and document recovery. This lesson is a learning exercise, not an authorization to interrupt an occupied building's access system.

Key Idea

An offline indication describes a communication condition. It does not, by itself, tell you whether the reader has power, whether a lock is energized, whether a door is latched, or whether required egress operates. Start by naming the path being interrupted: controller-to-host, controller-to-peer, reader-to-controller, or wireless lock-to-hub. These are different tests. This exercise concerns the host data path while local device power remains present.

Manufacturer Context

Axis describes the A12 series as supporting local door-access operation during a network outage and local storage of credentials and event logs. That is a product-family capability, not evidence that every server-dependent feature or every other manufacturer's controller works identically. Consult the actual controller, firmware and software documentation before selecting expected results. Source: https://www.axis.com/products/axis-a12-series

Feature dependencies matter. The AXIS Camera Station Pro Secure Entry manual states that offline anti-passback can continue when the zone's doors belong to the same controller; it describes a limitation when the zone spans different offline controllers. This demonstrates why a successful local credential test does not establish correct operation of a distributed feature. Do not confuse that controller-to-host condition with the separate wireless-lock offline condition described elsewhere in the manual. Source: https://help.axis.com/en-us/axis-camera-station-secure-entry

Prepare The Test

Use a dedicated, supervised trainer and fictitious credentials. Identify the controller, reader, lock simulator or trainer hardware, firmware, software, relevant configuration revision and expected sequence. Record which functions are local and which require communication. Obtain the instructor's approved method for interrupting only the intended data path while retaining the existing power arrangement.

Do not casually unplug a PoE connection: it may carry the controller's power as well as data. Likewise, disabling a switch port may affect PoE depending on its configuration. Have the instructor establish a suitable isolated test method. This lesson does not instruct you to alter a production firewall, disable shared switches or add an alternate power supply.

Create a baseline with one authorized test credential and one deliberately unentitled test credential. Record the reason for each expected outcome. Keep schedules, time, input conditions and the test opening consistent. Confirm that the instructor can stop and restore the exercise.

Worked through

Trainer T171 has locally provisioned fictional credential A and an unentitled credential B. Its approved exercise predicts that A can obtain entry and B cannot during a host disconnection. That prediction belongs to this fictional configuration, not every controller.

Before disconnection, observe the entry-side response, opening and closing, latch condition and instructor-approved egress check. Record the corresponding host events. During the controlled interruption, confirm that power remains present, note the host's communication indication and repeat the same test cases. A green reader indication alone is not a complete result: record the access decision and actual lock or simulator response separately.

If an instructor stages a permission change on the isolated host, record it as pending until delivery and enforcement are demonstrated. A successful save in a management application is not proof that an unreachable controller received a revocation. Do not use real credentials or create a security exposure to demonstrate this point.

After communication returns, verify the connection state and repeat the access tests. Compare observations with event records using event occurrence times as well as receipt times where the system exposes them. Verify any expected buffered event transfer; do not assume unlimited storage, guaranteed backfill or a particular duplicate-handling method. Record missing evidence as unresolved. Verify that intended permission changes reached the target and that the trainer returned to its documented normal configuration.

Record Sheet

Record the opening/trainer ID; system versions; data path interrupted; power-retention evidence; preloaded configuration reference; interruption and restoration times; each credential's expected and observed outcome; physical entry, latch and egress observations; local and host event references; pending updates; post-reconnection results; anomalies; restoration confirmation; and instructor sign-off. Keep secrets and personal credential identifiers out of teaching examples.

Knowledge Check

Supervised Exercise

Use the fictional T171 configuration on paper. The instructor supplies a baseline showing A granted and B denied, a host-offline indication with separate evidence that device power remains present, and a host-side revocation of A saved during the interruption. No delivery confirmation is supplied.

Prepare separate rows for observed baseline results, predicted offline results and the pending update. Explain why the saved revocation is not evidence of controller enforcement. List the observations needed after reconnection: delivery status, a controlled retest of A and B, relevant event records and final configuration. Have another learner identify which conclusions are supported and which remain predictions. No live disconnection is part of this paper exercise.

Where beginners go wrong

Sources