Vulnerability Directory For Access Control Cards

By: Brian Rhodes, Published on Aug 14, 2017

Knowing which access credentials are insecure can be unclear, especially because most look and feel the same. Even the most insecure 125 kHz types are still widely supported, and using 13.56 MHz smartcards is no sure guarantee the format has not been hacked.

In this report, we take a deeper look at:

  • Why To Stop Using 125 kHz Formats
  • Which 13.56 MHz Formats are Uncracked (So Far)
  • The Cracked 13.56 Types Still Widely Used
  • Why No Formats Are Uncrackable
  • Thousands Are Working On Hacks
  • High Technology Skills Needed
  • Steps To Defend Against Hacks

We cover these points inside.

125 kHz Riskiest of All

While the vulnerability of specific 13.56 MHz formats is mixed, older 125 kHz are highly vulnerable to pragmatic copying with cheap and widely available components.  We covered the risk in our Hack Your Access Control With This $30 HID 125kHz Card Copier test, and then how to address the vulnerability with the Hackable 125kHz Access Control Migration Guide.

Common 125 kHz Formats Are Insecure

The list of vulnerable, unencrypted 125 kHz formats used in access is substantial, easily reaching into millions of credentials still in use daily. The common formats include:

******* ***** ****** *********** are ******** *** ** unclear, ********** ******* **** **** and **** *** ****. Even *** **** ******** 125 *** ***** *** still ****** *********, *** using **.** *** ********** is ** **** ********* the ****** *** *** been ******.

** **** ******, ** take * ****** **** at:

  • *** ** **** ***** 125 *** *******
  • ***** **.** *** ******* are ********* (** ***)
  • *** ******* **.** ***** Still ****** ****
  • *** ** ******* *** Uncrackable
  • ********* *** ******* ** Hacks
  • **** ********** ****** ******
  • ***** ** ****** ******* Hacks

** ***** ***** ****** inside.

125 *** ******** ** ***

***** *** ************* ** specific **.** *** ******* is *****, ***** *** kHz *** ****** ********** to ********* ******* **** cheap *** ****** ********* components.  ** ******* *** risk ** *** **** **** ****** ******* With **** $** *** 125kHz **** ****** ****, *** **** *** to ******* *** ************* with *** ******** ****** ****** ******* Migration *****.

Common *** *** ******* *** ********

*** **** ** **********, unencrypted *** *** ******* used ** ****** ** substantial, ****** ******** **** millions ** *********** ***** in *** *****. *** common ******* *******:

[***************]

Formats *** *** *******

*** **** ** ******* access ******* ********* *** claimed ** ****** ** small *** ******** ***** main *****:

*** ****** ****

***'* ****** **.** *** format *** *** ** be ****** *** ********* as ******* ***** ********** tools.  *******,**** **** ******* ******* without '**** *************', *** ******** ******* [*,*,*] ***** '** ** close' ** ********** ** official *****. 

****** ******* ***(********* ****)

**** ******** *** **.** MHz ****** *** **** widely ******* ******* ***** America, ** ***-********** ****** control *******, *** **** less-expensive ****-************** ****** *********** and *******, *** **** 128-bit *** ********** *** onboard **** *******. 

****** ******* ***(********* ****)

**** '**** ***' *** format ****** ** ***** multiple ********** ******* ** how *********** ** ********** on *** **********, *** does *** ***********  ******** improvements.  ** *******, ******* designed ** *** *** can **** **** ***, although *** *** *********** is **** *** *** formatted ** ********* ** access *******.

Formats ************ *******

*** ******* ****** ** exploits ** *** ****** realized ** *********** *** endusers. *** ******* ***** used ** **** ** systems **** **** ******, but *********** **** ** 'secure' ** ****** *************:

****** ******* ******* 

********* ********* ****** ******* Classic *** *********** ****, **** *** *** been ****** ********** ** the **** ******, **** **** users ******** *** **.** MHz ********* ****** ** safe. *******, *** ****** of ********** ******** ******** keys ******** *** ******* to *********** **********. *** format ** ***** ********* **** *********** vendors.

*** ****** ***** (*** SE/SEOs *******)

*** ****** ** ********** 'keys' **** ***'* ******** 13.56 *** ****** ***** multiple ******* *** ***** and *** ********** ******* in *** '***** ** ********' *****.  **** ******** individual ********** *********** *** be ******* ** *** cards. *** ***** ***** these ********** ***********, ******** the **** ****** **/**** format *** * ********* format *** ******** ****** of ********** ** ******* similar ********. 

No ******* *** ***********

******* ** ****** ** 'unpickable' ** '**********' ***** that *** ***** ********* given **** *** ******** to *** ******, ** credential ******* ****** ** viewed ** '***********'. ***** broad ******** **** ******* and ********* ******* *** notoriety ** ******** ******* essentially '******* *** ***** locked' ** ********* *****, efforts ** **** **** are ******* *** **********.

** ****** ****, *********, or ********** ****** ****** formats *********** ******, *** planning *** *****-****** ************** *** ******** ********* ** prudent.

Cracking ********* ******* ** ****** *********

*** ********* *** ****** needed ** ***** ********* formats ********* *** ******** bench *********** **** ******* software ***********, ********** ***********, and ********* ***** ** code.

*** ** *** **** popular ********** **** ******* tools, *** ****-******* *********, *** **** ********** ** the ***** ****:

** ****** ** ******* out ***** ***** **** the ********* ** *** really *** *********. ** you *** *** ******* fairly ******** **** ***********, embedded ***********, **** ** design *** *** *********, this ****** **** ******** bring *** **** *********** than ******** **** ! Users **** ** *** understand *** ***** ********** behind **** *** **** difficulty ***** *** ******.

*** ***** ******* *** the **** ******** *****, they ****** *** ****** a '***** *** *****' card ******, *** ****** a *** ** ********** that ******* **********, ********, and ******** **** **** be ********** ******** *** access ********** *******:

**** *** ***** *********** 125 *** *******, *** cheap, *****-****, *** **** to *** ******* *********, like ***$** **** *** *** copier** ****** **** ********* success:

*******, *** *** '***** and *****' ******* *** risks ** ****** *******. For *******, ** ****** ********* (**.*****) ****** **** *** *** **** with ****** ****** *******, despite *** ****** ** copying ********, ********* *******:

The ******* ********* ** *****

******* ** *** '*********' community ** ********* ********** in ******* ********** *****, there *** ********* ****** who ******** *********** *** contribute ** ******* ****** credentials.

*** ** *** ****** forums ***** ***** ***** gather ** *** ******** ********** *********, **** ********* ** users *** ******** ** posts ***** *****, ***** collaborative ******* ** ******* progress *** ******* *** multiple ******* (********* ******, MIFARE, *****, *** *** credentials) **** *****.

***** ****** *********, **** source ********* *** **** to ******. ******** ******* projects *** ** ***** on ******, * ***** and ***** ****** ************* source ** ***** ************. While ***** *** **** relating ** ********** ********, an ******* *** ***:

******* *******

Significant ****** *** ** ********

******* ********* *** ********* risk ** ******, ** that ******** ****** *** modification ** ********* ** often ******. *** *******, one ** *** **** commonly **** ******* ** extracting ******* **** **** iClass ******* ******** ********** wiring * ******* ** splicing *** ****** **********.

*** **** ****** *******, the ********** *** **** needed ** *** **** method ** * **** significantly ********* *** ****, as *** ****** ***** be ****** ******** ** authorities.

*** **** ******** *** many ******* ***** ***** hours ** **********. **** methods *** **** ** few ** * ******* (with *********** ***), ***** ****** **** multiple ***** ** **** days (**** ******** ***** **** ******* unit).

High ***** **.** ****** **** ** ***** *******

*** *** *********** ** that **** *** **** ***** and ******* ****** **** to ***** ********** *******, the ******* **** ** electronic ****** ******* ** spoofing *** ******* ***** still ***** ****.

*******, *** $** *** kHz ****** *** ** used ** ******* *** semi-covertly, ** ***** ******* should ** *******. *** for **.** *** *******, even ***** ******* ******, hours ** ****, ******** keys, *** ******** ************ of ******* ** ***** required.

*** **** ********* ******* against *******: ******** ***** administrative ******* ** **** keys, '**** ***' **** keys ********, ** *** reissue ***********, *** **** sharp **** **** *** tampering ** ********* ******* and ***********.

Comments (22)

Great info covering card to reader hacks :) There is still the vulnerability of reader to controller hacks that is also out there. Careful installation and use of tampers mitigates a bit ... at least until we get true end to end encryption.

The 30 dollar hack has shaken up a lot of people (myself included). We expect Gov't agencies and super hackers to find vulnerabilities but the "point and click" ease of that tool is disturbing.

The shelf life of Security by Obscurity is shrinking every day. Designing security with the assumption of an open source peer review for security should become the norm.

rbl

Nedap has end to end encryption :

http://www.nedapsecurity.com/aeos-end-end-security

But requires some advanced knowledge (certificates) and the use of sim card like "SAM" modules. It will add cost, but high security sites might benefit...

Filip

The shelf life of Security by Obscurity is shrinking every day. Designing security with the assumption of an open source peer review for security should become the norm.

This is the key 'theme' of Milosch Meriac's 'Heart of Darkness' iClass Crack. He suggests that just because iClass is a particular brand of RFID in a niche application, common methods used to break other RFID technologies (ie: EAS tags, bus/train passes) can/will be modified against physical access.

Thank you for putting all this in one article.

I liked it very much.

Great article,

K. Chung's method works. I used it to demo unauthorized iClass duplication for a security research project. It takes a bit of effort but was the only way that didnt require hardware hacking older readers.

Very good article, a couple of further points, fruit your links in the paragraph about iClass SE seem to broken, ( I think the proxmark Forum is down this morning) and second the fundamental reason that the iClass cards are weak is due to the weakness of the underlying Silicon, which is not from NXP.

Your comment on securing the keys is best advice, any cryptographic system can be broken, and the easiest way to do that is to access the keys.

The most recent work is now focussing on emulating EV1/2, a device claiming to do this is now being offered on the proxmark forum, and there is the Chameleon.

Also the Chinese iClass software is in fact Copy Class, which can be download for free, and runs on a XP machine( both physical and VM). I have extended that package to make it more user friendly, i.e. to understand site codes etc, nothing fundamental, but useful.

Thanks for the feedback here!

Do you have a sense of how difficult extracting iClass SE keys are?

In browsing Proxmark forums, I gather current attempts are only partially successful, but close to a full 'crack'.

Do you see that, or do you think a crack is still somewhat far away?

iClass SE is typically a second application on PicoPass silicon. In theory the PicoPass transport key can be found using similar methods as the over the Air published methods, but then there is a second application key structure, which is currently held and managed on the reader. Modern HID readers utilise a Secure Authentication Module, which would be impervious to Side Channel attacks, so these keys are fairly safe. But from my understanding there remains 2 attack surfaces.

Firstly the legacy application is often included on the card and the readers will normally read this is the flag for the SE application is disabled, and this can be achieved with the known keys.

Secondly, when the transport key is known the device can be emulated using a Proxmark, you cannot work out the contents, but you don't need to as usually they tell you what the number is with laser printing on the back of the card....

From my reading of the forums, the application remains secure, except from the possibility of bit copying and emulating the CSN, at present I unaware of any attempts to produce soft silicon implementations of PicoPass, the effort seems to be focussed on creating EV1/2 emulations. So the application keys are likely to remain secure.

Supporting legacy is often a big problem with security systems, and also ensuring that the secure features that the manufacturers have laboured long and hard to create are actually turned on.

I would qualify these statements that I haven't had access to many SE cards, but those I have seen have allowed legacy operation, defeating the reason for the deployment.

On a positive note, from what I have HID Seos looks very good, but I am very concerned that HID won't open the process to review, or even tell Consultants under NDA, so no-one knows what it actually is.

Also I would only implement it on DESFire EV2, and we need to start to implement features such as usage counters over an interface such as OSDP, and ideally don't put keys in readers.

Interesting. Like you mention, in terms of HID discussing or divulging details, the strict insularity seems to be company culture. Even HID's PR people paid to answer non-technical questions are often vague and nonspecific in responses.

Thanks for the feedback!

I think George, when referring to SE Cards with legacy, is talking about the SR range of cards within the i-Class SE family. These cards are made to work with both the original i-Class platform (typically readers with a part number beginning with a 6) and the later i-Class SE platform that has a part number beginning with a 9. The idea being that when all the older series readers are replaced the legacy portion of the reader can be disabled by config. card and the reader will only operate on the latest SE technology. It is strongly recommended that any new site only use ER version credentials with i-Class SE readers with the legacy option disabled.

I would agree that this is the case (SR cards). But the problem with PicoPass implementations of iClass is that it based on 25 year silicon, designed to improve on Mifare Classic, but before any of the attacks were revealed. Why would you continue to use a weak 64 bit DES implementation using a maximum of 2 keys ( common read & write), when a robust 128 bit AES device (EV1/2) is available with multiple read, write and change keys?

Especially with the availability of card cloning devices such as Proxmark, which can simulate a card, removing the protection of a unique UID per card.

Also if you are changing all readers, and cards as you suggest, the new readers will support EV1/2 and the cards are cheaper.

If you are changing the readers, make sure to specify OSDP.

George, are you saying you would issue EV1/2 instead of Seos? Or am I mistaken.

At the end of your previous comment you said "you would only implementing it on DESFire EV2", where "it", I believe, was referencing Seos. I could be mistaken. Can that even be done? I've not seen anything like that.

It seems to me that Seos is pretty secure and well designed. I've been debating which is more likely to remain secure Seos or MIFARE DESFire but I'll admit I don't know enough about either to make even an educated guess.

I believe HID recommends to new installations "Seos-profile" SE readers which only read Seos credentials. Or you can order "Standard-profile" SE readers where the full range of iClass and MIFARE are supported. This supports a phased migration from old credentials to Seos.

Firstly there a several Vendors which support a transition from older Credentials, in Europe Deister and STiD would commonly be used, and they are supported in the US.

But with technologies such as EV2, MiFare Plus and Javacard (I believe Seos is a Javacard application) we are moving to phase when the key lifecycle, and third party validation is becoming more important than the technologies to which it is applied.

Therefore as users of these technologies, we need to ask questions such as:-

who knows my keys?,

were are they stored?,

do they exist in human readable form?,

can they be securely recreated?

how can I rotate keys on a system?,

and who has independently reviewed and approved the system?.

The last point is especially important as we got to this place, by being too trusting of suppliers, their requirement to maintain profits, and thereby suppliers not being open with their customers. Historically we have been too dependent on method, and not cryptographic secrets.

I don't think we can be making decisions based on "It seems to me that" have you completed any analysis that you would be in a position to share?

I'm not making any statement of fact or even really pretending to know if Seos is secure. Just from my cursory reading it seems well thought out. I found THIS a decent high level overview of Seos. How well concepts translate to execution matter though. We see in the IT security space that just saying you are "implementing a proven and reliable encryption" doesn't mean it was "implemented correctly". I'm certainly not here promoting one or the other. Unfortunately HID is pretty dominate in the US and most physical security vendors I've talked to don't know much of anything about NXP, let alone have an understanding of the low level details on how they work.

As far as the keys are concerned. My understanding is that both HID Seos and MIFARE DESFire EV1 (not sure about EV2) solutions allow you to control your own keys if you so choose. I believe with HID that means investing in encoders, software, and "credits". Not sure what the common workflow is for MIFARE though.

I believe both use the symmetric key model, which means keys are going to be stored in readers as well as credentials. And at the current time I don't know of anything that doesn't require this.

Both utilize the "application" concept. Each applications having it's own master key. And also a PICC master key. DESFire stores the keys in what they call the SAM. Seos calls it the SIO. Both, I believe, use the same standard encryption algorithms (3DES, AES, RSA).

I'm not sure about "securely recreating them". I would suspect both can provide that.

And I'm fairly confident DESFire EV1 has gone through various review processes and certifications by outside entities. I suspect HID hasn't, which wouldn't be that surprising.

My inquiry is more to help me understand more. Because 1) I'm very interested in the topic and 2) I'm actually putting in a solution and quickly came to the conclusion it would be Seos or DESFire. I find it hard to get a clear picture of the inner working of both solutions from a technical level. And for DESFire I actually found it pretty hard to find a vendor who can propose an end-to-end solution and explain it to me (readers, credentials, encoding, software, etc).

Jason, in terms of recommendations, I would recommend using EV2 with a known PICC master Key, this allows multiple applications to be supported on the card.

Furthermore I recommend a third party application to held inside the AES encrypted file. This can be Seos, Deister SecureProx or similar.

Readers in public areas should operate in a transparent mode, i.e. no keys in the reader.

As the keys are symmetric, the system design must allow for key rotation.

Encoders must be controlled and contain a SAM, there must be central control of the key and number distribution.

We (www.lumenid.co.uk) have created an end to end key and credential management system based on Deister, and I am aware of at least one system based on HID from a Platinum partner.

It is surprising how many customers allow their encoders to go "feral" with absolutely no controls, and then situate them in semi-public areas.

Keys must be anonymous (i.e. no one knows the keys) yet must be capable of being recreated in the event of the failure of a SAM, and be supported by suitable protocols for Audit and maintenance.

Thanks for the response! Can you provide me a bit more info on the part about

"Readers in public areas should operate in a transparent mode, i.e. no keys in the reader"

I came up with very little about this. How is this achieved? Is this referencing a device between the reader and panel that holds the keys so that they aren't in an exposed area?

Wanted to add some more specifics on HID key management. There are 3 approaches I'm aware of. Below is my understanding and summary of what I've read/discussed regarding the matter.

Standard Security. This is the off the shelf version where the keys are the same across all readers and credentials regardless of site/company.

Elite/Elite SE. This is the program where HID manages a custom high security site specific key for you. Your readers and cards must be special ordered from HID and are programmed from the factory. A nominal fee is paid through your integrator for the HID management of the cards. While you're no longer using the standard key, you are still trusting HID to some degree and sacrificing a small bit of lead time for parts.

Custom high security. This is the same as the Elite except now you as the end user control the key. Obviously this adds overhead for the site. You'll need additional hardware/software. But you now don't have to trust a 3rd party with your keys.

Readers can be converted between the various modes with special configuration cards at any time.

Elite/Elite SE keys are 64 bit and not given to the customer. Orders and changes are controlled on the account as well.

The custom high security keys managed by the customer are also 64 bit. They are derived from a 128 bit user specified seed value when defining the key. Because of this, the end user does not have knowledge of the actual 64 bit key, just seed value. I suspect the Elite program probably handles it similarly to this, just at the HID factory.

I think that info speaks directly to the questions of who has my keys, can they be securely re-created, and how to rotate them.

Also, I'm not entirely sure if Seos is 64 bit, I think that might be higher.

Jason, I suspect you are describing the model from iClass, which has now been largely superseded by the EV2 model which is based on 128 bit AES.

If we look at the Deister model, they provide software to the user to allow multiple persons to enter a paraphrase, these are then concatenated to create a long phrase, which is used as the seed to create a unique random set of AES keys (13 keys in total) to control the application. The key set is stored in a tightly control encoder, which contains a SAM AV2. For each client Deister creates a unique shipping key set, which they control, and the users then create their own key change set and active key set completely independent of Deister, including the reader key change cards. This ensures that the process is completely anonymous. The active and key change cards can be recreated from the paraphrase, which exists on both cards and can be stored in a written form, in a controlled safe, only brought out in the event that the key change cards are lost/failed. I have had to do this for clients when a SAM failed.

In my view this is the best model, which is available to commercial users for key security, as it is anonymous, and independent of the Vendor and this has been approved by the CPNI in the UK (somewhat equivalent to NIST), i.e. been rigorously reviewed by a third party. Integrators can manage this anonymously for end users, or large end users can do it themselves.

As to Transparent readers, the OSDP 2.1.X supports this, but I haven't seen it supported on panels at present (the union of ASSA/Mercury will probably accelerate this being implemented), but Deister currently ship a device called a Cipher box which can convert one of their readers to transparent device, sending only ADPUs from the reader, and containing no keys, except a one-time key to pair the cipher box and a reader, this device can then output Wiegand (in this case this is ok as the Cipher box is installed in the same cabinet) to a legacy Panel, or OSDP.

Very few panels support an onboard secure element(SAM), which is an essential pre-requisite, I know Nedap make a 2 door panel with a SAM, and the recent announcement from Mercury on Secure elements on their expansion boards, is also good news, as most developers proceed in the mistaken belief that security can be provided in software.

The Deister key management sounds a lot like what HID does with the Asure ID software and CP1000 encoder. The encoder has a SAM module. Only thing I think that sounds different to me is the "shipping key set". I think HID just ships them with the standard default keys they control. And then you program them with your own custom keys. Section 7.1 HERE has details and then goes into the actual process in the software.

I would add Mifire Plus in SL3 mode to the list of "not yet cracked".
It is more cheep than Mifare DESFire (which in comparison with Plus has some nice properties but not relevant to physical access control) or any HID product.

I would also say that Mifare Plus is much more open than HID solutions, after signing an NDA developer gets complete protocol description there every single bit is explained. There is no "security by obscurity" layer at all, it is based on common AES cypher. As for me, it gives much more confidence than I have with partically closed proprietary HID solutions.

Btw, I'm in Russia, we don't have HID dominance here, Mifare market share is significant here, we produce of our own readers for it.

Alexander, it is interesting that you make the comparison between NXP and HID, NXP is a designer, manufacturer and provider of smart card platforms such as Mifare Plus and DESFire, whereas HID resells and personalises these platforms. The iClass Platform was designed by Inside Secure and sold originally as PicoPass. Therefore this is not a valid comparison.

This difference is the basis of the openness you refer to, i.e. NXP are selling to developers whereas HID is selling to end users and Consultants.

I can see little logic in using Mifare Plus for Access Control applications, as the cost difference between Mifare Plus and DESFire is relatively small, certainly in comparison to the cost to the user for a completed card, and the readers are no more expensive. The only reason to use Mifare Plus is to aid migration from Classic, and the problem then becomes that typically insecure legacy features remain enabled, providing a back door for exploitation.

Thank you for the details about HID, some are new for me.

If we use Plus cards in SL3 mode then there is no Classic compatibility, nothing that can be considered to be a "back door".
End-user product (cards not just chips) in case of Mifare are produced by many, for example in Russia there are companies who fabricate them locally, it all even more increeses cost effectivnes.

I know that DESFire is more popular in physical access control in western world than Plus. Even you speak about DESFire as about "default" option and I have to proof that Plus is good as well. I never understood why, is there something more than historical reasons?

As for HID vs NXP, at the end of the day I think I still have a right to compare NXP-based cards with HID iClass cards. Including openness - I never managed to extract any deep technical details out of HID (I've tried a couple of times), I'm ready to speak with Inside Secure or anyone else who they direct me to, but they don't, and I'm not sure it works this way with them in principle. I have to trust them, they don't leave my any other option. As for NXP-based products I'm still not a card manufacturer myself, just a guy, but it is completly open technology for me, that's why it is more predictable for me and I can recommend it my customers. At the end of the day I just see not a single reason why I should consider using HID or Legic instead of Mifare.

Login to read this IPVM report.
Why do I need to log in?
IPVM conducts unique testing and research funded by member's payments enabling us to offer the most independent, accurate and in-depth information.

Related Reports

ZK Teco Atlas Access Control Tested on Aug 20, 2019
Who needs access specialists? China-based ZKTeco claims its newest access panel 'makes it very easy for anyone to learn and install access control...
Suprema Biometric Mass Leak Examined on Aug 19, 2019
While Suprema is rarely discussed even within the physical security market, the South Korean biometrics manufacturer made global news this past...
Dahua OEM Directory 2019 on Aug 16, 2019
US Government banned Dahua OEMs for dozens of companies. The following directory includes 40+ of those companies with a graphic and links to...
Installation Course - Register Now on Aug 15, 2019
Register Now for the September 2019 Video Surveillance Install Course. This is a unique installation course in a market where little practical...
Hikvision OEM Directory on Aug 13, 2019
The Chinese government-owned and US-government banned Hikvision has become the world's largest video surveillance manufacturer and generally hidden...
Biometrics Usage Statistics 2019 on Aug 13, 2019
Biometrics are commonly used in phones, but how frequently are they used for access? 150+ integrators told us how often they use biometrics,...
Milestone "GDPR-ready" Certification Claim Critiqued on Aug 12, 2019
Milestone is touting that its latest XProtect VMS is "GDPR-ready" with a 'European Privacy Seal'. However, our investigation raises significant...
Hikvision Global News Reports Directory on Aug 11, 2019
Hikvision has received the most global news reporting of any video surveillance company, ever, ranging from the WSJ, the Financial Times, Reuters,...
ProdataKey (PDK) Access Company Profile on Aug 09, 2019
 Utah based ProdataKey touts low cost cloud access, wireless controllers, and no dealer required national distribution availability.  But how does...
Axis Door Station A8207-VE Tested on Aug 07, 2019
Axis newest door station, the A8207-VE, claims to deliver "video surveillance, two-way communication, and access control" in a single device. But...

Most Recent Industry Reports

TMA Apologizes to Amazon / Ring on Aug 23, 2019
Not only is Amazon / Ring making major incursions into the residential security market, the organization representing the biggest incumbents, The...
China Dahua Replaces Their Software With US Pepper on Aug 22, 2019
What does a US government banned company do to improve its security positioning in the US? Well, Dahua is unveiling a novel solution, partnering...
Security Integrators Outlook On Remaining Integrators In 2025 on Aug 22, 2019
The industry has changed substantially in the last decade, with the rise of IP cameras and the race to the bottom. Indeed, more changes may be...
First GDPR Facial Recognition Fine For Sweden School on Aug 22, 2019
A school in Sweden has been fined $20,000 for using facial recognition to keep attendance in what is Sweden's first GDPR fine. Notably, the fine is...
Anyvision Facial Recognition Tested on Aug 21, 2019
Anyvision is aiming for $1 billion in revenue by 2022, backed by $74 million in funding. But does their performance live up to the hype they have...
JCI Sues Wyze on Aug 21, 2019
The mega manufacturer / integrator JCI has sued the fast-growing $20 camera Seattle startup Wyze. Inside this note: Share the court...
Dahua 4K Camera Shootout on Aug 20, 2019
Dahua's new Pro Series 4K N85CL5Z claims to "deliver superior images in all lighting and environmental conditions", but how does this compare to...
ZK Teco Atlas Access Control Tested on Aug 20, 2019
Who needs access specialists? China-based ZKTeco claims its newest access panel 'makes it very easy for anyone to learn and install access control...
Uniview Beats Intel In Trademark Lawsuit on Aug 19, 2019
Uniview has won a long-running trademark lawsuit brought by Intel, with Beijing's highest court reversing an earlier Intel win, centered on...
Suprema Biometric Mass Leak Examined on Aug 19, 2019
While Suprema is rarely discussed even within the physical security market, the South Korean biometrics manufacturer made global news this past...

The world's leading video surveillance information source, IPVM provides the best reporting, testing and training for 10,000+ members globally. Dedicated to independent and objective information, we uniquely refuse any and all advertisements, sponsorship and consulting from manufacturers.

About | FAQ | Contact