Physical Access Control Systems 101

Introduction

The Physical Access Control System (PACS) 101 will help you understand concepts related to Federal Identity, Credential, and Access Management-compliant PACSs. At a high level, a PACS is a collection of technologies that control physical access at one or more federal agency sites by electronically authenticating employees, contractors, and visitors.

The contents of these 101 guides are meant to be informative and do not serve as the basis for determining PACS compliance. Agency-specific guidance should supersede the recommendations within these guides, where appropriate.

Acknowledgment

We want to thank the Secure Technology Alliance, especially the members of the Access Control Council, for contributions to the original PACS Guides which is now the PACS 101 page and permission to reuse content from their presentations and the How to Plan, Procure and Deploy a pacs-Enabled Physical Access Control System webinar training.

PACS Explained

A Physical Access Control System (PACS) grants access to employees and contractors who work at or visit a site by electronically authenticating their PIV credentials. Although PACSs are information technology (IT) systems, they must be designed, deployed, and operated in cooperation with Physical Security teams to successfully meet agency mission needs.

Components

The following table defines common PACS components:

Component	Description
Access point	Entrance point or physical barrier where an employee or contractor interacts with the PACS. Example access points include turnstiles, gates, and locking doors.
PIV credential	Federal employees and contractors use Personal Identity Verification (PIV) credentials to physically access federal facilities and logically access federal information systems.
Credential reader and keypad	The reader provides power to and reads data from a PIV credential. The reader also sends this data to a control panel to authenticate the PIV credential and request access authorization. Employees and contractors may need to enter a PIN into the keypad and add a biometric, depending on the facility’s security classification and risk levels.
Biometric reader	Captures biometric data (for example, fingerprint or iris scan) and verifies it against the PIV credential’s biometric data.
Control panel	Receives the credential data sent by the reader and verifies its presence in the credential holder data repository. It then makes an access decision and transmits authorization data to the access control server and access point.
Access control server	Grants authorization to the employee or contractor requesting access (for example, presenting a PIV credential to a reader). It also registers and enrolls employees and contractors, enrolls and validates credentials, and logs system events.
Credential holder data repository	Contains employee and contractor data and physical access privileges. Control panels use this authoritative data to validate credential data.
Auxiliary Systems	Agencies may integrate the PACS with additional facility monitoring systems such as surveillance systems, fire alarm systems, and evacuation systems.

All agency-purchased PACS components must be FIPS 201-compliant and selected from GSA's Approved Products List (APL) for PACS Products. The products in this list have undergone vulnerability and interoperability testing through the FIPS 201 Evaluation Program. As an IT system, a PACS must still complete Certification and Accreditation and obtain an Authority to Operate from your agency before connecting to the network.

Compliant PACS Characteristics

In May 2019, the Office of Management and Budget (OMB) released memorandum M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management. Related to PACS, M-19-17 rescinded memorandum M-11-11, Continued Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors. The updated guidance adds further specificity to require the use of PIV credentials for physical access to federal facilities, implemented per The Risk Management Process for Federal Facilities: An Interagency Security Committee Standard and NIST SP 800-116, Revision 1, _ Guidelines for the Use of PIV Credentials in Facility Access_.

Characteristics of NIST SP 800-116, Revision 1, compliant systems include, but are not limited to:

Use high-assurance credentials for electronic authentication of employees and contractors.
Use non-deprecated authentication mechanisms, as defined by FIPS 201-3.
Validate the status and authenticity of credentials.
Interoperate with PIV credentials issued by other agencies.
Use components listed on the GSA FIPS 201 Approved Products List (APL).

The FIPS 201 Evaluation Program in collaboration with the PACS Modernization Working Group created an operational self-assessment tool. The tool helps PACS implementers determine if facility access systems that use PIV credentials are configured according to FICAM and NIST guidelines.

PACS Assessment Toolkit Version 1.0

Deployment Models

There are two PACS deployment models.

Standalone PACS - a local system that controls physical access to a facility or specific areas within it.
Enterprise PACS (E-PACS) - extends the concept of a standalone PACS to act as a unified, enterprise-wide system that controls physical access at most (or all) sites that belong to an agency.

Standalone PACS

A standalone PACS is a local system that controls physical access to a facility or specific areas within it—for example, a Sensitive Compartmented Information Facility (SCIF). Standalone PACSs are facility-centric, and consequently, these systems typically do not connect to enterprise networks. While this deployment model tends to be the most common and uncomplicated method of managing access to controlled areas, it has several challenges.

Standalone PACS’ Operational Challenges

Agencies that use standalone PACSs have encountered operational challenges:

Sites must independently control physical access.
Agencies see delays with credential transfers or terminations.
Employees and contractors must re-enroll their credentials for all federal work sites that they visit.
Departments inconsistently apply enterprise-wide security policies.
Agencies experience reduced situational awareness (for example, logs cannot be correlated across the enterprise).
Agencies with many standalone PACSs see increased human error, such as data entry errors.

Can agencies centrally control physical access for most, or all, of their sites? Yes. The answer is to implement an Enterprise Physical Access Control System.

Enterprise PACS

An Enterprise PACS (E-PACS) extends the concept of a standalone PACS to act as a unified, enterprise-wide system that controls physical access at most (or all) sites that belong to an agency. E-PACSs address the operational challenges of standalone PACSs and improve system management, scalability, monitoring, and performance.

E-PACSs rely on the same components as standalone PACSs. However, an essential architectural distinction is that an E-PACS connects to an agency’s enterprise network, whereas a PACS typically does not.

Some agencies need standalone PACSs for their unique sites and missions, but most agencies could benefit from transitioning to an E-PACS.

Would an Enterprise PACS Work for Our Agency?

Here are some key E-PACS advantages to consider:

One enterprise-wide system controls physical access for many (or all) agency sites.
One employee and contractor enrollment system that connects multiple enrollment locations.
One credential registration and provisioning point.
One enterprise-wide system for administrators to modify or terminate access privileges.
One enterprise-wide system that regularly polls for Certificate Revocation List (CRL) updates and maintains revocation data.
Reduced costs for system management, such as patching, server system administration, and software updates.
Reduced costs for reporting, such as Federal Information Security Modernization Act [FISMA] reporting.
Reduced costs for:
- Server hardware
- System security assessment and accreditation

Aligning Facility Security Level and Authentication

Federal agencies rely on Physical Access Control Systems (PACSs) and Personal Identity Verification (PIV) credentials to confirm that an employee, contractor, or visitor is or is not authorized to access a site and its critical assets, such as systems, information, and people.

To protect your agency’s critical assets, you must assess each site’s risk level (called Facility Security Level) and decide what level of PIV credential authentication is required (called authentication mechanism).

Additional guidance regarding aligning FSL to PACS authentication factors can be found in the Security Control Overlay for Electronic Physical Access Control Systems (ePACS) . This overlay provides additional guidance on configuring and securing PACS systems in accordance with relevant guidance and in support of the NIST Risk Management Framework (RMF).

Assess Facility Security Level

These federal standards provide guidance for assessing FSL, including how to categorize site risks:
- The Risk Management Process for Federal Facilities: An Interagency Security Committee Standard
- NIST SP 800-116, Revision 1, Guidelines for the Use of PIV Credentials in Facility Access.

Inventory critical assets for each agency site

When you inventory critical assets, also document any challenges to secure them.

Examples of critical assets include:
- People
- Information systems and IT infrastructure
- Campuses, buildings, secure vaults, and armories
- Tenant agencies’ people, information systems, and IT infrastructure
If you must evaluate an asset’s criticality, consider:
- Security classification level
- Impact on national security from potential asset loss, compromise, or damage
- Cost of replacing the asset

Assess site, critical asset risks, and risks to tenant agencies’ assets

Examples of potential risks to a site and its critical assets include:
- Site mission(s) (those of the agency, its organizations, and tenant agencies)
- Site “symbolism” (public perception of the agency, its organizations, tenant agencies, or missions)
- Total population (employees plus contractors)
- Size (square footage)
- Geographical location
- Proximity to other facilities or structures not owned by the agency
- Threats specific to tenant agencies
Consider the following for each asset:
- Criticality - Is it mission-critical?
- Sensitivity - Does it contain classified or sensitive information?
- Likelihood - What is the probability of loss, compromise, or damage?

Categorize each asset by risk impact level

FIPS 199 defines three (3) impact levels on organizations and people (that is, a loss of confidentiality, integrity, or availability):

Impact Level	Description
Low	The loss of confidentiality, integrity, or availability could have a limited adverse effect on organizational operations, organizational assets, or individuals.
Moderate	The loss of confidentiality, integrity, or availability could have a serious adverse effect on organizational operations, organizational assets, or individuals.
High	The loss of confidentiality, integrity, or availability could have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Create a site map of categorized assets

This map will help you determine each security area’s minimum security level.

As an alternative to assessing a site's risk, you can select a pre-determined FSL as described in The Risk Management Process for Federal Facilities: An Interagency Security Committee Standard.

Categorize Security Areas

Agencies may use different terms for their security areas; however, each agency should establish its criteria for authentication mechanisms, according to NIST SP 800-116, Revision 1, Guidelines for the Use of PIV Credentials in Facility Access.

Categorize security areas

Once you’ve inventoried and mapped assets by risk and impact level, it’s time to categorize security areas.
NIST SP 800-116, Revision 1, defines three (3) security area categories:

Category	Description
Exclusion	An area where uncontrolled movement would permit direct access to a security asset, such as a Sensitive Compartmented Information Facility (SCIF).
Limited	An area near a secure asset. Uncontrolled movement within a limited area may permit access to an asset. Escorts and other restrictions can prevent access.
Controlled	An area near or surrounding a Limited or Exclusion area, such as a facility lobby. A Controlled area provides administrative control, safety, or a buffer zone for embedded Limited or Exclusion areas. Movement of authorized personnel within this area usually is not controlled because this area doesn’t provide immediate access to secure assets.

Assign the same risk level as the highest risk asset within the area.
- Example: If three (3) assets exist within a security area: one Low-risk, one Moderate-risk, and one High-risk, you must categorize the security area as High-risk. Alternatively, the area may be split into three (3) security areas that each have a different risk level.

Determine Authentication Factors

NIST SP 800-116, Revision 1, Guidelines for the Use of PIV Credentials in Facility Access recommends the following method to determine authentication factors for Exclusion, Limited and Controlled security areas.

Determine authentication factors required for security area categories

Once you have categorized all security area categories, you will select the minimum number of authentication factors (1, 2, or 3) needed to access and safeguard the facility:

Category	Minimum Number of Factors	Description
Exclusion	3	Exclusion areas require all three authentication factors: Something you have, such as a PIV credential; something you know, such as the PIV credential PIN; and something you have on or in your body, such as a fingerprint or iris scan.
Limited	2	Limited areas require 2 of the 3 authentication factors, such as a PIV credential and PIN or a PIV credential and fingerprint or iris scan.
Controlled	1	Controlled areas require only one authentication factor, such as a PIV credential.

Select Authentication Mechanisms

FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, defines authentication mechanisms at four assurance levels (Little or No, Some, High, and Very High).

Select authentication mechanism for each security area

Based on the security area categories and required authentication factors for each security area, choose the PIV credential authentication mechanism(s) that enforce these factors at each access point.
FIPS 201-2 specifies these authentication mechanisms for PIV credentials:
- PKI authentication using the PIV Authentication Certificate (PKI-AUTH)
- PKI authentication using the Card Authentication Certificate (PKI-CAK)
- Authentication using the Symmetric Card Authentication Key (SYM-CAK)
- Unattended authentication using off-card biometric comparisons (BIO)
- Attended authentication using off-card biometric comparisons (BIO-A)
- Either attended or unattended authentication using off-card biometric comparisons (BIO(-A))
- Authentication using on-card biometric comparisons (OCC-AUTH)

The table below gives the possible authentication mechanisms for the three (3) security area categories defined by NIST SP 800-116, Revision 1:

Category	Minimum Number of Factors	Acceptable Factors	Authentication Mechanism: Contact Interface	Authentication Mechanism: Contactless Interface
Exclusion	3	Something you have AND Something you know AND Something you have on or in your body	PKI-AUTH + BIO	N/A
Limited	2	Something you have AND Something you know, OR Something you have AND Something you have on or in your body, OR Something you know AND Something you have on or in your body	PKI-AUTH (with PIN or OCC) or OCC-AUTH	OCC-AUTH
Controlled	1	Something you have OR Something you have on or in your body	PKI-CAK	PKI-CAK SYM-CAK

Note: Some authentication mechanisms defined by NIST SP 800-116, Revision 1 might not be available on all user-population cards (for example, on-card biometric comparison or PKI-CAK).

When using PKI-CAK and PKI-AUTH as authentication mechanisms, certificates must be validated. Verify the certificate against a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) server response. Also, verify that the certificate chains to the Federal Common Policy root certification authority (CA).

Visit the PKI 101 to learn more about certificate trust.

A good starting point that will help you understand Physical Access Control System procurements is GSA’s PACS Customer Ordering Guide.

This page provides a sample PACS Procurement Checklist. You can reuse or tailor this checklist according to your agency’s practices. The checklist highlights common procurement activities as they relate to the following roles:

Information Technology or Physical Security Engineers (ENG)
Project Managers (PM)
Procurement Officers (PO)
Chief Information Officers (CIO)
Chief Security Officers (CSO)

Agency staff are encouraged to participate in steps where their roles are listed in bold underlined font.

PACS Procurement Best Practices

PACS Procurement Checklist	Recommended Participants
1. Identify your agency’s need to procure or upgrade a PACS.	ENG	PM	PO	CIO	CSO
Determine whether your agency has similar efforts underway or other projects that could impact the procurement. Determine why the agency needs to procure or upgrade a PACS. Perform a cost-benefit analysis.
2. Develop a PACS project charter.	ENG	PM	PO	CIO	CSO
Identify the PACS project’s executive sponsor. Document a high-level project purpose, scope, and goals. Determine the PACS deployment model required for the project's scope. Identify what standards and requirements need to be addressed (for example, HSPD-12, FIPS 201-3, NIST SP 800-116, Revision 1). Estimate the project's duration.
3. Identify and obtain support from PACS stakeholders (iterative).	ENG	PM	PO	CIO	CSO
Identify your required and optional stakeholders and request their participation. Include national, regional, state, and local stakeholders. Involve stakeholders from agency information technology (IT) teams (for example, architects/engineers, network engineers, security, infrastructure services, directory services, web services). Involve agency facility and personnel support organizations (for example, physical security, building operations, Human Resources).
4. Identify PACS project phases and tasks (iterative).	ENG	PM	PO	CIO	CSO
Document the project’s phases and required tasks. Samples include: Pre-project planning Site security assessment(s) Statement of Work (SOW) PACS Requirements Document (or Specification) Request for Information (RFI) Request for Proposal (RFP)/Request for Quotation (RFQ) Integrator (vendor) evaluation and award Design Implementation Inspections Testing Close-out Sustainment
5. Develop a project schedule (iterative).	ENG	PM	PO	CIO	CSO
Use automated tools or agency software to create a project schedule (that is, project tasks, dependencies, durations, and resources). Share the project schedule with stakeholders to ensure it is accurate and complete.
6. Conduct a Facility Security Level (FSL) assessment of project-related agency sites and determine Personal Identity Verification (PIV) authentication mechanisms for each site.	ENG	PM	PO	CIO	CSO
For details, see Aligning FSL and Authentication Mechanism. The FSL assessment and chosen PIV authentication mechanisms will form the basis for the PACS requirements document/specification as well as affect the SOW and project costs. The sample survey questions below will help you assess the FSL of each facility and select the right PIV authentication mechanisms: Who will use a facility’s PACS? Include all possible users. What credentials do the facility’s users and visitors have? What facility access risks exist? How can the facility mitigate these risks? What PACS installations does the facility need? What support systems would be integrated into the facility’s PACS (for example, intrusion detection, video surveillance, emergency notification, elevator control)? What PACS integrator or other contractor services does the agency need to solicit bids on? What PACS hardware and software is needed? Your agency’s selected integrator will help select the approved, needed hardware and software through the GSA Acquisitions process (Schedules 70 and 84, Blanket Purchase Orders, etc.). The following are some useful considerations: What are the facility’s common ingress and egress traffic patterns? What throughput speeds are needed? What are the ongoing operational and projected maintenance needs? What are the training needs for PACS administrators, operators, technicians, and users? Which PIV authentication mechanism(s) will be needed to secure the facility?
7. Develop a PACS requirements document or specification.	ENG	PM	PO	CIO	CSO
When documenting PACS requirements, it is critical to solicit input from your stakeholders. Organize requirements into clear categories (for example, technical, performance, and operational) to help stakeholders give targeted feedback.
8. Release a Request for Information (RFI) to potential service providers.	ENG	PM	PO	CIO	CSO
Create and issue an RFI to vendors that requests specific qualifications and capabilities against PACS requirements.
9. Submit an IT funding proposal following your agency’s budgetary process.	ENG	PM	PO	CIO	CSO
Follow your agency's existing budgetary procedures to submit a funding proposal for the project.
10. Develop an RFP and SOW to solicit GSA-approved integrator bids.	ENG	PM	PO	CIO	CSO
You can reuse the GSA PACS Customer Ordering Guide’s Sample Statement of Work, page 17. For help creating an RFP, see Enabling Strong Authentication with PIV Cards: PKI in Enterprise PACS Recommended Procurement Language for RFPs Version 1.1.0. For help with Requests for Quotations (RFQs), see GSA’s eBuy RFQ Online Tool.
11. Solicit bids, evaluate, and award integrator contract.	ENG	PM	PO	CIO	CSO
Include these steps during your bid and evaluation process: Identify members of the evaluation committee. Establish evaluation criteria for bid review. Identify how well proposed integrator solutions meet your needs. Document the award rationale and announce the contract award decision. Upon request, provide a brief explanation of the award rationale to unsuccessful bidder(s).
12. Develop a PACS architecture and migration strategy.	ENG	PM	PO	CIO	CSO
Define a migration strategy to transition facilities to the new PACS solution.
13. Buy products listed on the GSA PACS APL.	ENG	PM	PO	CIO	CSO
After contract award, your integrator will help you: Choose the best PACS topology (that is, an end-to-end solution of hardware, software, a Certificate Validation System, and PIV credential readers) listed on the GSA PACS APL for the PIV authentication mechanisms selected for your facility. Buy the products and additional services you need by using the GSA Multiple Award Schedule (MAS). Your chosen integrator will help your agency choose the right PACS products and services, according to your agency’s preferred GSA purchasing vehicle(s). Want to learn more about GSA Schedules? Training is available: On-demand GSA Schedules Training. For help with GSA Schedules, email the GSA National Customer Service Center at NCSCcustomer dot service at gsa dot gov or call 1-800-488-3111.

If at any time you have PACS procurement questions, contact the GSA IT Customer Service at ITCSC at gsa dot gov or call 1-855-482-4348.

Why Can We Buy Only GSA-Approved Products and Services?

GSA’s FIPS 201 Evaluation Program tests all GSA-listed PACS products, topologies, and services for compliance with FIPS 201 requirements. Purchasing products listed on the GSA APL ensures product compliance with FIPS 201, secure operations, and interoperability.

What Other GSA Resources Can Help Us?

GSA Schedules - General Information
GSA Schedules - Tools and Resources
GSA Multiple Awards Schedule (MAS)
GSA Multiple Awards Schedule (MAS) Categories
GSA Multiple Awards Schedule (MAS) News and Updates
GSA’s eBuy RFQ online system enables you to post requirements, obtain quotes, and issue orders electronically.
Approved Certified System Engineer ICAM PACS (CSEIP) List. Agencies must use FIPS 201-approved integrators and other contractors. The “lead designer” for FIPS 201-approved integrators must possess a Certified System Engineer ICAM PACS (CSEIP) certification or be certified by another federally recognized certification program.

Training

Specialized training is essential for Physical Access Control System (PACS) technical leads and team members. This page describes roles, responsibilities, and training opportunities.

Technical Roles and Responsibilities

PACS project teams consist of both agency employees and contractors. Teams include an IT Architect, Engineers, Technicians, Operators, System Administrators, Physical Security Specialists, Facility Managers, a variety of technical services team members, etc. The table below describes the most common PACS technical roles:

Technical Role	Responsibilities
IT Architect	Defines the project’s technical activities according to the project scope and requirements; conducts further analysis and design, as required; and directs the implementation of a PACS solution.
Engineer	Makes configuration recommendations and advises the IT Architect about enterprise-wide network improvements, PACS hardware and software optimization, testing, deployment, and maintenance.
Technician	Installs, administers, and maintains network and system components.
Operator	Uses physical security functions, such as setting access privileges or taking actions to resolve system-generated events and alarms.

IT Architects, Engineers, and Operators may be federal employees and/or contractors. Technicians are typically contractors.

Teams also include a PACS Project Manager, Procurements Official or Specialist, project management specialists, budget analysts, lawyer(s), etc.

Recommended Technical Training

Role	Recommended Training
IT Architects	Must be knowledgeable about the GSA PACS APL and the manufacturers’ solutions for PACS. Should be knowledgeable about federal government and agency-specific policies, standards, and guidance documents to make design recommendations related to PACS implementation. In order to implement a PACS solution, IT Architects must possess a current Certified System Engineer ICAM PACS (CSEIP) certification. There are no other similar, federally recognized certifications as of May 24, 2022.
Engineers	May hold a CSEIP certification. There are no other similar, federally recognized certifications as of May 24, 2022. Engineers may optionally complete PACS product manufacturers’ training (for example, PACS APL products) related to the PACS implementation. Should be knowledgeable about federal government and agency-specific policies, standards, and guidance documents related to enterprise networks and PACS implementation.
Technicians	Should complete PACS product manufacturers’ training (i.e., PACS APL products) related to the PACS solution implementation.
Operators	Should complete tailored training in federal government policies and standards related to PACS. Completing PACS product manufacturers’ (i.e., PACS APL products) certification related to the PACS implementation is recommended.

Agencies must specify their requirements for specific roles, responsibilities, and training in their Request for Information (RFI) (that is, request for contractor qualifications statements) and Statement of Work (SOW).

Training Opportunities

Agencies that plan to initiate a PACS project should include line items for related employee training in their annual training plans and annual training budgets.

Department of Homeland Security - Interagency Security Committee

The Interagency Security Committee developed a series of free, self-paced, online training courses that provide an overview of facility security standards, processes, and practices.

Equipment Manufacturers

GSA PACS APL PACS manufacturers whose products are listed on the GSA PACS APL offer product-specific courses for Operators and Technicians directly or through authorized service providers. Operators and Technicians may obtain certifications for completing some series of courses.

Note: Manufacturer training may not address unique operational requirements or site-specific configurations, so authorized service providers should conduct this training: GSA Multiple Award Schedule (MAS).

Authorized Service Providers

Authorized service providers offer manufacturer training for installing, configuring, and maintaining PACSs: GSA Multiple Award Schedule (MAS). This training can be tailored to your agency, facility, implementation features, operational policies, and procedures. This training should be planned during the Procurements phase.

Industry Certifications

Industry certifications are vendor neutral and standards based. GSA requires that all work performed on approved PACS for GSA-managed facilities must be designed and installed by a Certified System Engineer for ICAM PACS (CSEIP). The CSEIP Program trains those who implement solutions related to OMB M-05-24 and OMB M-19-17.

Commercial vendors offer additional certification opportunities.

GSA PACS Reverse Industry Day Conference (2018)

In 2018, GSA hosted a PACS Reverse Industry Day conference that featured government and industry experts on a range of PACS topics. Event videos are available via the GSA YouTube channel:

Lessons Learned

Federal agencies have shared these PACS lessons learned:

Planning

Identify all stakeholders upfront, including an Executive Sponsor.
Designate staff to fill key roles, such as architects, engineers, and operators.
Engage CIO/CISO representatives early. Remember: A PACS is an IT system.
As an IT system, a PACS must complete Certification and Accreditation and obtain an Authority to Operate before connecting to the network.
Create, maintain, and share an integrated master schedule that presents project phases, tasks, resources, and dependencies.
Establish a PACS component lifecycle management plan to help estimate hardware and software upgrades over the life of the system.
Build the cost of software licensing and system sustainment into your project budget.
Work with facility engineers to identify constraints specific to your workplace, such as mandatory construction requirements. These constraints may limit solution offerings.
Consider the impact on the federal facility population when modernizing PACS assets, especially if your agency is moving toward FICAM-compliant PACS.
Plan a standardized deployment strategy across locations.
Remember that legacy system hardware, such as credential readers, may not support FICAM-compliant modes of operation. (FICAM Mode implies using PKI-based authentication mechanisms and online identity validation.) Review your system hardware capabilities after identifying desired authentication mechanisms to determine if upgrades are necessary.
Use legacy credentials and non-FICAM compliant modes of operation only in a migration strategy, not as the end state.
Retire and phase out secondary, legacy credentials.
Use your agency Identity Management System as the authoritative source for all user records in the PACS.
Recall that some PACS allow assignment of user access levels at the time of credential registration. Plan the method of assignment before provisioning/registration.
Avoid acts of “omission” that create noncompliance. For example, procuring products listed on the Approved Products List (APL) but not correctly enabling FICAM Mode.
Use a risk-based approach when selecting appropriate PIV authentication mechanisms for physical access to federal government buildings and facilities, regardless of whether they are leased or government-owned.
Remember that access points should not rely solely on an authentication mechanism that requires optional card features, as these features might not be available on all user-population cards (for example, on-card biometric comparison).
Plan the PACS to meet the needs of the operating environment (for example, do not require three-factor authentication when only one factor is needed).
Understand that PKI is the foundation for high-assurance PACS implementations.

Procurement

Do not procure noncompliant PACS technologies, such as proximity cards.
Use consistent terms and recommended procurement language within requirements documents, specifications, SOWs, RFIs, RFPs, and RFQs.
Leverage agency subject matter experts (SMEs) to review SOWs, RFPs, and RFQs before releasing them for bid.
Resolve SOW and PACS compliance issues as soon as they are recognized.
Work closely with agency legal team members to define an SOW that contains unambiguous responsibilities for the integrator and appropriate cures for non-performance.
Have your integrator provide copies of all relevant FIPS 201-3 compliance and functionality testing documentation.
Specify personnel roles, responsibilities, and training requirements within the SOW (for example, all engineers must be CSEIP certified).
Ensure qualified professionals and/or SMEs review the design documents before releasing them for bid or formal contractor response. Consider hiring an SME capability to augment agency staff as a “buyer’s agent” during these activities.
Consider looking for evidence of qualified and/or registered personnel certifying the proposed solution (submittals) before approval or notice to proceed.

Operations

Define clear processes and procedures to support the remedy of system incidents (for example, a failed credential reader). Be sure to identify key support personnel and expected levels of support.
Perform regular system maintenance and patching of the PACS components. Establish clear procedures for testing upgrades prior to widespread deployment, and develop “roll-back” procedures in the event they are required.
Ensure the PACS is configured and maintained to operate in FICAM Mode.
Work with your IT Department to ensure your PACS can perform online certificate validation. Credential validation should take place at or near the time of authentication. If your PACS is limited to offline certificate validation, manually load CRLs and certificate trust lists into the PACS daily.
Provision only assured identities from an agency authoritative source into your PACS.
Consider having the PACS administrator disable PIV credentials that are invalid (expired, certificates placed on CRL, etc.) immediately rather than waiting for automatic disabling through the routine credential validation process. Consider disabling identity and credential records rather than removing them to retain audit data that might be needed at a later time (for example, employee misconduct investigations).
Remove all PII from PACS endpoints to protect privacy.
Audit expected system functionality on a regular basis. Minimally, verify that access points are challenging the correct number and type of authentication factors. Consider using test credentials that have expired or been revoked to further ensure correct operation.

Training

Create and maintain a training plan that formally documents training requirements.
Provide role-specific training to agency stakeholders, such as HR, IT, or Security.

References

Public Law

Federal Information Security Modernization Act (FISMA) of 2014, Public Law No. 113-283.

Policies

OMB M-15-13, “Policy to Require Secure Connections Across Federal Websites and Web Services”, June 8, 2015

OMB Circular A-130, “Managing Information as a Strategic Resource”, July 2016

OMB M-05-24, “Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and Contractors”, August 5, 2005

OMB M-19-17, Enabling Mission Delivery Through Improved Identity, Credential, and Access Management, May 21, 2019

E.O. 13800, “Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure”, May 11, 2017

E.O. 13636 and PPD-21 - “Fact Sheet: Improving Critical Infrastructure Cybersecurity and Critical Infrastructure Security and Resilience”), December 2020

Regulations

Federal Acquisition Regulation (FAR)

Standards

FIPS PUB 199, Standards for Security Categorization of Federal Information and Information Systems, NIST, February 2004

FIPS PUB 200, Minimum Security Requirements for Federal Information and Information Systems, NIST, March 9, 2006

FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, NIST, January 2022

NIST SP 800-53, Revision 5, Recommended Security Controls for Federal Information Systems and Organizations, September 2020

NIST SP 800-60, Volume 1, Revision 1, Guide for Mapping Types of Information and Information Systems to Security Categories, August 2008

NIST SP 800-60, Volume II, Revision 1, Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories, August 2008

NIST SP 800-73-4, Interfaces for Personal Identity Verification, Parts 1 and 2, May 2015 (Updated February 8, 2016)

NIST SP 800-116, Revision 1, Guidelines for the Use of PIV Credentials in Facility Access, June 2018

NIST SP 800-171, Revision 2, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations, February 2020

Guidance and Best Practices

Compliance Guide: The HTTPS-Only Standard

Best Practices for Planning and Managing Physical Security Resources: An Interagency Security Committee Guide, Interagency Security Council (ISC), December 2015

Enabling Strong Authentication with PIV Cards: Public Key Infrastructure (PKI) in Enterprise Physical Access Control Systems (E-PACS) Recommended Procurement Language for RFPs, v1.1.0, GSA, February 24, 2015

Facility Access Control: An Interagency Security Committee Best Practice, 2020 Edition

PACS Customer Ordering Guide (v2.0), GSA Schedule 84 - Security, Fire, & Law Enforcement, June 2018

Personal Identity Verification (PIV) in Enterprise Physical Access Control Systems (E-PACS), Interagency Security Committee (ISC), Version 3.0, March 26, 2014

Personal Identity Verification Interoperability for Issuers, Version 2.0.1, July 27, 2017

The Risk Management Process for Federal Facilities: An Interagency Security Committee Standard, ISC, 2nd Edition, November 2016

Security Control Overlay of Special Publication 800-53 Revision 5: Security Controls for Electronic Physical Access Control Systems (ePACS), Version 1.0, December 2020

Federal Public Key Infrastructure (FPKI) Security Controls Overlay of Special Publication 800-53 Security Controls for PKI Systems, Version 3.0, February 26, 2021

Other Relevant Publications

“Federal Building Security: Actions Needed to Help Achieve Vision for Secure, Interoperable Physical Access Control”, Government Accountability Office (GAO), December 20, 2018

Glossary

NIST SP-800-116, Revision 1, "Guidelines for the Use of PIV Credentials in Facility Access" Appendix G contains additional PACS-related terms and definitions.

Access Control - The process of granting or denying specific requests to: (1) obtain and use information and related information processing services; and (2) enter physical facilities, such as federal buildings, military establishments, and border crossing entrances.
Access Point - An access point can be a door, turnstile, or other physical barrier where granting access can be electronically controlled.
Authentication - The process of establishing confidence in the authenticity and validity of a person’s identity.
Authentication Factors - Authentication systems are often categorized by the number of factors that they incorporate. The three factors often considered as the cornerstone of authentication are something you know (for example, a password), something you have (for example, an ID badge or a cryptographic key), and something you are (for example, a thumbprint or other biometric data). Authentication systems that incorporate all three factors are stronger than systems that only incorporate one or two of the factors.
Authorization - Grants access to only the resources a person needs to perform a job. A person with an authentic, high-assurance credential (PIV or CAC) will not have access to all resources. In a large enterprise with thousands of employees and contractors needing access to hundreds of different access points, attempting to manage authorization manually is costly, time consuming, and error-prone.
Biometric - A measurable, physical characteristic or personal behavioral trait used to recognize the identity, or verify the claimed identity, of an applicant. Facial images, fingerprints, and iris image samples are all examples of biometrics.
BIO - A FIPS 201 authentication mechanism that is implemented by using a fingerprint or iris images data object sent from the PIV credential to the PACS and which is matched to the credential holder’s live scan.
BIO-A - A FIPS 201 authentication mechanism in which the BIO authentication mechanism is performed in the presence of an attendant who supervises the use of the PIV credential and the submission of the PIN and the sample biometric by the credential holder.
BIO(-A) - A shorthand used to represent both BIO and BIO-A authentication mechanisms.
Credential - A collection of information about a person, attested to by an issuing authority. A credential is a data object, such as a certificate, that can be used to authenticate the credential holder. One or more data object credentials may be stored on the same physical memory device, such as a PIV card.
Credential Validation - The process of determining if a credential is valid, which can include the following requirements:
- The credential was legitimately issued.
- The credential’s activation date has been reached.
- The credential has not expired.
- The credential has not been tampered with.
- The credential has not been suspended or revoked by the issuing authority.
Certificate Revocation List - A list of revoked public key certificates created and digitally signed by a certification authority.
Identity Management System (IDMS) - A system comprising one or more systems or applications that manages the identity verification, validation, and issuance process.
Identity Registration - The process of making a person’s identity known to the PIV system, associating a unique identifier with that identity, and collecting and recording the person’s relevant attributes in the system.
Identity Verification - The process of confirming or denying that a claimed identity is correct by comparing the credentials (something you know, something you have, something you are) of a person requesting access with those previously proven and stored in the PIV credential or system and associated with the identity being claimed.
Interoperability - The quality of allowing any government facility or information system to verify a credential holder’s identity using the credentials on the PIV credential, regardless of issuer.
OCC-AUTH - A two-factor authentication mechanism that uses secure messaging and an on-credential comparison of credential holder fingerprint(s).
Physical Access Control System - An electronic system that controls the ability of people to enter a protected area, by means of authentication and authorization at access control points.
PKI-AUTH - A PIV authentication mechanism that is implemented by an asymmetric key challenge/response protocol using the PIV Authentication certificate and key.
PKI-CAK - A PIV authentication mechanism that is implemented by an asymmetric key challenge/response protocol using the Card Authentication certificate and key.
Provisioning - The process of specifying for each identity both the credential used (for example, a PIV, CAC, or PIV-I card) and the privileges granted to access specific resources (for example, a particular facility, door, or access point), and ensuring that a complex set of rules is enforced.
SYM-CAK - An authentication mechanism based on the optional symmetric card authentication key. As the name implies, the purpose of the SYM-CAK authentication mechanism is to authenticate the credential and thereby the credential holder.
Validation - The process of determining that an identity credential was legitimately issued and is still valid (that is, the credential has not expired or been revoked).