"Future-Proofing" Access Control Guide

By Brian Rhodes, Published Jul 30, 2015, 12:00am EDT

Its one of the most misused phrases around: "Future-proof". However, even without the crystal ball and wizards, designing access control to be "future proof" is much more pratical that the concept implies.

The features we tag as 'future proof' are:

  • OSDP
  • Smartcard Frequencies
  • Door Controllers
  • Third Party Controllers

While we explain why these products or features should be avoided:

  • ONVIF C
  • 125 kHz Cards
  • Combo Readers and Controllers
  • Mobile Credentials

Inside, we explain the pros or cons of each technology and how following these guidelines can save you thousands or more.

** *** ******** *****, we ******** *** ****** technologies ** ***** *** avoid *** *** **** results *** ***** ** come.

*****

*****, **** *** *** technologies ** *** ** your ****** ******, *** why *** ******:

  • ****: * *** ******** **** resolves ************ ******** *************** between *********** *** ******* is ****. *** ******** is ****** ** * replacement *** ******* ** offering ********** **** **********, two-way *************, *** *********** more ********** ****, ******. (For **** ******, *** our ******* ** **** ****)  ********, ***** *** protocol ** ***** ***, adoption ** ******** ****** has **** ********** **** leading ********* ** **** the ****** *** *********** side ******* ******** **.
  • **.** *** ***********: ***** *** ***, the ****** *** **** slow ** ******* ** the ****** *********, **** secure '*********' ********* ******. However, ** **** **********, the ************ ** ***** formats ******* **** ********* *** expensive [**** ** ****** available], ******** ***** *****.  With ********** ******* ******* ******** *** *********** ********* *** **.** MHz *******, ******** ****** changeovers **** ******** *** format ***.
  • ************* ***********: ** *** ****, the **** ****** ************ for ****** *** ** use *** ***** ** control **** ** **** doors, ********* ** **** as** ** *** ********* ** **** *********** **** controllers ******** (*** *** *********** ******* ******? ******** ****** *** *** *******). However, **** *** ******** and ************ ** ** networks ****** ****** **********, adding * '***** **********' at *** **** ** not * ********* *** offers ******* ** ******** in ******** ***** *** installation ***** ** * few **** ****** **** homerun ** ******* *******. 
  • *** ***** ********: ***** '***********' ****** be ********** ******** **** access, ************ *** ** lessened ** ******** ******** controllers **** *** ** used ** ******** *******. Options *** ************* ******* are ******* ** *** three ***** ********* *** controllers ** **** ** our **** ** *** ** Mercury ****** *********** ****. ** ******* **** hardware **** *** ** these ********* ********* *** multiple ********** ******** ******* to ***** **** ** the ******* ****** ** failing ** *** *** job **** ** **** out ** ********.

*****

*** **** *** *** technologies ** ***** ***** of *** *** ******* why:

  • ***** ******* *: ******* ******** ********* early, *****'* ****** **************** guideline *** ******* **** no *********** ********* ***** **** released ***** ***** *** years ***. *** ******* outlook *** ***** *** other **************** ********* ** grim **** ****** ****** traction, ******** ** *** ****** ****************: ***** ******* ****.
  • *** *** ***********: ***** ***** ** older, **** *********, *********** contactless *********** ***** *** 125 *** *********.  ******* YouTube ***** **** ** videos ********* *** ** use $** ******* **** widely ********* ******, **** endusers *** *********** ***** are ******** ** ** the *** ** ***** systems. ** *** **** ************** ****** ******* *********** ******, * ******** **% still **** *** **** their ********* ******. *******, with ***** *** *** kHz ***** *** ******* typically ***** ** **** **** **.** MHz ********, ***** ** little ****** ** ******** using ****. 
  • ***** ***********: ***** ************* *********** make **** *****, *** idea *** ** ***** too ***, ** ** frequently *** **** ** combining *** ********** **** the ******. *** ***** weakness ** *** ******** is *** ************* **** hanging *** ***** ** the ********* **** ** the **** ******* *** opening - *** ********** area ******** - ** great **** ** ********* threats. ** ****** *** risk ** ********* *******: ***** ****** / *********** ******** ****.
  • ****** ***** ***********: *** ****** ************ have ****** *** **** of ********** ***********. *** slick ******* ** ****** users ****** ***** *********** in ***** ** * reader ******* ** * stale, ****** ** **** may **** *** ***** tradeshow ****, *** ******** to ****** ** ********* and ****** *** *********** problems, **** *** ******* smartphone ***** **** ** letting ********* ****** ****** settings, *** *********** *** provisioned, *** ******* ** not ***** **** ** carry ***** ****** *** picture ***.  ** ******* these ***** ***** ** our ***: *** ***** *** Primetime ****, *** **** **** apply ** *** (********* *** ******) for ****** ** ****.

Cost *******

*** ***** ****** ****** ****** of ***** ********* ** sunstantial, *** ***** ********* and *** ***** *** save ********* ** '****** right' *******.

*** *******, * '******** upgrade' ** *********** *********** instead ** ******* ******** 3rd ***** ******** *** amount ** **** $**** per **** **** ******* *** additional *********** *** ************ labor. *** **** ** upgrading * ****** ** work **** **.** *** smartcards *** ** $*** per ****** *** $** per **** *** **** user **** ******** *** kHz ******* *** ************ by *** ****** [**** no ****** *********].

Comments (3)

Brian,

as you mentioned OSDP is future of Standard Access Control Protocol [like, Currently Wiegand]. I wish it will, as Biometric reader needs two way data transfer and it is not possible through existing wiegand protocol.

But, still I have not seen/heard installations of different reader with third party panel over OSDP due to it's lower acceptance in access control manufacturer.

Like ONVIF, is there any specific group of manufacturer or organization which is promoting OSDP ?

On which basis we can predict, other manufacturers will include OSDP in their future products ?

Hello Sundar:

Good question. OSDP is promoted by SIA.

Unlinke ONVIF C, their efforts have added access manufacturers with considerable marketshare, including Mercury Security and HID Global (who co-authored the protocol). The member list also includes Axis, Siemens, Identive, Nedap, and Brivo.

It's not comprehensively adopted like Weigand, but the list of OSDP supported devices is growing with each new product release cycle.

In terms of current, real support, controllers like the Mercury EP1501/02, Axis A1001 and readers like HID's iClass SE series provide the option to connect with OSDP. Again, not comprehensive, but those components are widely adopted by a large number of systems today.

It's important to point out here and say that OSDP and ONVIF C are apples & oranges. ONVIF C is a controller protocol. OSDP is a reader device protocol. While I know this is obvious, it is essentially the reason why OSDP is getting traction and ONVIF C is not.

People lament that ONVIF C hasn't caught on for access, as other ONVIF profiles have for video. I think the reason for this is that a controller is more analogous to a VMS than a camera. Does anyone use ONVIF above the VMS? Didn't think so.

So OSDP is catching on more than ONVIF C because of the role of readers is fairly well defined, as is that of cameras. In contrast, any value-add or differentiator at the controller level will have to be added to ONVIF C. Think of all the different ways you have seen controllers do access levels, triggers and procedures, etc. I think it has a tough road ahead.

Read this IPVM report for free.

This article is part of IPVM's 6,649 reports, 895 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

Already a member? Login here | Join now
Loading Related Reports