NIST PIV and digital identity FIPS 201-3

Controls in this version
Ref	Title	Text
1	Introduction	This section is informative except where otherwise marked as normative. It provides background information for understanding the scope of this Standard. Authentication of an individual’s identity is a fundamental component of both physical	changed here
1.1 in 1	Purpose	This Standard defines reliable, government-wide identity credentials for use in applications such as access to federally controlled facilities and information systems. This Standard has been developed within the context and constraints of f	changed here
1.2 in 1	Scope	[HSPD-12], signed by President George W. Bush on August 27, 2004, established the requirements for a common identification standard for identity credentials issued by federal departments and agencies to federal employees and contractors (in	changed here
1.3 in 1	Change Management	Every revision of this Standard introduces refinements and changes that may impact existing implementations. FIPS 201 and associated normative specifications encourage implementation approaches that reduce the high cost of configuration and	changed here
1.3.1 in 1.3	Backward Compatible Change	A backward compatible change is a change or modification to an existing feature that does not break relying systems using the feature. For example, changing the card authentication certificate from optional to mandatory does not affect the	changed here
1.3.2 in 1.3	Backward Incompatible Change	A backward incompatible change is a change or modification to an existing feature such that the modified feature cannot be used with existing relying systems. For example, changing the format of the biometric data records would not be compa	changed here
1.3.3 in 1.3	New Features	New features are features that are added to the Standard. These features can be optional or mandatory. New features do not interfere with backward compatibility because they are not part of the existing relying systems. For example, the opt	changed here
1.3.4 in 1.3	Deprecated and Removed Features	This subsection is normative. When a feature is to be discontinued or is no longer needed, it is deprecated. In general, a feature that is currently in use by relying systems would only be deprecated if there were a compelling reason to do	changed here
1.3.5 in 1.3	FIPS 201 Version Management	Subsequent revisions of this Standard may necessitate FIPS 201 version management that introduces new version numbers for FIPS 201 products. Components that may be affected by version management include but are not limited to PIV Cards, PIV	changed here
1.3.6 in 1.3	Section Number Stability	Section numbers have not been changed in this revision. While the general focus of each section’s content remain the same, some section titles have changed to better reflect the updated content. Any deleted sections have had their content r	changed here
1.4 in 1	Document Organization	This Standard describes the minimum requirements for a federal personal identity verification system that meets the control and security objectives of [HSPD-12], including identity proofing, registration, and issuance. It provides detailed	changed here
2	Common Identification, Security, and Privacy Requirements	This section is normative. It addresses the fundamental control and security objectives outlined in [HSPD-12], including the identity proofing requirements for federal employees and contractors. Note that identity proofing, registration, i	changed here
2.1 in 2	Control Objectives	[HSPD-12] establishes control objectives for secure and reliable identification of federal employees and contractors. These control objectives, provided in paragraph 3 of the directive, are quoted here: (3) “Secure and reliable forms of id	changed here
2.2 in 2	Credentialing Requirements	Federal departments and agencies SHALL use the credentialing eligibility standards issued by the Director of the Office of Personnel Management (OPM) 3 and OMB. 4 Federal departments and agencies must follow investigative requirements esta	changed here
2.3 in 2	Biometric Data Collection for Background Investigations	This section applies to applicants that do not have a completed and favorably adjudicated Tier 1 or higher federal background investigation on record that can be located and referenced. A full set of fingerprints SHALL be collected from ea	changed here
2.4 in 2	Biometric Data Collection for PIV Card	The following biometric data SHALL be collected from each PIV applicant: • Two fingerprints for off-card one-to-one comparison. These fingerprints MAY be taken from the full set of fingerprints collected in Section 2.3. • An electronic fac	changed here
2.5 in 2	Biometric Data Use	The full set of fingerprints SHALL be collected for biometric identification against databases of fingerprints maintained by the FBI. The two mandatory fingerprints SHALL be used for the preparation of biometric templates to be stored on t	changed here
2.6 in 2	PIV Enrollment Records	Note: This section was formerly entitled “Chain-of-Trust”. The card issuer SHALL maintain the enrollment record for each issued PIV Card. These enrollment records are created and maintained through the methods of contemporaneous acquisitio	changed here
2.7 in 2	PIV Identity Proofing and Registration Requirements	Identity proofing and registration requirements for the issuance of PIV Cards meet Identity Assurance Level (IAL) 3 since they follow a tailored process based on [SP 800-63A] IAL3 requirements. Departments and agencies SHALL follow an ident	changed here
2.7.1 in 2.7	Supervised Remote Identity Proofing	Departments and agencies MAY use a supervised remote identity proofing process for the identity proofing of PIV Card applicants. This process involves the use of an issuer- controlled station at a remote location that is connected to a trai	changed here
2.8 in 2	PIV Card Issuance Requirements	Departments and agencies SHALL meet the requirements defined below when issuing PIV Cards. The issuance process used when issuing PIV Cards SHALL be accredited by the department or agency as satisfying the requirements below and approved in	changed here
2.8.1 in 2.8	Special Rule for Pseudonyms	In limited circumstances, federal employees and contractors are permitted to use pseudonyms during the performance of their official duties with the approval of their employing agency. If an agency determines that the use of a pseudonym is	changed here
2.8.2 in 2.8	Grace Period	In some instances, an individual’s status as a federal employee or contractor will lapse for a brief time period. For example, a federal employee may leave one federal agency for another federal agency and thus incur a short employment laps	changed here
2.8.3 in 2.8	Remote Issuance	Departments and agencies MAY use a supervised remote identity proofing station as described in Section 2.7.1 for the processes involved in the issuance of PIV Cards. This involves the use of an issuer-controlled station at a remote location	changed here
2.9 in 2	PIV Card Maintenance Requirements	The PIV Card SHALL be maintained using processes that comply with this section. The data and credentials held by the PIV Card may need to be updated or invalidated prior to the expiration date of the card. For example, a previously issued	changed here
2.9.1 in 2.9	PIV Card Reissuance Requirements	Reissuance is the process by which a new PIV Card is issued to a cardholder without the need to repeat the entire identity proofing and registration process. The reissuance process may be used to replace a PIV Card that is nearing expiratio	changed here
2.9.1.1 in 2.9.1	Special Rule for Name Change by Cardholder	Name changes frequently occur as a result of marriage, divorce, or as a matter of personal preference. In the event that a cardholder notifies the card issuer that their name has changed and presents the card issuer with evidence of a forma	changed here
2.9.2 in 2.9	PIV Card Post-Issuance Update Requirements	A PIV Card post-issuance update MAY be performed without replacing the PIV Card in cases where none of the printed information on the surface of the card is changed. The post-issuance update applies to cases where one or more certificates,	changed here
2.9.3 in 2.9	PIV Card Activation Reset	Both the Personal Identification Number (PIN) and OCC activation methods for a PIV Card can be reset in certain circumstances. The PIN on a PIV Card may need to be reset if the cardholder has forgotten the PIN or if PIN-based cardholder au	changed here
2.9.3.1 in 2.9.3	PIN Reset	PIN reset MAY be performed in person at an issuing facility, at a kiosk operated by the issuer, remotely via a general computing platform, or at a supervised remote identity proofing station: In person When PIN reset is performed in person	changed here
2.9.3.2 in 2.9.3	OCC Reset	Both fingerprints used for OCC SHALL be replaced during an OCC reset. OCC reset MAY be performed in person at an issuing facility or a supervised remote identity proofing station: In person When OCC reset is performed in person at the iss	changed here
2.9.4 in 2.9	PIV Card Termination Requirements	A PIV Card is terminated when the department or agency that issued the card determines that the cardholder is no longer eligible to have a PIV Card. The PIV Card SHALL be terminated under any of the following circumstances: • A federal emp	changed here
2.10 in 2	Derived PIV Credentials	Derived PIV credentials are additional PIV credentials that are issued based on proof of possession and control of a PIV Card. These credentials are not embedded in the PIV Card but instead are stand-alone or integrated in a variety of devi	changed here
2.10.1 in 2.10	Derived PIV Credential Issuance Requirements	Issuance of a derived PIV credential is an instance of the post-enrollment binding of an authenticator described in [SP 800-63B] and SHALL be performed in accordance with the requirements that apply to physical authenticators as well as the	changed here
2.10.2 in 2.10	Derived PIV Credential Invalidation Requirements	Derived PIV credentials SHALL be invalidated in any of the following circumstances: • upon request of the PIV cardholder as a result of loss, failure, compromise, or intent to discontinue use of a derived PIV credential; • at the determina	changed here
2.10.3 in 2.10	Derived PIV Credential Reissuance and Post-Issuance Update Requirements	PKI-based derived PIV Credentials (i.e., those containing attribute information describing the PIV cardholder) SHALL be updated or reissued as described in [SP 800-157] Section 2.3 when the corresponding PIV Card is updated or reissued. Non	changed here
2.11 in 2	PIV Privacy Requirements	[HSPD-12] explicitly states that “protect[ing] personal privacy” is a requirement of the PIV system. As such, all departments and agencies SHALL implement the PIV system in accordance with the spirit and letter of all privacy controls speci	changed here
3	PIV System Overview	This section is informative. It provides an overview of the different components of the PIV system. The PIV system is composed of components and processes that support a common platform for identity authentication across federal department	changed here
3.1 in 3	Functional Components	An operational PIV system can be divided into three major subsystems: PIV Front-End Subsystem The PIV Card, card readers, biometric capture devices, and PIN input devices, as well as any derived PIV credentials used by the PIV cardholder.	changed here
3.1.1 in 3.1	PIV Front-End Subsystem	The PIV Front-End Subsystem in Figure 3-1 consists of credentials and devices that are used during authentication and, as described in Section 3.1.2, for PIV issuance and management. The PIV Card takes the physical form of the [ISO 7816] ID	changed here
3.1.2 in 3.1	PIV Issuance and Management Subsystem	The registration and issuance activities in Figure 3-1 start with identity proofing and registration, during which all information and documentation required for enrollment are collected, stored, and maintained. The collected information is	changed here
3.1.3 in 3.1	PIV Relying Subsystem	The PIV relying subsystem in Figure 3-1 includes components responsible for determining a particular PIV cardholder’s access to a physical or logical resource. 22 A physical resource is the secured facility (e.g., building, room, parking ga	changed here
3.2 in 3	PIV Card Lifecycle Activities	The PIV Card lifecycle consists of seven activities. 23 The activities that take place during fabrication and pre-personalization of the card at the manufacturer are not considered a part of this lifecycle model. Figure 3-2 presents these P	changed here
3.3 in 3	Connections Between System Components	To perform authentication for logical or physical access using a PIV Card or a derived PIV credential directly, the credential is verified and attributes from the PIV identity account are provided to the relying subsystem. The connections a	changed here
4	PIV Front-End Subsystem	This section is normative. It provides the requirements for the PIV front-end subsystem components.	changed here
4.1 in 4	PIV Card Physical Characteristics	References to the PIV Card in this section pertain to its physical characteristics only. References to the front of the card apply to the side of the card that contains electronic contacts. References to the back of the card apply to the si	changed here
4.1.1 in 4.1	Printed Material	The printed material SHALL NOT rub off during the life of the PIV Card. The printing process SHALL NOT deposit debris on the printer rollers during printing and laminating. Printed material SHALL NOT interfere with the ICCs or related compo	changed here
4.1.2 in 4.1	Tamper-proofing and Resistance	To combat counterfeiting and alterations, the PIV Card SHALL contain security features outlined in the American Association of Motor Vehicle Administrators (AAMVA) Drivers License/Identification Card (DL/ID) Card Design Standard [CDS]. The	changed here
4.1.3 in 4.1	Physical Characteristics and Durability	This section describes the physical requirements for the PIV Card. The PIV Card SHALL contain a contact and a contactless ICC interface. The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security	changed here
4.1.4 in 4.1	Visual Card Topography	The information on a PIV Card SHALL be in visual printed and electronic form. This section covers the placement of visual and printed information. It does not cover information stored in electronic form, such as stored data elements or othe	changed here
4.1.4.1 in 4.1.4	Mandatory Items on the Front of the PIV Card	Zone 1F: Photograph The photograph SHALL be placed in the upper left corner, as depicted in Figure 4-1, and be a frontal pose from top of the head to shoulder. A minimum of 300 dots per inch (DPI) resolution SHALL be used. The background SH	changed here
4.1.4.2 in 4.1.4	Mandatory Items on the Back of the PIV Card	Zone 1B: Agency Card Serial Number This item SHALL be printed on the back of the card and contain the unique serial number from the issuing department or agency. The format SHALL be at the discretion of the issuing department or agency. The	changed here
4.1.4.3 in 4.1.4	Optional Items on the Front of the PIV Card	This section contains a description of the optional information and machine-readable technologies that may be used as well as their respective placement. The storage capacity of all optional technologies is as prescribed by individual depar	changed here
4.1.4.4 in 4.1.4	Optional Items on the Back of the PIV Card	Zone 3B: Magnetic Stripe (Deprecated) The magnetic stripe is deprecated in this version of the Standard. In a future version of this Standard, the magnetic stripe may be removed and the space may be allocated for agency-specific data to be	changed here
4.1.5 in 4.1	Color Representation	Table 4-2 provides quantitative specifications for colors in four different color systems: sRGB Tristimulus [IEC 61966], sRGB [IEC 61966], CMYK (Cyan, Magenta, Yellow, and Key or ‘blacK’), and PANTONE®. Note the PANTONE® color cue mapping i	changed here
4.2 in 4	PIV Card Logical Characteristics	This section defines the PIV Card’s logical identity credentials and the requirements for use of these credentials. To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of ver	changed here
4.2.1 in 4.2	Cardholder Unique Identifier (CHUID)	Note: The CHUID authentication mechanism (Section 6.2.5) has been removed from this version of the Standard. The CHUID data element itself, however, has not been removed and continues to be mandatory as it supports other PIV authentication	changed here
4.2.2 in 4.2	Cryptographic Specifications	The PIV Card SHALL implement the cryptographic operations and support functions defined in [SP 800-78] and [SP 800-73]. The PIV Card has both mandatory and optional keys: PIV authentication key A mandatory asymmetric private key that supp	changed here
4.2.2.1 in 4.2.2	PIV Authentication Key	This key SHALL be generated on the PIV Card. The PIV Card SHALL NOT permit exportation of the PIV authentication key. The cryptographic operations that use the PIV authentication key SHALL be available through the contact interface and MAY	changed here
4.2.2.2 in 4.2.2	Asymmetric Card Authentication Key	The asymmetric card authentication key MAY be generated on the PIV Card or imported to the card. The PIV Card SHALL NOT permit exportation of the card authentication key. Cryptographic operations that use the card authentication key SHALL b	changed here
4.2.2.3 in 4.2.2	Symmetric Card Authentication Key (Deprecated)	The symmetric card authentication key is deprecated in this version of the Standard. Both the symmetric card authentication key and the associated SYM-CAK authentication mechanism may be removed in a future revision of the Standard. If use	changed here
4.2.2.4 in 4.2.2	Digital Signature Key	The PIV digital signature key SHALL be generated on the PIV Card. The PIV Card SHALL NOT permit exportation of the digital signature key. If this key is present, cryptographic operations that use the digital signature key SHALL be available	changed here
4.2.2.5 in 4.2.2	Key Management Key	This key MAY be generated on the PIV Card or imported to the card. If present, the cryptographic operations that use the key management key SHALL be available through the contact interface and MAY additionally be available over the virtual	changed here
4.2.2.6 in 4.2.2	PIV Card Application Administration Key	If present, the PIV Card application administration key SHALL be imported onto the card by the issuer. If present, the cryptographic operations that use the PIV Card application administration key SHALL only be available through the contact	changed here
4.2.2.7 in 4.2.2	PIV Secure Messaging Key	The PIV secure messaging key supports the establishment of secure messaging and authentication using the SM-AUTH authentication mechanism. If present, the key SHALL be generated on the PIV Card and SHALL NOT be exported. The cryptographic o	changed here
4.2.3 in 4.2	Biometric Data Specifications	The PIV front-end subsystem employs biometric verification to automate the recognition of cardholders based on their biological characteristics. The PIV Card can digitally store fingerprint, face, and iris biometric characteristics. Techniq	changed here
4.2.3.1 in 4.2.3	Biometric Data Representation	The following biometric data SHALL be stored on the PIV Card: • Two fingerprint biometric templates. If no fingerprint images meet the quality criteria of [SP 800-76], the PIV Card SHALL nevertheless be populated with fingerprint biometric	changed here
4.2.3.2 in 4.2.3	Biometric Data Record Protection	The integrity of all biometric data records, except for fingerprint biometric templates for OCC, SHALL be protected using digital signatures. The records SHALL be prepended with a Common Biometric Exchange Formats Framework (CBEFF) header a	changed here
4.2.3.3 in 4.2.3	Biometric Data Record Access	The biometric data records, except for fingerprint biometric templates for OCC, that are stored on the card • SHALL be readable through the contact interface only after the presentation of a valid PIN; and • MAY optionally be readable thro	changed here
4.2.4 in 4.2	PIV Unique Identifiers	A cardholder is authenticated using the mechanisms described in Section 6. The authenticated identity MAY then be used as the basis for making authorization decisions. Unique identifiers for both authentication and authorization are provide	changed here
4.3 in 4	PIV Card Activation	The PIV Card SHALL be activated 34 to perform privileged 35 operations such as using the PIV authentication key, digital signature key, and key management key. The PIV Card SHALL be activated for privileged operations only after authenticat	changed here
4.3.1 in 4.3	Activation by Cardholder	PIV Cards SHALL implement user-based cardholder activation to allow privileged operations using PIV credentials held by the card. At a minimum, the PIV Card SHALL implement PIN-based cardholder activation in support of interoperability acro	changed here
4.3.2 in 4.3	Activation by Card Management System	PIV Cards MAY support card activation by the card management system to support card personalization and post-issuance card update. To activate the card for personalization or update, the card management system SHALL perform a challenge resp	changed here
4.4 in 4	Card Reader Requirements	This section provides minimum requirements for contact and contactless card readers. This section also provides requirements for PIN input devices. Further card reader requirements are specified in [SP 800-96].	changed here
4.4.1 in 4.4	Contact Reader Requirements	Contact card readers SHALL conform to [ISO 7816] for the card-to-reader interface. These readers SHALL conform to the Personal Computer/Smart Card (PC/SC) Specification [PCSC] for the reader-to-host system interface in general-purpose deskt	changed here
4.4.2 in 4.4	Contactless Reader Requirements	Contactless card readers SHALL conform to [ISO 14443] for the card-to-reader interface, and data transmitted over the [ISO 14443] link SHALL conform to [ISO 7816]. In cases where these readers are connected to general-purpose desktop comput	changed here
4.4.3 in 4.4	Reader Interoperability (Removed)	Note: This section was formerly entitled “Reader Resilience and Flexibility.” The content of this section has been removed since the PIV middleware specified in [SP 800-73] adequately covers reader interoperability, resilience, and flexibi	changed here
4.4.4 in 4.4	Card Activation Device Requirements	When the PIV Card is used with a PIN or OCC data for physical access, the input device SHALL be integral to (i.e., built into) the PIV Card reader. When the PIV Card is used with a PIN or OCC data for logical access (e.g., to authenticate t	changed here
5	PIV Key Management Requirements	This section is normative. It defines the processes and components required for managing a PIV Card’s lifecycle and provides the requirements and specifications related to key management. PIV Cards consistent with this specification SHALL	changed here
5.1 in 5	Architecture	CAs that issue certificates to support PIV private keys SHALL participate in the hierarchical PKI for the Common Policy managed by the Federal PKI Management Authority. CA certificates SHALL conform to [COMMON].	changed here
5.2 in 5	PKI Certificate	All certificates issued to support PIV private keys (i.e., PIV authentication, card authentication, digital signature, and key management certificates) SHALL be issued in accordance with [COMMON]. CAs and registration authorities can either	changed here
5.2.1 in 5.2	X.509 Certificate Contents	The required contents of X.509 certificates associated with PIV private keys are based on [PROF]. The relationship is described below: • Certificates that contain the public key associated with a PIV authentication private key SHALL confor	changed here
5.3 in 5	X.509 Certificate Revocation List (CRL) Contents	CAs that issue certificates corresponding to PIV private keys SHALL issue CRLs as specified in [COMMON]. The contents of X.509 CRLs SHALL conform to CRL Profile in [PROF].	changed here
5.4 in 5	Legacy PKIs (Removed)	The content of this section has been removed. Details for certificates issued to support PIV private keys are specified in Section 5.2.	changed here
5.5 in 5	PKI Repository and Online Certificate Status Protocol (OCSP)	Responders CAs that issue certificates corresponding to PIV private keys (i.e., PIV authentication, card authentication, digital signature, or key management certificates) SHALL • maintain a Hypertext Transfer Protocol (HTTP) accessible s	changed here
5.5.1 in 5.5	Certificate and CRL Distribution	This Standard requires the distribution of CA certificates and CRLs using HTTP. Specific requirements are found in [PROF]. Certificates that contain the FASC-N or card UUID in the SAN extension, such as PIV authentication certificates and	changed here
5.5.2 in 5.5	OCSP Status Responders	OCSP status responders SHALL be implemented as a certificate status mechanism. The OCSP status responders SHALL be updated at least as frequently as CRLs are issued.	changed here
6	PIV Cardholder Authentication	This section is normative. It defines a suite of authentication mechanisms that are supported by all PIV Cards as well as the applicability of these mechanisms in meeting the requirements for a set of graduated assurance levels. This sectio	changed here
6.1 in 6	PIV Assurance Levels	This Standard defines multiple levels of assurance for logical and physical access. Each assurance level establishes a degree of confidence that the presenter of the PIV Card is the person referred to by the PIV credential. The entity perfo	changed here
6.1.1 in 6.1	Relationship to Federal Identity Policy (Removed)	Note: This section was formerly entitled “Relationship to OMB’s E- Authentication Guidance.” The content of this section has been removed since OMB [M-04-04] has been rescinded by OMB [M-19-17], which recognizes the IALs and AALs defined i	changed here
6.2 in 6	PIV Card Authentication Mechanisms	The following subsections define the basic types of authentication mechanisms that are supported by the credential set hosted by the PIV Card application. PIV Cards can be used for authentication in environments that are equipped with conta	changed here
6.2.1 in 6.2	Authentication Using O˙-Card Biometric One-to-One Comparison	The PIV Card application hosts the fingerprint biometric templates, electronic facial image, and optional electronic iris images. These biometric data records can be read from the card following CTC authentication using a PIN supplied by th	changed here
6.2.1.1 in 6.2.1	Unattended Authentication Using Biometric Data (BIO)	The following steps SHALL be performed for unattended authentication using biometric data: • The CHUID or another data element 38 is read from the card. The signature of the CHUID or another data element is verified to ensure that the card	changed here
6.2.1.2 in 6.2.1	Attended Authentication Using Biometric Data (BIO-A)	In this higher assurance variant of BIO, an attendant (e.g., security guard) supervises the submission of the new biometric sample by the cardholder. Otherwise, the steps for this authentication mechanism are the same as in Section 6.2.1.1.	changed here
6.2.2 in 6.2	Authentication Using On-Card Biometric One-to-One Comparison (OCC-AUTH)	The PIV Card application MAY host an optional OCC algorithm. In this case, OCC data is stored on the card, which cannot be read from the card but could be used for biometric verification. A fingerprint biometric template is supplied to the	changed here
6.2.3 in 6.2	Authentication Using PIV Asymmetric Cryptography	The PIV Card contains two mandatory asymmetric authentication private keys and corresponding certificates to support CTE authentication, as described in Section 4. The following subsections describe how to perform authentication using the a	changed here
6.2.3.1 in 6.2.3	Authentication with the PIV Authentication Certificate Credential (PKI-AUTH)	The following steps SHALL be performed for PKI-AUTH: • The PIV authentication certificate is read from the PIV Card application. • The relying system validates the PIV authentication certificate from the PIV Card application using certific	changed here
6.2.3.2 in 6.2.3	Authentication with the Card Authentication Certificate Credential (PKI-CAK)	The following steps SHALL be performed for PKI-CAK: • The card authentication certificate is read from the PIV Card application. • The relying system validates the card authentication certificate from the PIV Card application using certifi	changed here
6.2.3.3 in 6.2.3	Authentication Using Secure Messaging Key (SM-AUTH)	The PIV Card MAY include a secure messaging key and corresponding CVC to establish symmetric keys for use with secure messaging. The same key, CVC, and key establishment protocol can also be used for authentication, since the PIV Card is au	changed here
6.2.4 in 6.2	Authentication Using the Symmetric Card Authentication Key (SYM-CAK)	(Deprecated) The symmetric card authentication key and associated SYM-CAK authentication mechanism are deprecated in this version of the Standard. Both the key and the authentication mechanism may be removed in a future version of this Sta	changed here
6.2.5 in 6.2	Authentication Using the CHUID (Removed)	The content of this section has been removed since the CHUID authentication mechanism is no longer allowed under FIPS-201. The BIO, BIO-A, and the deprecated SYM-CAK authentication mechanisms use the CHUID data element as a source for the	changed here
6.2.6 in 6.2	Authentication Using PIV Visual Credentials (VIS) (Deprecated)	Visual authentication of a PIV cardholder as a stand-alone authentication mechanism has been deprecated in this version of the Standard. The mechanism provides little or no assurance of the cardholder’s identity and SHOULD NOT be used. It i	changed here
6.3 in 6	PIV Support of Graduated Authenticator Assurance Levels	The PIV Card supports a set of authentication mechanisms that can be used to implement graduated assurance levels. The assurance levels used for remote/networked access within this Standard are closely aligned with NIST [SP 800-63], which s	changed here
6.3.1 in 6.3	Physical Access	The PIV Card can be used to authenticate the cardholder in a physical access control environment using the authentication mechanisms described in Section 6.2. Each authentication mechanism provides a degree of assurance, as summarized in Ta	changed here
6.3.2 in 6.3	Logical Access	The PIV Card can be used to authenticate the cardholder in support of decisions regarding access to logical information resources. For example, a cardholder may authenticate to their department or agency network using the PIV Card; the iden	changed here
7	Federation Considerations for PIV	This section is normative. It defines a set of mechanisms for using federation technologies to interoperate with PIV and derived PIV credentials issued by other agencies. Federation protocols allow a trusted IdP to assert a cardholder’s id	changed here
7.1 in 7	Connecting PIV to Federation	When using a federation protocol, the PIV Card or derived PIV credential is not directly presented to the relying subsystem. Instead, the PIV Card or derived PIV credential SHALL be used to authenticate the PIV cardholder to the IdP of a fe	changed here
7.2 in 7	Federation Assurance Level (FAL)	[SP 800-63] defines three dimensions of assurance: IAL, AAL, and FAL. The use of a PIV Card or a derived PIV credential for authentication in a federation transaction will determine the IAL and AAL of that transaction, but the FAL is determ	changed here
7.3 in 7	Benefits of Federation	While it is possible to directly process a PIV credential that belongs to a different agency, federation is the recommended way for an agency to accept and process PIV credentials from other agencies. Benefits of using a federation protoco	changed here
Appendix A	PIV Validation, Certification, and Accreditation	This appendix is normative. It provides compliance requirements for PIV validation, certification, and accreditation.	changed here
A.1 in A	Accreditation of PIV Card Issuers (PCI) and Derived PIV Credential	Issuers (DPCI) [HSPD-12] requires that PIV credentials be issued by providers whose reliability has been established by an official accreditation process. Consistent assessment guidelines are established for PIV Card Issuers (PCI) and Deri	changed here
A.2 in A	Application of Risk Management Framework to IT Systems	Supporting PCI The accreditation of the capability and reliability of a PCI and DPCI using the methodology outlined in [SP 800-79] depends on adequate security for the information systems that are used for PCI and DPCI functions. The assur	changed here
A.3 in A	Conformance Testing of PIV Card Application and Middleware	Assurance of conformance of the PIV Card application interface to this Standard and its associated technical specifications is needed in order to meet the security and interoperability goals of [HSPD-12]. To facilitate this, NIST has establ	changed here
A.4 in A	Cryptographic Testing and Validation	All on-card cryptographic modules that host the PIV Card application and cryptographic modules of card issuance and maintenance systems SHALL be validated to [FIPS 140] with an overall Security Level 2 (or higher). The facilities for [FIPS	changed here
A.5 in A	FIPS 201 Evaluation Program	In order to evaluate the conformance of specialized products that support the PIV functionality to this Standard and its associated technical specifications, GSA established the FIPS 201 Evaluation Program. The product families may include	changed here
Appendix B	PIV Object Identifiers and Certificate Extension	This appendix is normative. It provides additional details for the PIV objects identified in Section 4.	changed here
B.1 in B	PIV Object Identifiers	Table B-1, Table B-2, and Table B-3 list details for PIV object identifiers. Table B-1. PIV Object Identifiers for PIV eContent Types ID Object Identifier Description id-PIV- CHUIDSecurityObject 2.16.840.1.101.3.6.1 The associated content	changed here
B.2 in B	PIV Background Investigation Indicator Certificate Extension	(Deprecated) The PIV background investigation indicator (previously known as the NACI indicator) is deprecated under this version of the Standard, and it is expected that the indicator will be removed from a future revision. Instead of the	changed here
Appendix C	Glossary of Terms, Acronyms, and Notations	This appendix is informative. It describes the vocabulary and textual representations used in the document.	changed here
C.1 in C	Glossary of Terms	The following terms are used throughout this Standard. Access Control The process of granting or denying specific requests to 1) obtain and use information and related information processing services and 2) enter specific physical faciliti	changed here
C.2 in C	Acronyms and Abbreviations	The following acronyms and abbreviations are used throughout this Standard: AAL Authenticator Assurance Level AAMVA American Association of Motor Vehicle Administrators ACL Access Control List AID Application Identifier AIM Association	changed here
C.3 in C	Notations	This Standard uses the following typographical conventions in text: • ASN.1 data types are represented in a monospaced font . For example, SignedData and SignerInfo are data types defined for digital signatures. • Specific terms in CAPITAL	changed here
Appendix D	References	This appendix is informative. It lists the specifications and standards referred to in this document. [A-130] Office of Management and Budget (2016) Managing Information as a Strategic Resource. (The White House, Washington, DC), OMB Circu	changed here
Appendix E	Revision History	This appendix is informative. It provides an overview of the changes to FIPS 201 since its initial release. Version Release Date Updates Location FIPS 201 February 2005 Initial Release FIPS 201-1 March 2006 Added the requirement for electr	changed here

Introduction

This section is informative except where otherwise marked as normative. It provides background information for understanding the scope of this Standard. Authentication of an individual’s identity is a fundamental component of both physical

changed here

1.1

in 1

Purpose

This Standard defines reliable, government-wide identity credentials for use in applications such as access to federally controlled facilities and information systems. This Standard has been developed within the context and constraints of f

changed here

1.2

in 1

Scope

[HSPD-12], signed by President George W. Bush on August 27, 2004, established the requirements for a common identification standard for identity credentials issued by federal departments and agencies to federal employees and contractors (in

changed here

1.3

in 1

Change Management

Every revision of this Standard introduces refinements and changes that may impact existing implementations. FIPS 201 and associated normative specifications encourage implementation approaches that reduce the high cost of configuration and

changed here

1.3.1

in 1.3

Backward Compatible Change

A backward compatible change is a change or modification to an existing feature that does not break relying systems using the feature. For example, changing the card authentication certificate from optional to mandatory does not affect the

changed here

1.3.2

in 1.3

Backward Incompatible Change

A backward incompatible change is a change or modification to an existing feature such that the modified feature cannot be used with existing relying systems. For example, changing the format of the biometric data records would not be compa

changed here

1.3.3

in 1.3

New Features

New features are features that are added to the Standard. These features can be optional or mandatory. New features do not interfere with backward compatibility because they are not part of the existing relying systems. For example, the opt

changed here

1.3.4

in 1.3

Deprecated and Removed Features

This subsection is normative. When a feature is to be discontinued or is no longer needed, it is deprecated. In general, a feature that is currently in use by relying systems would only be deprecated if there were a compelling reason to do

changed here

1.3.5

in 1.3

FIPS 201 Version Management

Subsequent revisions of this Standard may necessitate FIPS 201 version management that introduces new version numbers for FIPS 201 products. Components that may be affected by version management include but are not limited to PIV Cards, PIV

changed here

1.3.6

in 1.3

Section Number Stability

Section numbers have not been changed in this revision. While the general focus of each section’s content remain the same, some section titles have changed to better reflect the updated content. Any deleted sections have had their content r

changed here

1.4

in 1

Document Organization

This Standard describes the minimum requirements for a federal personal identity verification system that meets the control and security objectives of [HSPD-12], including identity proofing, registration, and issuance. It provides detailed

changed here

2

Common Identification, Security, and Privacy Requirements

This section is normative. It addresses the fundamental control and security objectives outlined in [HSPD-12], including the identity proofing requirements for federal employees and contractors. Note that identity proofing, registration, i

changed here

2.1

in 2

Control Objectives

[HSPD-12] establishes control objectives for secure and reliable identification of federal employees and contractors. These control objectives, provided in paragraph 3 of the directive, are quoted here: (3) “Secure and reliable forms of id

changed here

2.2

in 2

Credentialing Requirements

Federal departments and agencies SHALL use the credentialing eligibility standards issued by the Director of the Office of Personnel Management (OPM) 3 and OMB. 4 Federal departments and agencies must follow investigative requirements esta

changed here

2.3

in 2

Biometric Data Collection for Background Investigations

This section applies to applicants that do not have a completed and favorably adjudicated Tier 1 or higher federal background investigation on record that can be located and referenced. A full set of fingerprints SHALL be collected from ea

changed here

2.4

in 2

Biometric Data Collection for PIV Card

The following biometric data SHALL be collected from each PIV applicant: • Two fingerprints for off-card one-to-one comparison. These fingerprints MAY be taken from the full set of fingerprints collected in Section 2.3. • An electronic fac

changed here

2.5

in 2

Biometric Data Use

The full set of fingerprints SHALL be collected for biometric identification against databases of fingerprints maintained by the FBI. The two mandatory fingerprints SHALL be used for the preparation of biometric templates to be stored on t

changed here

2.6

in 2

PIV Enrollment Records

Note: This section was formerly entitled “Chain-of-Trust”. The card issuer SHALL maintain the enrollment record for each issued PIV Card. These enrollment records are created and maintained through the methods of contemporaneous acquisitio

changed here

2.7

in 2

PIV Identity Proofing and Registration Requirements

Identity proofing and registration requirements for the issuance of PIV Cards meet Identity Assurance Level (IAL) 3 since they follow a tailored process based on [SP 800-63A] IAL3 requirements. Departments and agencies SHALL follow an ident

changed here

2.7.1

in 2.7

Supervised Remote Identity Proofing

Departments and agencies MAY use a supervised remote identity proofing process for the identity proofing of PIV Card applicants. This process involves the use of an issuer- controlled station at a remote location that is connected to a trai

changed here

2.8

in 2

PIV Card Issuance Requirements

Departments and agencies SHALL meet the requirements defined below when issuing PIV Cards. The issuance process used when issuing PIV Cards SHALL be accredited by the department or agency as satisfying the requirements below and approved in

changed here

2.8.1

in 2.8

Special Rule for Pseudonyms

In limited circumstances, federal employees and contractors are permitted to use pseudonyms during the performance of their official duties with the approval of their employing agency. If an agency determines that the use of a pseudonym is

changed here

2.8.2

in 2.8

Grace Period

In some instances, an individual’s status as a federal employee or contractor will lapse for a brief time period. For example, a federal employee may leave one federal agency for another federal agency and thus incur a short employment laps

changed here

2.8.3

in 2.8

Remote Issuance

Departments and agencies MAY use a supervised remote identity proofing station as described in Section 2.7.1 for the processes involved in the issuance of PIV Cards. This involves the use of an issuer-controlled station at a remote location

changed here

2.9

in 2

PIV Card Maintenance Requirements

The PIV Card SHALL be maintained using processes that comply with this section. The data and credentials held by the PIV Card may need to be updated or invalidated prior to the expiration date of the card. For example, a previously issued

changed here

2.9.1

in 2.9

PIV Card Reissuance Requirements

Reissuance is the process by which a new PIV Card is issued to a cardholder without the need to repeat the entire identity proofing and registration process. The reissuance process may be used to replace a PIV Card that is nearing expiratio

changed here

2.9.1.1

in 2.9.1

Special Rule for Name Change by Cardholder

Name changes frequently occur as a result of marriage, divorce, or as a matter of personal preference. In the event that a cardholder notifies the card issuer that their name has changed and presents the card issuer with evidence of a forma

changed here

2.9.2

in 2.9

PIV Card Post-Issuance Update Requirements

A PIV Card post-issuance update MAY be performed without replacing the PIV Card in cases where none of the printed information on the surface of the card is changed. The post-issuance update applies to cases where one or more certificates,

changed here

2.9.3

in 2.9

PIV Card Activation Reset

Both the Personal Identification Number (PIN) and OCC activation methods for a PIV Card can be reset in certain circumstances. The PIN on a PIV Card may need to be reset if the cardholder has forgotten the PIN or if PIN-based cardholder au

changed here

2.9.3.1

in 2.9.3

PIN Reset

PIN reset MAY be performed in person at an issuing facility, at a kiosk operated by the issuer, remotely via a general computing platform, or at a supervised remote identity proofing station: In person When PIN reset is performed in person

changed here

2.9.3.2

in 2.9.3

OCC Reset

Both fingerprints used for OCC SHALL be replaced during an OCC reset. OCC reset MAY be performed in person at an issuing facility or a supervised remote identity proofing station: In person When OCC reset is performed in person at the iss

changed here

2.9.4

in 2.9

PIV Card Termination Requirements

A PIV Card is terminated when the department or agency that issued the card determines that the cardholder is no longer eligible to have a PIV Card. The PIV Card SHALL be terminated under any of the following circumstances: • A federal emp

changed here

2.10

in 2

Derived PIV Credentials

Derived PIV credentials are additional PIV credentials that are issued based on proof of possession and control of a PIV Card. These credentials are not embedded in the PIV Card but instead are stand-alone or integrated in a variety of devi

changed here

2.10.1

in 2.10

Derived PIV Credential Issuance Requirements

Issuance of a derived PIV credential is an instance of the post-enrollment binding of an authenticator described in [SP 800-63B] and SHALL be performed in accordance with the requirements that apply to physical authenticators as well as the

changed here

2.10.2

in 2.10

Derived PIV Credential Invalidation Requirements

Derived PIV credentials SHALL be invalidated in any of the following circumstances: • upon request of the PIV cardholder as a result of loss, failure, compromise, or intent to discontinue use of a derived PIV credential; • at the determina

changed here

2.10.3

in 2.10

Derived PIV Credential Reissuance and Post-Issuance Update Requirements

PKI-based derived PIV Credentials (i.e., those containing attribute information describing the PIV cardholder) SHALL be updated or reissued as described in [SP 800-157] Section 2.3 when the corresponding PIV Card is updated or reissued. Non

changed here

2.11

in 2

PIV Privacy Requirements

[HSPD-12] explicitly states that “protect[ing] personal privacy” is a requirement of the PIV system. As such, all departments and agencies SHALL implement the PIV system in accordance with the spirit and letter of all privacy controls speci

changed here

3

PIV System Overview

This section is informative. It provides an overview of the different components of the PIV system. The PIV system is composed of components and processes that support a common platform for identity authentication across federal department

changed here

3.1

in 3

Functional Components

An operational PIV system can be divided into three major subsystems: PIV Front-End Subsystem The PIV Card, card readers, biometric capture devices, and PIN input devices, as well as any derived PIV credentials used by the PIV cardholder.

changed here

3.1.1

in 3.1

PIV Front-End Subsystem

The PIV Front-End Subsystem in Figure 3-1 consists of credentials and devices that are used during authentication and, as described in Section 3.1.2, for PIV issuance and management. The PIV Card takes the physical form of the [ISO 7816] ID

changed here

3.1.2

in 3.1

PIV Issuance and Management Subsystem

The registration and issuance activities in Figure 3-1 start with identity proofing and registration, during which all information and documentation required for enrollment are collected, stored, and maintained. The collected information is

changed here

3.1.3

in 3.1

PIV Relying Subsystem

The PIV relying subsystem in Figure 3-1 includes components responsible for determining a particular PIV cardholder’s access to a physical or logical resource. 22 A physical resource is the secured facility (e.g., building, room, parking ga

changed here

3.2

in 3

PIV Card Lifecycle Activities

The PIV Card lifecycle consists of seven activities. 23 The activities that take place during fabrication and pre-personalization of the card at the manufacturer are not considered a part of this lifecycle model. Figure 3-2 presents these P

changed here

3.3

in 3

Connections Between System Components

To perform authentication for logical or physical access using a PIV Card or a derived PIV credential directly, the credential is verified and attributes from the PIV identity account are provided to the relying subsystem. The connections a

changed here

4

PIV Front-End Subsystem

This section is normative. It provides the requirements for the PIV front-end subsystem components.

changed here

4.1

in 4

PIV Card Physical Characteristics

References to the PIV Card in this section pertain to its physical characteristics only. References to the front of the card apply to the side of the card that contains electronic contacts. References to the back of the card apply to the si

changed here

4.1.1

in 4.1

Printed Material

The printed material SHALL NOT rub off during the life of the PIV Card. The printing process SHALL NOT deposit debris on the printer rollers during printing and laminating. Printed material SHALL NOT interfere with the ICCs or related compo

changed here

4.1.2

in 4.1

Tamper-proofing and Resistance

To combat counterfeiting and alterations, the PIV Card SHALL contain security features outlined in the American Association of Motor Vehicle Administrators (AAMVA) Drivers License/Identification Card (DL/ID) Card Design Standard [CDS]. The

changed here

4.1.3

in 4.1

Physical Characteristics and Durability

This section describes the physical requirements for the PIV Card. The PIV Card SHALL contain a contact and a contactless ICC interface. The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security

changed here

4.1.4

in 4.1

Visual Card Topography

The information on a PIV Card SHALL be in visual printed and electronic form. This section covers the placement of visual and printed information. It does not cover information stored in electronic form, such as stored data elements or othe

changed here

4.1.4.1

in 4.1.4

Mandatory Items on the Front of the PIV Card

Zone 1F: Photograph The photograph SHALL be placed in the upper left corner, as depicted in Figure 4-1, and be a frontal pose from top of the head to shoulder. A minimum of 300 dots per inch (DPI) resolution SHALL be used. The background SH

changed here

4.1.4.2

in 4.1.4

Mandatory Items on the Back of the PIV Card

Zone 1B: Agency Card Serial Number This item SHALL be printed on the back of the card and contain the unique serial number from the issuing department or agency. The format SHALL be at the discretion of the issuing department or agency. The

changed here

4.1.4.3

in 4.1.4

Optional Items on the Front of the PIV Card

This section contains a description of the optional information and machine-readable technologies that may be used as well as their respective placement. The storage capacity of all optional technologies is as prescribed by individual depar

changed here

4.1.4.4

in 4.1.4

Optional Items on the Back of the PIV Card

Zone 3B: Magnetic Stripe (Deprecated) The magnetic stripe is deprecated in this version of the Standard. In a future version of this Standard, the magnetic stripe may be removed and the space may be allocated for agency-specific data to be

changed here

4.1.5

in 4.1

Color Representation

Table 4-2 provides quantitative specifications for colors in four different color systems: sRGB Tristimulus [IEC 61966], sRGB [IEC 61966], CMYK (Cyan, Magenta, Yellow, and Key or ‘blacK’), and PANTONE®. Note the PANTONE® color cue mapping i

changed here

4.2

in 4

PIV Card Logical Characteristics

This section defines the PIV Card’s logical identity credentials and the requirements for use of these credentials. To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of ver

changed here

4.2.1

in 4.2

Cardholder Unique Identifier (CHUID)

Note: The CHUID authentication mechanism (Section 6.2.5) has been removed from this version of the Standard. The CHUID data element itself, however, has not been removed and continues to be mandatory as it supports other PIV authentication

changed here

4.2.2

in 4.2

Cryptographic Specifications

The PIV Card SHALL implement the cryptographic operations and support functions defined in [SP 800-78] and [SP 800-73]. The PIV Card has both mandatory and optional keys: PIV authentication key A mandatory asymmetric private key that supp

changed here

4.2.2.1

in 4.2.2

PIV Authentication Key

This key SHALL be generated on the PIV Card. The PIV Card SHALL NOT permit exportation of the PIV authentication key. The cryptographic operations that use the PIV authentication key SHALL be available through the contact interface and MAY

changed here

4.2.2.2

in 4.2.2

Asymmetric Card Authentication Key

The asymmetric card authentication key MAY be generated on the PIV Card or imported to the card. The PIV Card SHALL NOT permit exportation of the card authentication key. Cryptographic operations that use the card authentication key SHALL b

changed here

4.2.2.3

in 4.2.2

Symmetric Card Authentication Key (Deprecated)

The symmetric card authentication key is deprecated in this version of the Standard. Both the symmetric card authentication key and the associated SYM-CAK authentication mechanism may be removed in a future revision of the Standard. If use

changed here

4.2.2.4

in 4.2.2

Digital Signature Key

The PIV digital signature key SHALL be generated on the PIV Card. The PIV Card SHALL NOT permit exportation of the digital signature key. If this key is present, cryptographic operations that use the digital signature key SHALL be available

changed here

4.2.2.5

in 4.2.2

Key Management Key

This key MAY be generated on the PIV Card or imported to the card. If present, the cryptographic operations that use the key management key SHALL be available through the contact interface and MAY additionally be available over the virtual

changed here

4.2.2.6

in 4.2.2

PIV Card Application Administration Key

If present, the PIV Card application administration key SHALL be imported onto the card by the issuer. If present, the cryptographic operations that use the PIV Card application administration key SHALL only be available through the contact

changed here

4.2.2.7

in 4.2.2

PIV Secure Messaging Key

The PIV secure messaging key supports the establishment of secure messaging and authentication using the SM-AUTH authentication mechanism. If present, the key SHALL be generated on the PIV Card and SHALL NOT be exported. The cryptographic o

changed here

4.2.3

in 4.2

Biometric Data Specifications

The PIV front-end subsystem employs biometric verification to automate the recognition of cardholders based on their biological characteristics. The PIV Card can digitally store fingerprint, face, and iris biometric characteristics. Techniq

changed here

4.2.3.1

in 4.2.3

Biometric Data Representation

The following biometric data SHALL be stored on the PIV Card: • Two fingerprint biometric templates. If no fingerprint images meet the quality criteria of [SP 800-76], the PIV Card SHALL nevertheless be populated with fingerprint biometric

changed here

4.2.3.2

in 4.2.3

Biometric Data Record Protection

The integrity of all biometric data records, except for fingerprint biometric templates for OCC, SHALL be protected using digital signatures. The records SHALL be prepended with a Common Biometric Exchange Formats Framework (CBEFF) header a

changed here

4.2.3.3

in 4.2.3

Biometric Data Record Access

The biometric data records, except for fingerprint biometric templates for OCC, that are stored on the card • SHALL be readable through the contact interface only after the presentation of a valid PIN; and • MAY optionally be readable thro

changed here

4.2.4

in 4.2

PIV Unique Identifiers

A cardholder is authenticated using the mechanisms described in Section 6. The authenticated identity MAY then be used as the basis for making authorization decisions. Unique identifiers for both authentication and authorization are provide

changed here

4.3

in 4

PIV Card Activation

The PIV Card SHALL be activated 34 to perform privileged 35 operations such as using the PIV authentication key, digital signature key, and key management key. The PIV Card SHALL be activated for privileged operations only after authenticat

changed here

4.3.1

in 4.3

Activation by Cardholder

PIV Cards SHALL implement user-based cardholder activation to allow privileged operations using PIV credentials held by the card. At a minimum, the PIV Card SHALL implement PIN-based cardholder activation in support of interoperability acro

changed here

4.3.2

in 4.3

Activation by Card Management System

PIV Cards MAY support card activation by the card management system to support card personalization and post-issuance card update. To activate the card for personalization or update, the card management system SHALL perform a challenge resp

changed here

4.4

in 4

Card Reader Requirements

This section provides minimum requirements for contact and contactless card readers. This section also provides requirements for PIN input devices. Further card reader requirements are specified in [SP 800-96].

changed here

4.4.1

in 4.4

Contact Reader Requirements

Contact card readers SHALL conform to [ISO 7816] for the card-to-reader interface. These readers SHALL conform to the Personal Computer/Smart Card (PC/SC) Specification [PCSC] for the reader-to-host system interface in general-purpose deskt

changed here

4.4.2

in 4.4

Contactless Reader Requirements

Contactless card readers SHALL conform to [ISO 14443] for the card-to-reader interface, and data transmitted over the [ISO 14443] link SHALL conform to [ISO 7816]. In cases where these readers are connected to general-purpose desktop comput

changed here

4.4.3

in 4.4

Reader Interoperability (Removed)

Note: This section was formerly entitled “Reader Resilience and Flexibility.” The content of this section has been removed since the PIV middleware specified in [SP 800-73] adequately covers reader interoperability, resilience, and flexibi

changed here

4.4.4

in 4.4

Card Activation Device Requirements

When the PIV Card is used with a PIN or OCC data for physical access, the input device SHALL be integral to (i.e., built into) the PIV Card reader. When the PIV Card is used with a PIN or OCC data for logical access (e.g., to authenticate t

changed here

5

PIV Key Management Requirements

This section is normative. It defines the processes and components required for managing a PIV Card’s lifecycle and provides the requirements and specifications related to key management. PIV Cards consistent with this specification SHALL

changed here

5.1

in 5

Architecture

CAs that issue certificates to support PIV private keys SHALL participate in the hierarchical PKI for the Common Policy managed by the Federal PKI Management Authority. CA certificates SHALL conform to [COMMON].

changed here

5.2

in 5

PKI Certificate

All certificates issued to support PIV private keys (i.e., PIV authentication, card authentication, digital signature, and key management certificates) SHALL be issued in accordance with [COMMON]. CAs and registration authorities can either

changed here

5.2.1

in 5.2

X.509 Certificate Contents

The required contents of X.509 certificates associated with PIV private keys are based on [PROF]. The relationship is described below: • Certificates that contain the public key associated with a PIV authentication private key SHALL confor

changed here

5.3

in 5

X.509 Certificate Revocation List (CRL) Contents

CAs that issue certificates corresponding to PIV private keys SHALL issue CRLs as specified in [COMMON]. The contents of X.509 CRLs SHALL conform to CRL Profile in [PROF].

changed here

5.4

in 5

Legacy PKIs (Removed)

The content of this section has been removed. Details for certificates issued to support PIV private keys are specified in Section 5.2.

changed here

5.5

in 5

PKI Repository and Online Certificate Status Protocol (OCSP)

Responders CAs that issue certificates corresponding to PIV private keys (i.e., PIV authentication, card authentication, digital signature, or key management certificates) SHALL • maintain a Hypertext Transfer Protocol (HTTP) accessible s

changed here

5.5.1

in 5.5

Certificate and CRL Distribution

This Standard requires the distribution of CA certificates and CRLs using HTTP. Specific requirements are found in [PROF]. Certificates that contain the FASC-N or card UUID in the SAN extension, such as PIV authentication certificates and

changed here

5.5.2

in 5.5

OCSP Status Responders

OCSP status responders SHALL be implemented as a certificate status mechanism. The OCSP status responders SHALL be updated at least as frequently as CRLs are issued.

changed here

6

PIV Cardholder Authentication

This section is normative. It defines a suite of authentication mechanisms that are supported by all PIV Cards as well as the applicability of these mechanisms in meeting the requirements for a set of graduated assurance levels. This sectio

changed here

6.1

in 6

PIV Assurance Levels

This Standard defines multiple levels of assurance for logical and physical access. Each assurance level establishes a degree of confidence that the presenter of the PIV Card is the person referred to by the PIV credential. The entity perfo

changed here

6.1.1

in 6.1

Relationship to Federal Identity Policy (Removed)

Note: This section was formerly entitled “Relationship to OMB’s E- Authentication Guidance.” The content of this section has been removed since OMB [M-04-04] has been rescinded by OMB [M-19-17], which recognizes the IALs and AALs defined i

changed here

6.2

in 6

PIV Card Authentication Mechanisms

The following subsections define the basic types of authentication mechanisms that are supported by the credential set hosted by the PIV Card application. PIV Cards can be used for authentication in environments that are equipped with conta

changed here

6.2.1

in 6.2

Authentication Using O˙-Card Biometric One-to-One Comparison

The PIV Card application hosts the fingerprint biometric templates, electronic facial image, and optional electronic iris images. These biometric data records can be read from the card following CTC authentication using a PIN supplied by th

changed here

6.2.1.1

in 6.2.1

Unattended Authentication Using Biometric Data (BIO)

The following steps SHALL be performed for unattended authentication using biometric data: • The CHUID or another data element 38 is read from the card. The signature of the CHUID or another data element is verified to ensure that the card

changed here

6.2.1.2

in 6.2.1

Attended Authentication Using Biometric Data (BIO-A)

In this higher assurance variant of BIO, an attendant (e.g., security guard) supervises the submission of the new biometric sample by the cardholder. Otherwise, the steps for this authentication mechanism are the same as in Section 6.2.1.1.

changed here

6.2.2

in 6.2

Authentication Using On-Card Biometric One-to-One Comparison (OCC-AUTH)

The PIV Card application MAY host an optional OCC algorithm. In this case, OCC data is stored on the card, which cannot be read from the card but could be used for biometric verification. A fingerprint biometric template is supplied to the

changed here

6.2.3

in 6.2

Authentication Using PIV Asymmetric Cryptography

The PIV Card contains two mandatory asymmetric authentication private keys and corresponding certificates to support CTE authentication, as described in Section 4. The following subsections describe how to perform authentication using the a

changed here

6.2.3.1

in 6.2.3

Authentication with the PIV Authentication Certificate Credential (PKI-AUTH)

The following steps SHALL be performed for PKI-AUTH: • The PIV authentication certificate is read from the PIV Card application. • The relying system validates the PIV authentication certificate from the PIV Card application using certific

changed here

6.2.3.2

in 6.2.3

Authentication with the Card Authentication Certificate Credential (PKI-CAK)

The following steps SHALL be performed for PKI-CAK: • The card authentication certificate is read from the PIV Card application. • The relying system validates the card authentication certificate from the PIV Card application using certifi

changed here

6.2.3.3

in 6.2.3

Authentication Using Secure Messaging Key (SM-AUTH)

The PIV Card MAY include a secure messaging key and corresponding CVC to establish symmetric keys for use with secure messaging. The same key, CVC, and key establishment protocol can also be used for authentication, since the PIV Card is au

changed here

6.2.4

in 6.2

Authentication Using the Symmetric Card Authentication Key (SYM-CAK)

(Deprecated) The symmetric card authentication key and associated SYM-CAK authentication mechanism are deprecated in this version of the Standard. Both the key and the authentication mechanism may be removed in a future version of this Sta

changed here

6.2.5

in 6.2

Authentication Using the CHUID (Removed)

The content of this section has been removed since the CHUID authentication mechanism is no longer allowed under FIPS-201. The BIO, BIO-A, and the deprecated SYM-CAK authentication mechanisms use the CHUID data element as a source for the

changed here

6.2.6

in 6.2

Authentication Using PIV Visual Credentials (VIS) (Deprecated)

Visual authentication of a PIV cardholder as a stand-alone authentication mechanism has been deprecated in this version of the Standard. The mechanism provides little or no assurance of the cardholder’s identity and SHOULD NOT be used. It i

changed here

6.3

in 6

PIV Support of Graduated Authenticator Assurance Levels

The PIV Card supports a set of authentication mechanisms that can be used to implement graduated assurance levels. The assurance levels used for remote/networked access within this Standard are closely aligned with NIST [SP 800-63], which s

changed here

6.3.1

in 6.3

Physical Access

The PIV Card can be used to authenticate the cardholder in a physical access control environment using the authentication mechanisms described in Section 6.2. Each authentication mechanism provides a degree of assurance, as summarized in Ta

changed here

6.3.2

in 6.3

Logical Access

The PIV Card can be used to authenticate the cardholder in support of decisions regarding access to logical information resources. For example, a cardholder may authenticate to their department or agency network using the PIV Card; the iden

changed here

7

Federation Considerations for PIV

This section is normative. It defines a set of mechanisms for using federation technologies to interoperate with PIV and derived PIV credentials issued by other agencies. Federation protocols allow a trusted IdP to assert a cardholder’s id

changed here

7.1

in 7

Connecting PIV to Federation

When using a federation protocol, the PIV Card or derived PIV credential is not directly presented to the relying subsystem. Instead, the PIV Card or derived PIV credential SHALL be used to authenticate the PIV cardholder to the IdP of a fe

changed here

7.2

in 7

Federation Assurance Level (FAL)

[SP 800-63] defines three dimensions of assurance: IAL, AAL, and FAL. The use of a PIV Card or a derived PIV credential for authentication in a federation transaction will determine the IAL and AAL of that transaction, but the FAL is determ

changed here

7.3

in 7

Benefits of Federation

While it is possible to directly process a PIV credential that belongs to a different agency, federation is the recommended way for an agency to accept and process PIV credentials from other agencies. Benefits of using a federation protoco

changed here

Appendix A

PIV Validation, Certification, and Accreditation

This appendix is normative. It provides compliance requirements for PIV validation, certification, and accreditation.

changed here

A.1

in A

Accreditation of PIV Card Issuers (PCI) and Derived PIV Credential

Issuers (DPCI) [HSPD-12] requires that PIV credentials be issued by providers whose reliability has been established by an official accreditation process. Consistent assessment guidelines are established for PIV Card Issuers (PCI) and Deri

changed here

A.2

in A

Application of Risk Management Framework to IT Systems

Supporting PCI The accreditation of the capability and reliability of a PCI and DPCI using the methodology outlined in [SP 800-79] depends on adequate security for the information systems that are used for PCI and DPCI functions. The assur

changed here

A.3

in A

Conformance Testing of PIV Card Application and Middleware

Assurance of conformance of the PIV Card application interface to this Standard and its associated technical specifications is needed in order to meet the security and interoperability goals of [HSPD-12]. To facilitate this, NIST has establ

changed here

A.4

in A

Cryptographic Testing and Validation

All on-card cryptographic modules that host the PIV Card application and cryptographic modules of card issuance and maintenance systems SHALL be validated to [FIPS 140] with an overall Security Level 2 (or higher). The facilities for [FIPS

changed here

A.5

in A

FIPS 201 Evaluation Program

In order to evaluate the conformance of specialized products that support the PIV functionality to this Standard and its associated technical specifications, GSA established the FIPS 201 Evaluation Program. The product families may include

changed here

Appendix B

PIV Object Identifiers and Certificate Extension

This appendix is normative. It provides additional details for the PIV objects identified in Section 4.

changed here

B.1

in B

PIV Object Identifiers

Table B-1, Table B-2, and Table B-3 list details for PIV object identifiers. Table B-1. PIV Object Identifiers for PIV eContent Types ID Object Identifier Description id-PIV- CHUIDSecurityObject 2.16.840.1.101.3.6.1 The associated content

changed here

B.2

in B

PIV Background Investigation Indicator Certificate Extension

(Deprecated) The PIV background investigation indicator (previously known as the NACI indicator) is deprecated under this version of the Standard, and it is expected that the indicator will be removed from a future revision. Instead of the

changed here

Appendix C

Glossary of Terms, Acronyms, and Notations

This appendix is informative. It describes the vocabulary and textual representations used in the document.

changed here

C.1

in C

Glossary of Terms

The following terms are used throughout this Standard. Access Control The process of granting or denying specific requests to 1) obtain and use information and related information processing services and 2) enter specific physical faciliti

changed here

C.2

in C

Acronyms and Abbreviations

The following acronyms and abbreviations are used throughout this Standard: AAL Authenticator Assurance Level AAMVA American Association of Motor Vehicle Administrators ACL Access Control List AID Application Identifier AIM Association

changed here

C.3

in C

Notations

This Standard uses the following typographical conventions in text: • ASN.1 data types are represented in a monospaced font . For example, SignedData and SignerInfo are data types defined for digital signatures. • Specific terms in CAPITAL

changed here

Appendix D

References

This appendix is informative. It lists the specifications and standards referred to in this document. [A-130] Office of Management and Budget (2016) Managing Information as a Strategic Resource. (The White House, Washington, DC), OMB Circu

changed here

Appendix E

Revision History

This appendix is informative. It provides an overview of the changes to FIPS 201 since its initial release. Version Release Date Updates Location FIPS 201 February 2005 Initial Release FIPS 201-1 March 2006 Added the requirement for electr

changed here