Why Your Physical Access Control System Is Probably Insecure by Default

TLDR: The Open Supervised Device Protocol (OSDP) is often marketed as a secure alternative to legacy Wiegand systems, but it frequently fails to enforce encryption in real-world deployments. Researchers demonstrated that attackers can perform replay and downgrade attacks by exploiting insecure "install modes" and hardcoded default keys. If you are auditing physical security, do not assume a system is secure just because it claims to support OSDP.

Physical security assessments often feel like a relic of the past compared to modern web application testing. We spend our days hunting for complex logic flaws in APIs, yet we walk past badge readers that are essentially glorified serial ports. The industry has been pushing for a transition from the ancient, unencrypted Wiegand protocol to the Open Supervised Device Protocol (OSDP), promising that it brings modern cryptographic standards to the door.

Research presented at Black Hat 2023 by Dan Petro and David Vargas reveals that this transition is largely a mirage. The protocol itself is capable of security, but the implementations are riddled with the same configuration and logic failures we see in software development.

The Illusion of Secure Channels

OSDP is built on top of RS-485, a multi-drop serial protocol. In a standard setup, a controller communicates with multiple readers on a single bus. Because it is a broadcast medium, every device on the bus sees every message. The protocol includes an extension called OSDP-SC (Secure Channel) that provides AES-128 encryption.

The fundamental problem is that OSDP supports encryption but does not mandate it. During the initial handshake, the controller asks the reader for its capabilities. If the reader is misconfigured or if the controller is set to prioritize compatibility over security, the system will happily fall back to plaintext communication.

Even when Secure Channel is enabled, the implementation often falls short. The researchers highlighted that OSDP-SC uses Cipher Block Chaining (CBC) mode, which is prone to specific cryptographic attacks if not handled correctly. More importantly, the protocol designers decided to truncate the Message Authentication Code (MAC) to just four bytes to save bandwidth. This is a catastrophic decision for a security protocol. It makes brute-forcing the MAC trivial, effectively rendering the integrity checks useless against a motivated attacker.

The Danger of Install Mode

Perhaps the most egregious failure is the existence of "install mode." This is a feature designed to simplify the initial pairing of a reader and a controller. In this mode, the devices exchange keys to establish a secure channel. The issue is that many controllers leave this mode enabled indefinitely, or they use a hardcoded, default key for the initial exchange.

The researchers demonstrated that an attacker can simply show up on the RS-485 bus, identify as a new reader, and request the encryption key from the controller. If the controller is in install mode, it will hand over the key without hesitation. This is the physical equivalent of leaving an SSH private key in a public S3 bucket.

For a pentester, this changes the engagement entirely. You no longer need to worry about complex signal analysis or high-end RFID cloning tools. If you can gain physical access to the wiring—often by simply unscrewing a reader from the wall—you can insert a small, custom device like the one the researchers built to sniff the bus. Once you have the key, you can decrypt the traffic, capture badge numbers, or even inject commands to unlock the door.

Why Best Practices Fail

Defenders often point to OWASP A05:2021 – Security Misconfiguration as the reason for these failures, but that is only half the story. The real issue is that the "secure" configuration is often hidden behind complex, vendor-specific interfaces that are rarely documented well. When a reader fails to communicate, the first thing an IT technician does is disable encryption to see if the connection stabilizes. Once the door is working, they rarely go back to re-enable the security features.

If you are performing a physical security audit, do not just check if the system uses OSDP. You need to verify that:

1. Secure Channel is actually enforced, not just supported.
2. Install mode is disabled on all controllers.
3. The system is not using default, hardcoded keys for key exchange.

The reality is that most of these systems are deployed by people who prioritize uptime over security. As researchers, our job is to expose the gap between the marketing brochure and the actual implementation. If you find a system that claims to be "unhackable" because it uses AES-128, treat that as a red flag. It is almost certainly a sign that the vendor has not considered the actual threat model of a physical, serial-based attack.

Stop trusting the "it's encrypted" label. Start looking at the bus. The wires are where the truth lives, and in the case of OSDP, the truth is usually that the encryption is either missing, truncated, or easily bypassed.