Physical Access Control Systems 101

Introduction

The Physical Access Control System (PACS) 101 will help you understand Federal Identity, Credential, and Access Management-compliant PACSs concepts. 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.

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 PIV-Enabled Physical Access Control System webinar training. Links to the training are below in the training section.

PACS Explained

A Physical Access Control System (PACS) grants access to employees, contractors, and visitors 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 meet agency mission needs.

Components

The following table defines common PACS components:

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 whether 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.

1. Standalone PACS - a local system that controls physical access to a facility or specific areas within the facility.
2. 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; 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.

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) agency-owned sites. 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.

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 Authorization (A & A)

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 PIV credential authentication is required (called authentication mechanism).

The Security Control Overlay for Electronic Physical Access Control Systems (ePACS) provides additional guidance on aligning FSL to PACS authentication factors. 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

  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):

 Create a site map of categorized assets

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

Categorize Security Areas

 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:

• 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

 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:

Select Authentication Mechanisms

 Select authentication mechanisms 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-3 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)
  • PIV authentication using the Secure Message key (SM-AUTH)
  • 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 fingerprint biometric comparisons (OCC-AUTH)

The table below gives the possible authentication mechanisms for the three (3) security area categories:

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, off-card biometric comparison). Certificates must be validated when using PKI-CAK and PKI-AUTH as authentication mechanisms. 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 PKI 101 to learn more about certificate trust.

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 that list their roles in bold, underlined font.

PACS Procurement Best Practices

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 lets 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:

Recommended Technical Training

Training Opportunities

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. It should be planned during the Procurement 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.

Industry Training

The Secure Technology Alliance Access Control Council held a six-part webinar on planning, procuring, and implementing PIV-enabled physical access control systems (PACS) for government facilities. The series was created for systems engineers, facility managers, physical security personnel, and other government facility stakeholders.

Webinar sessions feature industry and government experts covering: -Identifying stakeholders involved in deploying a PIV-enabled PACS -Planning implementation: facility characterization and risks -Establishing the project scope -Developing and implementing the procurement strategy -Deploying the chosen solution -Reviewing use cases and agency lessons learned

Recordings of completed webinars are available. Part 1: How to Plan, Procure, and Deploy a PIV-Enabled Physical Access Control System Part 2: Facility Characterization and Risk Management Part 3: Establishing the Project Scope Part 4: Developing the Procurement Strategy Part 5: Implementing the Solution Part 6: Use Cases and Lessons Learned

GSA PACS Reverse Industry Day Conference (2018)

In 2018, GSA hosted a PACS Reverse Industry Day conference featuring government and industry experts on various PACS topics. Event videos are available via the GSA YouTube channe:

• Morning Session
• Afternoon Session

Lessons Learned

Federal agencies have shared these PACS lessons learned:

Planning

• Identify all stakeholders upfront, including an Executive Sponsor.
• Designate staff, such as architects, engineers, and operators, to fill key roles.
• 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 system’s lifetime.
• 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.
• When modernizing PACS assets, consider the impact on the federal facility population, 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.) After identifying desired authentication mechanisms, review your system hardware capabilities 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’s Identity Management System as the authoritative source for all user records in the PACS.
• Recall that some PACS allows the 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, whether 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 operating environment’s needs (e.g., 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 capable of augmenting agency staff as a “buyer’s agent” during these activities
• Consider seeking evidence of qualified and/or registered personnel certifying the proposed solution (submittals) before approval or notice to proceed.

Operations

• Define clear processes and procedures for remedying 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 before widespread deployment and develop “roll-back” procedures if 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 immediately having the PACS administrator disable invalid PIV credentials (expired, certificates placed on CRL, etc.) rather than waiting for automatic disabling through the routine credential validation process. Also, consider disabling identity and credential records rather than removing them to retain audit data that might be needed later (for example, employee misconduct investigations).
• Remove all PII from PACS endpoints to protect privacy.
• Audit expected system functionality regularly. 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 ensure correct operation further.

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-73pt1-5, Interfaces for Personal Identity Verification, Parts 1 ,July 2024

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, January 2021

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

1. 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.
2. Access Point - An access point can be a door, turnstile, or other physical barrier that can be electronically controlled to grant access.
3. Authentication - The process of establishing confidence in the authenticity and validity of a person’s identity.
4. Authentication Factors - Authentication systems are often categorized by the number of factors 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.
5. Authorization - GGrants access to only the resources a person needs to perform a job. A person with an authentic, high-assurance credential (PIV or CAC) cannot access 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.
6. Biometric - A measurable, physical characteristic or personal behavioral trait used to recognize or verify an applicant’s claimed identity. Facial images, fingerprints, and iris image samples are all examples of biometrics.
7. BIO - A FIPS 201 authentication mechanism that is implemented by using a fingerprint, facial, or iris image data object sent from the PIV credential to the PACS and matched to the credential holder’s live scan.
8. 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.
9. BIO(-A) - A shorthand represents both BIO and BIO-A authentication mechanisms.
10. 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.
11. 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.
12. Certificate Revocation List - A list of revoked public key certificates created and digitally signed by a certification authority.
13. Identity Management System (IDMS) - A system comprising one or more systems or applications that manages the identity verification, validation, and issuance process.
14. 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.
15. 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.
16. 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 the issuer.
17. OCC-AUTH - A two-factor authentication mechanism that uses secure messaging and an on-credential comparison of credential holder fingerprint(s).
18. Physical Access Control System - An electronic system that controls the ability of people to enter a protected area utiizing authentication and authorization at access control points.
19. PACS Alternative Authenticator- Derived PKI-CAK - A PIV authentication mechanism implemented on an approved alternative authenticator (token) using wireless asymmetric key challenge/response protocol of a Derived (NIST SP 800-157) Card Authentication certificate and key.
20. PKI-AUTH - A PIV authentication mechanism implemented by an asymmetric key challenge/response protocol using the PIV Authentication certificate and key.
21. PKI-CAK - A PIV authentication mechanism implemented by an asymmetric key challenge/response protocol using the Card Authentication certificate and key.
22. 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.
23. SM-AUTH - A PIV authentication mechanism implemented by an elliptic curve key challenge/response protocol using the Secure Message key.
24. Validation - The process of determining that an identity credential was legitimately issued and is still valid (the credential has not expired or been revoked).