The list shows that the industry has made a significant investment in developing products to meet the standard. It shows that the normal evolution of a program is continuing. We have gone from mandate in HSDP 12, to specification, to testing program and list of approved products to implementation recommendations—for example National Institute of Standards Special Publication 800-116 .

The next evolution needs to be specific acquisition guidance, acquisition rules and consistent implementation. This occurs in parallel as industry continues to invest to meet the full set of requirements and to adapt to the evolution of the specifications to meet the real world needs for practical security.

The APL has thirty categories. The following is a breakdown of the categories along with the number of products listed in each category and the number of companies represented among those products.

A few items jump out immediately, first there are 11 categories with no products listed. Second, for those categories with products listed all have multiple suppliers with one exception, third the distribution of products is heavily geared toward the top categories—about 36% in the top category and about 55% in the top three.

So does this meet the goals of the program among which are interoperability, improved security and cost savings?

As per usual the answer is yes and no. Having a program is crucial. It sends a clear message that the government is serious about HPSD-12 (although acquisition regulations with real teeth would be better). But, all of the products currently listed are tested in isolation against a rig that is not representative of a production system.

In other cases interoperability is achieved at the test level but not fully to the specification or not to what would occur in practice. For example, card readers can be run against the test scripts but do not necessarily include a check of all of the data that can be processed; i.e. biometric templates and matching can determine that the ANSI-INCITS standard has been followed for the biometric data but it does not necessarily determine that balance of the data in the biometric object is formatted correctly.

Further since there is no biometric authentication device listed it’s still a game of “wait and see.” So just because a generator and matcher are on the list it doesn’t mean the device is interoperable–however likely that outcome may be.

The same is true for the PIV cards. Multiple card reader vendors, in particular physical access control vendors, have encountered PIV cards in agencies that are approved yet are not read due to improper implementation of the card specification. In these cases it falls to the card reader vendor to convince the agency that its product is solid, at additional time and expense for those involved, which is a little discouraging considering the cost involved in getting approved in the first place.

Another and extremely important matter involves the fact that products are listed independently of the assurance level that they provide (unless you connect the category to the relevant document and category). It is not surprising that the category with the largest number of products listed (transparent reader) happens to implement the specification at the lowest, and some would say no, assurance level. There are a big difference among the ways a product or solution can make the statement that it meets HSPD-12 or FIPS 201.

The GSA has introduced a number of new categories to begin to address this issue. The point to be made here is that the vendor community is the most in tune to these new categories and the relevant differences. More needs to be done to educate the agencies.

Presentation made at the Interagency Advisory Board and other conferences matter but only go part way. These presentations educate the most knowledgeable members of the community. They go deeper but not wider with regards to the audience.

A complementary activity needs to occur with regards to users and integrators. Those who purchase and those who install the products on the approved products list need to understand the difference between products that implement little to no assurance versus high assurance.

A clear message needs to be sent: buying a product that can deliver high assurance doesn’t necessarily mean that’s what it will deliver. The assurance level is not just related to the product or system purchased but also how that system is designed and integrated into the enterprise. It is not enough to just get listed or to just acquire things on a list in order to be able to say it’s an approved product.

An approved product or service does not eliminate the need to understand the assurance level provided by the overall solution or enterprise architecture. Experience on the system level has to come into play. It is not enough to just get listed or acquire things on list. So once again caveat emptor, the list is a piece not the puzzle.