Physical Access Control Systems 101
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.
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.
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.
The following table defines common PACS components:
|Entrance point or physical barrier where an employee or contractor interacts with the PACS. Example access points include turnstiles, gates, and locking doors.
|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.
|Captures biometric data (for example, fingerprint or iris scan) and verifies it against the PIV credential’s biometric data.
|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.
holder data repository
|Contains employee and contractor data and physical access privileges. Control panels use this authoritative data to validate credential data.
|Agencies may integrate the PACS with additional facility monitoring systems such as surveillance systems, fire alarm systems, and evacuation systems.
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.
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.
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.
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.
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
Inventory critical assets for each agency site
- When you inventory critical assets, also document any challenges to secure them.
Examples of critical assets include:
- 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):
|The loss of confidentiality, integrity, or availability could have a limited adverse effect on organizational operations, organizational assets, or individuals.
|The loss of confidentiality, integrity, or availability could have a serious adverse effect on organizational operations, organizational assets, or individuals.
|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.
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:
|An area where uncontrolled movement would permit direct access to a security asset, such as a Sensitive Compartmented Information Facility (SCIF).
|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.
|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
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:
|Minimum Number of Factors
|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 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 areas require only one authentication factor, such as a PIV credential.
Select Authentication Mechanisms
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:
|Something you have AND
Something you know AND
Something you have on or in your body
|PKI-AUTH + BIO
|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
|Something you have OR
Something you have on or in your body
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).
Visit the 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 where their roles are listed in bold underlined font.
PACS Procurement Best Practices
|PACS Procurement Checklist
|1. Identify your agency’s need to procure or upgrade a PACS.
|2. Develop a PACS project charter.
|3. Identify and obtain support from PACS stakeholders (iterative).
|4. Identify PACS project phases and tasks (iterative).
|5. Develop a project schedule (iterative).
|6. Conduct a Facility Security Level (FSL) assessment of project-related agency sites and determine Personal Identity Verification (PIV) authentication mechanisms for each site.
|7. Develop a PACS requirements document or specification.
|8. Release a Request for Information (RFI) to potential service providers.
|9. Submit an IT funding proposal following your agency’s budgetary process.
|10. Develop an RFP and SOW to solicit GSA-approved integrator bids.
|11. Solicit bids, evaluate, and award integrator contract.
|12. Develop a PACS architecture and migration strategy.
|13. Buy products listed on the GSA PACS APL.
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.
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:
|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.
|Makes configuration recommendations and advises the IT Architect about enterprise-wide network improvements, PACS hardware and software optimization, testing, deployment, and maintenance.
|Installs, administers, and maintains network and system components.
|Uses physical security functions, such as setting access privileges or taking actions to resolve system-generated events and alarms.
Recommended Technical Training
|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.
|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.
|Should complete PACS product manufacturers’ training (i.e., PACS APL products) related to the PACS solution implementation.
|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.
Department of Homeland Security - Interagency Security Committee
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 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:
Federal agencies have shared these PACS lessons learned:
- 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.
- 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.
- 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.
- Create and maintain a training plan that formally documents training requirements.
- Provide role-specific training to agency stakeholders, such as HR, IT, or Security.
Federal Information Security Modernization Act (FISMA) of 2014, Public Law No. 113-283.
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-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
NIST SP 800-73-4, Interfaces for Personal Identity Verification, Parts 1 and 2, May 2015 (Updated February 8, 2016)
Guidance and Best Practices
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
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
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
- 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).