Wiegand to OSDP

Migrating from Wiegand to OSDP

Wiegand puts credential bits on two unauthenticated wires that anyone who can unscrew a reader can read and replay. OSDP replaces that with an addressed, supervised, AES-128-encrypted RS-485 link. This is a working guide to making that change on a real site — what actually differs on the wire, what the migration fixes, what it does not fix, and the deployment mistakes that leave a nominally OSDP door no safer than the Wiegand one it replaced.

1996SIA AC-01 fixes the 26-bit Wiegand interface — no encryption, no addressing
2015BLEKey and ESPKey make Wiegand replay an off-the-shelf purchase
2020OSDP becomes an international standard, IEC 60839-11-5
v2.2.2Current SIA OSDP revision, published October 2024
What Wiegand is on the wireWhy it stopped being defensibleWhat OSDP puts in its placeSecure Channel is not automaticReusing existing cableThe staged pathAcceptance evidence
The incumbent

What Wiegand actually is on the wire

Wiegand is not a protocol in any modern sense. It is a signalling convention — two open-collector data lines, no framing, no addressing, no integrity check, and no way for the panel to say anything back. Understanding exactly how little is on those wires is what makes the rest of a migration plan obvious.

10110DATA 1DATA 0idle highidle high20–100 µs200 µs – 20 ms

scroll to see the full read →

A Wiegand read, as the panel sees it. Both lines idle high; every bit is one low-going pulse on D1 (a 1) or D0 (a 0), and the two never overlap. Pulse and interval bounds are those set by SIA AC-01-1996.10.

The payload

Twenty-six bits, eight of them a site code

The one format everybody agrees on carries a facility code and a card number between two parity bits. Longer proprietary formats exist by the dozen, but nothing in Wiegand identifies which one is on the wire — the panel has to be told out of band.

1 bitEven parityover bits 2–13
8 bitsFacility code0–255
16 bitsCard number0–65,535
1 bitOdd parityover bits 14–25

The standard 26-bit format: 256 facility codes × 65,536 card numbers. Card vendors never policed uniqueness across that space, so duplicate facility-code-and-number pairs are in circulation — a fact that quietly undermines the assumption that a card number identifies one person.

Consequences

What is missing, and what each omission costs

No authentication or freshness

Nothing in a Wiegand frame proves where it came from or that it is new. A bitstream captured on Monday is indistinguishable from a card presented on Tuesday, so a recording is a working credential.

No reply channel

The reader can only push bits. The panel cannot ask a reader what it is, whether it has been opened, what firmware it runs, or whether it is still there — LEDs and buzzers are driven by extra dedicated wires, not messages.

No supervision

An idle Wiegand line and a cut Wiegand line look the same. A reader can be removed, shimmed, or fitted with an implant and the head end learns nothing until somebody tries to badge in and complains.

No addressing, one home run each

Because frames carry no address, each reader needs its own cable back to the panel — typically six to eight conductors for data, power, LED, buzzer, and tamper, with a practical limit around 150 m (500 ft).

No integrity check

Two parity bits over a 26-bit frame is the whole of it. There is no CRC, no length field, and no framing, so induced noise on a long run can present as a different, valid-looking card number.

No interoperable feature set

Anything beyond "here are some bits" — keypads, displays, biometric templates, firmware updates — is vendor-specific. Wiegand gives an integrator no common vocabulary to build on.

Why the industry moved

The attacks that ended the argument

Wiegand's weaknesses were theoretical for decades because exploiting them took a motivated specialist. That changed in 2015, when two research projects turned reader-side interception into a small board you buy, install in a minute, and query from a phone. The relevant detail is where those wires are: on the unsecured side of the door, behind a reader held on by two screws.

BLEKey

Black Hat USA 2015 · Baseggio & Evenchick

A coin-sized board that taps D0 and D1 inside the reader housing and bridges them to Bluetooth Low Energy. The researchers reported an install time of about a minute and estimated the technique applied to roughly 80% of the deployments they surveyed.

It demonstrated both halves of the problem: capture a credential as it is presented, and later replay it on demand with no card present at all.

ESPKey

Implantable Wiegand logic analyser · sold commercially

The same idea productised: an implant that logs tens of thousands of credential bitstreams to non-volatile memory and serves them over its own Wi-Fi interface, so an operator can browse captured credentials and replay any of them from a web page.

It is stocked by red-team suppliers today. Wiegand interception is no longer a research result; it is a line item.

The part supervision would have caught

The reason this works quietly

Both attacks require opening a reader and sitting on its data lines. On a supervised, addressed bus that is a detectable event — the head end notices a device that stopped answering, a tamper that tripped, or a session that failed to authenticate.

On Wiegand there is nothing to notice. The implant is invisible precisely because the protocol has no concept of a device being present.

What OSDP Secure Channel actually closes

With Secure Channel established, a tap in the same physical position records AES-128 ciphertext inside a MAC-chained session. Replaying a recorded frame fails because the message authentication is bound to session keys derived from fresh nonces on both sides — yesterday's capture does not authenticate in today's session. The implant is still physically possible; what it yields stops being a credential.

The replacement

What OSDP puts in its place

OSDP is a polled, addressed, half-duplex protocol on a single RS-485 pair. The access control unit (ACU, or CP in the specification's language) owns the bus and speaks first; each peripheral device (PD) answers only when its own address is called. Everything Wiegand needed a separate conductor for — LED, buzzer, tamper, text — becomes a message.

Physical layer
Half-duplex RS-485, one twisted pair plus signal ground, 8-N-1
Baud rates
9600 / 19200 / 38400 / 57600 / 115200 / 230400
Addressing
0x00–0x7E per PD, 0x7F broadcast — up to 126 devices on one bus
Access model
ACU polls; a PD transmits only in reply to a message addressed to it
Reply window
PD must answer within 200 ms; a healthy device replies in under 3 ms
Framing
Addressed packets with a sequence number and CRC, plus a ~20 ms inter-character timeout for resynchronisation
Encryption
AES-128 Secure Channel, per-device base key (SCBK), session keys re-derived per handshake
Standard
IEC 60839-11-5:2020; SIA OSDP v2.2.2 (October 2024) is the current revision
Beyond the credential

What the bidirectional link buys you

The security case for OSDP gets most of the attention, but the operational case is what changes day-to-day work — and it is the part that survives a budget conversation.

Device identity and capabilities

A PD reports its vendor, model, serial, firmware version, and a machine-readable capability list. The ACU knows what each device can do instead of relying on a spreadsheet from commissioning day.

Continuous supervision

Polling is the supervision. A device that stops answering, a bus that stops responding, or a tamper switch that trips is an event at the head end within one poll cycle.

Firmware update over the bus

OSDP v2.2 formalised file transfer, so a reader's firmware can be pushed down the same pair that carries card reads — no site visit per device, no vendor dongle.

Smart cards, PIV, and biometrics

The standard defines four profiles — Basic, Secure, Smartcard, and Biometric. Transparent Mode carries APDUs to a contactless card, which is what makes real PIV and DESFire authentication possible at the reader.

Feedback that is actually specified

LED colour and flash pattern, buzzer cadence, and display text are commands with defined semantics, so a third-party reader gives correct feedback without per-vendor wiring conventions.

One bus, many devices

Readers, keypads, biometric units, and I/O modules multidrop onto one pair, so a cabinet full of home runs becomes a single terminated segment — fewer controller ports, less cable, and less conduit per door.

Recent development

Transparent Mode is now open to the whole industry

Transparent Mode — the mechanism that tunnels card-specific APDUs through an OSDP session, and therefore the route to genuine smart-card and PIV authentication at the reader — sat under patents that made implementers cautious. In March 2026 SIA confirmed that HID's patents covering Transparent Mode as defined in the OSDP specification will not restrict implementation in OSDP-compliant products.

If a smart-card migration was deferred on licensing grounds, that objection is gone. It is worth revisiting before you finalise a reader specification.

Side by side

The differences that change a design

Not the marketing comparison — the rows that actually alter cable schedules, panel selection, latency budgets, and commissioning paperwork.

PropertyWiegandSIA AC-01, 1996OSDPIEC 60839-11-5, 2020
SignallingTwo open-collector lines, pulse per bit, no clockHalf-duplex RS-485 differential pair, 8-N-1 asynchronous
DirectionReader to panel onlyPolled command and reply, both directions
Cabling per deviceDedicated home run, typically 6–8 conductorsMultidrop onto a shared pair; feedback moves into messages
Devices per runOneUp to 126 addressable PDs (fewer in practice, for latency)
Practical distance~150 m (500 ft)Up to ~1,200 m on suitable cable, traded against baud rate
Error detectionTwo parity bits over 26 bitsCRC per packet, sequence numbers, retry and resync rules
ConfidentialityNone — credential bits in the clearAES-128 Secure Channel, per-device SCBK, per-session keys
Message authenticationNone — a recording is a valid credentialMAC-chained session; replayed frames fail authentication
SupervisionA cut line is indistinguishable from an idle lineMissed poll replies and tamper events surface at the head end
Latency profileImmediate on card read; nothing else measurableBounded by poll cycle — a design input, not an accident
Device managementNone — identity and firmware live in a spreadsheetIdentity, capability report, and file transfer for firmware
Credential handlingRaw bits; format known only out of bandStructured card data, plus APDU tunnelling for PIV and smart cards
Conformance testingNothing to test against beyond pulse timingPublished specification and the SIA OSDP Verified programme
scroll to compare →
The part most migrations get wrong

"OSDP" on a datasheet is not encryption on your bus

This is the single most important section on this page. OSDP supports Secure Channel; it does not force it. Bishop Fox's Badge of Shame research, presented at Black Hat USA 2023 and covered by Ars Technica, walked through five ways a real OSDP installation ends up no better protected than the Wiegand it replaced — and released mellon, a tool that exercises them. Not one of them is a flaw in the cryptography — each is a deployment or procurement decision. Below, each weakness is stated first, then the fix it calls for, then whether a protocol implementation can close it for you.

Weakness01

Encryption is optional in the standard

A device can be entirely OSDP-compliant and never negotiate Secure Channel. "OSDP support" on a datasheet tells you the framing is right; it says nothing about whether encryption is implemented, enabled, or on by default in the configuration you were shipped.

The fix

Require Secure Channel support stated explicitly, and verify it on the bus before you accept the device — not from the datasheet.

Closed by LibOSDP’s ENFORCE_SECURE

Weakness02

The capability exchange invites a downgrade

Before a session is secured, the ACU asks the PD what it supports, in the clear. A controller that accepts "I do not support Secure Channel" can be talked out of encryption by anything sitting on the pair during that exchange — the attack needs no key, only the ability to answer first.

The fix

Configure controllers to refuse any PD that will not run an encrypted channel. No unencrypted fallback, no "try secure, then plain".

Closed by LibOSDP’s ENFORCE_SECURE

Weakness03

Install mode left on hands out the key

Install mode exists so a new PD can be given its SCBK using the specification's default key, SCBK-D. It is meant to last minutes. In the field, controllers are routinely left in install mode indefinitely — at which point anyone on the bus can simply ask for the base key, and the encryption is decorative.

The fix

Disable install mode before a door goes live, and prove it: attempt a keyset on the commissioned bus and confirm it is refused.

Closed by LibOSDP’s ENFORCE_SECURE

Weakness04

Keys copied out of sample code

SCBK-D is published, and vendor sample code is full of placeholder keys with repeated or sequential bytes. Those placeholders reach production. A key that survives from a getting-started guide is not a secret, and one shared SCBK across a site means one compromised reader exposes every door.

The fix

Generate a unique, random SCBK per device from a real entropy source, and record it in an escrow you can audit and rotate.

Closed by your key-generation process

Weakness05

The standard has no key exchange

OSDP never defined a secure way to get a key onto a device. Whatever you do, the SCBK crosses the wire at some point. If that happens while the device is mounted on a populated, live bus, a listener installed earlier — or a reader replacement carried out under a work order — captures it.

The fix

Key devices over an isolated point-to-point link, off the production bus, and investigate tamper alerts on existing readers before any keying visit.

Closed by dedicated provisioner hardware

The library side

LibOSDP has enforced this since 2020

Three of those five findings are not things an installer should have to remember, because a protocol implementation can simply refuse to do the unsafe thing. LibOSDP's ENFORCE_SECURE flag has done exactly that since v1.3.0 in September 2020 — nearly three years before the research was presented. A control panel or peripheral device built with the flag set will not run without Secure Channel, will not allow Secure Channel to be turned off, and will not accept SCBK-D or install mode at all. When it blocks something, it says so: a … due to ENFORCE_SECURE line in the log.

Bishop Fox's researchers confirmed this in the Ars Technica coverage: the flag prevents the three attacks that rely on a device not supporting Secure Channel, allowing it to be disabled, or remaining in install mode — weaknesses 01, 02, and 03 above.

It does not close the other two, and we would rather say so plainly than imply the problem is solved in software. Key quality (04) is your provisioning process, not the library's: ENFORCE_SECURE will happily protect a session keyed with a weak SCBK you chose. And the researchers singled out the fifth as the one they considered most serious — recovering the SCBK while a new reader is being brought online. No library flag can prevent that, because the exposure is physical: the key has to cross a wire somebody may already be listening to. Closing it takes dedicated provisioning hardware that keys each device over an isolated point-to-point link instead of the populated bus — which is what phase 03 of the path below describes.

We maintain LibOSDP, so treat this as an interested party's account — and then go and read the original research and the Secure Channel documentation for yourself.

Where our tools fit

Turning those five fixes into checks you can run

Every fix above is verifiable on a bench before it becomes a site problem. That is deliberately what the Osprio toolkit is built to do.

Key it off the live bus

Provisioner Workspace writes a unique SCBK over an isolated one-to-one link, re-handshakes to verify it, then disables install mode — which is how you close weaknesses 04 and 05, the two ENFORCE_SECURE cannot.

Prove the refusals

Conformance Workspace drives the negative cases: a PD claiming no Secure Channel support, a keyset attempt after commissioning, a session replay — so the fixes for weaknesses 01 and 02 become recorded test results.

See what is really on the pair

Capture Workspace listens passively and shows you whether the traffic on a supposedly encrypted bus is actually encrypted, and where a handshake fell back.

Scope

What moving to OSDP does not fix

A Wiegand-to-OSDP project secures the link between the reader and the panel. It does nothing to the link between the card and the reader — and on most sites that is the weaker of the two.

Cloneable credentials stay cloneable

A 125 kHz proximity card presents a fixed number with no authentication. Copying one takes a cheap handheld and a moment of proximity to the holder. OSDP will carry that cloned number to the panel with perfect confidentiality and integrity — it is a genuine credential as far as the bus is concerned.

Secure Channel protects the wire, not the card. If your threat model includes someone standing near an employee in a lift, the credential is the thing to change.

26-bit numbering does not become unique

Eight bits of facility code and sixteen of card number is a small space that was never centrally administered, so duplicate pairs exist in the wild. Migrating the bus preserves whatever numbering you already have, duplicates included.

A reader-and-panel upgrade is the natural moment to move to a credential with real cryptographic authentication — DESFire EV2/EV3, SEOS, or mobile — because Transparent Mode gives the reader somewhere to do that authentication.

Physical access to the reader still matters

OSDP makes tampering detectable; it does not make it impossible. The value of a tamper event is entirely in whether somebody responds to it, so the migration only pays off if tamper and comms-loss alarms are routed somewhere a human acts on them.

Commission the alarm path with the same seriousness as the card read. An unmonitored tamper input is a checkbox, not a control.

None of this argues against the migration — it argues for sequencing it honestly. The bus and the credential are separable projects with separate budgets, and doing the bus first is defensible. Just do not let "we moved to OSDP" be recorded as "cloning is solved".

The first question on every site

Can you run OSDP on the cable already in the wall?

Often, yes — and that is what makes the migration affordable. But "often" is doing real work in that sentence, because Wiegand cable was never specified for a differential transmission line. Where the answer is no, multidrop still works in your favour: the cable you pull to replace it is a fraction of what Wiegand needed.

What RS-485 wants

A twisted pair with roughly 120 Ω characteristic impedance, plus a signal ground reference, terminated at the two physical ends of the segment and nowhere in between. Wiegand cable is typically multiconductor with untwisted, uncontrolled-impedance pairs — electrically a compromise, not a match.

What the field evidence says

Genetec's published signal-integrity testing ran OSDP at 115,200 baud over 500 ft of exactly that untwisted, uncontrolled-impedance cable — and it worked, once 120 Ω terminations were fitted at both ends. Any run over about 10 m needs them. Where errors persist, drop the baud rate: distance and speed trade against each other.

Conductors you get back

LED, buzzer, and tamper stop being conductors and become messages, which frees pairs in an existing home run. That is often where the spare pair for A/B data comes from without pulling new cable.

If you are pulling new cable anyway

Where reuse is not an option — star-wired plant, failed runs, a new build — multidrop is a saving rather than a cost. Wiegand priced a cable schedule per door; OSDP prices it per segment. Fewer panel ports, less conduit fill, and two terminations per bus instead of a landing at every door.

Power does not come free

Every saving above is on the data wiring. OSDP carries no power, so supply conductors still have to hold voltage at the far end — and multidropping concentrates current that used to be spread across separate cables. Recalculate volt drop for the new topology; do not inherit it.

Topology discipline

RS-485 wants a daisy chain, not a star and not a T-tap off the middle of a run. Star-wired Wiegand plant is the case where reuse most often fails, and it is better to discover that during a survey than during commissioning.

Deployment path

Migrate one controlled segment at a time

A Wiegand-to-OSDP migration is not a cutover. The management layer stays where it is while each controller, RS-485 segment, and group of readers is converted and validated before the next area is touched — so the failure blast radius is one bus, on a day you chose.

Phase 01

Survey and inventory

You cannot plan the electrical work from a door schedule. Walk the plant and record what is physically there, because the answers determine whether a door is a cable-reuse job or a re-pull.

  • Cable type, conductor count, twisting, shield, and measured run length per reader
  • Topology — is it a home run per reader, a daisy chain, or a star with T-taps?
  • Panel side: does the existing ACU speak OSDP at all, on which ports, at which baud rates?
  • Credential formats in circulation, including the proprietary ones nobody documented
  • Field-powered devices and the volt-drop headroom on each supply run
Output A per-door classification: reuse as-is, reuse with termination, or re-pull.
Phase 02

Bench the combination first

Buy one of each device and put the exact ACU-and-PD pairing on a bench before it reaches a live door. Interoperability failures between two nominally compliant OSDP devices are common, and they are far cheaper to find at a desk than up a ladder.

Where one side does not exist yet, emulate it — stand in as the ACU to qualify a reader, or as a PD to qualify a controller — and confirm the capability report, the Secure Channel handshake, and the behaviour when the handshake is refused.

Output A validated device profile: baud rate, capability expectations, Secure Channel policy, known quirks.
Phase 03

Provision keys and identities off the bus

Give each PD its address, baud rate, and unique SCBK on an isolated link — a staging bench or a one-to-one connection at the door — never on a populated segment, because the standard gives you no protected way to move a key across a shared bus.

Then disable install mode and record the key into escrow. A migration that reaches this phase without a key-custody decision already made will default to one shared key, which is the outcome you are trying to avoid.

Output Per-device SCBK escrow, install mode off, address and baud plan committed.
Phase 04

Pilot one representative bus

Pick a segment that represents the worst of the site, not the best — longest run, most devices, oldest cable. Convert it, terminate the two physical ends, and capture the traffic through commissioning so you have a reference recording of a bus that works.

Load it up to its intended device count and measure the poll cycle. Door response is bounded by that cycle, and a bus that feels instant with two readers can feel sluggish with twelve.

Output A commissioned reference segment, a baseline capture, and a measured latency figure.
Phase 05

Roll out against the proven profile

Every subsequent segment repeats the pilot's profile and acceptance checks rather than re-deriving them. Deviations get escalated rather than field-fixed, because a one-off workaround at door 40 is the thing nobody will remember at handover.

Archive the capture and the acceptance record per segment. That archive is what lets you answer "was this door ever running unencrypted?" two years later.

Output Per-segment evidence pack: configuration, capture, acceptance results, firmware versions.
Transitional hardware

Bridging options, and what each one actually costs you

Very few sites replace every reader and every panel in one purchase order, so the market sells three kinds of bridge. All three are legitimate. All three keep some Wiegand in the system, and it is worth being precise about where.

Dual-mode readers

A reader that speaks either protocol and picks one at power-up: if an OSDP poll arrives first it comes up as a PD; if a card is presented first it falls back to Wiegand. Excellent for phased work, because the same reader stock serves converted and unconverted doors.

Buys you One reader SKU across the whole migration; the door works before the panel is converted.
Costs you The auto-select behaviour is a downgrade path. Pin the mode explicitly once a door is converted, and confirm the reader will not fall back.

Wiegand-to-OSDP converters

A module that takes one or more legacy Wiegand readers and presents them to the panel as OSDP PDs on an RS-485 bus. This is the panel-side consolidation play: you get multidrop, addressing, and supervision from the converter inwards.

Buys you Existing readers keep working; the long cable run to the panel becomes supervised and encrypted.
Costs you The Wiegand tail between reader and converter is unchanged — still sniffable, still replayable. Mount the converter so that tail is as short and as protected as possible.

OSDP-to-Wiegand translators

The mirror image, for sites where new OSDP readers go in before the panel can be replaced: the translator runs OSDP out to the reader and hands Wiegand to the legacy panel input.

Buys you Reader-side security and supervision now, with the panel replacement deferred to its own budget cycle.
Costs you A short unsupervised Wiegand hop survives at the panel. Acceptable only if it lives entirely inside the secure enclosure.

The rule that keeps all three honest: write down where Wiegand still exists. A migration plan that cannot name its remaining Wiegand segments has not finished, and the segment everyone forgets is the one behind a converter on the unsecured side of a door.

Acceptance

What "this door is migrated" should mean

Sign-off criteria that are observable on the bus rather than asserted in a datasheet. Each of these is a thing somebody can demonstrate to somebody else.

Electrical

  • Termination present at exactly the two physical ends of the segment
  • No T-taps or star legs left in the topology
  • Volt drop measured at the furthest device under load, not calculated from the old design
  • Shield and signal ground referenced once, per the cable plan

Protocol

  • Unique address per PD, recorded against the physical door
  • Chosen baud rate documented, and the same across the segment
  • Capability report captured and matched against what the ACU expects
  • Poll cycle measured with the segment at its full intended device count

Security

  • Secure Channel established, verified from a passive capture rather than a status LED
  • A controller that refuses a PD advertising no Secure Channel support
  • Install mode disabled — demonstrated by a keyset attempt that fails
  • Unique SCBK per device, in escrow, with a rotation procedure that has been rehearsed

Operational

  • Cut-line and device-offline events observed arriving at the head end
  • Tamper event observed, and the alarm path to a responding human confirmed
  • Recovery after power loss and after bus disconnection verified
  • Firmware versions, configuration, and commissioning capture archived per segment
Capture a commissioning baseline →Discuss an OSDP migration →
FAQ

We get these questions a lot

Can I reuse my existing Wiegand cable for OSDP?

Often, but not always. RS-485 wants a twisted pair with roughly 120 Ω characteristic impedance, while Wiegand cable is usually multiconductor with untwisted, uncontrolled-impedance pairs. Genetec's published signal-integrity testing ran OSDP at 115,200 baud over 500 ft of exactly that kind of legacy cable once 120 Ω terminations were fitted at both physical ends, and their guidance is that any run over about 10 m needs them. If a segment still shows errors, lower the baud rate, correct the termination, or both. The cases that usually fail are star-wired plant and runs with T-taps, because RS-485 wants a daisy chain.

Is OSDP backwards compatible with Wiegand?

No — they are electrically and logically different. Wiegand is two open-collector data lines with no addressing or reply path; OSDP is a polled, addressed protocol on a half-duplex RS-485 pair. Compatibility comes from bridging hardware instead: dual-mode readers that speak either protocol, Wiegand-to-OSDP converters that present legacy readers to the panel as OSDP peripherals, and OSDP-to-Wiegand translators for panels that cannot yet speak OSDP. Each keeps a Wiegand segment somewhere in the system, so the migration plan should name exactly where that segment is.

Do I have to replace the access control panel as well as the readers?

Not necessarily in the same phase. If the existing ACU has no OSDP port, an OSDP-to-Wiegand translator lets new OSDP readers go in now and secures the long cable run out to the door, leaving a short unsupervised Wiegand hop inside the panel enclosure until the controller is replaced. That is a reasonable interim state as long as the remaining hop stays entirely within the secure enclosure and is recorded as outstanding work.

Does moving to OSDP stop card cloning?

No. OSDP Secure Channel protects the link between the reader and the panel, not the link between the card and the reader. A 125 kHz proximity card presents a fixed number with no authentication and is trivially cloned; OSDP will then carry that cloned number to the panel with full confidentiality and integrity, because as far as the bus is concerned it is a genuine credential. Stopping cloning is a credential project — DESFire EV2/EV3, SEOS, or mobile — and OSDP Transparent Mode is what gives the reader somewhere to perform that authentication.

If a reader says "OSDP" on the datasheet, is the bus encrypted?

Not necessarily. OSDP supports Secure Channel but does not require it, so a device can be fully compliant and never negotiate encryption. Worse, the capability exchange that precedes a secure session happens in the clear, so a controller willing to accept "I do not support Secure Channel" can be downgraded by anything sitting on the pair. Configure controllers to refuse peripherals that will not run an encrypted channel, and verify it from a passive bus capture rather than from a status LED.

How many readers should I put on one OSDP bus?

The protocol addresses up to 126 peripheral devices per bus (addresses 0x00–0x7E, with 0x7F reserved for broadcast), but that is an addressing limit, not a design target. Because the controller polls each device in turn, door response time is bounded by the poll cycle, and electrical loading grows with every device. In practice segments are split across several channels and the baud rate is raised above the 9600 default. Measure the poll cycle on a pilot segment loaded to its full intended device count before you commit the design.

Do the published OSDP attacks mean OSDP is not worth migrating to?

No. Bishop Fox's Badge of Shame research (Black Hat USA 2023) found five ways a real OSDP deployment ends up unprotected, and every one is a configuration or provisioning decision rather than a break in the cryptography. LibOSDP's ENFORCE_SECURE flag, shipped in v1.3.0 in September 2020 — nearly three years before the talk — already refuses to run without Secure Channel, refuses to let it be disabled, and refuses SCBK-D and install mode entirely. The researchers confirmed it prevents three of their five attacks. The remaining two are key quality, which is your provisioning process, and SCBK recovery while a reader is being onboarded, which no library flag can prevent because the key has to cross a physical wire — provision devices off the production bus instead. A correctly deployed OSDP bus is enormously better than Wiegand; an OSDP bus nobody configured may not be.

Why does install mode matter so much during migration?

Install mode exists so a new peripheral can be given its Secure Channel Base Key (SCBK) using the specification's published default key, SCBK-D. It is meant to be open for minutes. Controllers left in install mode indefinitely — a common field finding — let anyone on the bus simply ask for the base key, which makes the encryption decorative. Provision each device with a unique, randomly generated SCBK over an isolated point-to-point link, disable install mode before the door goes live, and prove it by attempting a keyset on the commissioned bus and confirming it is refused.

Have a question? Ask us →

Sources & further reading

Check any of this against the primary sources

The specifications, research, and field test data this page is built on. Where a figure belongs to a researcher or a vendor rather than to us, the entry says whose it is.