Access Control Offline Mode: What Happens When the Internet Goes Down, and How to Design for It

Access control offline mode is how a well-designed system keeps working when the internet goes down: the door controller behind each reader grants or refuses entry using the last permission list it received, stores every event in its own memory, and sends the records to the central system once the connection returns.

A poorly designed system either leaves doors locked while a whole shift waits at the gate, or has them propped open so nobody knows who came in. How each door behaves during an outage is a design decision that should be made door by door, before installation. For the building blocks and other scenarios, see our access control and attendance hub.

What happens on site during an outage

It's 07:50 and a shift of 300 people is arriving at the gatehouse. The site's internet link was cut overnight by roadworks. There are three possible outcomes:

• If the system asks a central server on every read, the turnstiles get no answer and stay locked. The guard releases them, the shift walks in, no attendance records are created, and that day's timesheets become guesswork.
• If the controller decides locally but does not store events, the doors work but every passage during the outage is lost. At month end, "who was in that day?" turns into a dispute.
• If the controller decides locally, stores events and syncs later, the shift walks in without noticing anything, and the records flow to the centre once the link is back.

The same question applies to power cuts, often more critically: does the lock stay locked or release when it loses power? Will controllers and readers stay powered during the outage?

The real cost of an outage

Connectivity and infrastructure outages happen to every organisation sooner or later, and they are not cheap:

In Uptime Institute's 2025 annual survey, 57% of respondents said their most recent major outage cost more than $100,000, and one in five reported costs above $1 million. (Uptime Institute, Annual Outage Analysis 2026)

A shift waiting at the gate is lost production. According to Siemens' The True Cost of Downtime 2024, an hour of unplanned downtime costs $2.3 million in a large automotive plant and $36,000 in fast-moving consumer goods (FMCG) plants. Access control doesn't stop the line, but a crew stuck at the gatehouse for half an hour has much the same effect.

The costs of an access control system that isn't prepared for outages:

• Shift delays and lost output. If turnstiles stay locked, the shift start slips.
• Uncontrolled entry. If doors are left open by hand, nobody knows who came in, leaving a blind spot for both security and health and safety.
• Missing attendance data and timesheet disputes. Days without records make overtime and absence calculations contentious.
• Duplicate or lost meals in the canteen. If an offline terminal can't tell that someone has already eaten, meal counts break down (canteen meal counting automation).

How access control offline mode works: four layers

A robust access control system is prepared for outages layer by layer:

1. Local decisions. The door controller keeps an up-to-date copy of the permission list in its own memory and decides without asking the centre. The centre only distributes permission changes and collects records (our card access control system guide explains where the controller fits).
2. Local storage and sync. Every event is stored on the controller with a timestamp, connected or not, and sent to the centre in order when the link returns. Controller clocks must be synchronised regularly, or attendance records drift.
3. Power continuity. An uninterruptible power supply (UPS) or battery backup for controllers, readers and locks, with the required run time calculated for each door.
4. Connection backup. At critical sites, a second connection (for example a mobile data link; see our LoRa vs NB-IoT vs cellular comparison) takes over when the main line fails, keeping the centre in touch. On sites with weak infrastructure, such as construction site access control, this layer is a necessity rather than an option.

A door-by-door decision table

Not every door should behave the same way. What happens during an outage is decided by door type:

Escape-route door behaviour must comply with fire regulations and fire service requirements; in Türkiye that includes the Regulation on the Protection of Buildings from Fire. Settle it at the design stage.

The limits of offline mode

Offline operation is not magic; three limits are worth knowing:

• Revocations are delayed. If someone is dismissed during an outage, their card may remain valid on the controller until the link returns. Critical doors need a separate procedure for this.
• Cross-door rules weaken. Rules such as anti-passback, which require several doors to know about each other, can't be fully enforced if controllers can't communicate.
• The live list goes stale. The "who is inside now" list is not updated centrally during an outage, so plan how local records will be reached in an emergency. We cover this in our article on the emergency muster report.

Six tests to run before you sign off

1. Physically unplug the main internet line, walk 20 people through the gatehouse and watch how doors and records behave.
2. Restore the connection and check that every event from the outage reaches the centre, complete and correctly timestamped.
3. During an outage, revoke a card centrally; once the link returns, measure how long the change takes to reach the controller.
4. Cut mains power and see how long the UPS keeps each door running and whether locks behave as designed.
5. At the canteen terminal, try to take two meals with the same card in offline mode.
6. Write all results into a test report, and repeat at least once a year.

How we approach it at Digital Bridge

We develop software and hardware in the same team: electronics and PCB design, mechanical enclosures, embedded software and web/mobile panels under one roof. That avoids the familiar outage scenario in which the software supplier blames the hardware and the hardware supplier blames the software.

• Door-by-door scenario work. During needs analysis we record in a table like the one above how each door should behave in power and network outages, and attach it to the written proposal.
• Hardware and power design. Turnstiles, readers, locks and UPS are specified under card access control, with vehicle entrances on barrier and parking systems tied into the same scenario. For special requirements, our device manufacturing and IoT team develops solutions suited to site conditions.
• Infrastructure and monitoring. We design site networks and backup connectivity through cloud migration and infrastructure consultancy, and remote monitoring of device health with our remote monitoring solutions. We explain how to watch controller, UPS and link status on one screen in our remote monitoring IoT platform guide.
• On-site testing. During commissioning we run the six tests above with you and report the results. Our technical support is available 24/7.

Continuity with SmartPass

Our own product, SmartPass, combines access control, time and attendance, and canteen meal counting in one system: a single card read opens the door, records attendance and, where earned, deducts a meal. That unified design also simplifies continuity planning. Instead of three separate systems with three outage scenarios, you plan around one terminal and one rule set.

On SmartPass installations, we handle outage scenarios like this:

• Per-door behaviour based on your rules. Every door and mobile terminal carries a copy of the permission list signed by the server; when the connection drops, decisions are made from that list under the same rules, and a list whose signature does not check out is not used. Each access point gets one of three behaviours: follow the cache, stay closed or stay open, with a cache lifetime set per point between 5 minutes and 30 days.
• Nothing lost, nothing duplicated. While offline, accesses are queued on the device and uploaded in order, in full and without duplicates once the link returns. In the canteen a second pass is blocked even while offline, and any over-use of entitlement is flagged afterwards. If a fixed device fails, an NFC-capable Android phone can be attached to the same point as a mobile terminal, and it too decides without internet.
• Dashboard and emergencies. While connected, the dashboard shows how many people are inside, device connectivity and a live access feed; analysis tracks each access's decision source (server, device cache, policy) separately. At an access point in emergency mode, exits are freed and entries closed.
• Data protection (KVKK) and audit log. Card numbers are not stored but turned into a one-way hash as they are read, every change is logged with previous and new values, and records past their retention period lose the fields that identify a person.
• Separate data per organisation. Each organisation's data sits in its own separate database; in multi-site groups each site can be opened as a separate SmartPass organisation, so an outage at one site does not affect another's records.

We show how outage scenarios at your site will work with SmartPass in writing at proposal stage, and by testing on site during commissioning.

Next step

List the doors on your site and write two questions beside each: should it stay open or locked if the power fails? Should the shift still get in if the internet drops? Bring that list and get in touch, and we'll agree the door-by-door scenario together. For how to standardise these decisions across locations, see multi-site access control.