Always excited to take on new projects and collaborate with innovative ideas.
+968 97716144
contact@aljulanda.info
https://aljulanda.info
Sultanate of Oman - Nizwa
Most access control failures aren't hacks — they're wiring, protocol, and integration mistakes made at install. Here's what to audit before and after go-live.
Everyone worries about the exotic access control hack — the cloned badge, the exploited firmware. Meanwhile, the system down the hall is failing for a much more boring reason: someone wired the wrong lock type, left a legacy reader broadcasting plaintext credentials, or never gave the system a way to talk to CCTV and visitor logs. That's the failure mode that actually shows up on service calls, and it's entirely preventable.

An access control install almost always "works" on day one. You badge the door, the lock releases, everyone signs off. The problem is that a successful swipe test tells you almost nothing about whether the system will hold up under real operating conditions — power fluctuations, database growth, staff turnover, or a fire inspection that suddenly cares about your egress wiring.
Industry integrators report that a large share of organizations run into access control failures within six months of installation, and the root cause is rarely the hardware itself. It's rushed planning, cutting corners on components to hit a budget number, or treating the access control panel as a standalone box instead of one node in a larger security ecosystem. None of that shows up during commissioning. It shows up three months later when a door won't unlock during a fire alarm, or when nobody can produce an audit trail for an incident because the access logs were never tied to anything.
If you're scoping a deployment — or auditing one someone else installed — the first question isn't "does it open the door." It's "what happens when the network drops, the power drops, or the reader gets swapped." If nobody can answer that, you don't have a finished system. You have a demo.

A huge number of readers in service today still speak Wiegand, a protocol that transmits credential data in plain text with no encryption. That's not a minor technical footnote — it means a device physically positioned near the reader can intercept and clone that credential data without ever touching the panel or the network. Wiegand was never designed with that threat model in mind; it's simply old.
This is exactly why the Security Industry Association created the Open Supervised Device Protocol (OSDP) — specifically to replace Wiegand and give access control products a more secure, interoperable communication standard. OSDP supports encrypted communication between reader and controller and adds supervision, meaning the panel actually knows if a reader has been disconnected or tampered with. Vendors now recommend it for new deployments, and for good reason: it closes off one of the simplest physical attack vectors in the entire access control stack.
The practical takeaway: if you're specifying new hardware, don't accept Wiegand readers on the bill of materials unless there's a specific legacy-integration reason. If you're auditing an existing system, check reader models against manufacturer documentation — most modern controllers support OSDP alongside Wiegand, so migrating door-by-door as readers are replaced is realistic. You don't need to rip out a whole system to fix this; you need a migration plan and the discipline to stop adding more Wiegand devices to it.
This is the mistake that has real safety consequences, not just security ones. A fail-safe lock unlocks when power is cut — required on doors that sit on a fire egress path, because people need to get out during a power failure. A fail-secure lock stays locked when power is cut — appropriate for doors where you want to maintain security even during an outage, like a server room or cash office. Wire a fail-safe door as fail-secure and you've just created a door that traps people during a fire. Wire a fail-secure door as fail-safe and you've built a door that unlocks itself every time the power blinks.
This isn't a rare error. Documented installation mistakes in the field include exactly this reversal, along with two other recurring wiring faults: a missing flyback diode on an electromagnetic lock — which lets the voltage spike from the lock's coil damage the controller when it de-energizes — and reversed polarity on an RS-485 bus, which can take down communication to every downstream reader or, worse, damage the bus drivers on connected devices. All three are cheap to prevent and expensive to diagnose after the fact, because by the time someone notices, the symptom (a "randomly" unresponsive reader, a controller that keeps resetting) looks nothing like the cause.
If you're commissioning a system, physically verify — don't just trust the drawing — that each door's fail state matches its life-safety classification, confirm flyback diodes are present on every mag lock, and check RS-485 polarity with a meter before powering up the bus. It takes twenty extra minutes per door. Skipping it costs you a service call and, in the fail-safe/fail-secure case, potentially a life-safety violation that a fire inspector will not let slide.
A badge swipe that doesn't correlate to anything is just a database entry. The value of access control multiplies the moment it's integrated with your other systems: CCTV footage tagged to a specific badge event, visitor management records that automatically expire a temporary credential at the end of a visit, and alarm panels that can lock down or unlock zones based on an access control trigger. Treat these as separate systems bought from separate vendors with no integration plan, and you end up with three sources of truth that don't agree with each other — which is exactly the situation an investigator does not want to walk into after an incident.
This is also where the "it's just physical security, not IT" mindset breaks down. Modern access control panels are networked devices, and networked devices get targeted. CISA's Known Exploited Vulnerabilities catalog includes real access-control software flaws actively exploited in the wild — including an improper access control vulnerability in Ubiquiti UniFi OS that could let an attacker already on the network make unauthorized system changes. That's not a theoretical risk sitting in a whitepaper; it's the kind of finding that lands in a government vulnerability catalog because it's being used. Access control infrastructure needs the same patching discipline, network segmentation, and VLAN isolation you'd apply to any other server or appliance on your network — not a "set it and forget it" install.
If you want a defensible, auditable baseline rather than an ad-hoc set of preferences, NIST SP 800-53's PE-3 control is the right anchor point. It requires organizations to verify individual access authorizations before granting facility entry and to control ingress and egress at defined entry and exit points — which sounds obvious until you check whether your system actually enforces individual verification or just checks "is this a valid badge" without tying it to a specific authorized person and schedule. NIST also maintains a dedicated Electronic Physical Access Control System (ePACS) overlay, published in 2021, as government-wide guidance for combining physical and identity-based access controls. You don't have to be a federal facility to use it — it's a solid checklist for any organization that wants its access control policy to be more than a vendor default configuration.
Pick one door in your facility right now — ideally the one nobody's touched since install — and run this checklist against it. If it fails more than two items, that's not a future project. That's this week's.
Featured image source: csrc.nist.gov
Your email address will not be published. Required fields are marked *
Cookie preferences