Access control readers and controllers need to communicate. While Wiegand has been the de facto standard for decades, OSDP aims to solve major problems of Wiegand.
In particular, OSDP's benefits:
Bidirectional Communication, Including reader displayed feedback
Standardized biometrics integration with access systems
Handling large amounts Of credential data
OSDP's 'Secure Channel' version supporting data encryption
However, the protocol has several significant issues impacting adoption, including:
Unclear OSDP versions and profile definition
Lack of OSDP conformance checking
Vendors claiming only 'OSDP Support' is not enough
No Official OSDP 'Conformant Products' directory
This report examines those issues and more basic details including:
What OSDP Does
Why OSDP Is Needed
How OSDP is Organized
What OSDP's Profiles Are
Performance and Wiring differences between Wiegand and OSDP
*** ***access ******* ****** **** ** *********** **** ***** ******* on the OSDP profiles that they support, Basic, Secure Channel, Biometric, etc. While this system of communication and trust was not too much of an issue when only a few vendors were offering OSDP solutions we realize that this model will not work for long, and as stated, we will be working to address this.
In fairness to OSDP: I think IPv6 'fixes' a potential issue with IPv4 that can be solved other ways (like bit borrowing in LANs, for example), but OSDP 'fixes' Wiegand problems that cannot be fixed by 'tweaking' Wiegand otherwise.
There is adoption and its on the roadmap in a number of large enterprises. In these cases there is a valid business case for the transition. Not sure there is the same business (cyber and privacy) risk imperative in the broad market. It is also something new to sell and that takes time as well. The OSDP secure channel specification is settling down now from an international standard perspective to where you can assess compatibility and interoperability across a fairly wide feature set. All of these things point to healthy adoption imbo (in my biased opinion ;-).
In my region at least, many new tenders and bids still do not specify OSDP for new greenfiled installations. How is it like in the US and Europe when it comes to new tenders and bids? It would be interesting to know how often OSDP is actually specified.
you know the end users, they don't really have thorough knowledge. I've seen three types of tenders:
1. The first stage tender, when the end user picks the auditor/system designer and this company cannot participate in the second stage, installation.
2. The integrator creates an RFQ/RFP on an end-user behalf, makes it hard or impossible to win by someone else (corruption). Example - you require the integrator to have at least 5 ABCD certified employees, and you know that there are 3 companies in the region that are qualified. You make a deal with those guys, provide the quotes so they just need to submit the numbers and solution you have prepared. You win this bidding, they will win the next one with their customer.
3. The mix of the previous two, when the same owners use their companies to participate in the design and then implement the solution. Again, kickbacks and bribes usually involved.
And it's in any industry when the customer has a lot of money to spend.
PS that was Eastern Europe. Now, in NA, people just like, "we need access control" and the sales guy design something that installers are struggling to implement later. Usually, no professional estimators or pre-sale engineers are involved. Unless it's a 200+ door project.
'Wiegand' is the 'protocol', although I've been corrected that 'protocols' are usually bi-directional where Wiegand is not.
The wire media used for Wiegand is almost always copper/metal conductor, but it isn't necessarily UTP or ethernet based. TCP/IP cabling is a label that generalizes the cabling specific to ethernet.
Wiegand' is the 'protocol', although I've been corrected that 'protocols' are usually bi-directional where Wiegand is not.
is it wrong though to say that a given 125khz card is Wiegand encoded, and that the data read from that card is (at least when first read) in Wiegand format, even when that reader uses OSDP to communicate to the controller?
it seems sometimes Weigand refers to the wiring scheme, but sometimes to the data format, but maybe I’m confused.
TCP/IP cabling is a label that generalizes the cabling specific to ethernet.
In 2019, Wiegand is not a format. It previously also described a contactless card format, but it has not been a 'format' for many years/decades, so in common access use it describes only the data link between reader and controller.
Wiegand is essentially analog; every voltage drop on the line is registered as a 'bit' by the controller, where OSDP essentially is digital with structured, packetized data.
That's a bit of a generalization that ignores how the Wiegand / OSDP signal is modulated and timed, but it helps to visualize the difference along those lines.
Yes. But this is typical, as few controllers are configured as stand-alone devices outside of the management software. So pragmatically, the configuration happens at the controller via the software.
You can configure readers directly using the comset command with OSDP, in addition there are a number of other commands that allow you to test, LEDs, Buzzer, and also to get reader information such as make, model, serial number and firmware independently. There is open source to be able to do this as well as the Eidola product that we provide. There is also the ability to do file transfer and update readers.
Depending on the vendor there is some configuration that can be done independently of the access control system. As Brian points out ii is easier to do for readers than controllers. At IDmachines we have developed tools specifically to fill this gap.
Thanks for this article, IDmachines has partnered with SIA to put on the first of a series of OSDP Bootcamps, 25 June at SIA Headquarters. It is part of an ongoing effort to educate the supply chain to improve conformance and interoperability, critical parts of any standards effort. https://www.securityindustry.org/industry-standards/open-supervised-device-protocol/osdp-boot-camp/ And thanks John, for approving this post.
In the Federal Gov't world, OSDP is becoming mandatory very quickly thanks for HSPD-12 finally being taken seriously and dollars flowing towards making it happen.
I got you now. Meaning if the MR51e fails, and the only options is to replace with a MR62e then you maybe have cascading replacement implications of the other things don't support OSDP.
The problem with replacing the MR51e with the LP1501 is the limitation of inputs. If you originally used the MR51e for (2) door control with a REX and DC on each door, you'll have to install (2) LP1501's since the LP1501 only has two inputs. Also, both the LP1501 and MR62e are either POE or POE+ capable. By using POE+, that increases the 12V output on the board to 1.25A on the LP1501 and 1A on the MR62e which gives you more overall available power for a fully POE solution.
I'm still surprised Mercury didn't give the MR62e Weigand support as now we are stuck with the LP1501 for a POE and Weigand solution. I have seen OSDP to Weigand convertors for sale to mitigate the compatibility issue, just everything I have seen has been cost prohibitive.
Correct but if you're only using POE for the MR51E then you need up add a POE+ injector or replace your switch to use the MR62e if you need full power.
You would have to transition to POE+ to get more power no matter what controller you were using. The MR51e doesn't natively support POE+, so you're stuck with the ~.66A output unless you use a POE+ power extractor to power the MR51e and other door equipment. The MR62e gives you ~.66A on POE and 1A on POE+, so at least the ability to deliver additional power is built in. Just sucks you also have to look at card reader compatibility now with the MR62e.
For years decades I have been taken for granted, that everything supports wiegand. Of course it does how else would it function.
And now everyone needs to get into the habit of checking compatibility on every new part number for a reader and controller. Even if it is a replacement for something else. Assumptions are out.
I'll contact Mercury for comment on OSDP-only MR62e. When I spoke to them about this previously, the company had no immediate plans to stop production on MR51e, despite it being a 'Gen 2' board.
I can tell you that a recent order for 88 MR51e's from my vendor cannot be filled since they are no longer in production and completely out of stock.....
They are also listed as "No longer available for purchase" on their website: https://mercury-security.com/portal/products/type:controllers/subtype:legacy-controllers/
Access management vendors often do not design their own readers and credentials Controller (and vice versa), and the necessary 3rd party interoperability has been handled by Wiegand for several decades.
It should be between the readers & Controller. Since the OSDP protocol is being used in this area. correct me if i'm wrong.
(re-read this since this posting will likely be discussed next week at ISC East.)
I've not seen the A1001 do secure channel. 2017 firmware update, eh? Will retest that.
Not sure the wiring feedback is accurate. Many vendors use green/white for tx +/- and they still use red/black for +12/ground. That thing from proxy in your photo has weird cabling. Wiring is certainly a complexity, I'm not trying to claim it's all perfect.
Due to many platforms not offering nor supporting OSDP (examples like pdk, Proxy, Openpath), they will not be eligible.
However, even among those claiming OSDP support, the spec they've chosen to adopt is mixed and often not defined. For example, Verkada claims OSDP, as does their AD31 reader (test report coming next week), but they are adopting OSDP v1.0, not 'Secure Channel) OSDP v2.1.7+ that many platforms like Mercury Security and HID support.
Many OSDP products are absent, including HID Global who along with Mercury Security (now also owned by HID) were original members of the OSDP development group.
Outside of this, I am not aware of a current or tested OSDP conformance list.
There are only 3 companies listed, there is are a substantial number of vendors including most of the industry leaders in process. Why don't you just have people get in touch with SIA on the topic?
We'd be happy to fwd along SIA contact to anyone that asks, email me: brian@ipvm.com and I can help.
SIA offers a conformance testing tool but the utility is not a simple GUI, requiring some development or technical skill to use. I get a paid not found error. Is it a privileged page? Thanks Brian
Thanks for pointing that out. It appears the author of that page has taken it down. I'll email the author and SIA to ask if it can be downloaded elsewhere.
In the meantime, you might try Z-bit's OSDP Bench. It is a free PC based utility, but it requires that the PC has serial ports and readers connect using RS485 adapters:
That is not an officially supported conformance tool and the details are more simple, but you can toggle between OSDP versions and check if 'Secure Channel' is supported.
OSDP seems like it is in it's early stages which could cause many customers to try to avoid it. Without a solid backbone, I can understand the hesitancy of using it. Customers like ease of access and less cost. Less cost translates to less on site work and ease of installation. For technicians installing and troubleshooting OSDP, it seems like there would be significantly more time added in learning and finding issues, especially if there are limits on updates/upgrades of firmware and no conformance lists to cross-reference devices.
Sounds like OSDP is becoming more and more prevalent in the industry. Any word on when/if SIA is going to push for manufacturers to include proper disclaimers on what versions they're running and proper product compatibilities?
This challenge has been recognized by SIA’s OSDP Working Group, and that groupis in the process of drafting a document that lists the requirements for each OSDP profile (Basic, Secure, Smart Card, and Biometric) linked to OSDP version 2.2. Once published, manufacturers will be able to cite and prove which OSDP profile their products support.
SIA has also focused on growing the OSDP Verified program. OSDP Verified is specifically designed to help the public verify the functionalities of their OSDP products based on a manufacturer’s claims. The OSDP Verified product list includes the manufacturer’s brand, model, and firmware version along with which OSDP profile and OSDP standard version of the device and firmware was tested.
While SIA cannot enforce what manufacturers publish, we are encouraging the public to request OSDP Verified products. SIA also encourages all OSDP product manufacturers – even those not yet “OSDP Verified” – to provide their customers and prospective customers versioning and profile information that they support.
Additionally, SIA also offers an OSDP Conformance Tool that allows manufacturers to test their conformance to the OSDP standard (available for download from GitHub here).
Essentially, SIA is saying absent 'OSDP Verified' certification, which manufacturers pay to have, the future standard release of OSDP v2.2 will clarify profile support claims.
We'll publish an update on OSDP v2.2 and update this guide when released. Thanks for asking the question!
Agree
Disagree
Informative: 1
Unhelpful
Funny
Create New Topic
Login to read this IPVM report.
Why do I need to log in?
IPVM conducts reporting, tutorials and software funded by subscriber's payments enabling us to offer the most independent, accurate and in-depth information.
Comments (53)
Abdelhamid Metwally
Has IPVM done any surveys on how many integrators actually implement access control installations using OSDP over Weigand?
Create New Topic
Undisclosed #1
when you say “Weigand”, does that refer to the physical layer protocol, i.e. the wiring, or the data protocol, or both, or am I not making sense?
what is meant by “TCP/IP” cabling?
Create New Topic
Undisclosed Integrator #2
Great article. When using OSDP readers and controllers, does the access control software also have to support it for configuration?
Create New Topic
Salvatore D'Agostino
Thanks for this article, IDmachines has partnered with SIA to put on the first of a series of OSDP Bootcamps, 25 June at SIA Headquarters. It is part of an ongoing effort to educate the supply chain to improve conformance and interoperability, critical parts of any standards effort. https://www.securityindustry.org/industry-standards/open-supervised-device-protocol/osdp-boot-camp/ And thanks John, for approving this post.
Create New Topic
Scott Napier
In the Federal Gov't world, OSDP is becoming mandatory very quickly thanks for HSPD-12 finally being taken seriously and dollars flowing towards making it happen.
Create New Topic
Ty Mullen
06/07/19 02:08pm
I'm very surprised that the Mercuy MR62e does not support wiegand, only OSDP. Wondering how many people will buy and install it thinking it does.
Create New Topic
Brian Rhodes
I'll contact Mercury for comment on OSDP-only MR62e. When I spoke to them about this previously, the company had no immediate plans to stop production on MR51e, despite it being a 'Gen 2' board.
Create New Topic
Abdulwahab Al-Ibrahim
Brian,
I think this paragraph needs some correction.
It should be between the readers & Controller. Since the OSDP protocol is being used in this area. correct me if i'm wrong.
Thanks alot for this great article.
Create New Topic
Salvatore D'Agostino
SIA has just announced a certification program for 2020. There will be a short course at ISC East as well. OSDP Boot Camp, Short Course - Conferences - ISC East
Create New Topic
Undisclosed
(re-read this since this posting will likely be discussed next week at ISC East.)
I've not seen the A1001 do secure channel. 2017 firmware update, eh? Will retest that.
Not sure the wiring feedback is accurate. Many vendors use green/white for tx +/- and they still use red/black for +12/ground. That thing from proxy in your photo has weird cabling. Wiring is certainly a complexity, I'm not trying to claim it's all perfect.
Create New Topic
Charng Haw Guo
Great, in depth info about OSDP
Create New Topic
John Saunders
If a spec calls for OSDP compliance with readers/controllers are we eliminating some good options?
Create New Topic
John Saunders
Thanks. I'm trying to find a list of OSDP compliant products, but can't track anything down. Are you aware of such a Db?
Create New Topic
John Saunders
Thanks much.
Create New Topic
Delna Straus
SIA offers a conformance testing tool but the utility is not a simple GUI, requiring some development or technical skill to use. I get a paid not found error. Is it a privileged page? Thanks Brian
Create New Topic
Brian Rhodes
I added a section to this report on three types of OSDP Test tools, including a Linux-based utility that SIA recommends and a PC app-based tool.
Create New Topic
David Rasmussen
OSDP seems like it is in it's early stages which could cause many customers to try to avoid it. Without a solid backbone, I can understand the hesitancy of using it. Customers like ease of access and less cost. Less cost translates to less on site work and ease of installation. For technicians installing and troubleshooting OSDP, it seems like there would be significantly more time added in learning and finding issues, especially if there are limits on updates/upgrades of firmware and no conformance lists to cross-reference devices.
Create New Topic
John Bremner
Looks as though PDK now support OSDP:ProdataKey Launches the Red 2 Controller and Red Readers As Part of Its New High-Security Line
Create New Topic
James Clausen
Sounds like OSDP is becoming more and more prevalent in the industry. Any word on when/if SIA is going to push for manufacturers to include proper disclaimers on what versions they're running and proper product compatibilities?
Create New Topic