Physical Access Control System (PACS) Approved Products List
Click here for Recommended Procurement Language.
See below for additional information regarding testing and topologies. For a limited time only, product testing is currently being funded by the GSA.
Note: Procuring agencies can add (or incrementally update) components to an existing, and approved, PACS system configuration according to the tables / rows shown below. Note that there is not necessarily a 1-to-1 relationship between components in an approved configuration. As an example, in the 13.01 Topology it is likely that multiple readers may serve one validation system and connect to one PACS infrastructure. If you have additional questions please contact us at ICAM@gsa.gov.
PRACTICE NOTES IMPLEMENTING NIST SP800-116 GUIDANCESecurity professionals at federal buildings have three base case scenarios to consider when designing, specifying and implementing an APL Approved E-PACS. They are:
1. I am moving up in security levels (e.g., from Controlled up to Limited),
2. I am staying within the same level (e.g., from Limited to Limited), and
3. I am transiting down a level (e.g., from Limited down to Controlled).
SP800-116 mainly addresses (1). Appendix C provides for every possible combination of transition between levels in this context. Note that FIPS 201-2 deprecated CHUID Authentication.
SP800-116 does not cover (3). Security professionals should look to other federal guidance and policy sources as may be applicable to their facility to determine how to manage this transition. Documents from the Interagency Security Committee and other best practices in physical security should be consulted with special attention paid if to mustering if that is a requirement of the building.
SP800-116 covers (2). For any level other than exclusionary, any PIV authentication mechanism may be used when staying at the same level. For an exclusionary area, a two or three-factor mechanism should be used.
1 Note on Testing Criteria Applied: The Program has published the FICAM Testing Program Functional Requirements and Test Cases document, which specifies the functional requirements the Program uses to test a PACS submitted for approval. All requirements are tested using a smart card as presented to the PACS and various Public Key Infrastructure (PKI) paths. The PKI and smart cards test for specific common failures in smart cards and PKI, as well as Advanced Persistent Threat (APT) issues that impact PACS specifically.
2 Note on the Use of the Term "Topologies": Industry has noted that there is more than one possible PACS end-to-end configuration ( also called "Topology"). The FIPS 201 / FICAM Testing Program is agnostic to topology and focuses solely on functional testing using an end-to-end testing methodology. The Program encourages industry innovation and supports varying topologies. A new topology can be proposed to the Program via the streamlined "Topology Adoption Process". Adoption is based on whether the proposed topology is commercially available, conformant to applicable Program functional requirements, and is in the best interest of the federal government.