The office internet goes down just before the first staff arrive. Someone asks whether their card will still open the door. Later, the question changes: what if the building loses power too? Those are not the same failure.
Some door systems keep using permissions stored in powered local equipment when the internet or management system is unavailable. A power failure raises different questions about locks, backup supplies and safe exit. We would document each scenario for each affected door rather than promise that access control simply works offline.
Name the outage before predicting the result
The internet connection lets the site communicate with outside services. The management console is the computer or appliance used to administer the system. A door controller is the local equipment that makes or carries out access decisions. Any one of those can be unavailable while the others still have power.
When the internet fails but the local system remains healthy, some local access methods may continue. Remote administration or a feature needing an outside service may not. When the console fails, a controller with previously stored credentials may still admit authorized people, but new changes may not reach it.
Manufacturer documentation for one supported architecture describes this local credential behaviour. It does not mean every product, credential type or installed configuration has the same fallback. Ask the installer to list exactly what remains available in your system.
Separate getting in from getting out
An owner's first concern may be whether the building remains secured from outside. People already inside must also be able to leave safely. These requirements need to be assessed together by the responsible professionals, not inferred from a setting in an app.
Fail safe commonly means the lock releases when its power is lost. Fail secure commonly means it stays secured from the entry side when power is lost. These labels do not fully describe the door hardware, mechanical exit arrangement, emergency release or fire system interactions.
The correct choice depends on the specific opening and applicable requirements. Do not choose a mode solely because it sounds more secure. A qualified door and life safety assessment should establish the required behaviour, with the network plan supporting that design rather than overriding it.
Never bypass emergency release, fire interfaces or required exit hardware to keep a door locked during a fault. If safe exit is uncertain, follow the building's emergency procedure and contact the responsible qualified professional.
Trace every part that needs backup power
A battery protecting the network cabinet does not automatically protect the lock. Conversely, a backed up lock supply does not establish that the reader or controller can still make the intended decision. List the components needed for the required function and how each receives power.
Where Power over Ethernet, or PoE, supplies equipment through a network cable, the supplying switch must remain powered too. Any battery backed supply has a limited runtime affected by load, condition and the installation. Ask for the tested or designed runtime and its assumptions, not an unexplained battery capacity figure.
Decide what should happen when backup power is exhausted, not only while it is working. Also document maintenance responsibility. A battery that was suitable when installed needs checking over time; the presence of a battery box is not evidence of current runtime.
- Reader and local door controller power.
- Lock supply and the specific opening's required behaviour.
- Any network equipment needed for the intended function.
- Required management, communication and monitoring equipment.
- Backup runtime assumptions, inspection responsibility and end of runtime behaviour.
Treat access changes during an outage as unverified
Stored permissions can keep a site usable, but they also create an operational question: what happens when access must be changed while the equipment is disconnected? A newly issued credential may not work, and a removal may not yet have reached the affected door.
Have a defined escalation route for urgent changes. Do not tell a manager that access is revoked solely because a screen accepted the edit. Confirm the equipment's communication state and the result at the door using the approved process.
Event records can also be delayed or limited during a fault. Storage and later synchronization differ by model. Do not promise that every offline event will appear after recovery without verifying that capability for the installed equipment.
Write down what the door does in each failure, not just whether the app says it is online.Test recovery as well as failure
Arrange an authorized test with the people responsible for building safety and operations. Agree the conditions, affected areas, expected behaviour, stop criteria and restoration steps. Avoid interrupting an occupied site just to simulate a fault casually.
After service returns, confirm the doors follow the current permissions and schedules, remote functions work where expected, and any available event records have been reviewed. Check outstanding changes explicitly rather than assuming reconnection settled them.
Keep the results by door and scenario, including unresolved items. This gives the opening manager an answer they can use during the next outage and tells the support team when the real behaviour differs from the accepted design.
Plan the next step with NeuroDesk
NeuroDesk plans access control alongside the network and supporting equipment. Bring the door schedule, installed equipment details and the outage behaviour your business needs. We can identify the technical dependencies and coordinate the appropriate door and life safety review before changes are approved.
See our business access control planning for the relevant scope.
Sources and technical scope
The technical references below describe particular equipment and software. Features and limits must be checked against the installed model and configuration; they are not promises for every system.