Thanks Brian, good to see the device version and firmware used in the tests. Looks like you are the dedicated access control guy now.
Here is an idea IPVM may or may not have covered. A comparison of different access control manufacture's hardware real estate footprint for start up systems, scaling systems and overall IDF/Data closet space needed.
Example Lenel/Mercury 16 reader layout using CTX-6 enclosures versus Life Safety Power, Trove along with gutter boxes, power supply real estate all relative to a 4' x 8' back board plus how many card readers can fit that surface area - headend.
Example 2: Software House/Lenel/S2/Identiv/Amag/Vertx comparisons and scalability, how much head end space can you get into one location etc. Which system has the most bang for the buck?
Example: Rackmount + IP edge systems vs. Wall mount systems, power, battery backup.
Hopefully you can test STiD mobile readers in the next tests. They have a pretty strong offering, and the ability to open doors remotely through app + several gestures using your phone and tapping the reader to unlock doors.
Thanks for the recommendation. STiD is a low- recognition brand, but there has been interest among Genetec dealers. Their offerings are often mentioned as good fits for high-security systems, which is interesting.
We will reach out to STiD and queue up a profile post later this summer/ early fall.
Hi Brian, when you are ready to test STid Mobile ID please let me know. I will be more than happy to provide you with Sample Units & access to the Free portal where virtual credentials are managed and designed. STid North America out Dallas Texas will be more than happy to assist.
STid has 6 modes of identification through their STid Mobile ID App. Contact mode, Tap-tap mode (taping your phone), Remote mode, hands-free mode, slide mode (gliding your hand over the reader) and most recently Voice mode (using iPhone SIRI by saying, "Hey SIRI Open Door").
The 'bad' rating relates to the minimum required purchase.
HID enforces a 100 credential minimum on orders, so for that 3 reader a year system, if the user only has 25 'cardholders'/app users the cost is still ~$650 - $700. (It would be <$250 for physical credentials, or even other 'mobile' products described in the report, for the same number of users.)
The 'per reader' offerings scale per reader, with no minimums. However, once HID systems scale to 101 users, the HID cost doubles, but remains the same with 'per reader' systems.
HID specifically mentioned they target their mobile platform toward larger deployments at this point, which is fair. We asked HID if they plan to lower the minimum quantities for smaller systems. They told us:
Lowering the minimum order quantity is something we’ve considered but it will stay at 100 user licenses for now. Delivering a great overall onboarding, administrative, and user experience is very important to HID. With the MOQ at 100, we already have over 3000 organizations using the service. As you can probably imagine, it takes almost as much effort to stand up the service for a 10-user population as it does a 1000-user population. Before we consider offering a lower minimum license requirement for very small businesses, we want to ensure that our services, processes, internal support, and channel partners can scale accordingly.
However, considering the majority of access systems are not 'big', (only ~26% of systems have more than 33 doors, and most less than 16), HID's solution can be a tough fit, especially if only a few users are issued mobile credentials.
If fundamental 'mobile' pricing changes, we will update this report and findings as appropriate.
Still, the Brivo Mobile Pass app with their "Magic Button" connected to a Brivo (WaveLynx) reader sure makes deploying mobile credentials and training the end user simple. My limited experience with mobile credentials has taught me that the system they are connected to/integrated with, and the apps on the mobile devices themselves, can make for a fairly complex process for the end user. My experience with HID (tap and go/twist and go) made me wonder who would ever go through so many steps to issue a credential. While I have heard the HID set up has been simplified, my first experience was enough to make me look for a different solution. I would be interested in seeing a report on who has the best overall solution for issuance and use of mobile credentials as part of a complete solution. Thanks again for these types of reports.
We primary leverage HID's mobile SDK and API for our customers but have expanded to include Proxy's readers. The Proxy reader is very responsive and we've been impressed with them thus far. Looking forward to seeing how customers react to these competing mobile/reader technologies.
Brian, report looks good and makes the mobile compatible reader ecosystem very understandable. What would be helpful for systems like ours (Kisi) is an overview of traditional systems that allow connecting a reader via API instead of Wiegand/OSDP. Quite a few folks ask for this and I believe Lenel, Genetec, S2 & others have that ability.
Quite a few folks ask for this and I believe Lenel, Genetec, S2 & others have that ability.
Thanks for the comment. Are API connected readers in demand? Or am I reading that wrong?
OSDP is one of the more common connection schemes (does not need/use field configured API, but factory configured ports for the protocol), yet even then ~70% of installers do not use it.
Despite Wiegand being downright trashed for being insecure and antiquated in the new age of reader tech, it is the predominant connection method. OSDP is barely used, for all the advantages and ease of configuration.
Provided using APIs require additional install effort, which reader features typically need API?
API based systems can work to a backend that is either local or remote. Typically they would need a HTTPS connection back to the backend.
One reason why these are often used with the cloud is that this minimizes the configuration required. The reader can be pre-configured with a certificate identifying itself, and with the URI of the API to talk to. It can then just be plugged in and used.
If using these with a local backend, then many of those things need to be configured, and this done per reader.
One aspect of this that might be confusing to some (me specifically) is the use of the term 'reader'.
In general, when IPVM and others use the term 'readers', it describes an input peripheral to access systems. Readers are to access controllers as keyboards are to PCs.
However, some call controller/reader combination units just as 'readers', especially edge architecture systems. It is rare for readers to have ethernet connections or integrated web servers, but it is common for controllers.
So in this case, are combination controllers/readers the ones connected via API calls? Or are you specifically talking about (peripheral) readers only?
Thanks for the report. So all of these are physical access control credentials on a phone. What is more of interest, at least here, is the use of truly mobile and logical credentials such as FIDO. There are examples of this, though they only work with the particular manufacturer's readers and controllers. In this way you have a common credential across use cases. You could log into web sites and go through doors with the same FIDO key pair. You can use the same key management (something the physical security industry has barely touched except for proprietary ones in SAMs by vendors). Also use of asymmetric keys has a lot of benefits, and none are in use here. To me this means there is plenty of opportunity to raise the bar here.
I noticed that many of your articles on comparing readers with Bluetooth capability do not include STid. Will IPVM ever have comparisons on STid Mobile ID. They have one of the best Bluetooth Reader Solutions with flexibility to ensure the customer gets what they need.