OSDP reader and controller protocol

OSDP connects readers and other peripheral devices to a controller. Check Secure Channel support, key setup, supervision and recovery on both ends of the connection.

Overview#

The Open Supervised Device Protocol (OSDP) connects an Access Control Unit (ACU) to Peripheral Devices (PDs), such as readers, keypads, supervised I/O, and biometric devices. It is bidirectional, supports supervised communications and remote device functions, and defines Secure Channel for authenticated encrypted communication. SIA OSDP

Current revision and conformance#

SIA released OSDP 2.2.2 in October 2024. The international base IEC 60839-11-5:2020, edition 1.0, specifies OSDP commands and replies for electronic access control and has an IEC stability date of 2029. SIA's newer revision and its certification profiles are the source to use for current SIA product work. SIA OSDP IEC OSDP

“Supports OSDP” isn't the same as SIA OSDP Verified. Record:

• ACU or PD role;
• product and exact firmware/hardware version;
• OSDP version/profile and supported capabilities;
• Secure Channel support and production enforcement;
• multi drop, file transfer, smart card/biometric, and other required features;
• entry in SIA's Verified products register.

SIA describes OSDP Verified as third party conformance/interoperability testing. Verification is product, role, version, and feature specific. OSDP VERIFIED

Topology and roles#

                 two-wire, half-duplex RS-485 data pair
ACU / control panel ============================================
        | address A: reader/PD
        | address B: reader + keypad/PD
        ` address C: supervised I/O/PD

The ACU controls the poll/command sequence; a PD replies when addressed. This makes timeout, retry, address ownership, and fair polling explicit. OSDP commonly uses a multi drop RS485 bus, but electrical design, cable, topology, termination, bias, grounding, surge protection, power, distance, and baud rate, must follow the device and site engineering requirements.

The protocol uses a 7 bit address space; 0x7F is the special broadcast address, leaving addresses 0x00 through 0x7E for individual PDs. Don't use broadcast for security sensitive production commands unless the applicable standard/profile explicitly requires it and the risk is understood. LIBOSDP API

Frame and exchange model#

At a high level an OSDP frame contains:

start marker | address/direction | length | control | optional security block
             | command or reply data | checksum or CRC

The control field carries sequence/check/security indications. The start marker on the wire is 0x53. Exact bit/byte rules, maximum sizes, command payloads, timing, and retry behaviour are normative in the licensed current standard; don't implement from this summary alone.

Common command/reply families cover:

• poll, acknowledgment, negative acknowledgment, busy, and communication setup;
• PD identity and capabilities;
• local, input, output, and reader status;
• credential/card data and keypad data;
• LED, buzzer, display/text, and output control;
• smart card/transparent content exchanges;
• file transfer and manufacturer specific extensions;
• Secure Channel establishment and key management.

A PD capability report tells what the device claims to implement. It doesn't authorise the ACU to use a feature or prove the physical installation supports it.

Secure Channel#

OSDP Secure Channel uses AES 128 based mechanisms to authenticate and protect ACU to PD traffic. Production security depends on a unique Secure Channel Base Key (SCBK) per PD, correct establishment, protected key storage, strong randomness, and enforcement after provisioning. SIA says unsecured mode should exist only during initialisation before Secure Channel is configured. SIA CHECKLIST

Provisioning state model#

factory / controlled install state
    -> identify exact device and address
    -> establish controlled communication
    -> provision a unique SCBK through the approved process
    -> verify Secure Channel succeeds
    -> disable install/default-key acceptance
    -> enforce encrypted/authenticated operational traffic
    -> monitor loss, reset, replacement, and key rotation

Don't publish, log, inventory in plaintext, reuse, or copy a default installation key into documentation or configuration examples.

Key management requirements#

• Generate keys with an approved cryptographic random source or managed KDF under a root key/HSM design.
• Keep each PD's key distinct; bind it to device identity, address/bus, site, firmware, and lifecycle record.
• Protect keys at rest and while provisioned; restrict read/export and audit use.
• Define replacement and factory reset behaviour. A replacement device at the same address isn't the same cryptographic peer.
• Define rotation, escrow/recovery if allowed, loss, compromise, and secure destruction.
• Fail closed on unexpected fallback from Secure Channel, while preserving life safety egress and an authorised recovery procedure.
• Monitor repeated authentication failures, address identity changes, CRC/noise bursts, unexpected reset, and capability changes.

ACU implementation model#

Maintain state for each PD on the serial port:

configured -> discovering/identifying -> capability exchange
           -> secure-channel setup -> online/operational
           -> degraded/retrying -> offline/recovering

Per PD state should include address, expected identity, capabilities, sequence, negotiated check mode, secure channel state, outstanding command, retry/deadline, last authenticated response, counters, and firmware/configuration metadata.

Parser rules#

• Accumulate partial serial reads and locate a valid start only under bounded resynchronization rules.
• Validate address, declared length, control bits, security block consistency, sequence, and checksum/CRC before dispatch.
• Enforce the current standard's frame maximum before allocation.
• Authenticate/decrypt before interpreting protected application data.
• Don't deliver duplicate credential/keypad events on a retransmitted reply.
• Rate limit NAK/BUSY/retry loops and avoid letting one PD starve the bus.
• Treat manufacturer specific payloads as separately bounded schemas.
• Zeroize ephemeral key material and never emit keys or plaintext credentials in diagnostics.

Safe offline frame validation shape#

Target: Authorised implementation review, not a wire tool.

Inputs: A frame already supplied by a controlled unit test.

Side effects: None.

validate(frame):
  require minimum_header <= frame.length <= configured_max
  require frame.start_marker == 0x53
  require declared_length == frame.length
  require address_is_expected(frame.address)
  require control_bits_are_consistent(frame.control)
  require checksum_or_crc_is_valid(frame)
  if security_block_present(frame):
      plaintext = authenticate_then_decrypt(frame, peer_session)
      require sequence_is_expected(peer_session, frame)
      dispatch_bounded_reply(plaintext)
  else:
      require peer_is_in_explicit_install_or_allowed_clear_state
      dispatch_bounded_reply(frame.payload)

Real processing order and retransmission rules must follow SIA OSDP 2.2.2.

Bus scheduling and supervision#

• Poll frequently enough to meet status/alarm latency while reserving time for commands and slow devices.
• Use per command deadlines based on standard/device behaviour; file transfer isn't a normal poll latency.
• Mark a PD degraded/offline only under a defined missed response policy.
• Separate communication health from door/reader physical state.
• Measure collision/noise/retry rates and response latency by address.
• After reconnect, reidentify the device and reestablish Secure Channel before accepting credential or keypad data.
• Don't silently continue cleartext because secure establishment failed.

High impact functions#

LED/text/buzzer commands are low physical impact but can deceive users. Output/relay control, firmware/file transfer, configuration, key changes, and address/baud changes can cause denial of access or unsafe operation. Apply separate roles, maintenance windows, signed firmware/provenance checks, rollback, audit, and local safety controls.

Wiring and commissioning#

SIA's 2026 implementation checklist calls for OSDP Verified PDs and ACUs, Secure Channel, suitable two wire RS485 cabling, unique documented addresses, bench staging, and post install performance validation. It also recommends cataloguing address, speed, firmware, location, cable, interface, and keys. Store only a key reference/fingerprint in ordinary documentation, not the secret itself. SIA CHECKLIST

Environment acceptance should cover:

• minimum/maximum supported baud and bus loading;
• every installed PD model/firmware and required feature;
• power up, brownout, cable open/short, termination error, duplicate address, noise, and device replacement;
• Secure Channel success, prohibited fallback, wrong key behaviour, and factory reset/reprovision;
• credential/keypad duplicate suppression under lost reply/retry;
• controller restart, PD restart, long outage, file transfer interruption, and upgrade rollback;
• tamper, status, LED, buzzer, display, input/output, and event latency.

Migration from legacy interfaces#

1. Inventory reader, credential technology/format, panel, wiring, power, door behaviour, and life safety dependencies.
2. Confirm exact OSDP Verified roles/firmware and Secure Channel support.
3. Bench stage reader plus actual ACU with production like bus length/load.
4. Assign and document unique PD addresses and cryptographic identities.
5. Install in phases with rollback and outage communication.
6. Verify that Secure Channel is active and cleartext fallback is blocked.
7. Retire converters/legacy input where possible; a Wiegand bridge preserves the legacy weak link on one side.

Review checklist#

• SIA OSDP 2.2.2 and exact Verified product/firmware/profile recorded
• RS485 topology, cable, termination, bias, grounding, surge, power, and baud engineered
• Unique PD address and expected device identity bound in inventory
• Unique per PD SCBK generated, protected, rotated, and never logged
• Install/default key state disabled after controlled provisioning
• Cleartext operational fallback prohibited
• Per PD sequence, timeout, retry, duplicate, offline, and fairness state bounded
• Parser length/control/check/security validation occurs before dispatch/allocation
• Credential/keypad data, relay/output, file transfer, configuration, and key changes separately authorised/audited
• Acceptance evidence covers physical behaviour, Secure Channel, failure recovery, and safe state handling

Checks for your system#

Purchase and implement against SIA OSDP 2.2.2 and applicable conformance documents. Record OSDP Test Tool results, exact PD/ACU firmware and Verified profiles, bus measurements, key ceremony evidence, Secure Channel establishment and prohibited fallback results, fault recovery, and physical safe state acceptance.

Sources#

• SIA OSDP, Open Supervised Device Protocol, Security Industry Association, revision/status accessed 25 August 2026.
• IEC OSDP, IEC 60839-11-5:2020, IEC, edition 1.0, published 8 July 2020.
• OSDP VERIFIED, SIA OSDP Verified Products, Security Industry Association, accessed 25 August 2026.
• SIA CHECKLIST, Implementing OSDP Access Control? Follow This Simple Checklist, Security Industry Association, 10 February 2026.
• SIA CREDENTIAL GUIDE, Corporate Credential Design Guide, Security Industry Association, March 2026.
• LIBOSDP API, LibOSDP public API and address model, open source implementation documentation, accessed 25 August 2026; informative, not the normative standard.

Section overview · Wiki home