There is a complaint that arrives at property managers a few weeks after an access control system is commissioned, and it always sounds like a fault. A staff member badges at the parkade gate and nothing happens. Their card works everywhere else. It worked this morning. The system, when someone finally looks, has a record of the attempt with a reason attached: the credential is already inside.
It is not a fault. It is a feature called anti-passback, working exactly as designed, on a person who did nothing wrong.
Anti-passback is one of the genuinely useful controls in access control, and also the one most likely to be switched on because it sounded sensible in a meeting and quietly switched off three weeks later after the complaints. Both outcomes are avoidable. What separates them is understanding what the feature enforces, and choosing the mode deliberately.
What the feature actually does
Start with the problem it solves, because the name does not describe it.
A credential is a token — a card, a fob, a phone. The system knows which credential was presented, not who presented it. So the oldest weakness in access control needs no skill at all: a person badges in and a second walks through behind them. Or badges in, carries the card back out, and hands it to someone else. One credential, two people admitted, one line in the audit log.
Anti-passback attacks this by making the system keep a picture of where each credential is. Not a log of what it did — a live state. This credential is inside the parkade. That one is outside. And it enforces a rule against that state: you cannot enter a place you are already in, and you cannot exit a place you were never recorded entering.
Present the card at the entry reader and your credential's state moves to "inside". Present it again at the same reader with no exit in between and the request contradicts the picture. Either the card was passed back to a second person, or the system's record of you is stale. It cannot tell which, and that ambiguity is the whole subject of this article.
This is unlike every other rule in your system. Access levels ask about permissions — is this person allowed through this door at this hour? — and the answer does not depend on what happened five minutes ago. Anti-passback asks about history, so its correctness depends on the completeness of its own past observations. Everything below follows from that sentence.
Where it genuinely earns its place
It would be easy to read the rest of this and conclude the feature is not worth the trouble. In the right places it is.
Parkades are the classic case, because the abuse is routine: one resident's fob opens the gate for a vehicle that is not theirs, repeatedly, until the stall count stops matching the vehicle count. Secure areas where headcount matters — server rooms, cash handling, controlled-goods storage — need a defensible answer to "who is in there right now?", and a roster saying three people entered is worth little if one credential produced two of them. Turnstiles and controlled lobbies are the natural home: a turnstile permits one person per authorization, so the system's picture and physical reality stay in agreement on their own.
Notice what those have in common. Each is a bounded space with a small number of ways in and out, and every one of those ways can carry a reader on both sides.
Hard and soft: the same rule, two consequences
Every system offering anti-passback offers at least two modes, and the difference between them is the entire risk profile of the feature.
Hard anti-passback enforces the rule absolutely. The state says you are already inside; the request to enter is denied. The door does not open. The person stands there.
Soft anti-passback enforces nothing at the door. It notices the violation, writes it to the log, flags it, may alert someone — and grants the access anyway. The person walks through. The record of the anomaly survives.
The instinct is to hear soft mode as the weak option and hard mode as the serious one. What soft mode actually does is separate detection from enforcement. It gives you every bit of the information — the same violation records, the same pattern of a fob being passed around, the same evidence for a conversation with a resident or a contractor — without putting a locked door between a legitimate person and where they need to be.
Hard mode adds exactly one thing on top of that: the refusal. And the refusal is only correct when the system's picture is correct.
The picture goes wrong for innocent reasons
Here is the part that does not appear in the brochure. The picture desynchronizes from reality constantly, and almost never because anyone did anything wrong.
Someone leaves without badging. A colleague opens the door and two people walk out. Neither did anything except be polite. One credential is now recorded as inside a space it left half an hour ago.
A door is propped. Deliveries, moving day, a contractor running cable. Everyone who walks through is invisible to the system.
A reader fails. The exit reader on a stairwell door stops answering, and nothing announces it — on a one-way, unsupervised link the controller is not expecting to hear from it anyway, which is one of the strongest practical arguments for a supervised protocol on the wire. Every exit through that door goes unrecorded until someone reports it.
Power blips. A controller reboots, and depending on configuration the occupancy picture may not survive.
A fire drill. The worst case, and the most predictable. The building empties in minutes through every available route, including stairwell and exterior doors with no reader on the inside face — because nothing should ever stand between a person and the way out. None of those exits is recorded. Then everyone comes back, and under hard anti-passback a large part of the building is refused at the door at once.
In every one of those scenarios the person at the reader is legitimate and cannot fix the problem themselves. Hard mode cannot tell them apart from someone passing a card back through a fence. It sees the same contradiction and returns the same answer.
The reset problem is the real cost
Once a credential's state is wrong, someone has to reset it: a person with administrative access, available at the moment it happens, who can find the credential and clear its state. Early on a Sunday morning, at a parkade gate, in the rain, that person frequently does not exist. What exists is a phone number going to voicemail and a resident blocking a lane.
Some systems soften this — a scheduled reset clearing all states overnight, a timed variant where a credential's state expires after a configured interval, a bulk reset an administrator can fire after a drill. These help. They are also, every one of them, an admission that the picture is expected to go wrong. A nightly reset tolerates desynchronization; it does not prevent it.
Before enabling hard mode anywhere, answer this in writing: when a legitimate person is refused at this door, who fixes it, how are they reached, and how long does it take? If the honest answer is "we would call the integrator on Monday," you have chosen a control whose failure mode you cannot service. That is a reason to run it in soft mode, not a reason to abandon the feature.
Why it demands exit readers on every path out
There is a design prerequisite hiding in all of this, and it is where most deployments quietly break. For the picture to stay accurate, every exit has to be recorded. Not most exits. Every one. A single unread way out poisons the scheme, because everyone who uses it becomes a false "still inside" the next time they come back.
So an area under anti-passback needs a reader on the inside face of every door leading out of it — a real cost in hardware, cable and pathway for doors that were only ever wired one way. It is also, on some doors, the wrong thing to do, and this is the line the feature must never cross.
Egress is not negotiable. The BC Building Code states the free-egress principle in two parallel places, and which one reaches your door depends on where the door sits. Division B, Sentence 3.4.6.16.(1) covers a principal entrance door to a building and every exit door, requiring release hardware that permits the door to be readily opened from the inside with not more than one releasing operation and without requiring keys, special devices or specialized knowledge of the door-opening mechanism. Doors within a floor area — a suite door opening into a corridor, a door on the path toward the stairwell — are governed instead by Article 3.3.1.13, whose Sentence (2) requires a door in an access to exit to be readily openable in travelling to an exit without keys, special devices or specialized knowledge, and whose Sentence (3) requires release hardware and not more than one releasing operation.
Nothing about anti-passback may sit on top of those requirements. A reader that records an exit is fine — it observes, it does not gate. A reader a person must satisfy in order to leave is not, and no occupancy-tracking benefit outweighs that. If an integrator's answer to the coverage problem is a credential requirement on the way out, stop the conversation and have the design reviewed against the Code for your building, by someone accountable for the opinion, in writing. What your locks do when the power dies is a separate decision made door by door, and it interacts with this one: a door releasing on power loss also releases without generating an exit record.
There is a maintenance dimension too. The Building Code governs the design; the BC Fire Code governs the rest of the building's life, and its Division B Article 2.7.2.1 addresses ongoing testing of egress doors. We are deliberately not quoting it or naming an edition — confirm the current text and governing edition for your building. The obligation to keep egress usable is continuous and does not pause because a new feature was enabled.
The decision rule
Use anti-passback only where the picture can actually be kept accurate — a bounded area with a small, known set of ways out, every one of which can carry a reader that records exits without gating them. And use soft mode unless you have a specific, stated reason not to.
That specific reason usually exists in one place: a turnstile or a vehicle gate, where the hardware itself enforces one person or one vehicle per authorization, the exit is as controlled as the entry, and the picture stays true on its own. Everywhere else you are betting nobody will ever tailgate out, prop a door, or evacuate the building — and you lose that bet the first time there is a drill.
What to ask for
Five questions, in writing, before this is enabled anywhere in your building:
- Which areas is it on, and which mode is each in? Per area, not "the system has anti-passback." Modes differing between areas is normal; nobody knowing which is which is not.
- Every way out of each area, and whether each records an exit. A list of doors, not an assurance. This determines whether the feature can work at all.
- Confirmation that no egress path requires a credential to leave. Stated as a commissioning fact, per door.
- Who resets a stuck credential outside business hours? A name and a number, not a role.
- What happens after a drill or an evacuation? If the answer is not a bulk reset someone is trained to perform, hard mode is not ready to be on.
An integrator who works with this regularly answers all five without difficulty. If two and five come back vague, run soft mode until they do not. You will still catch the fob being passed around — in a report rather than at a door, which is where you wanted to deal with it.
If any of this is unfamiliar, the structure underneath it and the two questions that define every access level are worth reading first. A rule layered on a design nobody wrote down is a rule nobody can troubleshoot.
