OSDP v2.2: The Protocol Enabling Identity at the Door Edge
For decades, access control readers communicated with panels using Wiegand — a protocol designed in the 1970s that sends credential data as unencrypted electrical pulses over a pair of wires. Wiegand has no encryption, no authentication, no bidirectional communication, and no way to send anything more complex than a credential number.
OSDP (Open Supervised Device Protocol) v2.2, published by the Security Industry Association (SIA), replaced Wiegand with a modern, encrypted, bidirectional protocol. Most security professionals know OSDP as “the secure alternative to Wiegand.” What’s less appreciated is that OSDP v2.2 is the protocol that makes identity-based access control architecturally possible.
Why Wiegand can’t support identity verification
Identity-based access control requires the reader to do more than read a credential number. The reader must establish an NFC session with the employee’s phone, request specific identity attributes (name, date of birth, photo — via selective disclosure), verify the digital ID’s cryptographic signature, and transmit the verified attributes to the panel for credential derivation.
This workflow generates more data than a credential number, requires bidirectional communication (the reader sends a request to the phone and receives a response), and must be encrypted in transit (identity attributes are PII).
Wiegand can’t do any of this. It’s unidirectional (reader → panel only), unencrypted, and limited to sending a fixed-length credential number. The protocol was designed for proximity cards that contain a single number — not for digital identity credentials that contain structured, signed, attribute sets.
What OSDP v2.2 enables
OSDP v2.2 provides four capabilities that identity-based access requires:
Bidirectional communication. The panel can send commands to the reader (activate NFC session, request specific attributes) and the reader can send data to the panel (verified identity attributes, session metadata). This enables the panel to orchestrate the reader’s behavior — a critical capability for the Controller Derivation architecture where the panel, not the reader, makes access decisions.
Secure Channel Session (SCS). OSDP v2.2’s SCS provides AES-128 encryption for all data transmitted between reader and panel. Identity attributes (name, date of birth, document number) are encrypted in transit over the RS-485 bus. An attacker who taps the wire sees encrypted data, not PII.
Custom commands. OSDP v2.2 supports manufacturer-defined custom commands — enabling the Reader Library to transmit verified identity data in a structured format that the Panel Application can parse and process. The custom command carries the verified attributes and a session nonce; the Panel Application validates the nonce and derives the site-specific UUID.
Supervised communication. OSDP monitors the communication channel between reader and panel. If the reader is disconnected, tampered with, or replaced, the panel detects the event and can raise an alarm. This tamper detection is essential when the reader handles identity verification — you need to know if the reader has been compromised.
The RS-485 advantage
OSDP v2.2 runs over RS-485 — the same physical wiring that many existing reader installations already use. For buildings upgrading from Wiegand to OSDP, the wire upgrade is straightforward (RS-485 requires 2 wires for data, same as Wiegand’s 2 data lines, plus optional shield). For buildings already running OSDP-capable readers, the Reader Library firmware can be deployed via OTA update through the Panel Application — no physical reader change needed.
This is why the KeyShare physical access deployment can be software-only for buildings with OSDP-capable NFC readers: the wiring exists, the protocol exists, and the Reader Library firmware adds the identity verification capability.
The reader-as-verifier model
OSDP v2.2 enables a specific architectural pattern: the reader verifies identity, but the panel makes access decisions.
The Reader Library firmware handles the ISO 18013-5 NFC protocol stack — session establishment, selective disclosure request, and cryptographic signature verification. But the reader doesn’t decide whether to open the door. It sends the verification result to the Panel Application over OSDP (encrypted via SCS). The Panel Application derives the UUID, checks the manifest, and passes a standard credential number to the PACS.
This is the “thin reader” architecture: the reader is a verifier, not a decision-maker. It processes identity data in transient memory and discards it after each transaction. Zero PII at the reader edge. The intelligence — and the access decision — lives on the panel, where it’s physically secured in an IDF closet rather than exposed at the door frame.
