Ask most building owners what their access control system does and you get a description of a card reader. Somebody taps a fob, a light goes green, the door opens. That is the visible half-second of a system doing four separate jobs, and almost every expensive mistake in this field comes from collapsing those four into one.
The four are people, credentials, doors and time. They are not layers of the same thing. They are four different lists, maintained by different people, that fail in different ways. A system perfect at three of them and sloppy at the fourth has a hole in it, and the hole is usually in the two nobody thinks of as part of the system at all. This article is the map; everything else we publish about access control hangs off one of these four.
1. People: identities, not names
The first list is the people. Not employees — identities. A person can be a contractor, a strata resident, a tenant's staff member, a cleaner who works for a company that works for your building manager, or someone who left eight months ago and is still on the list.
An identity has a lifecycle: created, given a role, changed, and eventually ended. Almost every system is excellent at the first step and terrible at the last. Creating an identity is urgent — someone is starting, they need in today. Ending one is nobody's job and produces no complaint if skipped. That asymmetry is the most common defect we find, and it does not present as an incident. It presents as an active cardholder list noticeably longer than the list of people in the building, with nobody able to say which rows are which.
The fix is not technical. Whoever handles departures — HR, the property manager, the strata council secretary — has to be the one who removes access, on the same form and the same day they do everything else. If revoking access is a separate task on a separate system that a separate person remembers, it gets skipped silently.
An identity should also be one person. Shared identities — a "front desk" card, a "cleaners" fob passed between whoever is on shift — destroy everything downstream: the moment two people share one identity, your log stops recording who and records only which card.
2. Credentials: what they carry, and why it is not them
A credential is the thing a person presents: a card, a fob, a PIN, a phone, a fingerprint. It is the system's proxy for the person.
A credential is not a person. This is the most important sentence in this article, and the one most systems are sold in a way that obscures.
Your system does not know that Priya walked through the loading bay door at 04:12. It knows that a credential assigned to Priya was presented at that reader at that time, and the controller found it valid. Those are different claims, and between them sits every possibility that matters: the card was lent, lost, left in a coat, copied, or never returned when the person left.
That gap is not a flaw to be engineered away. It is a permanent property of the technology, and it changes how you use a log: as strong supporting evidence, corroborated by something else — video, a second reader, a person — rather than as proof of who was present.
Credential technology also varies enormously, and the difference is invisible from the outside. The beige proximity fob on your keyring and a modern encrypted smart credential look, feel and work identically at the reader. They are not equivalent. HID Global, describing the risk in its own products, states that third-party tools are used to create legacy credentials on "cards with fewer security features (like MIFARE Classic and legacy iCLASS Elite), legacy iCLASS, or cards with no electronic security at all (classic Prox)." That is a manufacturer conceding that a format it sells has no electronic security. We have written separately about upgrading the cards but leaving the old ones working — a migration that changes nothing.
Credentials have their own lifecycle, separate from the person's. A person can keep their identity and get a new card; a card can be reissued; lost cards need voiding rather than forgetting. If your system tracks people but not the physical items in circulation, you cannot answer the question that matters after an incident: how many credentials exist that we cannot account for?
3. Doors: five parts, and only one of them decides
A controlled door is five separate devices, and most owners have only ever seen one of them.
The reader is on the wall. It reads the credential and turns it into a number. That is the entirety of its job. It holds no list, checks nothing, and decides nothing. It is a sensor.
The controller is a metal box in an electrical or communications room somewhere else in the building. It holds the list of who is allowed through which door at which hours, it makes the decision, and it releases the lock. Everything you think of as "the system" is in that box or in the software that programs it.
Between them runs a wire, and that wire has a language — a design decision made on your behalf, usually without appearing in the quote. The industry body describes OSDP, the modern option, as "an open communications standard used between access-control panels and peripheral devices such as card readers... designed to improve interoperability, cybersecurity and device management while providing a more capable alternative to the legacy Wiegand interface." The legacy alternative is unencrypted and unsupervised, so your system cannot tell you when a reader stops working. That has its own article.
The lock is the electrified device that holds the door. What it does when power is lost — release, or stay locked — is a decision made door by door, against what that specific door is for. Electromagnetic locks are their own case with their own code conditions.
The request-to-exit device tells the controller a legitimate exit is happening — a sensor above the door, a switch in the push bar, or a contact in the lever — so a person leaving does not generate a forced-door alarm.
The door position sensor is a small magnetic contact reporting one fact: is this door open or closed? It is the cheapest part of the door and the one that turns a lock into an instrument. Without it, your system knows only that it released the lock. With it, your system knows whether the door actually opened, whether it closed again, and whether it is standing propped at 2 a.m. Almost every useful alert an access system produces — door forced, door held open, door left ajar — comes from this one component.
Two constraints sit above all of this. The BC Building Code requires that locking and fastening devices on a principal entrance door to a building and on every exit door include release hardware permitting the door to be readily opened from the inside with not more than one releasing operation and without keys, special devices or specialized knowledge of the door-opening mechanism (BCBC 2024, Division B, Sentence 3.4.6.16.(1)). Doors within a floor area — a suite door opening into a corridor — are governed instead by Article 3.3.1.13, which imposes a near-identical test on doors in an access to exit. Getting out is never a thing your access control system is allowed to decide. And the obligation lands on the building: Division A, Article 1.2.1.2 addresses the responsibility of the owner, so whatever your integrator proposed, the duty attaches to you and survives every change of contractor and strata council.
4. Time: access is a function of when
The fourth list is almost never maintained after installation, and it quietly does the most work.
Access is not a property of a person. It is a property of a person, at a door, at a time. The cleaner who should open the third-floor suite at 19:00 on a Tuesday should probably not be able to open it at 03:00 on a Sunday. That distinction costs nothing to configure and is worth more than most hardware upgrades.
Time usually appears as three things:
Schedules — named time bands, like "Business hours" or "Cleaning crew", attached to groups of people and doors. The trap is that a schedule gets named after the reason it was created and then outlives it. "Contractor — lobby renovation" is still active three years later because deleting things feels risky.
Holidays — a separate calendar overriding the schedules, and the most commonly broken piece of an access control system in Canada. Holiday tables get populated during commissioning for the current year and then never updated. A system whose table ran out four years ago treats every statutory holiday since as an ordinary weekday, and the front door unlocks automatically on a day the building is empty.
Automatic unlock — the schedule holding a door unlocked during opening hours. A door on an unlock schedule is not an access-controlled door during those hours. It is an open door. That may be exactly right for a lobby at 10 a.m. and is rarely right for anything else.
Add one annual task: open the holiday calendar in January, extend it, and check what your doors do on those dates.
What the system knows, and what it assumes
The difference determines what your logs are good for.
Your system knows: that a specific credential was presented at a specific reader at a specific time; that the controller accepted or rejected it, and on what rule; that the lock was released; and — if you have door position sensors — whether the door actually opened, and how long it stayed open.
Your system assumes: that the person the credential is assigned to is the person who presented it; that only one person went through; that the door closed behind them; and that the list of active identities matches the list of people who should have access.
Every one of those assumptions is routinely false in ordinary buildings, and none of them is a defect — they are the boundary of what the technology can establish. An owner who knows where that boundary sits asks better questions after an incident and buys the right things beforehand.
One consequence follows immediately: those logs are a dated record of named people's movements, which makes them personal information under BC's Personal Information Protection Act. Collection, use and disclosure carry notification duties (s.13, s.16 and s.19), the record must be protected by reasonable security arrangements (s.34), and it cannot be kept forever (s.35). We cover what that means in practice separately. Your door system is a privacy system, and nobody sold it to you as one.
What a well-run system looks like
Access control is not an install. It is a practice, and a system that was correct on commissioning day drifts into being wrong without anybody doing anything. A building running it well has five things:
A named owner of the people list, with a trigger tied to how departures already get handled. Not a policy — a name.
A quarterly reconciliation. Print the active cardholders, compare against the occupant or staff list, and resolve or disable every unexplained row.
A credential inventory — how many cards exist, who holds them, how many are unaccounted for, and what technology they are. If you cannot answer the last, that is your first task.
A door schedule. Every controlled opening in a row, with what it is for, what it does when power dies, how a person inside gets out with one motion, and whether it has a position sensor. This is the only form in which any of these decisions can be checked, handed to a successor, or shown to an inspector.
A testing routine that actually runs. Doors on an egress route are life-safety equipment and the BC Fire Code sets testing obligations for them at Article 2.7.2.1 — confirm the current edition and its exact requirements for your building with someone accountable for that opinion. Testing is its own subject, and it is where the gap between a compliant design and a compliant building shows up.
None of that is hardware. All of it is somebody's recurring calendar entry. The buildings with genuinely working access control are the ones where four lists have owners and get looked at; when that practice slips, the symptoms are usually recognizable and fixable.
Start with the reconciliation. Print the cardholder list this week and read it — whatever is in it is the honest state of your system.
