Back

North America > US National Institute of Standards and Technology

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



AD ID

0003421

AD STATUS

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

ORIGINATOR

US National Institute of Standards and Technology

TYPE

International or National Standard

AVAILABILITY

Free

SYNONYMS

FIPS Pub 201-3

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

EFFECTIVE

2022-01-25

ADDED

The document as a whole was last reviewed and released on 2022-04-26T00:00:00-0700.

AD ID

0003421

AD STATUS

Free

ORIGINATOR

US National Institute of Standards and Technology

TYPE

International or National Standard

AVAILABILITY

SYNONYMS

FIPS Pub 201-3

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

EFFECTIVE

2022-01-25

ADDED

The document as a whole was last reviewed and released on 2022-04-26T00:00:00-0700.


Important Notice

This Authority Document In Depth Report is copyrighted - © 2024 - Network Frontiers LLC. All rights reserved. Copyright in the Authority Document analyzed herein is held by its authors. Network Frontiers makes no claims of copyright in this Authority Document.

This Authority Document In Depth Report is provided for informational purposes only and does not constitute, and should not be construed as, legal advice. The reader is encouraged to consult with an attorney experienced in these areas for further explanation and advice.

This Authority Document In Depth Report provides analysis and guidance for use and implementation of the Authority Document but it is not a substitute for the original authority document itself. Readers should refer to the original authority document as the definitive resource on obligations and compliance requirements.

The process we used to tag and map this document

This document has been mapped into the Unified Compliance Framework using a patented methodology and patented tools (you can research our patents HERE). The mapping team has taken every effort to ensure the quality of mapping is of the highest degree. To learn more about the process we use to map Authority Documents, or to become involved in that process, click HERE.

Controls and asociated Citations breakdown

When the UCF Mapping Teams tag Citations and their associated mandates within an Authority Document, those Citations and Mandates are tied to Common Controls. In addition, and by virtue of those Citations and mandates being tied to Common Controls, there are three sets of meta data that are associated with each Citation; Controls by Impact Zone, Controls by Type, and Controls by Classification.

The online version of the mapping analysis you see here is just a fraction of the work the UCF Mapping Team has done. The downloadable version of this document, available within the Common Controls Hub (available HERE) contains the following:

Document implementation analysis – statistics about the document’s alignment with Common Controls as compared to other Authority Documents and statistics on usage of key terms and non-standard terms.

Citation and Mandate Tagging and Mapping – A complete listing of each and every Citation we found within FIPS Pub 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors that have been tagged with their primary and secondary nouns and primary and secondary verbs in three column format. The first column shows the Citation (the marker within the Authority Document that points to where we found the guidance). The second column shows the Citation guidance per se, along with the tagging for the mandate we found within the Citation. The third column shows the Common Control ID that the mandate is linked to, and the final column gives us the Common Control itself.

Dictionary Terms – The dictionary terms listed for FIPS Pub 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors are based upon terms either found within the Authority Document’s defined terms section(which most legal documents have), its glossary, and for the most part, as tagged within each mandate. The terms with links are terms that are the standardized version of the term.



Common Controls and
mandates by Impact Zone
118 Mandated Controls - bold    
83 Implied Controls - italic     457 Implementation

An Impact Zone is a hierarchical way of organizing our suite of Common Controls — it is a taxonomy. The top levels of the UCF hierarchy are called Impact Zones. Common Controls are mapped within the UCF’s Impact Zones and are maintained in a legal hierarchy within that Impact Zone. Each Impact Zone deals with a separate area of policies, standards, and procedures: technology acquisition, physical security, continuity, records management, etc.


The UCF created its taxonomy by looking at the corpus of standards and regulations through the lens of unification and a view toward how the controls impact the organization. Thus, we created a hierarchical structure for each impact zone that takes into account regulatory and standards bodies, doctrines, and language.

Number of Controls
658 Total
  • Human Resources management
    37
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Human Resources management CC ID 00763 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain high level operational roles and responsibilities. CC ID 00806 Establish Roles Preventive
    Define and assign the Privacy Officer's roles and responsibilities. CC ID 00714
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Assign an individual to the role of privacy official. The privacy official is the individual who oversees privacy-related matters in the PIV system and is responsible for implementing the privacy requirements in the Standard. The individual serving in this role SHALL NOT assume any other operational role in the PIV system. 2.11 ¶ 3 Bullet 1]
    Establish Roles Preventive
    Establish, implement, and maintain a personnel management program. CC ID 14018 Establish/Maintain Documentation Preventive
    Establish and maintain Personnel Files for all employees. CC ID 12438 Human Resources Management Preventive
    Include background check results in each employee's personnel file. CC ID 12439
    [{background investigation} Once the investigation is completed, the authorized adjudicative entity SHALL adjudicate the investigation and report the final eligibility determination to the Central Verification System (or successor) and, if applicable, their enrollment in the Continuous Vetting Program as defined in [EO 13764]. This determination SHALL be recorded in or referenced by the PIV enrollment record to reflect PIV eligibility for the PIV cardholder. 2.2 ¶ 5
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2]
    Human Resources Management Preventive
    Establish, implement, and maintain a personnel security program. CC ID 10628 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain security clearance level criteria. CC ID 00780 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain staff position risk designations. CC ID 14280
    [Federal departments and agencies must follow investigative requirements established by the Suitability and Credentialing Executive Agent and the Security Executive Agent. Departments and agencies SHALL use position designation guidance issued by the Executive Agents. The designation of the position determines the prerequisite investigative requirement. Individuals being processed for a PIV Card SHALL receive the required investigation and are subject to any applicable reinvestigation or continuous vetting requirements to maintain their PIV eligibility. 2.2 ¶ 2]
    Human Resources Management Preventive
    Employ individuals who have the appropriate staff qualifications, staff clearances, and staff competencies. CC ID 00782 Testing Detective
    Establish, implement, and maintain personnel screening procedures. CC ID 11700
    [For full guidance on PIV credentialing investigative and adjudicative requirements, to include continuous vetting, issuers must work closely with their personnel security/suitability offices to ensure adherence to the latest federal personnel vetting guidance as provided by the Executive Agents. 2.2 ¶ 6
    Federal departments and agencies must follow investigative requirements established by the Suitability and Credentialing Executive Agent and the Security Executive Agent. Departments and agencies SHALL use position designation guidance issued by the Executive Agents. The designation of the position determines the prerequisite investigative requirement. Individuals being processed for a PIV Card SHALL receive the required investigation and are subject to any applicable reinvestigation or continuous vetting requirements to maintain their PIV eligibility. 2.2 ¶ 2]
    Establish/Maintain Documentation Preventive
    Perform a background check during personnel screening. CC ID 11758
    [{does not exist} For individuals for whom no prior investigation exists, the appropriate required investigation SHALL be initiated with the authorized federal investigative service provider and the FBI NCHC portion of the background investigation SHALL be completed and favorably adjudicated prior to PIV Card issuance. 2.2 ¶ 4]
    Human Resources Management Detective
    Perform a personal identification check during personnel screening. CC ID 06721 Human Resources Management Preventive
    Perform a criminal records check during personnel screening. CC ID 06643
    [Biometric identification using fingerprints is the primary input to law enforcement checks. In cases where ten fingerprints are not available, then as many fingers as possible SHALL be imaged as per guidance in [SP 800-76]. In cases where no fingers are available to be imaged, agencies SHALL seek guidance from their respective investigative service provider for alternative means of performing law enforcement checks. 2.3 ¶ 3]
    Establish/Maintain Documentation Preventive
    Include all residences in the criminal records check. CC ID 13306 Process or Activity Preventive
    Document any reasons a full criminal records check could not be performed. CC ID 13305 Establish/Maintain Documentation Preventive
    Perform a personal references check during personnel screening. CC ID 06645 Human Resources Management Preventive
    Perform a credit check during personnel screening. CC ID 06646 Human Resources Management Preventive
    Perform an academic records check during personnel screening. CC ID 06647 Establish/Maintain Documentation Preventive
    Perform a drug test during personnel screening. CC ID 06648 Testing Preventive
    Perform a resume check during personnel screening. CC ID 06659 Human Resources Management Preventive
    Perform a curriculum vitae check during personnel screening. CC ID 06660 Human Resources Management Preventive
    Allow personnel being screened to appeal findings and appeal decisions. CC ID 06720 Human Resources Management Preventive
    Disseminate and communicate screening results to interested personnel and affected parties. CC ID 16445 Communicate Preventive
    Perform personnel screening procedures, as necessary. CC ID 11763
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential is issued to an individual only after a proper authority has authorized issuance of the credential, the individual’s identity has been verified, and the individual has been vetted per Section 2.2. 2.1 ¶ 2 Bullet 1]
    Human Resources Management Preventive
    Establish, implement, and maintain security clearance procedures. CC ID 00783
    [For linking to background investigations, only fingerprints SHALL be used, since fingerprints are the only biometric characteristic used for background investigations. For all other purposes, verification attempts MAY be performed against any available biometric characteristic stored electronically on the PIV Card or in the enrollment record. 2.5 ¶ 7]
    Establish/Maintain Documentation Preventive
    Perform periodic background checks on designated roles, as necessary. CC ID 11759
    [{are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2]
    Human Resources Management Detective
    Perform security clearance procedures, as necessary. CC ID 06644 Human Resources Management Preventive
    Establish and maintain security clearances. CC ID 01634 Human Resources Management Preventive
    Document the security clearance procedure results. CC ID 01635 Establish/Maintain Documentation Detective
    Establish and maintain the staff structure in line with the strategic plan. CC ID 00764 Establish Roles Preventive
    Implement segregation of duties in roles and responsibilities. CC ID 00774
    [The PIV identity proofing, registration, issuance, and reissuance processes SHALL adhere to the y-noun">principlespan> of an style="background-color:#F0BBBC;" class="term_primary-noun">separation of duties to ensure that no single individual has the capability to issue a PIV Card without the cooperation of another authorized person. The PIV identity proofing, registration, issuance, and reissuance processes SHALL adhere to the principle of separation of duties to ensure that no single individual has the capability to issue a PIV Card without the cooperation of another authorized person. 2.7 ¶ 10]
    Testing Detective
    Establish, implement, and maintain segregation of duties compensating controls if segregation of duties is not practical. CC ID 06960 Technical Security Preventive
    Train all personnel and third parties, as necessary. CC ID 00785 Behavior Preventive
    Establish, implement, and maintain training plans. CC ID 00828 Establish/Maintain Documentation Preventive
    Include duties and responsibilities in the training plan, as necessary. CC ID 12800 Human Resources Management Preventive
    Conduct bespoke roles and responsibilities training, as necessary. CC ID 13192
    [Supervised remote identity proofing SHALL meet the following requirements: The issuer SHALL require operators to have undergone a training program to detect potential fraud and to properly perform a supervised remote identity proofing session. 2.7.1 ¶ 4 Bullet 3]
    Training Preventive
  • Leadership and high level objectives
    9
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Leadership and high level objectives CC ID 00597 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain a reporting methodology program. CC ID 02072 Business Processes Preventive
    Establish, implement, and maintain communication protocols. CC ID 12245 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain alert procedures that follow the organization's communication protocol. CC ID 12406
    [{be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2]
    Establish/Maintain Documentation Preventive
    Include the capturing and alerting of compliance violations in the notification system. CC ID 12962 Monitor and Evaluate Occurrences Preventive
    Include the capturing and alerting of unethical conduct in the notification system. CC ID 12932 Monitor and Evaluate Occurrences Preventive
    Include the capturing and alerting of performance variances in the notification system. CC ID 12929 Monitor and Evaluate Occurrences Preventive
    Include the capturing and alerting of weaknesses in the notification system. CC ID 12928 Monitor and Evaluate Occurrences Preventive
    Include the capturing and alerting of account activity in the notification system. CC ID 15314 Monitor and Evaluate Occurrences Preventive
  • Monitoring and measurement
    31
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Monitoring and measurement CC ID 00636 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain a testing program. CC ID 00654 Behavior Preventive
    Establish, implement, and maintain a stress test program for identification cards or badges. CC ID 15424
    [{PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain a compliance monitoring policy. CC ID 00671 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain a metrics policy. CC ID 01654 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain an approach for compliance monitoring. CC ID 01653 Establish/Maintain Documentation Preventive
    Monitor personnel and third parties for compliance to the organizational compliance framework. CC ID 04726
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that the technologies used in the department or agency’s implementation of the PIV system allow for continuous auditing of compliance with stated privacy policies and with practices governing the collection, use, and distribution of information in the operation of the program. 2.11 ¶ 3 Bullet 9]
    Monitor and Evaluate Occurrences Detective
    Identify and document instances of non-compliance with the compliance framework. CC ID 06499 Establish/Maintain Documentation Preventive
    Align enforcement reviews for non-compliance with organizational risk tolerance. CC ID 13063 Business Processes Detective
    Determine the causes of compliance violations. CC ID 12401 Investigate Corrective
    Identify and document events surrounding non-compliance with the organizational compliance framework. CC ID 12935 Establish/Maintain Documentation Preventive
    Determine if multiple compliance violations of the same type could occur. CC ID 12402 Investigate Detective
    Correct compliance violations. CC ID 13515 Process or Activity Corrective
    Review the effectiveness of disciplinary actions carried out for compliance violations. CC ID 12403 Investigate Detective
    Carry out disciplinary actions when a compliance violation is detected. CC ID 06675 Behavior Corrective
    Align disciplinary actions with the level of compliance violation. CC ID 12404 Human Resources Management Preventive
    Establish, implement, and maintain disciplinary action notices. CC ID 16577 Establish/Maintain Documentation Preventive
    Include a copy of the order in the disciplinary action notice. CC ID 16606 Establish/Maintain Documentation Preventive
    Include the sanctions imposed in the disciplinary action notice. CC ID 16599 Establish/Maintain Documentation Preventive
    Include the effective date of the sanctions in the disciplinary action notice. CC ID 16589 Establish/Maintain Documentation Preventive
    Include the requirements that were violated in the disciplinary action notice. CC ID 16588 Establish/Maintain Documentation Preventive
    Include responses to charges from interested personnel and affected parties in the disciplinary action notice. CC ID 16587 Establish/Maintain Documentation Preventive
    Include the reasons for imposing sanctions in the disciplinary action notice. CC ID 16586 Establish/Maintain Documentation Preventive
    Disseminate and communicate the disciplinary action notice to interested personnel and affected parties. CC ID 16585 Communicate Preventive
    Include required information in the disciplinary action notice. CC ID 16584 Establish/Maintain Documentation Preventive
    Include a justification for actions taken in the disciplinary action notice. CC ID 16583 Establish/Maintain Documentation Preventive
    Include a statement on the conclusions of the investigation in the disciplinary action notice. CC ID 16582 Establish/Maintain Documentation Preventive
    Include the investigation results in the disciplinary action notice. CC ID 16581 Establish/Maintain Documentation Preventive
    Include a description of the causes of the actions taken in the disciplinary action notice. CC ID 16580 Establish/Maintain Documentation Preventive
    Include the name of the person responsible for the charges in the disciplinary action notice. CC ID 16579 Establish/Maintain Documentation Preventive
    Include contact information in the disciplinary action notice. CC ID 16578 Establish/Maintain Documentation Preventive
  • Operational management
    74
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Operational management CC ID 00805 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain a disability accessibility program. CC ID 06191
    [There are methods by which proper card orientation can be indicated. Section 4.1.4.3, for example, defines Zones 21F and 22F, where card orientation features MAY be applied. Note: If an agency determines that tactilely discernible markers for PIV Cards impose an undue burden, the agency SHALL implement policies and procedures to accommodate employees and contractors with disabilities in accordance with Sections 501 and 504 of the Rehabilitation Act. 4.1.3 ¶ 6]
    Establish/Maintain Documentation Preventive
    Include disability accessibility standards in the disability accessibility program. CC ID 06192 Testing Detective
    Follow disability accessibility standards when designing and building content. CC ID 06193 Testing Detective
    Install telecommunications equipment that meets the disability accessibility standards. CC ID 06194 Testing Detective
    Install audio and visual equipment that meets the disability accessibility standards. CC ID 06195 Testing Detective
    Acquire commercial off the shelf products that meet the disability accessibility standards. CC ID 06196 Testing Detective
    Acquire workstations and laptops that meet the disability accessibility standards. CC ID 06197 Testing Detective
    Write functional requirements for new systems to meet the disability accessibility standards. CC ID 06198 Business Processes Preventive
    Separate foreground from background when designing and building content. CC ID 15125 Systems Design, Build, and Implementation Preventive
    Establish, implement, and maintain web content accessibility guidelines. CC ID 14949 Establish/Maintain Documentation Preventive
    Configure focus order in a meaningful way. CC ID 15206 Configuration Preventive
    Configure keyboard interfaces to provide all the functionality that is available for the associated website content. CC ID 15151 Configuration Preventive
    Programmatically set the states, properties, and values of user interface components. CC ID 15150 Configuration Preventive
    Notify users of changes to user interface components. CC ID 15149 Configuration Preventive
    Refrain from designing content in a way that is known to cause seizures or physical reactions. CC ID 15203 Configuration Preventive
    Configure content to be compatible with various user agents and assistive technologies. CC ID 15147 Configuration Preventive
    Configure content to be interpreted by various user agents and assistive technologies. CC ID 15146 Configuration Preventive
    Provide captions for prerecorded audio content. CC ID 15204 Configuration Preventive
    Ensure user interface component names include the same text that is presented visually. CC ID 15145 Configuration Preventive
    Configure user interface components to operate device motion and user motion functionality. CC ID 15144 Configuration Preventive
    Configure single pointer functionality to organizational standards. CC ID 15143 Configuration Preventive
    Configure the keyboard operable user interface so the keyboard focus indicator is visible. CC ID 15142 Configuration Preventive
    Provide users the ability to disable user motion and device motion. CC ID 15205 Configuration Preventive
    Refrain from duplicating attributes in website content using markup languages. CC ID 15141 Configuration Preventive
    Use unique identifiers when using markup languages. CC ID 15140 Configuration Preventive
    Programmatically determine the status messages to convey to users. CC ID 15139 Configuration Preventive
    Advise users on how to navigate content. CC ID 15138 Communicate Preventive
    Allow users the ability to move focus with the keyboard. CC ID 15136 Configuration Preventive
    Avoid using images of text to convey information. CC ID 15202 Configuration Preventive
    Allow users to pause, stop, or hide moving, blinking or scrolling information. CC ID 15135 Configuration Preventive
    Display website content without loss of information or functionality and without requiring scrolling in two dimensions. CC ID 15134 Configuration Preventive
    Use images of text to convey information, as necessary. CC ID 15132 Configuration Preventive
    Refrain from using color as the only visual means to distinguish content. CC ID 15130 Configuration Preventive
    Refrain from restricting content to a single display orientation. CC ID 15129 Configuration Preventive
    Use text to convey information on web pages, as necessary. CC ID 15128 Configuration Preventive
    Configure the contrast ratio to organizational standards. CC ID 15127 Configuration Preventive
    Programmatically determine the correct reading sequence. CC ID 15126 Configuration Preventive
    Refrain from creating instructions for content that rely on sensory characteristics of components. CC ID 15124 Establish/Maintain Documentation Preventive
    Programmatically determine the information, structure, and relationships conveyed through the presentation. CC ID 15123 Configuration Preventive
    Provide audio descriptions for all prerecorded video content. CC ID 15122 Configuration Preventive
    Provide alternative forms of CAPTCHA, as necessary. CC ID 15121 Configuration Preventive
    Provide alternatives for time-based media. CC ID 15119 Configuration Preventive
    Configure non-text content to be ignored by assistive technology when it is pure decoration or not presented to users. CC ID 15118 Configuration Preventive
    Configure non-text content with a descriptive identification. CC ID 15117 Configuration Preventive
    Provide text alternatives for non-text content, as necessary. CC ID 15078 Configuration Preventive
    Implement functionality for a single pointer so an up-event reverses the outcome of a down-event. CC ID 15076 Configuration Preventive
    Implement functionality for a single pointer so the completion of a down-event is essential. CC ID 15075 Configuration Preventive
    Implement functionality to abort or undo the function when using a single pointer. CC ID 15074 Configuration Preventive
    Implement functionality for a single pointer so the up-event signals the completion of a function. CC ID 15073 Configuration Preventive
    Implement functionality for a single pointer so the down-event is not used to execute any part of a function. CC ID 15072 Configuration Preventive
    Allow users the ability to use various input devices. CC ID 15071 Configuration Preventive
    Implement mechanisms to allow users the ability to bypass repeated blocks of website content. CC ID 15068 Configuration Preventive
    Implement flashes below the general flash and red flash thresholds on web pages. CC ID 15067 Configuration Preventive
    Configure content to be presentable in a manner that is clear and conspicuous to all users. CC ID 15066 Configuration Preventive
    Configure non-text content that is a control or accepts user input with a name that describes its purpose. CC ID 15065 Configuration Preventive
    Allow users the ability to modify time limits in website content a defined number of times. CC ID 15064 Configuration Preventive
    Provide users with a simple method to extend the time limits set by content. CC ID 15063 Configuration Preventive
    Allow users the ability to disable time limits set by content. CC ID 15062 Configuration Preventive
    Warn users before time limits set by content are about to expire. CC ID 15061 Configuration Preventive
    Allow users the ability to modify time limits set by website or native applications. CC ID 15060 Configuration Preventive
    Provide users time to read and use website content, as necessary. CC ID 15059 Configuration Preventive
    Activate keyboard shortcuts on user interface components only when the appropriate component has focus. CC ID 15058 Configuration Preventive
    Provide users a mechanism to turn off keyboard shortcuts, as necessary. CC ID 15057 Configuration Preventive
    Configure all functionality to be accessible with a keyboard. CC ID 15056 Configuration Preventive
    Establish, implement, and maintain a registration database. CC ID 15048
    [{PIV enrollment records} The card issuer SHALL maintain the enrollment record for each issued ground-color:#CBD0E5;" class="term_secondary-verb">PIV Card. These enrollment records are created and maintained through the methods of contemporaneous acquisition at each step of the PIV issuance process—typically including identity proofing, registration, and biometric enrollment. 2.6 ¶ 1
    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-PKI derived PIV credentials are not required to be updated or reissued in these situations. 2.10.3 ¶ 1
    {PIV enrollment records} The card issuer SHALL maintain the enrollment record for each issued ground-color:#CBD0E5;" class="term_secondary-verb">PIV Card. These enrollment records are created and maintained through the methods of contemporaneous acquisition at each step of the PIV issuance process—typically including identity proofing, registration, and biometric enrollment. 2.6 ¶ 1
    The requirements for identity proofing and registration also apply to citizens of foreign countries who are working for the U.S. Federal Government overseas. However, a process for identity proofing and registration SHALL be established using a method approved by the U.S. Department of State's Bureau of Diplomatic Security, except for employees under the command of a U.S. area military commander. These procedures vary depending on the country. The requirements for identity proofing and registration also apply to citizens of foreign countries who are working for the U.S. Federal Government overseas. However, a process for identity proofing and registration SHALL be established using a method approved by the U.S. Department of State's Bureau of Diplomatic Security, except for employees under the command of a U.S. area military commander. These procedures vary depending on the country. 2.7 ¶ 12]
    Data and Information Management Preventive
    Grant registration after competence and integrity is verified. CC ID 16802 Behavior Detective
    Include contact details in the registration database. CC ID 15109 Establish/Maintain Documentation Preventive
    Include personal data in the registration database, as necessary. CC ID 15108
    [{data in transit}{data at rest} PIV enrollment records contain Personally Identifiable Information (PII). PII SHALL be protected in a manner that protects the individual’s privacy and maintains the integrity of the records both in transit and at rest. 2.6 ¶ 5]
    Establish/Maintain Documentation Preventive
    Make the registration database available to the public. CC ID 15107 Communicate Preventive
    Impose conditions or restrictions on the termination or suspension of a registration. CC ID 16796 Business Processes Preventive
    Publish the IP addresses being used by each external customer in the registration database. CC ID 16403 Data and Information Management Preventive
    Maintain the accuracy of registry information published in registration databases. CC ID 16402 Data and Information Management Preventive
    Include all required information in the registration database. CC ID 15106
    [{individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    PIV enrollment records SHOULD include the following data: Unique identifiers issued to the individual, such as the Federal Agency Smart Credential Number (FASC-N), the cardholder Universally Unique Identifier (UUID), and the card UUID. The record MAY contain historical unique identifiers. 2.6 ¶ 3 Bullet 3
    PIV enrollment records SHOULD include the following data: Information about the authorizing entity that has approved the issuance of a credential. 2.6 ¶ 3 Bullet 4
    PIV enrollment records SHOULD include the following data: Current status of the background investigation, including the results of the investigation once completed. 2.6 ¶ 3 Bullet 5
    PIV enrollment records SHOULD include the following data: Current status of the background investigation, including the results of the investigation once completed. 2.6 ¶ 3 Bullet 5
    PIV enrollment records SHOULD include the following data: The evidence of authorization if the credential is issued under a pseudonym. 2.6 ¶ 3 Bullet 6
    PIV enrollment records SHOULD include the following data: Any data about the cardholder, including subsequent changes in the data (e.g., cardholder name changes per Section 2.9.1.1). 2.6 ¶ 3 Bullet 7
    {applicable requirements} If there is any data change about the cardholder, the issuer SHALL record this data change in the PIV enrollment record, if applicable. If the changed data is the cardholder’s name, then the issuer SHALL meet the requirements in Section 2.9.1.1. 2.9.1 ¶ 6
    {applicable requirements} If there is any data change about the cardholder, the issuer SHALL record this data change in the PIV enrollment record, if applicable. If the changed data is the cardholder’s name, then the issuer SHALL meet the requirements in Section 2.9.1.1. 2.9.1 ¶ 6
    PIV enrollment records SHOULD include the following data: An enrollment data record that contains the most recent collection of each of the biometric data collected. The enrollment data record describes the circumstances of biometric acquisition including the name and role of the acquiring agent, the office and organization, time, place, and acquisition method. The enrollment data record MAY also document unavailable biometric data or failed attempts to collect biometric data. The enrollment data record MAY contain historical biometric data records. 2.6 ¶ 3 Bullet 2
    PIV enrollment records SHALL maintain an auditable sequence of enrollment events to facilitate binding an applicant to multiple transactions that might take place at different times and locations. These records are generally stored as part of the cardholder’s PIV identity account, either as part of the issuer’s IDMS or through links to records in other related systems (e.g., card management systems). 2.6 ¶ 2]
    Data and Information Management Preventive
  • Physical and environmental protection
    23
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Physical and environmental protection CC ID 00709 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain a physical security program. CC ID 11757 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain an anti-tamper protection program. CC ID 10638 Monitor and Evaluate Occurrences Detective
    Protect assets from tampering or unapproved substitution. CC ID 11902
    [{PIV Card}{anti-counterfeiting technique} All security features SHOULD maintain their function for the life of the card. As a generally accepted security procedure, federal departments and agencies SHOULD periodically review the viability, effectiveness, and currency of employed tamper resistance and anti-counterfeiting methods. 4.1.2 ¶ 10]
    Physical and Environmental Protection Preventive
    Establish, implement, and maintain a facility physical security program. CC ID 00711 Establish/Maintain Documentation Preventive
    Identify and document physical access controls for all physical entry points. CC ID 01637 Establish/Maintain Documentation Preventive
    Control physical access to (and within) the facility. CC ID 01329 Physical and Environmental Protection Preventive
    Establish, implement, and maintain physical identification procedures. CC ID 00713 Establish/Maintain Documentation Preventive
    Implement operational requirements for card readers. CC ID 02225
    [{applicable 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 desktop computing systems and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.1 ¶ 1
    {applicable 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 desktop computing systems and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.1 ¶ 1
    {applicable 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 desktop computing systems and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.1 ¶ 1
    {applicable 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 computing systems, they SHALL conform to [PCSC] for the reader-to-host system interface and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.2 ¶ 1
    {applicable 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 computing systems, they SHALL conform to [PCSC] for the reader-to-host system interface and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.2 ¶ 1
    {applicable 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 computing systems, they SHALL conform to [PCSC] for the reader-to-host system interface and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.2 ¶ 1
    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 to a website or other server), the input device is not required to be integrated with the PIV Card reader. If the input device is not integrated with the PIV Card reader, the PIN or OCC data SHALL be transmitted securely and directly to the PIV Card for card activation. 4.4.4 ¶ 1]
    Testing Preventive
    Establish, implement, and maintain lost or damaged identification card procedures, as necessary. CC ID 14819
    [Derived PIV credentials SHALL be invalidated in any of the following circumstances at the determination of the issuer upon reported loss or suspected compromise of a derived PIV credential; 2.10.2 ¶ 1 Bullet 2
    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; 2.10.2 ¶ 1 Bullet 1
    {lost identification card or badge}{stolen identification card or badge}{stipulated time frame} In the case of a lost, stolen, or compromised card, normal revocation procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay, and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.1 ¶ 5]
    Establish/Maintain Documentation Preventive
    Document all lost badges in a lost badge list. CC ID 12448 Establish/Maintain Documentation Corrective
    Report lost badges, stolen badges, and broken badges to the Security Manager. CC ID 12334
    [{lost identification card or badge}{stolen identification card or badge}{stipulated time frame} In the case of a lost, stolen, or compromised card, normal revocation procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay, and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.1 ¶ 5]
    Physical and Environmental Protection Preventive
    Establish, implement, and maintain identification issuance procedures for identification cards or badges. CC ID 06598
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A person suspected or known to the government as being a terrorist is not issued a credential. 2.1 ¶ 2 Bullet 5
    {stipulated time frame} The PIV Card SHALL be valid for no more than six years. 2.8 ¶ 1 Bullet 7
    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 identity proofing and registration process that meets the requirements defined below when issuing PIV Cards. 2.7 ¶ 1
    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 writing by the head or deputy (or equivalent) of the federal department or agency. 2.8 ¶ 1
    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 writing by the head or deputy (or equivalent) of the federal department or agency. 2.8 ¶ 1
    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 writing by the head or deputy (or equivalent) of the federal department or agency. 2.8 ¶ 1
    {applicable requirements} The department or agency SHALL use an approved PIV credential issuance process in accordance with [SP 800-79]. 2.8 ¶ 1 Bullet 2
    The department or agency SHALL issue PIV credentials only through systems and providers whose reliability has been established by the agency and so documented and approved in writing (i.e., accredited) in accordance with [SP 800-79]. 2.8 ¶ 1 Bullet 6
    PIV Cards SHALL be issued only after the adjudicative entity has authorized issuance of the credential. 2.8 ¶ 1 Bullet 1
    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 necessary to protect an employee or contractor (e.g., from physical harm, severe distress, or harassment), the agency may formally authorize the issuance of a PIV Card to the employee or contractor using the agency-approved pseudonym. The issuance of a PIV Card using an authorized pseudonym SHALL follow the procedures in Section 2.8 except that the card issuer SHALL receive satisfactory evidence that the pseudonym is authorized by the agency. 2.8.1 ¶ 1
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {negative biometric verification decision} {are not available} The issuer SHALL perform a biometric verification of the applicant to the biometric data records of the PIV enrollment record or to the biometric data records of the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. Minimum accuracy requirements for the biometric verification are specified in [SP 800-76]. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.9.1 ¶ 3
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {applicable requirements} Remote issuance SHALL satisfy all of the requirements of Section 2.8. The issuer SHALL have local trained staff to securely maintain custody of card stock received by the remote station when the station is used for PIV Card issuance. 2.8.3 ¶ 2
    {issuing organization} Derived PIV credentials SHALL be bound to the cardholder’s PIV identity account only by the issuing department or agency responsible for managing that PIV identity account. If the issuing department or agency relies on shared services for portions of the PIV Card or Derived PIV credential issuance process, it is the responsibility of the issuing department or agency to ensure that all credentials and IDMS records are properly maintained throughout the PIV lifecycle. 2.10.1 ¶ 3
    {issuing organization} Derived PIV credentials SHALL be bound to the cardholder’s PIV identity account only by the issuing department or agency responsible for managing that PIV identity account. If the issuing department or agency relies on shared services for portions of the PIV Card or Derived PIV credential issuance process, it is the responsibility of the issuing department or agency to ensure that all credentials and IDMS records are properly maintained throughout the PIV lifecycle. 2.10.1 ¶ 3
    {appear in person} If biometric data cannot be positively verified per the criteria defined in [SP 800-76], remote issuance SHALL NOT be used and issuance will be performed in person at the issuer’s facility. The trained operator SHALL terminate a remote issuance session and require in-person issuance at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.8.3 ¶ 3
    {appear in person} If biometric data cannot be positively verified per the criteria defined in [SP 800-76], remote issuance SHALL NOT be used and issuance will be performed in person at the issuer’s facility. The trained operator SHALL terminate a remote issuance session and require in-person issuance at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.8.3 ¶ 3]
    Establish/Maintain Documentation Preventive
    Record the assigned identification card or badge serial number when issuing an identification card or badge. CC ID 06714 Process or Activity Preventive
    Include error handling controls in identification issuance procedures. CC ID 13709
    [PIV Cards that contain topographical defects (e.g., scratches, poor color, fading, etc.) or that are not properly printed SHALL be destroyed. The PIV Card issuer is responsible for the card stock, its management, and its integrity. 2.8 ¶ 2]
    Establish/Maintain Documentation Preventive
    Include an appeal process in the identification issuance procedures. CC ID 15428
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Maintain appeal procedures for those who are denied a credential or whose credentials are revoked. 2.11 ¶ 3 Bullet 6]
    Business Processes Preventive
    Include information security in the identification issuance procedures. CC ID 15425
    [{refrain from implementing}{not be consistent} Departments and agencies may have a wide variety of uses for the PIV system and its components that were not intended or anticipated by the President in issuing [HSPD-12]. In considering whether a proposed use of the PIV system is appropriate, departments and agencies SHALL consider the aforementioned control objectives and the purpose of this Standard, namely “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy” as per [HSPD-12]. No department or agency SHALL implement a use of the identity credential inconsistent with these control objectives. 2.11 ¶ 2]
    Establish/Maintain Documentation Preventive
    Include identity proofing processes in the identification issuance procedures. CC ID 06597
    [Biometric data used to personalize the PIV Card SHALL be those captured during the identity proofing and registration process. 2.8 ¶ 1 Bullet 4
    The applicant SHALL appear in person at least once before the issuance of a PIV Card, either at the issuing facility or at a supervised remote identity proofing station (as described in Section 2.7.1). 2.7 ¶ 5
    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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {negative biometric verification decision} {are not available} The issuer SHALL perform a biometric verification of the applicant to the biometric data records of the PIV enrollment record or to the biometric data records of the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. Minimum accuracy requirements for the biometric verification are specified in [SP 800-76]. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.9.1 ¶ 3
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2
    {not acquire} When PIN reset is performed in person at the issuing facility, before providing the reset PIV Card back to the cardholder, the issuer SHALL perform a biometric verification to ensure that the cardholder’s biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect the identity document and <span style="background-color:#B7D8ED;" claground-color:#CBD0E5;" class="term_secondary-verb">ss="term_primary-verb">compare the "background-color:#F0BBBC;" class="term_primary-noun">cardholder with the electronic facial image retrieved from the enrollment data record and the ass="term_primary-noun">photograph printed on the card. 2.9.3.1 ¶ 3]
    Process or Activity Preventive
    Establish, implement, and maintain post-issuance update procedures for identification cards or badges. CC ID 15426
    [{be equivalent} A PIV Card post-issuance update MAY be done locally (i.e., performed with the issuer in physical custody of the PIV Card) or remotely (i.e., performed with the PIV Card at a remote location). Post-issuance updates SHALL be performed with issuer security controls equivalent to those applied during PIV Card reissuance. For remote postissuance updates, the following SHALL apply: 2.9.2 ¶ 2
    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, keys, biometric data records, or signed data objects are updated. A post-issuance update SHALL NOT modify the PIV Card expiration date, FASC-N, card UUID, or cardholder UUID. 2.9.2 ¶ 1
    For remote post-issuance updates, the following SHALL apply: Data transmitted between the PIV Card issuer and PIV Card SHALL be encrypted and contain data integrity checks. 2.9.2 ¶ 2 Bullet 2
    For remote post-issuance updates, the following SHALL apply: Communication between the PIV Card issuer and the PIV Card SHALL occur only over mutually authenticated secure sessions between tested and validated cryptographic modules (one being the PIV Card). 2.9.2 ¶ 2 Bullet 1
    For remote post-issuance updates, the following SHALL apply: The PIV Card application SHALL communicate with no endpoint entity other than the PIV Card issuer during the remote post-issuance update. 2.9.2 ¶ 2 Bullet 3
    For remote post-issuance updates, the following SHALL apply: Data transmitted between the PIV Card issuer and PIV Card SHALL be encrypted and contain data integrity checks. 2.9.2 ¶ 2 Bullet 2
    {after}{card issuance} The FASC-N, card UUID, expiration date, and, if present, cardholder UUID SHALL NOT be modified post-issuance. 4.2.1 ¶ 5
    {contact interface} All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL ound-color:#B7D8ED;" class="term_primary-verb">include all cryptographic operations performed over both the contact and contactless interfaces as part of -color:#CBD0E5;" class="term_secondary-verb">an style="background-color:#F0BBBC;" class="term_primary-noun">remote post issuance updates, as specified in Section 2.9.2. 4.2.2 ¶ 19 Bullet 3]
    Establish/Maintain Documentation Preventive
    Include an identity registration process in the identification issuance procedures. CC ID 11671
    [Before issuing the PIV Card, the issuer SHALL ensure that the individual receiving it has been properly processed per Section 2.1, Section 2.2, and Section 2.7. 2.8 ¶ 1 Bullet 3
    {identity proofing} {registration} The department or agency SHALL follow investigative requirements as outlined in Section 2.2. 2.7 ¶ 3
    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 necessary to protect an employee or contractor (e.g., from physical harm, severe distress, or harassment), the agency may formally authorize the issuance of a PIV Card to the employee or contractor using the agency-approved pseudonym. The issuance of a PIV Card using an authorized pseudonym SHALL follow the procedures in Section 2.8 except that the card issuer SHALL receive satisfactory evidence that the pseudonym is authorized by the agency. 2.8.1 ¶ 1
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain identification renewal procedures for identification cards or badges. CC ID 06599
    [If the expiration date of the new PIV Card is later than the expiration date of the old card, or if any data about the cardholder is being changed, the card issuer SHALL ensure that an adjudicative entity has authorized the issuance of the new PIV Card. The issuer SHALL ensure that the adjudicative entity has verified that there is a PIV eligibility determination in an authoritative record, such as the agency’s IDMS or the Central Verification System (or successor). 2.9.1 ¶ 2
    If the expiration date of the new PIV Card is later than the expiration date of the old card, or if any data about the cardholder is being changed, the card issuer SHALL ensure that an adjudicative entity has authorized the issuance of the new PIV Card. The issuer SHALL ensure that the adjudicative entity has verified that there is a PIV eligibility determination in an authoritative record, such as the agency’s IDMS or the Central Verification System (or successor). 2.9.1 ¶ 2
    {appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT pan style="background-color:#B7D8ED;" class="term_pri class="term_secondary-verb">mary-verb">resetspackground-color:#CBD0E5;" class="term_secondary-verb">n> the <span style="background-color:#F0BBBC;" class="term_primary-noun">PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain identification re-issuing procedures for identification cards or badges. CC ID 06596
    [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 formal name change—such as a marriage certificate, a divorce decree, judicial recognition of a name change, or other mechanism permitted by state law or regulation—the card issuer SHALL issue the cardholder a new card following the procedures set out in Section 2.9.1 and notify the respective adjudicative entity of the name change to ensure that appropriate records are updated. If the expiration date of the new card is no later than the expiration date of the old PIV Card and no data about the cardholder other than the cardholder’s name is being changed, then the new PIV Card MAY be issued without obtaining the approval of the adjudicative entity and without performing a re-investigation. 2.9.1.1 ¶ 1
    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 formal name change—such as a marriage certificate, a divorce decree, judicial recognition of a name change, or other mechanism permitted by state law or regulation—the card issuer SHALL issue the cardholder a new card following the procedures set out in Section 2.9.1 and notify the respective adjudicative entity of the name change to ensure that appropriate records are updated. If the expiration date of the new card is no later than the expiration date of the old PIV Card and no data about the cardholder other than the cardholder’s name is being changed, then the new PIV Card MAY be issued without obtaining the approval of the adjudicative entity and without performing a re-investigation. 2.9.1.1 ¶ 1
    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 PIV Card needs to be invalidated when the cardholder changes their name or employment status. In this regard, procedures for PIV Card maintenance must be integrated into department and agency procedures to ensure effective card maintenance. In order to maintain operational readiness of a cardholder’s PIV Card, agencies may require PIV Card update, reissuance, or biometric enrollment more frequently than the maximum PIV Card and biometric characteristic lifetimes stated in this Standard. Shorter lifetimes MAY be specified by agency policy. 2.9 ¶ 2
    Departments and agencies MAY adopt more stringent procedures for PIN or OCC reset (including disallowing resets); such procedures SHALL be formally documented by each department and agency. 2.9.3 ¶ 4
    Both fingerprints used for OCC SHALL be replaced during an OCC reset. 2.9.3.2 ¶ 1
    Post-issuance updates to biometric data records, other than to the digital signature blocks within the biometric data records, SHALL satisfy the requirements for PIV Card activation reset specified in Section 2.9.3. 2.9.2 ¶ 3]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain identification mechanism termination procedures. CC ID 06306
    [The revocation process SHALL include the following: The old PIV Card SHALL be collected and destroyed, if possible. 2.9.1 ¶ 4 Bullet 1
    The old PIV Card SHALL be revoked when the new PIV Card is issued. The revocation process SHALL include the following: 2.9.1 ¶ 4
    Derived PIV credentials SHALL be invalidated in any of the following circumstances at the determination of the issuer upon observation of possible fraudulent activity; or 2.10.2 ¶ 1 Bullet 3
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: The PIV Card SHALL be collected and destroyed, if possible. 2.9.4 ¶ 2 Bullet 1
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Per OPM guidance, the Central Verification System (or successor) SHALL be updated to reflect the change in status (see Section 2.2). 2.9.4 ¶ 2 Bullet 2
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: 2.9.4 ¶ 2
    {be fraudulent} 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 cardholder is determined to hold a fraudulent identity. 2.9.4 ¶ 1 Bullet 5
    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: An authorized adjudicative entity determines that the cardholder is ineligible for a PIV Card after completion of a cardholder’s background investigation or review of developed information (see [FCS] and [CSP]). 2.9.4 ¶ 1 Bullet 4
    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 cardholder passes away. 2.9.4 ¶ 1 Bullet 3
    {federal government} 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 contractor changes positions and no longer needs access to federal buildings or systems. 2.9.4 ¶ 1 Bullet 2
    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: 2.9.4 ¶ 1
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Any databases maintained by the PIV Card issuer that indicate current valid or invalid FASC-N or card UUID values SHALL be updated to reflect the change in status. 2.9.4 ¶ 2 Bullet 3
    In addition, the PIV Card termination procedures SHALL ensure that all derived PIV credentials bound to the PIV identity account are invalidated as specified in Section 2.10.2. 2.9.4 ¶ 3
    {PIV card} If the card cannot be collected, normal termination procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.4 ¶ 4
    {PIV card} If the card cannot be collected, normal termination procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.4 ¶ 4
    {not be destroyed} {not be collected} The revocation process SHALL include the following: If the old PIV Card cannot be collected and destroyed, or if the old PIV Card has been compromised or damaged, then the Certification Authority (CA) SHALL be informed and the certificates corresponding to the PIV authentication key (Section 4.2.2.1) and asymmetric card authentication key (Section 4.2.2.2) on the old PIV Card SHALL be revoked. If present, the certificates corresponding to the digital signature key (Section 4.2.2.1) and the key management key (Section 4.2.2.5) SHALL also be revoked. 2.9.1 ¶ 4 Bullet 3
    {not be destroyed} {not be collected} The revocation process SHALL include the following: If the old PIV Card cannot be collected and destroyed, or if the old PIV Card has been compromised or damaged, then the Certification Authority (CA) SHALL be informed and the certificates corresponding to the PIV authentication key (Section 4.2.2.1) and asymmetric card authentication key (Section 4.2.2.2) on the old PIV Card SHALL be revoked. If present, the certificates corresponding to the digital signature key (Section 4.2.2.1) and the key management key (Section 4.2.2.5) SHALL also be revoked. 2.9.1 ¶ 4 Bullet 3
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: If the PIV Card cannot be collected and destroyed, the CA SHALL be informed and the certificates corresponding to the PIV authentication key and the asymmetric card authentication key on the PIV Card SHALL be revoked. The certificates corresponding to the digital signature and key management keys SHALL also be revoked, if present. 2.9.4 ¶ 2 Bullet 4
    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 employee separates (voluntarily or involuntarily) from federal service. 2.9.4 ¶ 1 Bullet 1
    Derived PIV credentials SHALL be invalidated in any of the following circumstances: when the associated PIV Card is terminated as specified in Section 2.9.4—in this situation, all derived PIV credentials associated with the PIV identity account SHALL be invalidated. 2.10.2 ¶ 1 Bullet 4
    The revocation process SHALL include the following: Any databases maintained by the PIV Card issuer that contain FASC-N or card UUID values from the old PIV Card must be updated to reflect the change in status. 2.9.1 ¶ 4 Bullet 2
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Card management systems SHALL be updated to reflect PIV Card termination and method of termination (e.g., PIV Card destruction for collected PIV Cards or certificate revocations for uncollected PIV Cards). 2.9.4 ¶ 2 Bullet 5
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Card management systems SHALL be updated to reflect PIV Card termination and method of termination (e.g., PIV Card destruction for collected PIV Cards or certificate revocations for uncollected PIV Cards). 2.9.4 ¶ 2 Bullet 5]
    Establish/Maintain Documentation Preventive
  • Privacy protection for information and data
    182
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Privacy protection for information and data CC ID 00008 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain a privacy framework that protects restricted data. CC ID 11850 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain a personal data transparency program. CC ID 00375 Data and Information Management Preventive
    Establish and maintain privacy notices, as necessary. CC ID 13443 Establish/Maintain Documentation Preventive
    Include the types of third parties to which personal data is disclosed in the privacy notice. CC ID 13459
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Establish/Maintain Documentation Preventive
    Include the organization's policies, standards, and procedures in the privacy notice. CC ID 13455 Establish/Maintain Documentation Preventive
    Include the organization's privacy framework in the privacy notice, as necessary. CC ID 13456
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Establish/Maintain Documentation Preventive
    Include the types of personal data disclosed in the privacy notice. CC ID 13446
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Establish/Maintain Documentation Preventive
    Include descriptions of each type of personal data disclosed in the privacy notice. CC ID 13458 Establish/Maintain Documentation Preventive
    Provide adequate structures, policies, procedures, and mechanisms to support direct access by the data subject to personal data that is provided upon request. CC ID 00393 Establish/Maintain Documentation Preventive
    Provide the data subject with references to the appropriate safeguards used to protect the privacy of personal data. CC ID 12585 Process or Activity Preventive
    Provide the data subject with copies of the appropriate safeguards used to protect the privacy of personal data. CC ID 12608
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Provide PIV applicants with full disclosure of the intended uses of the information associated with the PIV Card and the related privacy implications. 2.11 ¶ 3 Bullet 4]
    Process or Activity Preventive
    Provide the data subject with a description of the type of information held by the organization and a general account of its use. CC ID 00397
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3
    {parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain a personal data accountability program. CC ID 13432 Establish/Maintain Documentation Preventive
    Assign ownership of the privacy program to the appropriate organizational role. CC ID 11848
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Assign an individual to the role of privacy official. The privacy official is the individual who oversees privacy-related matters in the PIV system and is responsible for implementing the privacy requirements in the Standard. The individual serving in this role SHALL NOT assume any other operational role in the PIV system. 2.11 ¶ 3 Bullet 1]
    Human Resources Management Preventive
    Establish, implement, and maintain a personal data use limitation program. CC ID 13428 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain a personal data use purpose specification. CC ID 00093 Establish/Maintain Documentation Preventive
    Notify the data subject of the collection purpose. CC ID 00095
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Provide PIV applicants with full disclosure of the intended uses of the information associated with the PIV Card and the related privacy implications. 2.11 ¶ 3 Bullet 4
    {parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Behavior Preventive
    Refrain from using restricted data collected for research and statistics for other purposes. CC ID 00096 Data and Information Management Preventive
    Establish, implement, and maintain restricted data use limitation procedures. CC ID 00128 Establish/Maintain Documentation Preventive
    Process restricted data lawfully and carefully. CC ID 00086
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that systems that contain PII for the purpose of enabling the implementation of PIV are handled in full compliance with fair information practices, as defined in [PRIVACY]. 2.11 ¶ 3 Bullet 5]
    Establish Roles Preventive
    Analyze requirements for processing personal data in contracts. CC ID 12550 Investigate Detective
    Implement technical controls that limit processing restricted data for specific purposes. CC ID 12646 Technical Security Preventive
    Process personal data pertaining to a patient's health in order to treat those patients. CC ID 00200 Data and Information Management Preventive
    Notify the subject of care when a lack of availability of health information systems might have adversely affected their care. CC ID 13990 Communicate Corrective
    Refrain from disclosing Individually Identifiable Health Information when in violation of territorial or federal law. CC ID 11966 Records Management Preventive
    Document the conditions for the use or disclosure of Individually Identifiable Health Information by a covered entity to another covered entity. CC ID 00210 Establish/Maintain Documentation Preventive
    Disclose Individually Identifiable Health Information for a covered entity's own use. CC ID 00211 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information for a healthcare provider's treatment activities by a covered entity. CC ID 00212 Data and Information Management Preventive
    Rely upon the warranty of the covered entity that the record disclosure request for Individually Identifiable Health Information is permitted with the consent of the data subject. CC ID 11970 Records Management Preventive
    Rely upon the warranty of the covered entity that the record disclosure request for Individually Identifiable Health Information is to support the treatment of the individual. CC ID 11969 Process or Activity Preventive
    Rely upon the warranty of the covered entity that the record disclosure request for Individually Identifiable Health Information is permitted by law. CC ID 11976 Records Management Preventive
    Disclose Individually Identifiable Health Information for payment activities between covered entities or healthcare providers. CC ID 00213 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information for Treatment, Payment, and Health Care Operations activities when both covered entities have a relationship with the data subject. CC ID 00214 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information for Treatment, Payment, and Health Care Operations activities between a covered entity and a participating healthcare provider when the information is collected from the data subject and a third party. CC ID 00215 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information in accordance with agreed upon restrictions. CC ID 06249 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information in accordance with the privacy notice. CC ID 06250 Data and Information Management Preventive
    Disclose permitted Individually Identifiable Health Information for facility directories. CC ID 06251 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information for cadaveric organ donation purposes, eye donation purposes, or tissue donation purposes. CC ID 06252 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information for medical suitability determinations. CC ID 06253 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information for armed forces personnel appropriately. CC ID 06254 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information in order to provide public benefits by government agencies. CC ID 06255 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information for fundraising. CC ID 06256 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information for research use when the appropriate requirements are included in the approval documentation or waiver documentation. CC ID 06257 Establish/Maintain Documentation Preventive
    Document the conditions for the disclosure of Individually Identifiable Health Information by an organization providing healthcare services to organizations other than business associates or other covered entities. CC ID 00201 Establish/Maintain Documentation Preventive
    Disclose Individually Identifiable Health Information when the data subject cannot physically or legally provide consent and the disclosing organization is a healthcare provider. CC ID 00202 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information to provide appropriate treatment to the data subject when the disclosing organization is a healthcare provider. CC ID 00203 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information when it is not contrary to the data subject's wish prior to becoming unable to provide consent and the disclosing organization is a healthcare provider. CC ID 00204 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information that is reasonable or necessary for the disclosure purpose when the disclosing organization is a healthcare provider. CC ID 00205 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information consistent with the law when the disclosing organization is a healthcare provider. CC ID 00206 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information in order to carry out treatment when the disclosing organization is a healthcare provider. CC ID 00207 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information in order to carry out treatment when the data subject has provided consent and the disclosing organization is a healthcare provider. CC ID 00208 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information in order to carry out treatment when the data subject's guardian or representative has provided consent and the disclosing organization is a healthcare provider. CC ID 00209 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information when the disclosing organization is a healthcare provider that supports public health and safety activities. CC ID 06248 Data and Information Management Preventive
    Disclose Individually Identifiable Health Information in order to report abuse or neglect when the disclosing organization is a healthcare provider. CC ID 06819 Data and Information Management Preventive
    Document how Individually Identifiable Health Information is used and disclosed when authorization has been granted. CC ID 00216 Establish/Maintain Documentation Preventive
    Define and implement valid authorization control requirements. CC ID 06258 Establish/Maintain Documentation Preventive
    Obtain explicit consent for authorization to release Individually Identifiable Health Information. CC ID 00217 Data and Information Management Preventive
    Obtain explicit consent for authorization to release psychotherapy notes. CC ID 00218 Data and Information Management Preventive
    Refrain from using Individually Identifiable Health Information to determine eligibility or continued eligibility for credit. CC ID 00219 Data and Information Management Preventive
    Process personal data after the data subject has granted explicit consent. CC ID 00180 Data and Information Management Preventive
    Process personal data in order to perform a legal obligation or exercise a legal right. CC ID 00182 Data and Information Management Preventive
    Process personal data relating to criminal offenses when required by law. CC ID 00237 Data and Information Management Preventive
    Process personal data in order to prevent personal injury or damage to the data subject's health. CC ID 00183 Data and Information Management Preventive
    Process personal data in order to prevent personal injury or damage to a third party's health. CC ID 00184 Data and Information Management Preventive
    Process personal data for statistical purposes or scientific purposes. CC ID 00256 Data and Information Management Preventive
    Process personal data during legitimate activities with safeguards for the data subject's legal rights. CC ID 00185 Data and Information Management Preventive
    Process traffic data in a controlled manner. CC ID 00130 Data and Information Management Preventive
    Process personal data for health insurance, social insurance, state social benefits, social welfare, or child protection. CC ID 00186 Data and Information Management Preventive
    Process personal data when it is publicly accessible. CC ID 00187 Data and Information Management Preventive
    Process personal data for direct marketing and other personalized mail programs. CC ID 00188 Data and Information Management Preventive
    Refrain from processing personal data for marketing or advertising to children. CC ID 14010 Business Processes Preventive
    Refrain from disseminating and communicating with individuals that have opted out of direct marketing communications. CC ID 13708 Communicate Corrective
    Process personal data for the purposes of employment. CC ID 16527 Data and Information Management Preventive
    Process personal data for justice administration, lawsuits, judicial decisions, and investigations. CC ID 00189 Data and Information Management Preventive
    Process personal data for debt collection or benefit payments. CC ID 00190 Data and Information Management Preventive
    Process personal data in order to advance the public interest. CC ID 00191 Data and Information Management Preventive
    Process personal data for surveys, archives, or scientific research. CC ID 00192 Data and Information Management Preventive
    Process personal data absent consent for journalistic purposes, artistic purposes, or literary purposes. CC ID 00193 Data and Information Management Preventive
    Process personal data for academic purposes or religious purposes. CC ID 00194 Data and Information Management Preventive
    Process personal data when it is used by a public authority for National Security policy or criminal policy. CC ID 00195 Data and Information Management Preventive
    Refrain from storing data in newly created files or registers which directly or indirectly reveals the restricted data. CC ID 00196 Data and Information Management Preventive
    Follow legal obligations while processing personal data. CC ID 04794 Data and Information Management Preventive
    Start personal data processing only after the needed notifications are submitted. CC ID 04791 Data and Information Management Preventive
    Establish, implement, and maintain restricted data retention procedures. CC ID 00167
    [PIV background investigation, identity proofing, registration, and issuance processes MAY be performed across multiple sessions at different facilities. If multiple sessions are needed, the applicant SHALL be linked through a positive biometric verification decision obtained from an automated comparison of biometric characteristics captured at a previous session to biometric characteristics captured during the current session. Issuers SHALL follow applicable federal laws and regulations regarding the retention and destruction of biometric data. 2.5 ¶ 6]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain personal data disposition procedures. CC ID 13498
    [PIV background investigation, identity proofing, registration, and issuance processes MAY be performed across multiple sessions at different facilities. If multiple sessions are needed, the applicant SHALL be linked through a positive biometric verification decision obtained from an automated comparison of biometric characteristics captured at a previous session to biometric characteristics captured during the current session. Issuers SHALL follow applicable federal laws and regulations regarding the retention and destruction of biometric data. 2.5 ¶ 6
    {privacy policy} The PII collected from the cardholder SHALL be disposed of in accordance with the stated privacy and data retention policies of the department or agency. 2.9.4 ¶ 5]
    Establish/Maintain Documentation Preventive
    Capture personal data removal requests. CC ID 13507 Communicate Preventive
    Remove personal data from records after receiving a personal data removal request. CC ID 11972 Records Management Preventive
    Refrain from erasing personal data upon receiving a personal data removal request when it is necessary for maintaining information assets. CC ID 13789 Process or Activity Preventive
    Refrain from erasing personal data upon receiving a personal data removal request when it is necessary to complete a payment transaction. CC ID 13788 Process or Activity Preventive
    Establish, implement, and maintain a personal data collection program. CC ID 06487 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain personal data collection limitation boundaries. CC ID 00507 Establish/Maintain Documentation Preventive
    Manage Personal Identification Numbers and PIN verification code numbers. CC ID 00058
    [The remote PIN reset operation SHALL satisfy the requirements for remote, postissuance updates specified in Section 2.9.2. The remote PIN reset operation SHALL satisfy the requirements for remote, postissuance updates specified in Section 2.9.2. 2.9.3.1 ¶ 10
    Remote PIN reset on a general computing platform (e.g., desktop, laptop) SHALL only be performed if all the following requirements are met: The cardholder initiates a ;" class="term_primary-noun">PIN reset with the issuer operator. 2.9.3.1 ¶ 9 Bullet 1
    Remote PIN reset on a general computing platform (e.g., desktop, laptop) SHALL only be performed if all the following requirements are met: The operator authenticates the owner of the round-color:#F0BBBC;" class="term_primary-noun">PIV Card through an background-color:#F0BBBC;" class="term_primary-noun">independent procedure, for example by authenticating the cardholder with an associated derived PIV credential or by confirming reset via email to the on-record government-issued email address. 2.9.3.1 ¶ 9 Bullet 2
    {appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is D8ED;" class="term_primary-verb">authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT reset the PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5
    {appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT reset the PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5]
    Data and Information Management Preventive
    Employ a random number generator to create authenticators. CC ID 13782 Technical Security Preventive
    Collect Personal Identification Numbers with the individual's consent. CC ID 00059 Data and Information Management Preventive
    Collect Personal Identification Numbers absent consent when the law mandates. CC ID 00061 Data and Information Management Preventive
    Collect Personal Identification Numbers absent consent for research purposes. CC ID 00065 Data and Information Management Preventive
    Collect Personal Identification Numbers absent consent to realize the rights or duties of the data subject or data controller. CC ID 04792 Data and Information Management Preventive
    Refrain from requiring a Personal Identification Number to purchase goods or services. CC ID 00069 Behavior Preventive
    Establish, implement, and maintain a data handling program. CC ID 13427 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain data handling policies. CC ID 00353 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain data and information confidentiality policies. CC ID 00361 Establish/Maintain Documentation Preventive
    Implement security measures to protect personal data. CC ID 13606
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Utilize security controls described in [SP 800-53] to accomplish privacy goals, where applicable. 2.11 ¶ 3 Bullet 10
    To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that the technologies used to implement PIV sustain and do not erode privacy protections relating to the use, collection, and disclosure of PII. Agencies MAY choose to deploy PIV Cards with electromagnetically opaque holders or other technology to protect against any unauthorized contactless access to information stored on a PIV Card. 2.11 ¶ 3 Bullet 11]
    Technical Security Preventive
    Establish, implement, and maintain a privacy impact assessment. CC ID 13712
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Conduct a comprehensive Privacy Impact Assessment (PIA) and a periodic review and update of the assessment on systems containing PII for the purpose of implementing PIV consistent with the methodology of [E-Gov] and the requirements of [M-03-22]. Consult with appropriate personnel responsible for privacy issues at the department or agency (e.g., Chief Information Officer) implementing the PIV system. 2.11 ¶ 3 Bullet 2
    To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Conduct a comprehensive Privacy Impact Assessment (PIA) and a periodic review and update of the assessment on systems containing PII for the purpose of implementing PIV consistent with the methodology of [E-Gov] and the requirements of [M-03-22]. Consult with appropriate personnel responsible for privacy issues at the department or agency (e.g., Chief Information Officer) implementing the PIV system. 2.11 ¶ 3 Bullet 2]
    Establish/Maintain Documentation Preventive
    Include the individuals with whom information is shared in the privacy impact assessment. CC ID 15520 Establish/Maintain Documentation Preventive
    Include how to grant consent in the privacy impact assessment. CC ID 15519 Establish/Maintain Documentation Preventive
    Include the opportunities for individuals to consent to using their information in the privacy impact assessment. CC ID 15518 Establish/Maintain Documentation Preventive
    Include the opportunities for opting out of information collection in the privacy impact assessment. CC ID 15517 Establish/Maintain Documentation Preventive
    Include data handling procedures in the privacy impact assessment. CC ID 15516 Establish/Maintain Documentation Preventive
    Include the intended use of information in the privacy impact assessment. CC ID 15515 Establish/Maintain Documentation Preventive
    Include the reason information is being collected in the privacy impact assessment. CC ID 15514 Establish/Maintain Documentation Preventive
    Include the type of information to be collected in the privacy impact assessment. CC ID 15513 Business Processes Preventive
    Disseminate and communicate the results of the Privacy Impact Assessment to interested personnel and affected parties. CC ID 15458 Communicate Preventive
    Develop remedies and sanctions for privacy policy violations. CC ID 00474
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Coordinate with appropriate department or agency officials to define consequences for violating privacy policies of the PIV system. 2.11 ¶ 3 Bullet 8]
    Data and Information Management Preventive
    Define the behaviors and actions that are included in privacy rights violations. CC ID 14852 Behavior Preventive
    Implement procedures to file privacy rights violation complaints. CC ID 00476 Data and Information Management Corrective
    File privacy rights violation complaints in writing. CC ID 00477 Establish/Maintain Documentation Corrective
    Include the acts or omissions that are in violation of privacy rights in the privacy rights violation complaint. CC ID 14360 Establish/Maintain Documentation Corrective
    Include the individual's name who is the subject of the complaint in the privacy rights violation complaint. CC ID 14359 Establish/Maintain Documentation Preventive
    Provide assistance to data subjects for filing privacy rights violation complaints. CC ID 00478 Behavior Corrective
    Refrain from charging a fee to file a privacy rights violation complaint. CC ID 16807 Business Processes Preventive
    File privacy rights violation complaints inside the mandate stipulated from the refusal. CC ID 00479 Behavior Corrective
    Change or destroy any personal data that is incorrect. CC ID 00462 Data and Information Management Corrective
    Notify the data subject of changes made to personal data as the result of a dispute. CC ID 00463 Behavior Corrective
    Refrain from updating personal data on a regular basis, unless it is necessary for the purposes it was collected. CC ID 13610 Data and Information Management Preventive
    Escalate the appeal process to change personal data when the data controller fails to make changes to the disputed data. CC ID 00465 Data and Information Management Corrective
    Establish, implement, and maintain a privacy dispute resolution program. CC ID 12526 Establish/Maintain Documentation Preventive
    Include potential remedies in the privacy dispute resolution program. CC ID 12531 Establish/Maintain Documentation Preventive
    Provide the data subject with the name, title, and address to whom complaints are forwarded. CC ID 00395 Establish/Maintain Documentation Preventive
    Include the time frames in which privacy rights violation complaints are processed in the privacy dispute resolution program. CC ID 12529 Establish/Maintain Documentation Preventive
    Document unresolved challenges. CC ID 13568 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain an accuracy resolution policy. CC ID 00460 Establish/Maintain Documentation Preventive
    Notify individuals of their right to challenge personal data. CC ID 00457 Data and Information Management Preventive
    Notify individuals of their right to object to personal data for legitimate reasons. CC ID 00458 Data and Information Management Preventive
    Terminate an individual's restriction agreement under specific circumstances. CC ID 06260 Configuration Preventive
    Notify individuals of their ability to challenge personal behavioral assessments on record. CC ID 04798 Human Resources Management Preventive
    Notify individuals of their ability to object to personal data processing, absent cost. CC ID 00459 Data and Information Management Preventive
    Investigate the disputed accuracy of personal data. CC ID 00461 Data and Information Management Preventive
    Notify the data subject of which and why disputed changes were not made to personal data. CC ID 00466 Behavior Corrective
    Notify entities to whom personal data was transferred that the personal data is wrong, along with the corrections. CC ID 00467 Behavior Corrective
    Notify third parties of unresolved challenges. CC ID 13559 Communicate Preventive
    Document disagreements as to whether personal data is complete and accurate. CC ID 06952 Establish/Maintain Documentation Preventive
    Include the change to the personal data that the data subject requested and the reason the organization refused to make the change in the statement of disagreement. CC ID 06954 Establish/Maintain Documentation Preventive
    Order the cessation of data processing when a violation of the privacy policy is detected. CC ID 00475 Data and Information Management Corrective
    Investigate privacy rights violation complaints. CC ID 00480 Behavior Detective
    Cooperate with authorities during a privacy rights violation complaint investigation. CC ID 14364 Business Processes Corrective
    Notify respondents after a privacy rights violation complaint investigation begins. CC ID 00491 Behavior Detective
    Include the allegations against the organization in the notice of investigation. CC ID 13031 Establish/Maintain Documentation Preventive
    Investigate privacy rights violation complaints in private. CC ID 00492 Behavior Detective
    Make appropriate inquiries and obtain appropriate information regarding privacy rights violation complaints. CC ID 00493 Behavior Detective
    Allow the complainant to appear before the commissioner and make a submission, orally or in writing, about the privacy rights violation complaint investigation prior to an adverse decision to the complainant is reached. CC ID 00494 Behavior Detective
    Refer privacy rights violation complaints to the Privacy Commissioner under certain conditions. CC ID 00481 Behavior Preventive
    Determine not to investigate privacy rights violation complaints under certain conditions. CC ID 00482 Behavior Preventive
    Refrain from investigating a privacy rights violation complaint when the act or practice does not interfere with an individual's privacy. CC ID 00483 Behavior Preventive
    Refrain from investigating a privacy rights violation complaint when the complaint is created outside the stipulated time frame after the complainant became aware of it. CC ID 00484 Behavior Preventive
    Refrain from investigating a privacy rights violation complaint when the complaint is frivolous, vexatious, misconceived, or lacking in substance. CC ID 00485 Behavior Preventive
    Refrain from investigating a privacy rights violation complaint if the act or practice is subject to an application under another commonwealth law, state law, or territory law, and the complaint was or is being dealt with adequately under the law. CC ID 00486 Behavior Preventive
    Defer privacy rights violation complaint investigations under certain conditions. CC ID 00487 Behavior Preventive
    Defer privacy rights violation complaint investigations when the respondent has made an application for a determination. CC ID 00488 Behavior Preventive
    Defer privacy rights violation complaint investigations when the Privacy Commissioner believes the data subject's interests would not be affected if the investigation or further investigation were deferred until the application was disposed of. CC ID 00489 Behavior Preventive
    Notify respondents after a privacy rights violation complaint investigation has been resolved. CC ID 13513 Communicate Corrective
    Create an investigative report in regards to a privacy rights violation complaint. CC ID 00495 Establish/Maintain Documentation Corrective
    Respond to an investigative report in regards to a privacy rights violation complaint. CC ID 00496 Behavior Corrective
    Define the available administrative remedies in regards to a privacy rights violation complaint. CC ID 00497 Establish/Maintain Documentation Detective
    Order the organization to change to be in compliance with applicable law. CC ID 00499 Behavior Corrective
    Order the organization to publish a notice with the corrections or actions taken. CC ID 00500 Behavior Corrective
    Award damages based on applicable law. CC ID 00501 Behavior Corrective
    Destroy personal data that breaches privacy after the privacy breach has been detected. CC ID 00503 Data and Information Management Corrective
    Define the organization's liability based on the applicable law. CC ID 00504 Establish/Maintain Documentation Preventive
    Define the sanctions and fines available for privacy rights violations based on applicable law. CC ID 00505 Establish/Maintain Documentation Preventive
    Define the appeal process based on the applicable law. CC ID 00506 Establish/Maintain Documentation Preventive
    Define the fee structure for the appeal process. CC ID 16532 Process or Activity Preventive
    Define the time requirements for the appeal process. CC ID 16531 Process or Activity Preventive
    Disseminate and communicate instructions for the appeal process to interested personnel and affected parties. CC ID 16544 Communicate Preventive
    Disseminate and communicate a written explanation of the reasons for appeal decisions to interested personnel and affected parties. CC ID 16542 Communicate Preventive
    Provide notice of proposed penalties. CC ID 06216 Establish/Maintain Documentation Preventive
    Notify the public and other agencies after a penalty becomes final. CC ID 06217 Behavior Preventive
    Refrain from subjecting individuals to retaliation or intimidation after a complaint is created. CC ID 06218 Testing Detective
    Establish, implement, and maintain a Customer Information Management program. CC ID 00084 Data and Information Management Preventive
    Establish, implement, and maintain customer data authentication procedures. CC ID 13187 Establish/Maintain Documentation Preventive
    Check the data accuracy of new accounts. CC ID 04859 Data and Information Management Preventive
    Compare the photograph on the customer's identification card or badge with the customer's physical appearance. CC ID 04861
    [{appear in person}{not be successful}{not be available} When OCC reset is performed in person at the issuing facility, before the reset, the issuer SHALL perform a biometric verification of the cardholder to the biometric data records in the PIV enrollment record. If the biometric verification decision is negative or no alternative biometric data records are available, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 4
    Remote PIN reset on a general computing platform (e.g., desktop, laptop) SHALL only be performed if all the following requirements are met: The cardholder’s biometric characteristics elicit a "background-color:#F0BBBC;" class="term_primary-noun">positive biometric verification decision> when compared to the stored biometric data records on the PIV Card through the OCC-AUTH authentication mechanism. 2.9.3.1 ¶ 9 Bullet 3
    {applicable requirements}{remote proofing procedure}{not acquire} PIN reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCCAUTH authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and D0E5;" class="term_secondary-verb">#B7D8ED;" cl
    ass="term_primary-verb">comparespan> the _pristyle="background-color:#CBD0E5;" class="term_secondary-verb">mary-noun">video feed of the cardholder with the style="background-color:#F0BBBC;" class="term_primary-noun">electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.1 ¶ 7]
    Testing Detective
  • Records management
    5
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Records management CC ID 00902 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain records management policies. CC ID 00903 Establish/Maintain Documentation Preventive
    Define each system's preservation requirements for records and logs. CC ID 00904 Establish/Maintain Documentation Detective
    Establish, implement, and maintain a data retention program. CC ID 00906 Establish/Maintain Documentation Detective
    Maintain continued integrity for all stored data and stored records. CC ID 00969
    [{data in transit}{data at rest} PIV enrollment records contain Personally Identifiable Information (PII). PII SHALL be protected in a manner that protects the individual’s privacy and maintains the integrity of the records both in transit and at rest. 2.6 ¶ 5]
    Testing Detective
  • System hardening through configuration management
    73
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    System hardening through configuration management CC ID 00860 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain system hardening procedures. CC ID 12001 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain authenticators. CC ID 15305 Technical Security Preventive
    Establish, implement, and maintain an authenticator standard. CC ID 01702
    [{be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2]
    Establish/Maintain Documentation Preventive
    Disallow personal data in authenticators. CC ID 13864 Technical Security Preventive
    Establish, implement, and maintain an authenticator management system. CC ID 12031 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain a repository of authenticators. CC ID 16372 Data and Information Management Preventive
    Establish, implement, and maintain authenticator procedures. CC ID 12002 Establish/Maintain Documentation Preventive
    Restrict access to authentication files to authorized personnel, as necessary. CC ID 12127 Technical Security Preventive
    Configure authenticators to comply with organizational standards. CC ID 06412 Configuration Preventive
    Configure the system to require new users to change their authenticator on first use. CC ID 05268 Configuration Preventive
    Configure authenticators so that group authenticators or shared authenticators are prohibited. CC ID 00519 Configuration Preventive
    Change the authenticator for shared accounts when the group membership changes. CC ID 14249 Business Processes Corrective
    Configure the system to prevent unencrypted authenticator use. CC ID 04457 Configuration Preventive
    Disable store passwords using reversible encryption. CC ID 01708 Configuration Preventive
    Configure the system to encrypt authenticators. CC ID 06735 Configuration Preventive
    Configure the system to mask authenticators. CC ID 02037 Configuration Preventive
    Configure the authenticator policy to ban the use of usernames or user identifiers in authenticators. CC ID 05992 Configuration Preventive
    Configure the "minimum number of digits required for new passwords" setting to organizational standards. CC ID 08717 Establish/Maintain Documentation Preventive
    Configure the "minimum number of upper case characters required for new passwords" setting to organizational standards. CC ID 08718 Establish/Maintain Documentation Preventive
    Configure the system to refrain from specifying the type of information used as password hints. CC ID 13783 Configuration Preventive
    Configure the "minimum number of lower case characters required for new passwords" setting to organizational standards. CC ID 08719 Establish/Maintain Documentation Preventive
    Disable machine account password changes. CC ID 01737 Configuration Preventive
    Configure the "minimum number of special characters required for new passwords" setting to organizational standards. CC ID 08720 Establish/Maintain Documentation Preventive
    Configure the "require new passwords to differ from old ones by the appropriate minimum number of characters" setting to organizational standards. CC ID 08722 Establish/Maintain Documentation Preventive
    Configure the "password reuse" setting to organizational standards. CC ID 08724 Establish/Maintain Documentation Preventive
    Configure the "Disable Remember Password" setting. CC ID 05270 Configuration Preventive
    Configure the "Minimum password age" to organizational standards. CC ID 01703 Configuration Preventive
    Configure the LILO/GRUB password. CC ID 01576 Configuration Preventive
    Configure the system to use Apple's Keychain Access to store passwords and certificates. CC ID 04481 Configuration Preventive
    Change the default password to Apple's Keychain. CC ID 04482 Configuration Preventive
    Configure Apple's Keychain items to ask for the Keychain password. CC ID 04483 Configuration Preventive
    Configure the Syskey Encryption Key and associated password. CC ID 05978 Configuration Preventive
    Configure the "Accounts: Limit local account use of blank passwords to console logon only" setting. CC ID 04505 Configuration Preventive
    Configure the "System cryptography: Force strong key protection for user keys stored in the computer" setting. CC ID 04534 Configuration Preventive
    Configure interactive logon for accounts that do not have assigned authenticators in accordance with organizational standards. CC ID 05267 Configuration Preventive
    Enable or disable remote connections from accounts with empty authenticators, as appropriate. CC ID 05269 Configuration Preventive
    Configure the "Send LanMan compatible password" setting. CC ID 05271 Configuration Preventive
    Configure the authenticator policy to ban or allow authenticators as words found in dictionaries, as appropriate. CC ID 05993 Configuration Preventive
    Set the most number of characters required for the BitLocker Startup PIN correctly. CC ID 06054 Configuration Preventive
    Set the default folder for BitLocker recovery passwords correctly. CC ID 06055 Configuration Preventive
    Notify affected parties to keep authenticators confidential. CC ID 06787 Behavior Preventive
    Discourage affected parties from recording authenticators. CC ID 06788 Behavior Preventive
    Ensure the root account is the first entry in password files. CC ID 16323 Data and Information Management Detective
    Configure the "shadow password for all accounts in /etc/passwd" setting to organizational standards. CC ID 08721 Establish/Maintain Documentation Preventive
    Configure the "password hashing algorithm" setting to organizational standards. CC ID 08723 Establish/Maintain Documentation Preventive
    Configure the "Disable password strength validation for Peer Grouping" setting to organizational standards. CC ID 10866 Configuration Preventive
    Configure the "Set the interval between synchronization retries for Password Synchronization" setting to organizational standards. CC ID 11185 Configuration Preventive
    Configure the "Set the number of synchronization retries for servers running Password Synchronization" setting to organizational standards. CC ID 11187 Configuration Preventive
    Configure the "Turn off password security in Input Panel" setting to organizational standards. CC ID 11296 Configuration Preventive
    Configure the "Turn on the Windows to NIS password synchronization for users that have been migrated to Active Directory" setting to organizational standards. CC ID 11355 Configuration Preventive
    Configure the authenticator display screen to organizational standards. CC ID 13794 Configuration Preventive
    Configure the authenticator field to disallow memorized secrets found in the memorized secret list. CC ID 13808 Configuration Preventive
    Configure the authenticator display screen to display the memorized secret as an option. CC ID 13806 Configuration Preventive
    Disseminate and communicate with the end user when a memorized secret entered into an authenticator field matches one found in the memorized secret list. CC ID 13807 Communicate Preventive
    Configure the look-up secret authenticator to dispose of memorized secrets after their use. CC ID 13817 Configuration Corrective
    Configure the memorized secret verifiers to refrain from allowing anonymous users to access memorized secret hints. CC ID 13823 Configuration Preventive
    Configure the system to allow paste functionality for the authenticator field. CC ID 13819 Configuration Preventive
    Configure the system to require successful authentication before an authenticator for a user account is changed. CC ID 13821 Configuration Preventive
    Implement safeguards to protect authenticators from unauthorized access. CC ID 15310
    [{applicable requirements}{remote proofing procedure}{not acquire} PIN reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCCAUTH authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.1 ¶ 7]
    Technical Security Preventive
    Configure Microsoft Office to Organizational Standards. CC ID 07147 Configuration Preventive
    Configure Microsoft Outlook settings for Microsoft Office in accordance with organizational standards. CC ID 07341 Configuration Preventive
    Configure the "Retrieving CRLs (Certificate Revocation Lists)" to organizational standards. CC ID 07417
    [PIV authentication, card authentication, digital signature, and key management certificates SHALL contain the crlDistributionPoints extension needed to locate CRLs, and 5.5 ¶ 2 Bullet 1]
    Configuration Preventive
    Configure Logging settings in accordance with organizational standards. CC ID 07611 Configuration Preventive
    Configure all logs to capture auditable events or actionable events. CC ID 06332 Configuration Preventive
    Configure the log to capture configuration changes. CC ID 06881 Configuration Preventive
    Configure the log to capture all changes to certificates. CC ID 05595
    [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. 5.5.2 ¶ 1]
    Configuration Preventive
    Configure Key, Certificate, Password, Authentication and Identity Management settings in accordance with organizational standards. CC ID 07621 Configuration Preventive
    Configure "client certificate authentication" to organizational standards. CC ID 14608
    [The relying system validates the PIV authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.1 ¶ 1 Bullet 2]
    Configuration Preventive
    Configure the "Password must meet complexity requirements" to organizational standards. CC ID 07743
    [{be unguessable}{not be identifiable}{be unique} The cardholder SHALL be guided in selecting a strong PIN value. The PIN SHALL be a minimum of six digits in length and SHOULD NOT be easily guessable, individually identifiable (e.g., part of a Social Security Number or phone number), or commonly used (e.g., 000000, 123456). 4.3.1 ¶ 2
    {be unguessable}{not be identifiable}{be unique} The cardholder SHALL be guided in selecting a strong PIN value. The PIN SHALL be a minimum of six digits in length and SHOULD NOT be easily guessable, individually identifiable (e.g., part of a Social Security Number or phone number), or commonly used (e.g., 000000, 123456). 4.3.1 ¶ 2]
    Configuration Preventive
    Configure the "Check for server certificate revocation" to organizational standards. CC ID 08120
    [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. 5.5.2 ¶ 1]
    Configuration Preventive
    Configure the "Allow the use of biometrics" to organizational standards. CC ID 08435
    [{refrain from exceeding} Previously collected biometric data MAY be reused with the new PIV Card if the expiration date of the new PIV Card is no later than 12 years after the date that the biometric data was obtained. As biometric system error rates generally increase with the time elapsed since initial collection (reference aging, [ISO 2382-37]), issuers MAY refresh biometric data in the PIV enrollment record during the re-issuance process. Even if the same biometric data is reused with the new PIV Card, the digital signature must be recomputed with the new FASC-N and card UUID. 2.9.1 ¶ 7]
    Configuration Preventive
    Configure the "Number of attempts allowed" to organizational standards. CC ID 08569
    [{maximum number of attempts} The PIN on a PIV Card may need to be reset if the cardholder has forgotten the PIN or if PIN-based cardholder authentication has been disabled by the usage of an invalid PIN more than the allowed number of retries. Fingers might need to be re-enrolled for OCC if the cardholder has experienced epidermal scarring or similar physical changes, resulting in false negative biometric verification decisions, or if OCC has been disabled by exceeding the allowed number of negative biometric verification decisions. No more than 10 consecutive activation retries for each of the activation methods (i.e., PIN and OCC attempts) SHALL be permitted. Card issuers MAY further restrict the maximum retry limit to a lower value. 2.9.3 ¶ 2
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1]
    Configuration Preventive
  • Systems design, build, and implementation
    12
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Systems design, build, and implementation CC ID 00989 IT Impact Zone IT Impact Zone
    Initiate the System Development Life Cycle development phase or System Development Life Cycle build phase. CC ID 06267 Systems Design, Build, and Implementation Preventive
    Develop systems in accordance with the system design specifications and system design standards. CC ID 01094 Systems Design, Build, and Implementation Preventive
    Develop new products based on best practices. CC ID 01095 Systems Design, Build, and Implementation Preventive
    Establish, implement, and maintain a system design specification. CC ID 04557 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain identification card or badge architectural designs. CC ID 06591
    [{applicable requirements} The PIV Card SHALL be maintained using processes that comply with this section. 2.9 ¶ 1
    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 Card Design Standard classifies security features into three categories, depending on the inspection level required for verification: 4.1.2 ¶ 1
    As noted in Section 4.1.3, the PIV Card SHALL contain a contact and a contactless ICC interface. This Standard does not specify the number of chips used to support the mandated contact and contactless interfaces. 4.1.4 ¶ 2
    The PIV Card SHALL contain a contact and a contactless ICC interface. 4.1.3 ¶ 2
    To achieve a common PIV Card appearance and provide departments and agencies with the flexibility to augment the card with department-or agency-specific requirements, the card SHALL contain printed information and machine-readable technologies. Mandated and optional items SHALL be placed as described and depicted. Printed data SHALL NOT interfere with machine-readable technology. 4.1.4 ¶ 3
    {PIV Card} Areas that are marked as reserved SHOULD NOT be used for printing. The reason for the recommended reserved areas is that placement of the embedded contactless ICC module may vary between manufacturers, and there are constraints that prohibit printing over the embedded contactless module. The PIV Card topography provides flexibility for placement of the embedded module, either in the upper right corner or in the lower portion. Printing restrictions apply only to the area where the embedded module is located. 4.1.4 ¶ 4
    {contact interface}{not require} The CHUID SHALL be accessible from both the contact and contactless interfaces of the PIV Card without card activation. 4.2.1 ¶ 4
    {PIV Card} 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 SHALL follow recommendations set forth in [SP 800-76]. 4.1.4.1 ¶ 2
    {PIV Card}{anti-counterfeiting technique} All security features SHOULD maintainspan> their function for the life of the card. As a generally accepted security procedure, federal departments and agencies SHOULD periodically review the viability, effectiveness, and currency of employed tamper resistance and anti-counterfeiting methods. 4.1.2 ¶ 10
    {pre-determined and authorized location} If used, the department or agency SHALL place the cardholder signature below the photograph and cardholder name, as depicted in Figure 4-3. The space for the signature SHALL NOT interfere with the placement of the ICCs and related components. Because of card surface space constraints, placement of a signature may limit the size of the optional two-dimensional bar code. 4.1.4.3 ¶ 3
    {issuing organization}{pre-determined and authorized location}{be visible} The Agency seal in Zone 11F may become a mandatory field in the next revision of the Standard. If used, the seal selected by the issuing department, agency, or organization SHALL be printed in the area depicted. It SHALL be printed using the n">guidelines provided in Figure 4-2 to ensure that information printed on the seal ss="term_secondary-verb">is legible and clearly visible. 4.1.4.3 ¶ 13
    If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process s="term_secondary-verb">are not adversely impacted. If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 29]
    Process or Activity Preventive
    Define the physical requirements for identification cards or badges in the identification card or badge architectural designs. CC ID 06592
    [{PIV Card} Decals SHALL NOT be adhered to the card. 4.1.3 ¶ 9
    {applicable requirements} The PIV Card SHALL comply with the physical characteristics described in [ISO 7810], [ISO 10373], and [ISO 7816] for contact cards in addition to [ISO 14443] for contactless cards. 4.1 ¶ 3
    The PIV Card SHALL NOT be embossed other than for security and accessibility features. 4.1.3 ¶ 8
    {PIV Card}{thickness}{applicable requirements} The card SHALL be 27 mil to 33 mil (0.68 mm to 0.84 mm) thick before lamination, in accordance with [ISO 7810]. 4.1.3 ¶ 7
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not alter or interfere with printed information, including the photograph; or 4.1.3 ¶ 10 Bullet 3
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not invalidate card manufacturer warranties or other product claims; 4.1.3 ¶ 10 Bullet 2
    {machine readable format} Incorporation of security features SHALL not impede access to machine-readable information. 4.1.2 ¶ 9 Bullet 4
    {PIV Card} The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security features, as described in Section 4.1.2, may modify the perceived color slightly. The presence of security features SHALL NOT prevent the recognition of white as the principal card body color by a person with normal vision (corrected or uncorrected) at a working distance of 50 cm to 200 cm. 4.1.3 ¶ 3
    {PIV Card} The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security features, as described in Section 4.1.2, may modify the perceived color slightly. The presence of security features SHALL NOT prevent the recognition of white as the principal card body color by a person with normal vision (corrected or uncorrected) at a working distance of 50 cm to 200 cm. 4.1.3 ¶ 3
    {PIV Card} The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security features, as described in Section 4.1.2, may modify the perceived color slightly. The presence of security features SHALL NOT prevent the recognition of white as the principal card body color by a person with normal vision (corrected or uncorrected) at a working distance of 50 cm to 200 cm. 4.1.3 ¶ 3
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not 4.1.3 ¶ 10
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not compromise card body durability requirements and characteristics; 4.1.3 ¶ 10 Bullet 1
    {PIV Card}{refrain from interfering} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not damage or interfere with machine-readable technology, such as the embedded antenna. 4.1.3 ¶ 10 Bullet 4
    {PIV Card} The card material SHALL withstand the effects of temperatures required by the application of a polyester laminate on one or both sides of the card by commercial off-the-shelf (COTS) equipment. The thickness added due to a laminate layer SHALL NOT interfere with the smart card reader operation. The card material SHALL allow production of a flat card in accordance with [ISO 7810] after lamination of one or both sides of the card. 4.1.3 ¶ 11
    {PIV Card} The card material SHALL withstand the effects of temperatures required by the application of a polyester laminate on one or both sides of the card by commercial off-the-shelf (COTS) equipment. The thickness added due to a laminate layer SHALL NOT interfere with the smart card reader operation. The card material SHALL allow production of a flat card in accordance with [ISO 7810] after lamination of one or both sides of the card. 4.1.3 ¶ 11
    {PIV Card} The card material SHALL withstand the effects of temperatures required by the application of a polyester laminate on one or both sides of the card by commercial off-the-shelf (COTS) equipment. The thickness added due to a laminate layer SHALL NOT interfere with the smart card reader operation. The card material SHALL allow production of a flat card in accordance with [ISO 7810] after lamination of one or both sides of the card. 4.1.3 ¶ 11
    To achieve a common PIV Card appearance and provide departments and agencies with the flexibility to augment the card with department-or agency-specific requirements, the card SHALL contain printed information and machine-readable technologies. Mandated and optional items SHALL be placed as described and depicted. Printed data SHALL NOT interfere with machine-readable technology. 4.1.4 ¶ 3
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    {PIV Card} 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 pan style="background-color:#F0BBBC;" class="term_primary-noun">background SHALL follow recommendations set forth in [SP 800-76]. 4.1.4.1 ¶ 2
    {PIV Card} 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 minimumspan> of 300 dots per inch (DPI) resolution SHALL be used. The background SHALL follow recommendations set forth in [SP 800-76]. 4.1.4.1 ¶ 2
    Incorporation of security features SHALL be free of defects, such as fading and discoloration; 4.1.2 ¶ 9 Bullet 2
    Incorporation of security features SHALL be in accordance with durability requirements; 4.1.2 ¶ 9 Bullet 1
    The electronic contact interface for the card as defined by [ISO 7816]. Printed items SHALL NOT cover the contact surface. The total size of the contact surface can vary between manufacturers. The area shown in Figure 4-1 roughly represents the minimal possible size. The electronic contact interface for the card as defined by [ISO 7816]. Printed items SHALL NOT cover the contact surface. The total size of the contact surface can vary between manufacturers. The area shown in Figure 4-1 roughly represents the minimal possible size. 4.1.4.1 ¶ 7
    {refrain from using} Foreign national color-coding has precedence over government employee and contractor color-coding. These colors SHALL be reserved and SHALL NOT be employed for other purposes. These colors SHALL be printed in accordance with the color specifications provided in Section 4.1.5. Zone 15F MAY be a solid or patterned line at the department or agency’s discretion. 4.1.4.1 ¶ 16
    {refrain from using} Foreign national color-coding has precedence over government employee and contractor color-coding. These colors SHALL be reserved and SHALL NOT be employed for other purposes. These colors SHALL:#CBD0E5;" class="term_secondary-verb"> be n style="background-color:#B7D8ED;" class="term_primary-verb">printed
    in accordance with the color specifications provided in Section 4.1.5. Zone 15F MAY be a solid or patterned line at the department or agency’s discretion. 4.1.4.1 ¶ 16
    {PIV Card} Color-coding SHALL be used for additional identification of employee affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be n style="background-color:#B7D8ED;" class="term_primary-verb">usedn>: tyle="background-color:#F0BBBC;" class="term_primary-noun">green: contractor. 4.1.4.1 ¶ 15 Bullet 3
    Color-coding SHALL be used for additional identification of employee affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be usedn>: tyle="background-color:#F0BBBC;" class="term_primary-noun">white: government employee, or 4.1.4.1 ¶ 15 Bullet 2
    {PIV Card} Color-coding SHALL be used for additional identification of employee affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be n style="background-color:#B7D8ED;" class="term_primary-verb">usedn>: tyle="background-color:#F0BBBC;" class="term_primary-noun">blue: foreign national, 4.1.4.1 ¶ 15 Bullet 1
    If used, this area SHALL incorporate edge ridging or a notched corner to indicate card -noun">orientation
    , as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. If used, this area SHALL incorporate edge ridging or a notched corner to indicate card orientation, as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 27
    If used, this area SHALL incorporate edge ridging or a notched corner to indicate card orientation, as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and class="term_primary-noun">manufacturer
    to ensure that the card material integrity and printing process s="term_secondary-verb">are not adversely impacted
    . If used, this area SHALL incorporate edge ridging or a notched corner to indicate card orientation, as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 27
    {PIV Card}{reserved area}{machine-readable information} Departments and agencies MAY choose to provide additional information to identify emergency response officials or to better identify the cardholder’s authorized access. If used, this additional text SHALL be in the general area depicted in Figure 4-7 and <span style="background-color:#B7D8ED;" class="term_primary-verb">SHALL NOT interfere
    with other printed text or machine-readable components. An example of a printed statement is provided in Figure 4-7. 4.1.4.4 ¶ 8]
    Process or Activity Preventive
    Define the mandatory items that must appear on identification cards or badges in the identification card or badge architectural designs. CC ID 06593
    [To achieve a common PIV Card appearance and provide departments and agencies with the flexibility to augment the card with department-or agency-specific requirements, the card SHALL contain printed information and machine-readable technologies. Mandated and optional items SHALL be placed as described and depicted. Printed data SHALL NOT interfere with machine-readable technology. 4.1.4 ¶ 3
    {approved font} Unless otherwise specified, all data labels SHALL be printed in 5 pt Arial with the corresponding data in 6 pt Arial Bold. If the Arial font is not available, a visually similar font, such as Public Sans [PublicSans], MAY be substituted for all references to Arial within this Standard. If such a substitution is made, the substitution SHALL be consistently applied to all uses of the Arial font on the PIV Card. Unless otherwise specified, all text SHALL be printed in black. 4.1.4 ¶ 5
    {approved font} Unless otherwise specified, all data labels SHALL be printed in 5 pt Arial with the corresponding data in 6 pt Arial Bold. If the Arial font is not available, a visually similar font, such as Public Sans [PublicSans], MAY be substituted for all references to Arial within this Standard. If such a substitution is made, the substitution SHALL be consistently applied to all uses of the Arial font on the PIV Card. Unless otherwise specified, all text SHALL be printed in black. 4.1.4 ¶ 5
    {approved font} Unless otherwise specified, all data labels SHALL be printed in 5 pt Arial with the corresponding data in 6 pt Arial Bold. If the Arial font is not available, a visually similar font, such as Public Sans [PublicSans], MAY be substituted for all references to Arial within this Standard. If such a substitution is made, the substitution SHALL be consistently applied to all uses of the Arial font on the PIV Card. Unless otherwise specified, all text SHALL be printed in black. 4.1.4 ¶ 5
    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 other possible machine-readable technologies. Logically stored data elements are discussed in Section 4.2. 4.1.4 ¶ 1
    {applicable requirements} {biometric authentication} The electronic facial image SHALL be stored on the PIV Card as described in Section 4.2.3.1. It SHALL be printed on the PIV Card according to Section 4.1.4.1. The image MAY be used for cardholder authentication (BIO or BIO-A) as described in Section 6.2.1. It MAY be retrieved and displayed on guard workstations to augment other authentication processes from Section 6.2. The electronic facial image is an additional means of authentication during PIV issuance and maintenance processes when used with an automated facial comparison algorithm. 2.5 ¶ 5
    Incorporation of security features SHALL not obscure printed information; and 4.1.2 ¶ 9 Bullet 3
    {PIV Card} The organizational affiliation SHALL be -color:#B7D8ED;" class="term_primary-verb">printed as depicted in Figure 4-1. 4.1.4.1 ¶ 11
    {PIV Card} An employee affiliation SHALL be #B7D8ED;" class="term_primary-verb">printed on the card as depicted in Figure 4-1. Examples of employee affiliation include “Employee,” “Contractor,” “Active Duty,” and “Civilian.” 4.1.4.1 ¶ 9
    Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL olor:#CBD0E5;" class="term_secondary-verb">s="term_primary-verb">indicate> such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. 4.1.4.1 ¶ 5
    Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. 4.1.4.1 ¶ 5
    Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. 4.1.4.1 ¶ 5
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be ry-verb">printed
    . Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be style="background-color:#B7D8ED;" class="term_primary-verb">printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {appropriate format}{refrain from exceeding} The affiliation color codes “B” for blue, “W” for white, and “G” for green SHALL be printed in a white circle on the right side of Zone 15F, as depicted in Figure 4-1. The diameter of the circle SHALL NOT be more than 5 mm. The lettering SHALL correspond to the printed >color</span> in Zone 15F. 4.1.4.1 ¶ 18
    {appropriate format}{refrain from exceeding} The affiliation color codes “B” for blue, “W” for white, and “G” for green SHALL be olor:#B7D8ED;" class="term_primary-verb">printed in a white circle on the right side of Zone 15F, as depicted in Figure 4-1. The diameter of the circle SHALL NOT be more than 5 mm. The lettering SHALL correspond to the printed color in Zone 15F. 4.1.4.1 ¶ 18
    {appropriate format}{refrain from exceeding} The affiliation color codes “B” for blue, “W” for white, and “G” for green SHALL be printed in a white circle on the right side of Zone 15F, as depicted in Figure 4-1. The diameter of the tyle="background-color:#CBD0E5;" class="term_secondary-verb">ass="term_primary-noun">circle SHALL NOT be more than 5 mm. The lettering SHALL correspond to the printed color in Zone 15F. 4.1.4.1 ¶ 18
    {appropriate format}{approved font} The card expiration date SHALL be printed in a MMMYYYY format in the upper right-hand corner as depicted in Figure 4-1. The YYYY characters represent the fourdigit year and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 19F expiration date SHALL be printed in 12 pt Arial Bold. 4.1.4.1 ¶ 20
    {appropriate format}{approved font} The card expiration date SHALL be printed in a MMMYYYY format in the upper right-hand corner as depicted in Figure 4-1. The YYYY characters represent the fourdigit year and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 19F expiration date SHALL be printed in 12 pt Arial Bold. 4.1.4.1 ¶ 20
    {PIV Card}{issuing organization} 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 preferred placement is as depicted in Figure 4-6, but variable placement along the outer edge is allowed in accordance with other FIPS 201 requirements, as shown in Figure 4-8. 4.1.4.2 ¶ 2
    {pre-determined and authorized location} If used, the department or agency SHALL place the cardholder un">signature below the photograph and cardholder name, as depicted in Figure 4-3. The space for the signature SHALL NOT interfere with the placement of the ICCs and related components. Because of card surface space constraints, placement of a signature may limit the size of the optional two-dimensional bar code. 4.1.4.3 ¶ 3
    {PIV Card}{issuing organization} 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 preferred placement is as depicted in Figure 4-6, but variable placement along the outer edge is allowed in accordance with other FIPS 201 requirements, as shown in Figure 4-8. 4.1.4.2 ¶ 2
    {PIV Card} Color-coding SHALL be used for additional identification of employee pan style="background-color:#F0BBBC;" class="term_primary-noun">affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be used: 4.1.4.1 ¶ 15
    {PIV Card}{appropriate format}{approved font} The card expiration date SHALL be printed on the card as depicted in Figure 4-1. The card expiration date SHALL be in a YYYYMMMDD format. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 14F expiration date SHALL be printed in 6 pt to 9 pt Arial Bold. 4.1.4.1 ¶ 13
    {PIV Card}{appropriate format}{approved font} The card expiration date SHALL be printed on the card as depicted in Figure 4-1. The card expiration date SHALL be in a YYYYMMMDD format. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 14F expiration date SHALL be printed in 6 pt to 9 pt Arial Bold. 4.1.4.1 ¶ 13
    {PIV Card}{appropriate format}{approved font} The card expiration date SHALL be pan style="background-color:#B7D8ED;" class="term_primary-verb">printed on the card as depicted in Figure 4-1. The card expiration date SHALL be in a YYYYMMMDD format. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 14F expiration date SHALL be printed in 6 pt to 9 pt Arial Bold. 4.1.4.1 ¶ 13
    {PIV Card}{pre-determined and authorized location} If used, the cardholder’s rank SHALL be "term_primary-verb">printed in the area, as illustrated in Figure 4-2. Data format is at the department or agency’s discretion. 4.1.4.3 ¶ 7
    {issuing organization}{pre-determined and authorized location}{be visible} The Agency seal in Zone 11F may become a mandatory field in the next revision of the Standard. If used, the class="term_primary-noun">seal selected by the issuing department, agency, or organization SHALL be n style="background-color:#B7D8ED;" class="term_primary-verb">printed in the area depicted. It SHALL be printed using the guidelines provided in Figure 4-2 to ensure that information printed on the seal is legible and clearly visible. 4.1.4.3 ¶ 13
    {appropriate format} If the PIV Card is used to identify a federal emergency response official, a department or agency SHALL priondary-verb">nt> “Federal Emergency Response Official” as depicted in Figure 4-2. The label SHOULD be in white lettering on a red background. Additional information regarding the federal emergency responder role MAY be included in Zone 9F, as depicted in Figure 4-2. 4.1.4.3 ¶ 15
    {approved font} The organizational affiliation abbreviation MAY be printed in the upper right-hand corner below the Zone 19F expiration date as shown in Figure 4-2. If printed, the organizational affiliation abbreviation SHALL be printed in 12 pt Arial Bold. 4.1.4.3 ¶ 25
    {appropriate format} If the PIV Card is used to identify a federal emergency response official, a department or agency SHALL print “Federal Emergency Response Official” as depicted in Figure 4-2. The label SHOULD be in white lettering on a red background. Additional information regarding the federal emergency responder role MAY be included in Zone 9F, as depicted in Figure 4-2. 4.1.4.3 ¶ 15
    If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 29
    {header} If used, the text “United States Government” SHALL be ="background-color:#B7D8ED;" class="term_primary-verb">placed
    as depicted in Figure 4-3, Figure 4-4, and Figure 4-5. Departments and agencies MAY instead use this zone for other department or agency-specific information, such as identifying a federal emergency responder role, as depicted in Figure 4-2. Some examples of official roles are “Law Enforcement,” “Fire Fighter,” and “Emergency Response Team (ERT).” 4.1.4.3 ¶ 11
    {appropriate format} A CHUID MAY also include a Cardholder UUID that represents a persistent identifier of the cardholder, as specified in [SP 800-73]. The value of the cardholder UUID SHALL _primary-verb">be
    the 16 byte binary representation of a valid UUID, as specified in [RFC 4122]. 4.2.1 ¶ 3
    {issuer identification number}{appropriate format} This item SHALL be printed as depicted in Figure 4-6 and consist of six characters for the department code, four characters for the agency code, and a five-digit number that uniquely identifies the issuing facility within the department or agency. 4.1.4.2 ¶ 4]
    Process or Activity Preventive
    Define the data elements to be stored on identification cards or badges in the identification card or badge architectural designs. CC ID 15427
    [The two mandatory fingerprints SHALL be used for the preparation of biometric templates to be stored on the PIV Card as described in Section 4.2.3.1. The fingerprints provide an interoperable authentication mechanism through an off-card comparison scheme (BIO or BIO-A) as described in Section 6.2.1. These fingerprints are also the primary means of authentication during PIV issuance and maintenance processes. 2.5 ¶ 2
    {not meet} 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 templates, as specified in [SP 800-76]. 4.2.3.1 ¶ 1 Bullet 1
    {not meet} 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 templates, as specified in [SP 800-76]. 4.2.3.1 ¶ 1 Bullet 1
    The following biometric data SHALL be stored on the PIV Card: An electronic facial image. 4.2.3.1 ¶ 1 Bullet 2
    All biometric data SHALL be stored in the data elements referenced by [SP 800-73] and in conformance with the preparation and formatting specifications of [SP 800-76]. 4.2.3.1 ¶ 3
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder’s identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: 4.2 ¶ 2
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: a PIN, 4.2 ¶ 2 Bullet 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: PIV authentication data (one asymmetric private key and corresponding certificate), 4.2 ¶ 2 Bullet 2
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: two fingerprint biometric templates, 4.2 ¶ 2 Bullet 4
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: card authentication data (one asymmetric private key and corresponding certificate), 4.2 ¶ 2 Bullet 3
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. Section 5 of this document specifies the certificate format and the key management infrastructure for key management keys. 4.2.2.5 ¶ 2
    {applicable requirements} Agencies MAY choose to collect electronic iris images as an additional biometric characteristic. If collected, the electronic iris images SHALL be stored on the PIV Card as described in Section 4.2.3.1. The images MAY be used for cardholder authentication (BIO or BIO-A) as described in Section 6.2.1. Electronic iris images are an additional means of authentication during PIV issuance and maintenance processes. 2.5 ¶ 4
    {applicable requirements} {biometric authentication} The electronic facial image SHALL be stored on the PIV Card as described in Section 4.2.3.1. It SHALL be printed on the PIV Card according to Section 4.1.4.1. The image MAY be used for cardholder authentication (BIO or BIO-A) as described in Section 6.2.1. It MAY be retrieved and displayed on guard workstations to augment other authentication processes from Section 6.2. The electronic facial image is an additional means of authentication during PIV issuance and maintenance processes when used with an automated facial comparison algorithm. 2.5 ¶ 5
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    All biometric data SHALL be stored in the data elements referenced by [SP 800-73] and in conformance with the preparation and formatting specifications of [SP 800-76]. 4.2.3.1 ¶ 3
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for PIV digital signature keys. 4.2.2.4 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for PIV digital signature keys. 4.2.2.4 ¶ 2
    A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. 4.1.2 ¶ 8
    A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. 4.1.2 ¶ 8
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder rb">does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17]
    Systems Design, Build, and Implementation Preventive
    Define the optional items that may appear on identification cards or badges in the identification card or badge architectural designs. CC ID 06594
    [{applicable requirements} When Zone 15F indicates foreign national affiliation and the department or agency does not need to highlight emergency response official status, Zone 12F MAY be used to denote the country or countries of citizenship. If so used, the department or agency SHALL le="background-color:#B7D8ED;" class="term_primary-verb">printpan> the country name or the three-letter country abbreviation (alpha3 format) in accordance with [ISO 3166]. Figure 4-4 illustrates an example of using country abbreviations for a card issued to a foreign national. 4.1.4.3 ¶ 16
    {appropriate format} If used, the card issuance date SHALL be printed above the Zone 14F expiration date in YYYYMMMDD format, as depicted in Figure 4-3. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. 4.1.4.3 ¶ 19
    A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. 4.1.4.3 ¶ 21
    A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. 4.1.4.3 ¶ 21
    If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 29
    If used, this area can be used for printing agency-specific requirements, such as employee status, as shown in Figure 4-2. Note that this zone overlaps with an area that some card manufacturers might not allow to be used for printing. If used, this area can be used for printing agency-specific requirements, such as employee status, as shown in Figure 4-2. Note that this zone overlaps with an area that some card manufacturers might not allow to be used for printing. 4.1.4.3 ¶ 5
    {PIV Card} If used, the “return if lost” language SHALL be placed on the olor:#F0BBlass="term_secondary-verb">BC;"
    class="term_primary-noun">back of the card in the general area depicted in Figure 4-7. 4.1.4.4 ¶ 4
    {PIV Card} If used, the cardholder physical characteristics (e.g., height, eye color, hair color) SHALL be class="term_primary-verb">printed in the general area illustrated in Figure 4-7. 4.1.4.4 ¶ 6
    {PIV Card}{be necessary} In cases in which other defined optional elements are not used, these zones MAY be used for other department or agency-specific information, as depicted in Figure 4-8. Departments and agencies SHOULD style="background-color:#B7D8ED;" class="term_primary-verb">minimize printed >textspan> to that which is absolutely necessary. 4.1.4.4 ¶ 14
    {PIV Card}{reserved area}{machine-readable information} Departments and agencies MAY choose to provide additional information to identify emergency response officials or to better identify the cardholder’s authorized access. If used, this additional text SHALL round-color:#B7D8ED;" class="term_primary-verb">be
    in the general area depicted in Figure 4-7 and SHALL NOT interfere with other printed text or machine-readable components. An example of a printed statement is provided in Figure 4-7. 4.1.4.4 ¶ 8
    If used, standard Section 499, Title 18, language warning against counterfeiting, altering, or misusing the card SHALL be printed in the general yle="background-color:#F0BBBC;" class="term_primary-noun">area depicted in Figure 4-7. If used, standard Section 499, Title 18, language warning against counterfeiting, altering, or misusing the card SHALL be printed in the general area depicted in Figure 4-7. 4.1.4.4 ¶ 10]
    Process or Activity Preventive
    Include security measures in the identification card or badge architectural designs. CC ID 15423
    [All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces 4.2.2 ¶ 19]
    Systems Design, Build, and Implementation Preventive
    Include the logical credential data model for identification cards or badges in the identification card or badge architectural designs. CC ID 06595
    [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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: a Cardholder Unique Identifier (CHUID). 4.2 ¶ 2 Bullet 6
    A new PIV authentication certificate and a new card authentication certificate SHALL be generated. The corresponding certificates SHALL be populated with the new FASCN and card UUID. For cardholders with government-issued email accounts, the digital signature and key management keys and associated certificates SHALL be populated. A new digital signature key and associated certificate SHALL be generated on the new PIV Card, while key management keys and associated certificates MAY be imported to the new PIV Card. 2.9.1 ¶ 8
    A new PIV authentication certificate and a new card authentication certificate SHALL be generated. The corresponding certificates SHALL be populated with the new FASCN and card UUID. For cardholders with government-issued email accounts, the digital signature and key management keys and associated certificates SHALL be populated. A new digital signature key and associated certificate SHALL be generated on the new PIV Card, while key management keys and associated certificates MAY be imported to the new PIV Card. 2.9.1 ¶ 8
    A new PIV authentication certificate and a new card authentication certificate SHALL be generated. The corresponding certificates SHALL be populated with the new FASCN and card UUID. For cardholders with government-issued email accounts, the digital signature and key management keys and associated certificates SHALL be populated. A new digital signature key and associated certificate SHALL be generated on the new PIV Card, while key management keys and associated certificates MAY be imported to the new PIV Card. 2.9.1 ¶ 8
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    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 contact interface of the PIV Card. Operations that use the key management key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.5 ¶ 1
    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 contact interface of the PIV Card. Operations that use the key management key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.5 ¶ 1
    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 interface unless otherwise specified by [SP 800-73]. 4.2.2.6 ¶ 1
    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 interface unless otherwise specified by [SP 800-73]. 4.2.2.6 ¶ 1
    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 and appended with the CBEFF signature block [NISTIR 6529-A]. 4.2.3.2 ¶ 1
    The PIV Card SHALL be activated to perform privileged 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 authenticating the cardholder or the appropriate card management system. Cardholder activation is described in Section 4.3.1 and card management system activation is described in Section 4.3.2. 4.3 ¶ 1
    The PIV Card SHALL be activated to perform privileged 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 authenticating the cardholder or the appropriate card management system. Cardholder activation is described in Section 4.3.1 and card management system activation is described in Section 4.3.2. 4.3 ¶ 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: an electronic facial image, and 4.2 ¶ 2 Bullet 5
    This Standard also defines two data elements for the PIV Card data model that are mandatory if the cardholder has a government-issued email account at the time of PIV Card issuance. These data elements are an asymmetric private key and corresponding certificate for key management. 4.2 ¶ 3 Bullet 2
    The expiration date of the PIV authentication and card authentication certificates SHALL NOT be after the expiration date of the PIV Card. The expiration date of the PIV Card is printed on the card in Zone 14F (see Section 4.1.4) and is contained in the CHUID data object (see Section 4.2.1). If the card is revoked, the PIV authentication and card authentication certificates SHALL be revoked in cases where the card cannot be collected and destroyed. However, a PIV authentication or card authentication certificate MAY be revoked and subsequently replaced without revoking the PIV Card. The presence of a valid, unexpired, and unrevoked authentication certificate on a card is sufficient proof that the card was issued and is not revoked. 5.2.1 ¶ 2
    The expiration date of the PIV authentication and card authentication certificates SHALL NOT be after the expiration date of the PIV Card. The expiration date of the PIV Card is printed on the card in Zone 14F (see Section 4.1.4) and is contained in the CHUID data object (see Section 4.2.1). If the card is revoked, the PIV authentication and card authentication certificates SHALL be revoked in cases where the card cannot be collected and destroyed. However, a PIV authentication or card authentication certificate MAY be revoked and subsequently replaced without revoking the PIV Card. The presence of a valid, unexpired, and unrevoked authentication certificate on a card is sufficient proof that the card was issued and is not revoked. 5.2.1 ¶ 2
    All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces 4.2.2 ¶ 19
    All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces 4.2.2 ¶ 19]
    Process or Activity Preventive
  • Technical security
    182
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Technical security CC ID 00508 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain a digital identity management program. CC ID 13713 Establish/Maintain Documentation Preventive
    Establish the requirements for Identity Assurance Levels. CC ID 13857
    [The selection of authentication assurance levels SHALL be made in accordance with the applicable policies for a facility’s security level [RISK-MGMT-FACILITIES]. Additional guidelines for the selection and use of PIV authentication mechanisms for facility access can be found in NIST [SP 800-116]. 6.3.1 ¶ 3]
    Technical Security Preventive
    Establish, implement, and maintain digital identification procedures. CC ID 13714
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that 2.1 ¶ 2
    The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. 2.7 ¶ 11]
    Establish/Maintain Documentation Preventive
    Implement digital identification processes. CC ID 13731 Process or Activity Preventive
    Implement identity proofing processes. CC ID 13719
    [The department or agency SHALL adopt and use an identity proofing and registration process that is approved in accordance with [SP 800-79]. 2.7 ¶ 2
    [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 specified in this Standard, as well as those specified in federal privacy laws and policies including but not limited to the E-Government Act of 2002 [E-Gov], the Privacy Act of 1974 [PRIVACY], and OMB [M-03-22], as applicable. 2.11 ¶ 1
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    {refrain from implementing}{not be consistent} Departments and agencies may have a wide variety of uses for the PIV system and its components that were not intended or anticipated by the President in issuing [HSPD-12]. In considering whether a proposed use of the PIV system is appropriate, departments and agencies SHALL consider the aforementioned control objectives and the purpose of this Standard, namely “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy” as per [HSPD-12]. No department or agency SHALL implement a use of the identity credential inconsistent with these control objectives. 2.11 ¶ 2
    The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. 2.7 ¶ 11]
    Process or Activity Preventive
    Verify the identity of the organization's authorized representative during the identity proofing process. CC ID 13786 Process or Activity Preventive
    Allow authorized representatives to act on behalf of the data subject during the identity proofing process. CC ID 13787 Process or Activity Preventive
    Refrain from performing identity proofing as a means of providing access to systems or services. CC ID 13776 Process or Activity Detective
    Support the identity proofing process through in-person proofing or remote proofing. CC ID 13750 Process or Activity Preventive
    Establish, implement, and maintain remote proofing procedures. CC ID 13796
    [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 issuercontrolled station at a remote location that is connected to a trained operator at a central location. The goal of this arrangement is to permit identity proofing and enrollment of individuals in remote locations where it is not practical for them to travel to the agency for in-person identity proofing. 2.7.1 ¶ 1
    Supervised remote identity proofing SHALL meet the following requirements: The issuer SHALL ensure that all communications occur over a mutually authenticated protected channel. 2.7.1 ¶ 4 Bullet 7
    The following forms of protection SHALL be provided by either inherent capabilities of the station or staff at the station location: ensuring that the physical integrity of the station (e.g., door locks and restricted access) and integral nature of its sensor devices (e.g., fingerprint readers and cameras) are maintained at all times to protect against tampering, removal, or replacement; 2.7.1 ¶ 3 Bullet 2
    Supervised remote identity proofing SHALL meet the following requirements: The station SHALL be maintained in a controlled-access environment and SHALL be monitored by staff at the station location while it is being used. 2.7.1 ¶ 4 Bullet 1]
    Establish/Maintain Documentation Preventive
    Require digital authentication of evidence by integrated scanners when performing remote proofing. CC ID 13805
    [Supervised remote identity proofing SHALL meet the following requirements: The operator SHALL validate the physical or cryptographic security features of primary and secondary identity source documents using scanners and sensors that are integrated into the station. 2.7.1 ¶ 4 Bullet 6]
    Configuration Preventive
    Interact with the data subject when performing remote proofing. CC ID 13777
    [{identity proofing} The following forms of protection SHALL be provided by either inherent capabilities of the station or staff at the station location: ensuring that only the applicant interacts with the station during any session; 2.7.1 ¶ 3 Bullet 1
    Supervised remote identity proofing SHALL meet the following requirements: The issuer SHALL have a live operator participate remotely with the applicant for the entirety of the identity proofing session. 2.7.1 ¶ 4 Bullet 2]
    Process or Activity Detective
    Use valid activation codes to complete the identity proofing process when performing remote proofing. CC ID 13742 Process or Activity Preventive
    View all applicant actions when performing remote proofing. CC ID 13804
    [Supervised remote identity proofing SHALL meet the following requirements: The operator SHALL monitor the entire identity proofing session—from which the applicant SHALL NOT depart—by at least one continuous, high-resolution video transmission of the applicant. 2.7.1 ¶ 4 Bullet 4
    Supervised remote identity proofing SHALL meet the following requirements: The operator SHALL require all actions taken by the applicant during the identity proofing session to be clearly visible to the operator. 2.7.1 ¶ 4 Bullet 5
    Supervised remote identity proofing SHALL meet the following requirements: The station SHALL be maintained in a controlled-access environment and SHALL be monitored by staff at the station location while it is being used. 2.7.1 ¶ 4 Bullet 1
    {not be successful}{not acquire} OCC reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 6]
    Process or Activity Detective
    Employ knowledge-based authentication tools to aid the identity proofing process. CC ID 13741 Process or Activity Preventive
    Verify transaction history as part of the knowledge-based authentication questions during the identity proofing process. CC ID 13755 Process or Activity Detective
    Base the knowledge-based authentication for the identity proofing process on authoritative sources. CC ID 13743 Process or Activity Detective
    Refrain from using publicly available information for knowledge-based authentication during the identity proofing process. CC ID 13752 Process or Activity Preventive
    Refrain from using knowledge-based authentication questions that hint at their own answers during the identity proofing process. CC ID 13785 Process or Activity Preventive
    Refrain from revealing the data subject's personal data in knowledge-based authentication questions for the identity proofing process. CC ID 13774 Process or Activity Detective
    Refrain from using static knowledge-based authentication questions during the identity proofing process. CC ID 13773 Process or Activity Preventive
    Require a minimum number of knowledge-based authentication questions for the identity proofing process. CC ID 13745 Configuration Preventive
    Require free-form response knowledge-based authentication questions for the identity proofing process. CC ID 13746 Configuration Preventive
    Set a maximum number of attempts to complete the knowledge-based authentication for the identity proofing process. CC ID 13747 Configuration Preventive
    Use information from authoritative sources or the applicant for knowledge-based authentication during the identity proofing process. CC ID 13749 Process or Activity Preventive
    Refrain from using diversionary knowledge-based authentication questions during the identity proofing processes. CC ID 13744 Process or Activity Detective
    Validate proof of identity during the identity proofing process. CC ID 13756
    [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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1]
    Process or Activity Detective
    Allow biometric authentication for proof of identity during the identity proofing process. CC ID 13797 Business Processes Detective
    Inspect for the presence of man-made materials when performing biometric authentication during the identity proofing process. CC ID 13803 Process or Activity Detective
    Verify proof of identity records. CC ID 13761
    [During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    {refrain from implementing}{not be consistent} Departments and agencies may have a wide variety of uses for the PIV system and its components that were not intended or anticipated by the President in issuing [HSPD-12]. In considering whether a proposed use of the PIV system is appropriate, departments and agencies SHALL consider the aforementioned control objectives and the purpose of this Standard, namely “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy” as per [HSPD-12]. No department or agency SHALL implement a use of the identity credential inconsistent with these control objectives. 2.11 ¶ 2
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    Departments and agencies SHALL ensure that driver’s licenses and ID cards presented by applicants comply with [REAL-ID] when required pursuant to DHS regulations. Stateissued driver’s licenses and ID cards that are not [REAL-ID] compliant MAY be used until the full enforcement date under [6 CFR § 37.5]. Departments and agencies SHALL ensure that driver’s licenses and ID cards presented by applicants comply with [REAL-ID] when required pursuant to DHS regulations. Stateissued driver’s licenses and ID cards that are not [REAL-ID] compliant MAY be used until the full enforcement date under [6 CFR § 37.5]. 2.7 ¶ 9
    {not be successful}{not acquire} OCC reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operatorground-color:#CBD0E5;" class="term_secondary-verb"> SHALL <span style="background-color:#B7D8ED;" class="term_primary-verb">inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 6]
    Investigate Detective
    Refrain from using knowledge-based authentication to verify an individual's identity against more than one proof of identity during the identity proofing process. CC ID 13784 Process or Activity Detective
    Allow records that relate to the data subject as proof of identity. CC ID 13772
    [During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6]
    Process or Activity Preventive
    Conduct in-person proofing with physical interactions. CC ID 13775
    [{appear in person} If biometric data cannot be collected per the criteria defined in [SP 800-76] or if validation of the identity evidence is inadequate, supervised remote identity proofing SHALL NOT be used and the identity proofing and enrollment will be performed in person at the issuer’s facility. The trained operator SHALL terminate a supervised remote identity proofing session and require in-person identity proofing at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.7.1 ¶ 5
    {appear in person} If biometric data cannot be collected per the criteria defined in [SP 800-76] or if validation of the identity evidence is inadequate, supervised remote identity proofing SHALL NOT be used and the identity proofing and enrollment will be performed in person at the issuer’s facility. The trained operator SHALL terminate a supervised remote identity proofing session and require in-person identity proofing at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.7.1 ¶ 5]
    Process or Activity Detective
    Include the consequences of refraining from providing attributes in the identity proofing process. CC ID 13748 Process or Activity Preventive
    Send a notification of proofing to a confirmed address of record when performing in-person proofing. CC ID 13739 Process or Activity Preventive
    Refrain from using unconfirmed self-asserted address data during the identity proofing process. CC ID 13738 Process or Activity Preventive
    Refrain from approving attributes in the identity proofing process. CC ID 13716 Process or Activity Preventive
    Reperform the identity proofing process for each individual, as necessary. CC ID 13762 Process or Activity Detective
    Establish, implement, and maintain federated identity systems. CC ID 13837
    [The IAL, AAL, and FAL SHALL be known to the RP at the conclusion of the federation transaction. This information MAY be pre-established or the IdP MAY communicate this at runtime in the assertion. For example, the information can be presented using technologies defined in [RFC 8485], [OIDC4IA], or [SAML-AC]. 7.2 ¶ 2]
    Technical Security Preventive
    Authenticate all systems in a federated identity system. CC ID 13835 Technical Security Preventive
    Send and receive authentication assertions, as necessary. CC ID 13839
    [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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1]
    Technical Security Preventive
    Make the assertion reference for authentication assertions single-use. CC ID 13843 Technical Security Preventive
    Validate the issuer in the authentication assertion. CC ID 13878 Technical Security Detective
    Limit the lifetime of the assertion reference. CC ID 13874 Technical Security Preventive
    Refrain from using authentication assertions that have expired. CC ID 13872
    [A derived PIV credential SHALL NOT be accepted for authentication once the credential has been invalidated. When invalidation occurs, the issuer SHALL notify the cardholder of the change. 2.10.2 ¶ 3]
    Technical Security Preventive
    Protect the authentication assertion from unauthorized access or unauthorized disclosure. CC ID 16836 Technical Security Preventive
    Include the issuer identifier in the authentication assertion. CC ID 13865 Technical Security Preventive
    Include attribute metadata in the authentication assertion. CC ID 13856 Technical Security Preventive
    Include the authentication time in the authentication assertion. CC ID 13855 Technical Security Preventive
    Validate each element within the authentication assertion. CC ID 13853
    [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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1]
    Technical Security Preventive
    Validate the timestamp in the authentication assertion. CC ID 13875 Technical Security Detective
    Validate the digital signature in the authentication assertion. CC ID 13869 Technical Security Detective
    Validate the signature validation element in the authentication assertion. CC ID 13867 Technical Security Detective
    Validate the audience restriction element in the authentication assertion. CC ID 13866 Technical Security Detective
    Include the subject in the authentication assertion. CC ID 13852 Technical Security Preventive
    Include the target audience in the authentication assertion. CC ID 13851 Technical Security Preventive
    Include audience restrictions in the authentication assertion. CC ID 13870 Technical Security Preventive
    Include the issue date in the authentication assertion. CC ID 13850 Technical Security Preventive
    Revoke authentication assertions, as necessary. CC ID 16534 Technical Security Preventive
    Include the expiration date in the authentication assertion. CC ID 13849 Technical Security Preventive
    Include identifiers in the authentication assertion. CC ID 13848 Technical Security Preventive
    Include digital signatures in the authentication assertion. CC ID 13847 Technical Security Preventive
    Include key binding in the authentication assertion. CC ID 13846 Technical Security Preventive
    Include attribute references in the authentication assertion. CC ID 13845 Technical Security Preventive
    Include attribute values in the authentication assertion. CC ID 13844 Technical Security Preventive
    Limit the use of the assertion reference to a single organization. CC ID 13841 Technical Security Preventive
    Request attribute references instead of attribute values during the presentation of an authentication assertion. CC ID 13840 Technical Security Preventive
    Define the assertion level for authentication assertions. CC ID 13873 Technical Security Preventive
    Refrain from assigning assertion levels for authentication assertions when not defined. CC ID 13879 Technical Security Preventive
    Authenticate systems referenced in the whitelist. CC ID 13838 Technical Security Preventive
    Place nonmembers of whitelists and blacklists into a gray area until a runtime decision is made during the authentication assertion. CC ID 13854 Technical Security Preventive
    Require runtime decisions regarding authentication for organizations that are excluded from the whitelist. CC ID 13842 Technical Security Preventive
    Establish, implement, and maintain an access control program. CC ID 11702 Establish/Maintain Documentation Preventive
    Include instructions to change authenticators as often as necessary in the access control program. CC ID 11931
    [{previously used PIN} Cardholders MAY change their PINs at any time by providing the current PIN and the new PIN values, as specified in [SP 800-73]. 2.9.3 ¶ 3]
    Establish/Maintain Documentation Preventive
    Include guidance for how users should protect their authentication credentials in the access control program. CC ID 11929
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that An issued credential is not modified by an unauthorized entity. 2.1 ¶ 2 Bullet 12]
    Establish/Maintain Documentation Preventive
    Include guidance on selecting authentication credentials in the access control program. CC ID 11928
    [{be unguessable}{not be identifiable}{be unique} The cardholder SHALL be guided in selecting a strong PIN value. The PIN SHALL be a minimum of six digits in length and SHOULD NOT be easily guessable, individually identifiable (e.g., part of a Social Security Number or phone number), or commonly used (e.g., 000000, 123456). 4.3.1 ¶ 2]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain an access rights management plan. CC ID 00513 Establish/Maintain Documentation Preventive
    Control access rights to organizational assets. CC ID 00004 Technical Security Preventive
    Establish, implement, and maintain lockout procedures or lockout mechanisms to be triggered after a predetermined number of consecutive logon attempts. CC ID 01412
    [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 card to perform CTC authentication, and the card responds with a positive or negative biometric verification decision. The response includes information that allows the reader to authenticate the card. Entry of the cardholder PIN is not required for OCC-AUTH. The PIV Card SHALL include a mechanism to block this authentication mechanism after a number of consecutive failed authentication attempts as stipulated by the department or agency. As with BIO and BIO-A, if agencies choose to implement OCC, it SHALL be implemented as defined in [SP 800-73] and [SP 800-76]. 6.2.2 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1]
    Technical Security Preventive
    Configure the lockout procedure to disregard failed logon attempts after the user is authenticated. CC ID 13822 Configuration Preventive
    Notify the user when an authentication is attempted using an expired authenticator. CC ID 13818
    [A derived PIV credential SHALL NOT be accepted for authentication once the credential has been invalidated. When invalidation occurs, the issuer SHALL notify the cardholder of the change. 2.10.2 ¶ 3]
    Communicate Corrective
    Disallow unlocking user accounts absent system administrator approval. CC ID 01413 Technical Security Preventive
    Establish, implement, and maintain User Access Management procedures. CC ID 00514 Technical Security Preventive
    Control the addition and modification of user identifiers, user credentials, or other authenticators. CC ID 00515
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A process exists to invalidate, revoke, or destroy credentials when the cardholder loses eligibility or when the credential is lost, stolen, or compromised. 2.1 ¶ 2 Bullet 9
    Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential remains serviceable only up to its expiration date. 2.1 ¶ 2 Bullet 8
    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 requirements in this section. 2.10.1 ¶ 1]
    Technical Security Preventive
    Assign roles and responsibilities for administering user account management. CC ID 11900 Human Resources Management Preventive
    Automate access control methods, as necessary. CC ID 11838 Technical Security Preventive
    Automate Access Control Systems, as necessary. CC ID 06854 Technical Security Preventive
    Refrain from storing logon credentials for third party applications. CC ID 13690 Technical Security Preventive
    Refrain from allowing user access to identifiers and authenticators used by applications. CC ID 10048 Technical Security Preventive
    Notify interested personnel when user accounts are added or deleted. CC ID 14327 Communicate Detective
    Protect and manage biometric systems and biometric data. CC ID 01261
    [The biometric data records in the PIV enrollment records SHALL be valid for a maximum of 12 years. In order to mitigate aging effects and thereby maintain operational readiness of a cardholder’s PIV Card, agencies MAY require biometric enrollment more frequently than 12 years. 2.6 ¶ 4
    The CBEFF signature block contains the digital signature of the biometric data record and facilitates the verification of the integrity of the biometric data record. The CBEFF signature block SHALL be encoded as a CMS external digital signature as specified in [SP 800-76]. The algorithm and key size requirements for the digital signature and digest algorithm are detailed in [SP 800-78]. 4.2.3.2 ¶ 3]
    Technical Security Preventive
    Establish, implement, and maintain biometric collection procedures. CC ID 15419
    [A full set of fingerprints SHALL be collected from each PIV applicant who is lacking an on-record background investigation. 2.3 ¶ 2
    The following biometric data MAY be collected from a PIV applicant: An electronic image of the right iris. 2.4 ¶ 2 Bullet 2
    The full set of fingerprints SHALL be collected for biometric identification against databases of fingerprints maintained by the FBI. 2.5 ¶ 1
    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. 2.4 ¶ 1 Bullet 1
    Fingerprint collection SHALL conform to the procedural and technical specifications of [SP 800-76]. 2.3 ¶ 4
    Biometric data collection SHALL conform to the procedural and technical specifications of [SP 800-76]. The choice of fingers to use for mandatory fingerprint templates and optional fingerprint templates MAY vary between persons. The recommended selection and order is specified in [SP 800-76]. 2.4 ¶ 5
    The following biometric data SHALL be collected from each PIV applicant: An electronic facial image. 2.4 ¶ 1 Bullet 2
    The following biometric data MAY be collected from a PIV applicant: Two fingerprints for on-card comparison (OCC). These fingerprints MAY be taken from the full set of fingerprints collected in Section 2.3 and SHOULD be imaged from fingers not imaged for off-card one-to-one comparison. 2.4 ¶ 2 Bullet 3
    The following biometric data MAY be collected from a PIV applicant: An electronic image of the left iris. 2.4 ¶ 2 Bullet 1]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain access control procedures. CC ID 11663
    [Parties responsible for controlling access to federal resources (both physical and logical) SHALL determine the appropriate assurance levels required for access based on the harm and impact to individuals and organizations that could occur as a result of errors in the authentication of the PIV cardholder. Once the required assurance level has been determined, one of the authentication mechanisms specified in Section 6.2 SHALL be applied to achieve that assurance level. 6.1 ¶ 3]
    Establish/Maintain Documentation Preventive
    Implement out-of-band authentication, as necessary. CC ID 10606 Technical Security Corrective
    Grant access to authorized personnel or systems. CC ID 12186
    [{is not issued} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that No credential is issued unless requested by the proper authority. 2.1 ¶ 2 Bullet 7
    To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that only personnel with a legitimate need for access to PII in the PIV system are authorized to access the PII, including but not limited to information and databases maintained for registration and credential issuance. 2.11 ¶ 3 Bullet 7]
    Configuration Preventive
    Document approving and granting access in the access control log. CC ID 06786 Establish/Maintain Documentation Preventive
    Disseminate and communicate the access control log to interested personnel and affected parties. CC ID 16442 Communicate Preventive
    Include the user identifiers of all personnel who are authorized to access a system in the system record. CC ID 15171 Establish/Maintain Documentation Preventive
    Include identity information of all personnel who are authorized to access a system in the system record. CC ID 16406 Establish/Maintain Documentation Preventive
    Include the date and time that access was reviewed in the system record. CC ID 16416 Data and Information Management Preventive
    Include the date and time that access rights were changed in the system record. CC ID 16415 Establish/Maintain Documentation Preventive
    Disseminate and communicate the access control procedures to all interested personnel and affected parties. CC ID 14123 Communicate Corrective
    Establish, implement, and maintain an identification and authentication policy. CC ID 14033 Establish/Maintain Documentation Preventive
    Include roles and responsibilities in the identification and authentication policy. CC ID 14230
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A single corrupt official in the process cannot issue a credential with an incorrect identity or to a person not entitled to the credential. 2.1 ¶ 2 Bullet 10
    PIV Cards that contain topographical defects (e.g., scratches, poor color, fading, etc.) or that are not properly printed SHALL be destroyed. The PIV Card issuer is responsible for the card stock, its management, and its integrity. 2.8 ¶ 2
    {applicable requirements} Remote issuance SHALL satisfy all of the requirements of Section 2.8. The issuer SHALL have local trained staff to securely maintain custody of card stock received by the remote station when the station is used for PIV Card issuance. 2.8.3 ¶ 2]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain identification and authentication procedures. CC ID 14053
    [Federal departments and agencies SHALL use the credentialing eligibility standards issued by the Director of the Office of Personnel Management (OPM) and OMB. 2.2 ¶ 1
    Parties responsible for controlling access to federal resources (both physical and logical) SHALL determine the appropriate assurance levels required for access based on the harm and impact to individuals and organizations that could occur as a result of errors in the authentication of the PIV cardholder. Once the required assurance level has been determined, one of the authentication mechanisms specified in Section 6.2 SHALL be applied to achieve that assurance level. 6.1 ¶ 3
    {be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2]
    Establish/Maintain Documentation Preventive
    Disseminate and communicate the identification and authentication procedures to interested personnel and affected parties. CC ID 14223 Communicate Preventive
    Include digital identification procedures in the access control program. CC ID 11841
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential is issued to an individual only after a proper authority has authorized issuance of the credential, the individual’s identity has been verified, and the individual has been vetted per Section 2.2. 2.1 ¶ 2 Bullet 1]
    Technical Security Preventive
    Employ unique identifiers. CC ID 01273 Testing Detective
    Disseminate and communicate user identifiers and authenticators using secure communication protocols. CC ID 06791
    [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 to a website or other server), the input device is not required to be integrated with the PIV Card reader. If the input device is not integrated with the PIV Card reader, the PIN or OCC data SHALL be transmitted securely and directly to the PIV Card for card activation. 4.4.4 ¶ 1]
    Data and Information Management Preventive
    Include instructions to refrain from using previously used authenticators in the access control program. CC ID 11930 Establish/Maintain Documentation Preventive
    Disallow the use of Personal Identification Numbers as user identifiers. CC ID 06785 Technical Security Preventive
    Define the activation requirements for identification cards or badges. CC ID 06583
    [{does not exist} For individuals for whom no prior investigation exists, the appropriate required investigation SHALL be initiated with the authorized federal investigative service provider and the FBI NCHC portion of the background investigation SHALL be completed and favorably adjudicated prior to PIV Card issuance. 2.2 ¶ 4
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1]
    Process or Activity Preventive
    Require multiple forms of personal identification prior to issuing user identifiers. CC ID 08712
    [{does not occur} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that No substitution occurs in the identity proofing process. More specifically, the individual who appears for identity proofing and whose fingerprints are checked against databases is the person to whom the credential is issued. 2.1 ¶ 2 Bullet 6
    Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that An individual is issued a credential only after presenting two identity source documents, at least one of which is a Federal or State Government-issued picture ID. 2.1 ¶ 2 Bullet 3
    Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential is issued to an individual only after a proper authority has authorized issuance of the credential, the individual’s identity has been verified, and the individual has been vetted per Section 2.2. 2.1 ¶ 2 Bullet 1]
    Human Resources Management Preventive
    Authenticate user identities before unlocking an account. CC ID 11837 Testing Detective
    Authenticate user identities before manually resetting an authenticator. CC ID 04567
    [{appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT reset the PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5]
    Testing Detective
    Require proper authentication for user identifiers. CC ID 11785
    [{be genuine} {is not altered} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that Fraudulent identity source documents are not accepted as genuine or unaltered. 2.1 ¶ 2 Bullet 4]
    Technical Security Preventive
    Assign authenticators to user accounts. CC ID 06855 Configuration Preventive
    Assign authentication mechanisms for user account authentication. CC ID 06856 Configuration Preventive
    Refrain from allowing individuals to share authentication mechanisms. CC ID 11932 Technical Security Preventive
    Establish and maintain a memorized secret list. CC ID 13791 Establish/Maintain Documentation Preventive
    Limit account credential reuse as a part of digital identification procedures. CC ID 12357
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that An issued credential is not duplicated or forged. 2.1 ¶ 2 Bullet 11]
    Configuration Preventive
    Refrain from assigning authentication mechanisms for shared accounts. CC ID 11910 Technical Security Preventive
    Use biometric authentication for identification and authentication, as necessary. CC ID 06857
    [If the identity proofing and enrollment process is performed over multiple visits, an automated biometric verification attempt comparing the applicant’s newly captured biometric characteristics against biometric data collected during a previous visit SHALL be performed at each visit and return a positive verification decision. 2.4 ¶ 3
    If biometric data was collected as specified in Section 2.3 and if collection of biometric data as specified in this section and in Section 2.3 occur on separate occasions, a biometric comparison SHALL be performed to confirm that the two fingerprints collected for off-card one-to-one comparisons elicit a positive biometric verification decision when compared to the same two fingerprints from the original set of ten fingerprints. 2.4 ¶ 4
    PIV background investigation, identity proofing, registration, and issuance processes MAY be performed across multiple sessions at different facilities. If multiple sessions are needed, the applicant SHALL be linked through a positive biometric verification decision obtained from an automated comparison of biometric characteristics captured at a previous session to biometric characteristics captured during the current session. Issuers SHALL follow applicable federal laws and regulations regarding the retention and destruction of biometric data. 2.5 ¶ 6
    For linking to background investigations, only fingerprints SHALL be used, since fingerprints are the only biometric characteristic used for background investigations. For all other purposes, verification attempts MAY be performed against any available biometric characteristic stored electronically on the PIV Card or in the enrollment record. 2.5 ¶ 7
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {negative biometric verification decision} {are not available} The issuer SHALL perform a biometric verification of the applicant to the biometric data records of the PIV enrollment record or to the biometric data records of the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. Minimum accuracy requirements for the biometric verification are specified in [SP 800-76]. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.9.1 ¶ 3
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {appear in person}{not be successful}{not be available} When OCC reset is performed in person at the issuing facility, before the reset, the issuer SHALL perform a biometric verification of the cardholder to the biometric data records in the PIV enrollment record. If the biometric verification decision is negative or no alternative biometric data records are available, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 4
    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 card to perform CTC authentication, and the card responds with a positive or negative biometric verification decision. The response includes information that allows the reader to authenticate the card. Entry of the cardholder PIN is not required for OCC-AUTH. The PIV Card SHALL include a mechanism to block this authentication mechanism after a number of consecutive failed authentication attempts as stipulated by the department or agency. As with BIO and BIO-A, if agencies choose to implement OCC, it SHALL be implemented as defined in [SP 800-73] and [SP 800-76]. 6.2.2 ¶ 1
    {not acquire} When PIN reset is performed in person at the issuing facility, before providing the reset PIV Card back to the cardholder, the issuer SHALL color:#B7D8ED;" class="term_primary-verb">performpan> a pan style="background-color:#F0BBBC;" class="term_primary-noun">biometric verification to ensure that the cardholder’s biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect the identity document and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the card. 2.9.3.1 ¶ 3
    {applicable requirements}{remote proofing procedure}{not acquire} PIN reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a ">positive biometric verification decision when ="term_secondary-verb">compared to biometric data records secondary-verb">stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCCAUTH authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.1 ¶ 7
    {not be successful}{not acquire} OCC reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a ">positive biometric verification decision when BD0E5;" class="term_secondary-verb">compared to biometric data records secondary-verb">stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 6]
    Establish Roles Preventive
    Employ live scans to verify biometric authentication. CC ID 06847
    [{identity proofing} {registration} Biometric data SHALL be captured as specified in Section 2.3 and Section 2.4. 2.7 ¶ 4
    Biometric identification using fingerprints is the primary input to law enforcement checks. In cases where ten fingerprints are not available, then as many fingers as possible SHALL be imaged as per guidance in [SP 800-76]. In cases where no fingers are available to be imaged, agencies SHALL seek guidance from their respective investigative service provider for alternative means of performing law enforcement checks. 2.3 ¶ 3]
    Technical Security Preventive
    Identify the user when enrolling them in the biometric system. CC ID 06882
    [{does not occur} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that No substitution occurs in the identity proofing process. More specifically, the individual who appears for identity proofing and whose fingerprints are checked against databases is the person to whom the credential is issued. 2.1 ¶ 2 Bullet 6
    {be different} The use of an different content signing key from that which signs the CHUID is deprecated in this revision of the Standard. If the signature on the biometric data record was generated with a different key than the signature on the CHUID, the certificates field of the CMS external digital signature SHALL include the content signing certificate required to verify the signature on the biometric data record. Otherwise, the certificates field SHALL be omitted. 4.2.3.2 ¶ 5]
    Testing Detective
    Disallow self-enrollment of biometric information. CC ID 11834 Process or Activity Preventive
    Tune the biometric identification equipment, as necessary. CC ID 07077 Configuration Corrective
    Notify a user when an authenticator for a user account is changed. CC ID 13820 Communicate Preventive
    Enforce information flow control. CC ID 11781 Monitor and Evaluate Occurrences Preventive
    Establish, implement, and maintain information flow control policies inside the system and between interconnected systems. CC ID 01410 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain information exchange procedures. CC ID 11782 Establish/Maintain Documentation Preventive
    Protect data from modification or loss while transmitting between separate parts of the system. CC ID 04554
    [{data in transit}{data at rest} PIV enrollment records contain Personally Identifiable Information (PII). PII SHALL be protected in a manner that protects the individual’s privacy and maintains the integrity of the records both in transit and at rest. 2.6 ¶ 5]
    Data and Information Management Preventive
    Manage the use of encryption controls and cryptographic controls. CC ID 00570 Technical Security Preventive
    Establish, implement, and maintain digital signatures. CC ID 13828
    [{refrain from exceeding} Previously collected biometric data MAY be reused with the new PIV Card if the expiration date of the new PIV Card is no later than 12 years after the date that the biometric data was obtained. As biometric system error rates generally increase with the time elapsed since initial collection (reference aging, [ISO 2382-37]), issuers MAY refresh biometric data in the PIV enrollment record during the re-issuance process. Even if the same biometric data is reused with the new PIV Card, the digital signature must be recomputed with the new FASC-N and card UUID. 2.9.1 ¶ 7
    The public key required to verify the digital signature SHALL be in a content signing certificate, which SHALL be issued under the id-fpki-common-piv-contentSigning policy of [COMMON] and SHALL include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. The signature on the biometric data record SHOULD be generated with the same signing key as the signature on the CHUID data object. The public key required to verify the digital signature is contained in the CHUID data object’s content signing certificate33 as detailed in Section 4.2.1. 4.2.3.2 ¶ 4]
    Data and Information Management Preventive
    Include the expiration date in digital signatures. CC ID 13833 Data and Information Management Preventive
    Include audience restrictions in digital signatures. CC ID 13834 Data and Information Management Preventive
    Include the subject in digital signatures. CC ID 13832 Data and Information Management Preventive
    Include the issuer in digital signatures. CC ID 13831 Data and Information Management Preventive
    Include identifiers in the digital signature. CC ID 13829 Data and Information Management Preventive
    Generate and protect a secret random number for each digital signature. CC ID 06577 Establish/Maintain Documentation Preventive
    Establish the security strength requirements for the digital signature process. CC ID 06578 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain an encryption management and cryptographic controls policy. CC ID 04546 Establish/Maintain Documentation Preventive
    Accept only trusted keys and/or certificates. CC ID 11988
    [{refrain from expiring}{not be revoked} The relying system validates the card authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.2 ¶ 1 Bullet 2]
    Technical Security Preventive
    Define the asymmetric signature field for the CHUID container on identification cards or badges. CC ID 06584
    [This Standard requires inclusion of the asymmetric signature field in the CHUID container. The asymmetric signature data element of the CHUID SHALL be encoded as a Cryptographic Message Syntax (CMS) external digital signature, as specified in [SP 800-73]. Algorithm and key size requirements for the asymmetric signature and digest algorithm are detailed in [SP 800-78]. 4.2.1 ¶ 6
    This Standard requires inclusion of the asymmetric signature field in the CHUID container. The asymmetric signature data element of the CHUID SHALL be encoded as a Cryptographic Message Syntax (CMS) external digital signature, as specified in [SP 800-73]. Algorithm and key size requirements for the asymmetric signature and digest algorithm are detailed in [SP 800-78]. 4.2.1 ¶ 6]
    Process or Activity Preventive
    Implement cryptographic operations and support functions on identification cards or badges. CC ID 06585
    [This Standard also defines two data elements for the PIV Card data model that are mandatory if the cardholder has a government-issued email account at the time of PIV Card issuance. These data elements are an asymmetric private key and corresponding certificate for digital signatures, and 4.2 ¶ 3 Bullet 1
    The PIV Card SHALL implement the cryptographic operations and support functions defined in [SP 800-78] and [SP 800-73]. 4.2.2 ¶ 1
    {be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1
    {be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1
    {be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1
    PIV Cards consistent with this specification SHALL have two or more asymmetric private keys. To manage the public keys associated with the asymmetric private keys, departments and agencies SHALL issue and manage X.509 public key certificates as specified in this section. 5 ¶ 2
    PIV Cards consistent with this specification SHALL have two or more asymmetric private keys. To manage the public keys associated with the asymmetric private keys, departments and agencies SHALL issue and manage X.509 public key certificates as specified in this section. 5 ¶ 2
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 be available through the contact and contactless interfaces of the PIV Card and SHALL NOT be available through the virtual contact interface of the PIV Card. Private key operations MAY be performed using this key without card activation (e.g., the PIN need not be supplied for operations with this key). 4.2.2.2 ¶ 1
    {contact interface} 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 be available through the contact and contactless interfaces of the PIV Card and SHALL NOT be available through the virtual contact interface of the PIV Card. Private key operations MAY be performed using this key without card activation (e.g., the PIN need not be supplied for operations with this key). 4.2.2.2 ¶ 1
    {contact interface} 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 be available through the contact and contactless interfaces of the PIV Card and SHALL NOT be available through the virtual contact interface of the PIV Card. Private key operations MAY be performed using this key without card activation (e.g., the PIN need not be supplied for operations with this key). 4.2.2.2 ¶ 1
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17
    With the exception of the card authentication key and keys used to establish secure messaging, cryptographic private key operations SHALL be performed only through the contact interface or the virtual contact interface. Any operation that MAY be performed over the contact interface of the PIV Card MAY also be performed over the virtual contact interface. Requirements for the virtual contact interface are specified in [SP 800-73]. With the exception of the card authentication key and keys used to establish secure messaging, cryptographic private key operations SHALL be performed only through the contact interface or the virtual contact interface. Any operation that MAY be performed over the contact interface of the PIV Card MAY also be performed over the virtual contact interface. Requirements for the virtual contact interface are specified in [SP 800-73]. 4.2.2 ¶ 18]
    Process or Activity Preventive
    Define the format of the biometric data on identification cards or badges. CC ID 06586
    [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 4.2.3.3 ¶ 1 Bullet 1
    OCC MAY be performed over the contact and contactless interfaces of the PIV Card to support card activation (Section 4.3.1) and cardholder authentication (Section 6.2.2). The fingerprint biometric templates for OCC SHALL NOT be exportable. If implemented, OCC SHALL be implemented and used in accordance with [SP 800-73] and [SP 800-76]. 4.2.3.3 ¶ 2
    OCC MAY be performed over the contact and contactless interfaces of the PIV Card to support card activation (Section 4.3.1) and cardholder authentication (Section 6.2.2). The fingerprint biometric templates for OCC SHALL NOT be exportable. If implemented, OCC SHALL be implemented and used in accordance with [SP 800-73] and [SP 800-76]. 4.2.3.3 ¶ 2]
    Process or Activity Preventive
    Establish, implement, and maintain cryptographic key management procedures. CC ID 00571 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain requirements for Personal Identity Verification authentication certificates. CC ID 06587
    [If the derived PIV credential to be invalidated contains a derived PIV authentication certificate and the corresponding private key cannot be securely zeroized or destroyed, the CA SHALL be informed and the certificate corresponding to the derived PIV authentication key SHALL be revoked. 2.10.2 ¶ 2]
    Establish/Maintain Documentation Preventive
    Establish, implement, and maintain Public Key certificate application procedures. CC ID 07079 Establish/Maintain Documentation Preventive
    Include the Identification and Authentication of individuals or entities in the Public Key certificate application procedures. CC ID 07080
    [{refrain from expiring}{not be revoked} The relying system validates the card authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.2 ¶ 1 Bullet 2]
    Establish/Maintain Documentation Preventive
    Include revocation of Public Key certificates in the Public Key certificate procedures. CC ID 07082
    [If the PIV authentication key (Section 4.2.2.1), asymmetric card authentication key (Section 4.2.2.2), digital signature key (Section 4.2.2.1), or key management key (Section 4.2.2.5) was compromised, the corresponding certificate SHALL be revoked. 2.9.2 ¶ 4
    {not be destroyed} {not be collected} The revocation process SHALL include the following: If the old PIV Card cannot be collected and destroyed, or if the old PIV Card has been compromised or damaged, then the Certification Authority (CA) SHALL be informed and the certificates corresponding to the PIV authentication key (Section 4.2.2.1) and asymmetric card authentication key (Section 4.2.2.2) on the old PIV Card SHALL be revoked. If present, the certificates corresponding to the digital signature key (Section 4.2.2.1) and the key management key (Section 4.2.2.5) SHALL also be revoked. 2.9.1 ¶ 4 Bullet 3
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: If the PIV Card cannot be collected and destroyed, the CA SHALL be informed and the certificates corresponding to the PIV authentication key and the asymmetric card authentication key on the PIV Card SHALL be revoked. The certificates corresponding to the digital signature and key management keys SHALL also be revoked, if present. 2.9.4 ¶ 2 Bullet 4
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: If the PIV Card cannot be collected and destroyed, the CA SHALL be informed and the certificates corresponding to the PIV authentication key and the asymmetric card authentication key on the PIV Card SHALL be revoked. The certificates corresponding to the digital signature and key management keys SHALL also be revoked, if present. 2.9.4 ¶ 2 Bullet 4
    Departments and agencies SHALL notify CAs when certificates need to be revoked. 5.5 ¶ 3
    If the derived PIV credential to be invalidated contains a derived PIV authentication certificate and the corresponding private key cannot be securely zeroized or destroyed, the CA SHALL be informed and the certificate corresponding to the derived PIV authentication key SHALL be revoked. 2.10.2 ¶ 2]
    Establish/Maintain Documentation Preventive
    Publish revoked Public Key certificates in the Certificate Revocation List. CC ID 07089
    [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 service that publishes the CRLs for the PIV certificates that it issues, as specified in [PROF]; 5.5 ¶ 1 Bullet 1
    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]. 5.3 ¶ 1
    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]. 5.3 ¶ 1
    {refrain from expiring}{not be revoked} The relying system validates the card authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.2 ¶ 1 Bullet 2]
    Establish/Maintain Documentation Preventive
    Establish a Root Certification Authority to support the Public Key Infrastructure. CC ID 07084
    [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. 5.1 ¶ 1]
    Technical Security Preventive
    Establish, implement, and maintain Public Key certificate procedures. CC ID 07085
    [{applicable requirements} 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 be operated by departments and agencies or be outsourced to PKI service providers. For a list of PKI service providers that have been approved to operate under [COMMON], see https://www.idmanagement.gov. 5.2 ¶ 1
    CAs that issue certificates corresponding to PIV private keys (i.e., PIV authentication, card authentication, digital signature, or key management certificates) SHALL maintain an HTTP-accessible service that publishes any CA certificates issued to it, as specified in [PROF]; and 5.5 ¶ 1 Bullet 2
    operate Online Certificate Status Protocol (OCSP, specified in [RFC 6960]) services for the PIV certificates that it issues, as specified in [PROF]. 5.5 ¶ 1 Bullet 3
    PIV authentication, card authentication, digital signature, and key management certificates SHALL contain the authorityInfoAccess extension needed to locate the authoritative OCSP responder. 5.5 ¶ 2 Bullet 2
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7
    Certificates containing the public key associated with a key management private key SHALL conform to the Key Management Certificate Profile in [PROF] and SHALL specify the id-fpki-common-policy or id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.5), except as provided below. 5.2.1 ¶ 1 Bullet 4
    Certificates containing the public key associated with a key management private key SHALL conform to the Key Management Certificate Profile in [PROF] and SHALL specify the id-fpki-common-policy or id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.5), except as provided below. 5.2.1 ¶ 1 Bullet 4
    The public key required to verify the digital signature SHALL be in a content signing certificate, which SHALL be issued under the id-fpki-common-piv-contentSigning policy of [COMMON] and SHALL include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. The signature on the biometric data record SHOULD be generated with the same signing key as the signature on the CHUID data object. The public key required to verify the digital signature is contained in the CHUID data object’s content signing certificate33 as detailed in Section 4.2.1. 4.2.3.2 ¶ 4
    The public key required to verify the digital signature SHALL be in a content signing certificate, which SHALL be issued under the id-fpki-common-piv-contentSigning policy of [COMMON] and SHALL include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. The signature on the biometric data record SHOULD be generated with the same signing key as the signature on the CHUID data object. The public key required to verify the digital signature is contained in the CHUID data object’s content signing certificate33 as detailed in Section 4.2.1. 4.2.3.2 ¶ 4
    Certificates that contain the public key associated with a PIV authentication private key SHALL conform to the PIV Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-authentication policy of [COMMON] in the certificate policies extension (Section 4.2.2.1). 5.2.1 ¶ 1 Bullet 1
    Certificates that contain the public key associated with a PIV authentication private key SHALL conform to the PIV Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-authentication policy of [COMMON] in the certificate policies extension (Section 4.2.2.1). 5.2.1 ¶ 1 Bullet 1
    Certificates that contain the public key associated with a digital signature private key SHALL conform to the End Entity Signature Certificate Profile in [PROF] and SHALL specify the id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.4), except as provided below. 5.2.1 ¶ 1 Bullet 3
    Certificates that contain the public key associated with a digital signature private key SHALL conform to the End Entity Signature Certificate Profile in [PROF] and SHALL specify the id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.4), except as provided below. 5.2.1 ¶ 1 Bullet 3
    {asymmetric card authentication key} Certificates that contain the public key associated with an asymmetric card authentication private key SHALL conform to the Card Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-cardAuth policy of [COMMON] in the certificate policies extension (Section 4.2.2.2). 5.2.1 ¶ 1 Bullet 2
    {asymmetric card authentication key} Certificates that contain the public key associated with an asymmetric card authentication private key SHALL conform to the Card Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-cardAuth policy of [COMMON] in the certificate policies extension (Section 4.2.2.2). 5.2.1 ¶ 1 Bullet 2
    {applicable requirements} CA certificates SHALL conform to [COMMON]. 5.1 ¶ 2
    Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.3.2 ¶ 6]
    Establish/Maintain Documentation Preventive
    Include signing and issuing Public Key certificates in the Public Key certificate procedures. CC ID 11817
    [{electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7]
    Establish/Maintain Documentation Preventive
    Include publishing Public Key certificates in the Public Key certificate procedures. CC ID 07087 Establish/Maintain Documentation Preventive
    Include access to issued Public Key certificates in the Public Key certificate procedures. CC ID 07086
    [Certificates that contain the FASC-N or card UUID in the SAN extension, such as PIV authentication certificates and card authentication certificates, SHALL NOT be distributed publicly (e.g., via HTTP accessible from the public internet). Individual departments and agencies can decide whether digital signature and key management certificates can be distributed publicly by the CA. 5.5.1 ¶ 2
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7]
    Establish/Maintain Documentation Preventive
    Connect the Public Key Infrastructure to the organization's identity and access management system. CC ID 07091 Technical Security Preventive
    Archive Public Key certificate records according to organizational Records Management rules. CC ID 07090 Records Management Preventive
    Use strong data encryption to transmit in scope data or in scope information, as necessary. CC ID 00564 Technical Security Preventive
    Configure the encryption strength to be appropriate for the encryption methodology of the cryptographic controls. CC ID 12492
    [{be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1]
    Technical Security Preventive
    Establish, implement, and maintain a malicious code protection program. CC ID 00574
    [{do not introduce} The following forms of protection SHALL be provided by either inherent capabilities of the station or staff at the station location: ensuring that no malicious code is introduced to compromise or otherwise impair the station and the PIV Card; and 2.7.1 ¶ 3 Bullet 3]
    Establish/Maintain Documentation Preventive
    Disseminate and communicate the malicious code protection policy to all interested personnel and affected parties. CC ID 15485 Communicate Preventive
    Disseminate and communicate the malicious code protection procedures to all interested personnel and affected parties. CC ID 15484 Communicate Preventive
    Establish, implement, and maintain malicious code protection procedures. CC ID 15483 Establish/Maintain Documentation Preventive
    Establish, implement, and maintain a malicious code protection policy. CC ID 15478 Establish/Maintain Documentation Preventive
    Restrict downloading to reduce malicious code attacks. CC ID 04576 Behavior Preventive
    Install security and protection software, as necessary. CC ID 00575 Configuration Preventive
    Install and maintain container security solutions. CC ID 16178 Technical Security Preventive
    Scan for malicious code, as necessary. CC ID 11941 Investigate Detective
    Test all removable storage media for viruses and malicious code. CC ID 11861 Testing Detective
    Test all untrusted files or unverified files for viruses and malicious code. CC ID 01311 Testing Detective
    Remove malware when malicious code is discovered. CC ID 13691 Process or Activity Corrective
    Notify interested personnel and affected parties when malware is detected. CC ID 13689 Communicate Corrective
    Protect the system against replay attacks. CC ID 04552 Technical Security Preventive
    Define and assign roles and responsibilities for malicious code protection. CC ID 15474 Establish Roles Preventive
    Establish, implement, and maintain a malicious code outbreak recovery plan. CC ID 01310 Establish/Maintain Documentation Corrective
    Log and react to all malicious code activity. CC ID 07072 Monitor and Evaluate Occurrences Detective
    Analyze the behavior and characteristics of the malicious code. CC ID 10672 Technical Security Detective
    Incorporate the malicious code analysis into the patch management program. CC ID 10673 Technical Security Corrective
    Lock antivirus configurations. CC ID 10047 Configuration Preventive
  • Third Party and supply chain oversight
    30
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular TYPE CLASS
    Third Party and supply chain oversight CC ID 08807 IT Impact Zone IT Impact Zone
    Establish, implement, and maintain anti-counterfeit measures. CC ID 11522
    [{PIV Card}{anti-counterfeiting technique} All security features SHOULD maintain their function for the life of the card. As a generally accepted security procedure, federal departments and agencies SHOULD periodically review the viability, effectiveness, and currency of employed tamper resistance and anti-counterfeiting methods. 4.1.2 ¶ 10]
    Technical Security Preventive
    Establish, implement, and maintain electronic marketplace terms of service guidelines. CC ID 11523 Technical Security Preventive
    Include the prohibition of counterfeiting in the electronic marketplace terms of service guidelines. CC ID 11524 Technical Security Preventive
    Enforce the electronic marketplace terms of service guidelines. CC ID 11525 Technical Security Preventive
    Post anti-counterfeiting warnings within the electronic marketplace. CC ID 11526 Technical Security Preventive
    Establish, implement, and maintain a counterfeit product reporting system. CC ID 11527 Technical Security Preventive
    Include required information in the counterfeit product report. CC ID 11518 Business Processes Corrective
    Include evidence that the counterfeit product was purchased in the counterfeit product report. CC ID 11519 Business Processes Corrective
    Include evidence of what was counterfeited in the counterfeit product report. CC ID 11529 Business Processes Corrective
    Include damages caused by counterfeiting in the counterfeit product report. CC ID 11530 Business Processes Corrective
    Include suggested remediation steps in the counterfeit product report. CC ID 11531 Business Processes Corrective
    Disseminate and communicate ethics complaint reports to interested personnel and affected parties. CC ID 11521 Business Processes Corrective
    Include response times in ethics complaint reports. CC ID 11520 Business Processes Corrective
    Respond to counterfeit product reports. CC ID 11528 Technical Security Preventive
    Establish, implement, and maintain a trademark infringement reporting system. CC ID 11532 Technical Security Preventive
    Allow anti-counterfeit testing of products. CC ID 11533 Technical Security Preventive
    Categorize product information for anti-counterfeit testing to be either for a general audience or restricted audience. CC ID 11534 Technical Security Preventive
    Include static characteristics of product information in anti-counterfeit testing. CC ID 11543 Technical Security Preventive
    Include usage conditions of product information in anti-counterfeit testing. CC ID 11544 Technical Security Preventive
    Include health impacts of product information in anti-counterfeit testing. CC ID 11545 Technical Security Preventive
    Include environmental impacts of product information in anti-counterfeit testing. CC ID 11617 Physical and Environmental Protection Preventive
    Include feature-linked physical characteristics of product information in anti-counterfeit testing. CC ID 11546 Technical Security Preventive
    Allow anti-counterfeit testing to use either authentication tools or human senses. CC ID 11535 Technical Security Preventive
    Establish and maintain anti-counterfeit test authentication elements. CC ID 11542 Technical Security Preventive
    Allow either online anti-counterfeit authentication tools or stand-alone anti-counterfeit authentication tools for anti-counterfeit testing. CC ID 11536 Technical Security Preventive
    Allow either bespoke anti-counterfeit authentication tools or commercial off-the-shelf anti-counterfeit authentication tools for anti-counterfeit testing. CC ID 11537 Technical Security Preventive
    Use overt authentication elements when using human senses for anti-counterfeit testing. CC ID 11538 Technical Security Preventive
    Disallow covert authentication elements when using human senses for anti-counterfeit testing. CC ID 11539 Technical Security Preventive
    Review the performance criteria of anti-counterfeit testing authentication tools. CC ID 11541 Technical Security Preventive
Common Controls and
mandates by Type
118 Mandated Controls - bold    
83 Implied Controls - italic     457 Implementation

Each Common Control is assigned a meta-data type to help you determine the objective of the Control and associated Authority Document mandates aligned with it. These types include behavioral controls, process controls, records management, technical security, configuration management, etc. They are provided as another tool to dissect the Authority Document’s mandates and assign them effectively within your organization.

Number of Controls
658 Total
  • Behavior
    34
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Establish, implement, and maintain a testing program. CC ID 00654 Monitoring and measurement Preventive
    Carry out disciplinary actions when a compliance violation is detected. CC ID 06675 Monitoring and measurement Corrective
    Restrict downloading to reduce malicious code attacks. CC ID 04576 Technical security Preventive
    Train all personnel and third parties, as necessary. CC ID 00785 Human Resources management Preventive
    Grant registration after competence and integrity is verified. CC ID 16802 Operational management Detective
    Notify affected parties to keep authenticators confidential. CC ID 06787 System hardening through configuration management Preventive
    Discourage affected parties from recording authenticators. CC ID 06788 System hardening through configuration management Preventive
    Notify the data subject of the collection purpose. CC ID 00095
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Provide PIV applicants with full disclosure of the intended uses of the information associated with the PIV Card and the related privacy implications. 2.11 ¶ 3 Bullet 4
    {parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Preventive
    Refrain from requiring a Personal Identification Number to purchase goods or services. CC ID 00069 Privacy protection for information and data Preventive
    Define the behaviors and actions that are included in privacy rights violations. CC ID 14852 Privacy protection for information and data Preventive
    Provide assistance to data subjects for filing privacy rights violation complaints. CC ID 00478 Privacy protection for information and data Corrective
    File privacy rights violation complaints inside the mandate stipulated from the refusal. CC ID 00479 Privacy protection for information and data Corrective
    Notify the data subject of changes made to personal data as the result of a dispute. CC ID 00463 Privacy protection for information and data Corrective
    Notify the data subject of which and why disputed changes were not made to personal data. CC ID 00466 Privacy protection for information and data Corrective
    Notify entities to whom personal data was transferred that the personal data is wrong, along with the corrections. CC ID 00467 Privacy protection for information and data Corrective
    Investigate privacy rights violation complaints. CC ID 00480 Privacy protection for information and data Detective
    Notify respondents after a privacy rights violation complaint investigation begins. CC ID 00491 Privacy protection for information and data Detective
    Investigate privacy rights violation complaints in private. CC ID 00492 Privacy protection for information and data Detective
    Make appropriate inquiries and obtain appropriate information regarding privacy rights violation complaints. CC ID 00493 Privacy protection for information and data Detective
    Allow the complainant to appear before the commissioner and make a submission, orally or in writing, about the privacy rights violation complaint investigation prior to an adverse decision to the complainant is reached. CC ID 00494 Privacy protection for information and data Detective
    Refer privacy rights violation complaints to the Privacy Commissioner under certain conditions. CC ID 00481 Privacy protection for information and data Preventive
    Determine not to investigate privacy rights violation complaints under certain conditions. CC ID 00482 Privacy protection for information and data Preventive
    Refrain from investigating a privacy rights violation complaint when the act or practice does not interfere with an individual's privacy. CC ID 00483 Privacy protection for information and data Preventive
    Refrain from investigating a privacy rights violation complaint when the complaint is created outside the stipulated time frame after the complainant became aware of it. CC ID 00484 Privacy protection for information and data Preventive
    Refrain from investigating a privacy rights violation complaint when the complaint is frivolous, vexatious, misconceived, or lacking in substance. CC ID 00485 Privacy protection for information and data Preventive
    Refrain from investigating a privacy rights violation complaint if the act or practice is subject to an application under another commonwealth law, state law, or territory law, and the complaint was or is being dealt with adequately under the law. CC ID 00486 Privacy protection for information and data Preventive
    Defer privacy rights violation complaint investigations under certain conditions. CC ID 00487 Privacy protection for information and data Preventive
    Defer privacy rights violation complaint investigations when the respondent has made an application for a determination. CC ID 00488 Privacy protection for information and data Preventive
    Defer privacy rights violation complaint investigations when the Privacy Commissioner believes the data subject's interests would not be affected if the investigation or further investigation were deferred until the application was disposed of. CC ID 00489 Privacy protection for information and data Preventive
    Respond to an investigative report in regards to a privacy rights violation complaint. CC ID 00496 Privacy protection for information and data Corrective
    Order the organization to change to be in compliance with applicable law. CC ID 00499 Privacy protection for information and data Corrective
    Order the organization to publish a notice with the corrections or actions taken. CC ID 00500 Privacy protection for information and data Corrective
    Award damages based on applicable law. CC ID 00501 Privacy protection for information and data Corrective
    Notify the public and other agencies after a penalty becomes final. CC ID 06217 Privacy protection for information and data Preventive
  • Business Processes
    18
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Establish, implement, and maintain a reporting methodology program. CC ID 02072 Leadership and high level objectives Preventive
    Align enforcement reviews for non-compliance with organizational risk tolerance. CC ID 13063 Monitoring and measurement Detective
    Allow biometric authentication for proof of identity during the identity proofing process. CC ID 13797 Technical security Detective
    Include an appeal process in the identification issuance procedures. CC ID 15428
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Maintain appeal procedures for those who are denied a credential or whose credentials are revoked. 2.11 ¶ 3 Bullet 6]
    Physical and environmental protection Preventive
    Write functional requirements for new systems to meet the disability accessibility standards. CC ID 06198 Operational management Preventive
    Impose conditions or restrictions on the termination or suspension of a registration. CC ID 16796 Operational management Preventive
    Change the authenticator for shared accounts when the group membership changes. CC ID 14249 System hardening through configuration management Corrective
    Refrain from processing personal data for marketing or advertising to children. CC ID 14010 Privacy protection for information and data Preventive
    Include the type of information to be collected in the privacy impact assessment. CC ID 15513 Privacy protection for information and data Preventive
    Refrain from charging a fee to file a privacy rights violation complaint. CC ID 16807 Privacy protection for information and data Preventive
    Cooperate with authorities during a privacy rights violation complaint investigation. CC ID 14364 Privacy protection for information and data Corrective
    Include required information in the counterfeit product report. CC ID 11518 Third Party and supply chain oversight Corrective
    Include evidence that the counterfeit product was purchased in the counterfeit product report. CC ID 11519 Third Party and supply chain oversight Corrective
    Include evidence of what was counterfeited in the counterfeit product report. CC ID 11529 Third Party and supply chain oversight Corrective
    Include damages caused by counterfeiting in the counterfeit product report. CC ID 11530 Third Party and supply chain oversight Corrective
    Include suggested remediation steps in the counterfeit product report. CC ID 11531 Third Party and supply chain oversight Corrective
    Disseminate and communicate ethics complaint reports to interested personnel and affected parties. CC ID 11521 Third Party and supply chain oversight Corrective
    Include response times in ethics complaint reports. CC ID 11520 Third Party and supply chain oversight Corrective
  • Communicate
    22
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Disseminate and communicate the disciplinary action notice to interested personnel and affected parties. CC ID 16585 Monitoring and measurement Preventive
    Notify the user when an authentication is attempted using an expired authenticator. CC ID 13818
    [A derived PIV credential SHALL NOT be accepted for authentication once the credential has been invalidated. When invalidation occurs, the issuer SHALL notify the cardholder of the change. 2.10.2 ¶ 3]
    Technical security Corrective
    Notify interested personnel when user accounts are added or deleted. CC ID 14327 Technical security Detective
    Disseminate and communicate the access control log to interested personnel and affected parties. CC ID 16442 Technical security Preventive
    Disseminate and communicate the access control procedures to all interested personnel and affected parties. CC ID 14123 Technical security Corrective
    Disseminate and communicate the identification and authentication procedures to interested personnel and affected parties. CC ID 14223 Technical security Preventive
    Notify a user when an authenticator for a user account is changed. CC ID 13820 Technical security Preventive
    Disseminate and communicate the malicious code protection policy to all interested personnel and affected parties. CC ID 15485 Technical security Preventive
    Disseminate and communicate the malicious code protection procedures to all interested personnel and affected parties. CC ID 15484 Technical security Preventive
    Notify interested personnel and affected parties when malware is detected. CC ID 13689 Technical security Corrective
    Disseminate and communicate screening results to interested personnel and affected parties. CC ID 16445 Human Resources management Preventive
    Advise users on how to navigate content. CC ID 15138 Operational management Preventive
    Make the registration database available to the public. CC ID 15107 Operational management Preventive
    Disseminate and communicate with the end user when a memorized secret entered into an authenticator field matches one found in the memorized secret list. CC ID 13807 System hardening through configuration management Preventive
    Notify the subject of care when a lack of availability of health information systems might have adversely affected their care. CC ID 13990 Privacy protection for information and data Corrective
    Refrain from disseminating and communicating with individuals that have opted out of direct marketing communications. CC ID 13708 Privacy protection for information and data Corrective
    Capture personal data removal requests. CC ID 13507 Privacy protection for information and data Preventive
    Disseminate and communicate the results of the Privacy Impact Assessment to interested personnel and affected parties. CC ID 15458 Privacy protection for information and data Preventive
    Notify third parties of unresolved challenges. CC ID 13559 Privacy protection for information and data Preventive
    Notify respondents after a privacy rights violation complaint investigation has been resolved. CC ID 13513 Privacy protection for information and data Corrective
    Disseminate and communicate instructions for the appeal process to interested personnel and affected parties. CC ID 16544 Privacy protection for information and data Preventive
    Disseminate and communicate a written explanation of the reasons for appeal decisions to interested personnel and affected parties. CC ID 16542 Privacy protection for information and data Preventive
  • Configuration
    115
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Require digital authentication of evidence by integrated scanners when performing remote proofing. CC ID 13805
    [Supervised remote identity proofing SHALL meet the following requirements: The operator SHALL validate the physical or cryptographic security features of primary and secondary identity source documents using scanners and sensors that are integrated into the station. 2.7.1 ¶ 4 Bullet 6]
    Technical security Preventive
    Require a minimum number of knowledge-based authentication questions for the identity proofing process. CC ID 13745 Technical security Preventive
    Require free-form response knowledge-based authentication questions for the identity proofing process. CC ID 13746 Technical security Preventive
    Set a maximum number of attempts to complete the knowledge-based authentication for the identity proofing process. CC ID 13747 Technical security Preventive
    Configure the lockout procedure to disregard failed logon attempts after the user is authenticated. CC ID 13822 Technical security Preventive
    Grant access to authorized personnel or systems. CC ID 12186
    [{is not issued} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that No credential is issued unless requested by the proper authority. 2.1 ¶ 2 Bullet 7
    To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that only personnel with a legitimate need for access to PII in the PIV system are authorized to access the PII, including but not limited to information and databases maintained for registration and credential issuance. 2.11 ¶ 3 Bullet 7]
    Technical security Preventive
    Assign authenticators to user accounts. CC ID 06855 Technical security Preventive
    Assign authentication mechanisms for user account authentication. CC ID 06856 Technical security Preventive
    Limit account credential reuse as a part of digital identification procedures. CC ID 12357
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that An issued credential is not duplicated or forged. 2.1 ¶ 2 Bullet 11]
    Technical security Preventive
    Tune the biometric identification equipment, as necessary. CC ID 07077 Technical security Corrective
    Install security and protection software, as necessary. CC ID 00575 Technical security Preventive
    Lock antivirus configurations. CC ID 10047 Technical security Preventive
    Configure focus order in a meaningful way. CC ID 15206 Operational management Preventive
    Configure keyboard interfaces to provide all the functionality that is available for the associated website content. CC ID 15151 Operational management Preventive
    Programmatically set the states, properties, and values of user interface components. CC ID 15150 Operational management Preventive
    Notify users of changes to user interface components. CC ID 15149 Operational management Preventive
    Refrain from designing content in a way that is known to cause seizures or physical reactions. CC ID 15203 Operational management Preventive
    Configure content to be compatible with various user agents and assistive technologies. CC ID 15147 Operational management Preventive
    Configure content to be interpreted by various user agents and assistive technologies. CC ID 15146 Operational management Preventive
    Provide captions for prerecorded audio content. CC ID 15204 Operational management Preventive
    Ensure user interface component names include the same text that is presented visually. CC ID 15145 Operational management Preventive
    Configure user interface components to operate device motion and user motion functionality. CC ID 15144 Operational management Preventive
    Configure single pointer functionality to organizational standards. CC ID 15143 Operational management Preventive
    Configure the keyboard operable user interface so the keyboard focus indicator is visible. CC ID 15142 Operational management Preventive
    Provide users the ability to disable user motion and device motion. CC ID 15205 Operational management Preventive
    Refrain from duplicating attributes in website content using markup languages. CC ID 15141 Operational management Preventive
    Use unique identifiers when using markup languages. CC ID 15140 Operational management Preventive
    Programmatically determine the status messages to convey to users. CC ID 15139 Operational management Preventive
    Allow users the ability to move focus with the keyboard. CC ID 15136 Operational management Preventive
    Avoid using images of text to convey information. CC ID 15202 Operational management Preventive
    Allow users to pause, stop, or hide moving, blinking or scrolling information. CC ID 15135 Operational management Preventive
    Display website content without loss of information or functionality and without requiring scrolling in two dimensions. CC ID 15134 Operational management Preventive
    Use images of text to convey information, as necessary. CC ID 15132 Operational management Preventive
    Refrain from using color as the only visual means to distinguish content. CC ID 15130 Operational management Preventive
    Refrain from restricting content to a single display orientation. CC ID 15129 Operational management Preventive
    Use text to convey information on web pages, as necessary. CC ID 15128 Operational management Preventive
    Configure the contrast ratio to organizational standards. CC ID 15127 Operational management Preventive
    Programmatically determine the correct reading sequence. CC ID 15126 Operational management Preventive
    Programmatically determine the information, structure, and relationships conveyed through the presentation. CC ID 15123 Operational management Preventive
    Provide audio descriptions for all prerecorded video content. CC ID 15122 Operational management Preventive
    Provide alternative forms of CAPTCHA, as necessary. CC ID 15121 Operational management Preventive
    Provide alternatives for time-based media. CC ID 15119 Operational management Preventive
    Configure non-text content to be ignored by assistive technology when it is pure decoration or not presented to users. CC ID 15118 Operational management Preventive
    Configure non-text content with a descriptive identification. CC ID 15117 Operational management Preventive
    Provide text alternatives for non-text content, as necessary. CC ID 15078 Operational management Preventive
    Implement functionality for a single pointer so an up-event reverses the outcome of a down-event. CC ID 15076 Operational management Preventive
    Implement functionality for a single pointer so the completion of a down-event is essential. CC ID 15075 Operational management Preventive
    Implement functionality to abort or undo the function when using a single pointer. CC ID 15074 Operational management Preventive
    Implement functionality for a single pointer so the up-event signals the completion of a function. CC ID 15073 Operational management Preventive
    Implement functionality for a single pointer so the down-event is not used to execute any part of a function. CC ID 15072 Operational management Preventive
    Allow users the ability to use various input devices. CC ID 15071 Operational management Preventive
    Implement mechanisms to allow users the ability to bypass repeated blocks of website content. CC ID 15068 Operational management Preventive
    Implement flashes below the general flash and red flash thresholds on web pages. CC ID 15067 Operational management Preventive
    Configure content to be presentable in a manner that is clear and conspicuous to all users. CC ID 15066 Operational management Preventive
    Configure non-text content that is a control or accepts user input with a name that describes its purpose. CC ID 15065 Operational management Preventive
    Allow users the ability to modify time limits in website content a defined number of times. CC ID 15064 Operational management Preventive
    Provide users with a simple method to extend the time limits set by content. CC ID 15063 Operational management Preventive
    Allow users the ability to disable time limits set by content. CC ID 15062 Operational management Preventive
    Warn users before time limits set by content are about to expire. CC ID 15061 Operational management Preventive
    Allow users the ability to modify time limits set by website or native applications. CC ID 15060 Operational management Preventive
    Provide users time to read and use website content, as necessary. CC ID 15059 Operational management Preventive
    Activate keyboard shortcuts on user interface components only when the appropriate component has focus. CC ID 15058 Operational management Preventive
    Provide users a mechanism to turn off keyboard shortcuts, as necessary. CC ID 15057 Operational management Preventive
    Configure all functionality to be accessible with a keyboard. CC ID 15056 Operational management Preventive
    Configure authenticators to comply with organizational standards. CC ID 06412 System hardening through configuration management Preventive
    Configure the system to require new users to change their authenticator on first use. CC ID 05268 System hardening through configuration management Preventive
    Configure authenticators so that group authenticators or shared authenticators are prohibited. CC ID 00519 System hardening through configuration management Preventive
    Configure the system to prevent unencrypted authenticator use. CC ID 04457 System hardening through configuration management Preventive
    Disable store passwords using reversible encryption. CC ID 01708 System hardening through configuration management Preventive
    Configure the system to encrypt authenticators. CC ID 06735 System hardening through configuration management Preventive
    Configure the system to mask authenticators. CC ID 02037 System hardening through configuration management Preventive
    Configure the authenticator policy to ban the use of usernames or user identifiers in authenticators. CC ID 05992 System hardening through configuration management Preventive
    Configure the system to refrain from specifying the type of information used as password hints. CC ID 13783 System hardening through configuration management Preventive
    Disable machine account password changes. CC ID 01737 System hardening through configuration management Preventive
    Configure the "Disable Remember Password" setting. CC ID 05270 System hardening through configuration management Preventive
    Configure the "Minimum password age" to organizational standards. CC ID 01703 System hardening through configuration management Preventive
    Configure the LILO/GRUB password. CC ID 01576 System hardening through configuration management Preventive
    Configure the system to use Apple's Keychain Access to store passwords and certificates. CC ID 04481 System hardening through configuration management Preventive
    Change the default password to Apple's Keychain. CC ID 04482 System hardening through configuration management Preventive
    Configure Apple's Keychain items to ask for the Keychain password. CC ID 04483 System hardening through configuration management Preventive
    Configure the Syskey Encryption Key and associated password. CC ID 05978 System hardening through configuration management Preventive
    Configure the "Accounts: Limit local account use of blank passwords to console logon only" setting. CC ID 04505 System hardening through configuration management Preventive
    Configure the "System cryptography: Force strong key protection for user keys stored in the computer" setting. CC ID 04534 System hardening through configuration management Preventive
    Configure interactive logon for accounts that do not have assigned authenticators in accordance with organizational standards. CC ID 05267 System hardening through configuration management Preventive
    Enable or disable remote connections from accounts with empty authenticators, as appropriate. CC ID 05269 System hardening through configuration management Preventive
    Configure the "Send LanMan compatible password" setting. CC ID 05271 System hardening through configuration management Preventive
    Configure the authenticator policy to ban or allow authenticators as words found in dictionaries, as appropriate. CC ID 05993 System hardening through configuration management Preventive
    Set the most number of characters required for the BitLocker Startup PIN correctly. CC ID 06054 System hardening through configuration management Preventive
    Set the default folder for BitLocker recovery passwords correctly. CC ID 06055 System hardening through configuration management Preventive
    Configure the "Disable password strength validation for Peer Grouping" setting to organizational standards. CC ID 10866 System hardening through configuration management Preventive
    Configure the "Set the interval between synchronization retries for Password Synchronization" setting to organizational standards. CC ID 11185 System hardening through configuration management Preventive
    Configure the "Set the number of synchronization retries for servers running Password Synchronization" setting to organizational standards. CC ID 11187 System hardening through configuration management Preventive
    Configure the "Turn off password security in Input Panel" setting to organizational standards. CC ID 11296 System hardening through configuration management Preventive
    Configure the "Turn on the Windows to NIS password synchronization for users that have been migrated to Active Directory" setting to organizational standards. CC ID 11355 System hardening through configuration management Preventive
    Configure the authenticator display screen to organizational standards. CC ID 13794 System hardening through configuration management Preventive
    Configure the authenticator field to disallow memorized secrets found in the memorized secret list. CC ID 13808 System hardening through configuration management Preventive
    Configure the authenticator display screen to display the memorized secret as an option. CC ID 13806 System hardening through configuration management Preventive
    Configure the look-up secret authenticator to dispose of memorized secrets after their use. CC ID 13817 System hardening through configuration management Corrective
    Configure the memorized secret verifiers to refrain from allowing anonymous users to access memorized secret hints. CC ID 13823 System hardening through configuration management Preventive
    Configure the system to allow paste functionality for the authenticator field. CC ID 13819 System hardening through configuration management Preventive
    Configure the system to require successful authentication before an authenticator for a user account is changed. CC ID 13821 System hardening through configuration management Preventive
    Configure Microsoft Office to Organizational Standards. CC ID 07147 System hardening through configuration management Preventive
    Configure Microsoft Outlook settings for Microsoft Office in accordance with organizational standards. CC ID 07341 System hardening through configuration management Preventive
    Configure the "Retrieving CRLs (Certificate Revocation Lists)" to organizational standards. CC ID 07417
    [PIV authentication, card authentication, digital signature, and key management certificates SHALL contain the crlDistributionPoints extension needed to locate CRLs, and 5.5 ¶ 2 Bullet 1]
    System hardening through configuration management Preventive
    Configure Logging settings in accordance with organizational standards. CC ID 07611 System hardening through configuration management Preventive
    Configure all logs to capture auditable events or actionable events. CC ID 06332 System hardening through configuration management Preventive
    Configure the log to capture configuration changes. CC ID 06881 System hardening through configuration management Preventive
    Configure the log to capture all changes to certificates. CC ID 05595
    [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. 5.5.2 ¶ 1]
    System hardening through configuration management Preventive
    Configure Key, Certificate, Password, Authentication and Identity Management settings in accordance with organizational standards. CC ID 07621 System hardening through configuration management Preventive
    Configure "client certificate authentication" to organizational standards. CC ID 14608
    [The relying system validates the PIV authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.1 ¶ 1 Bullet 2]
    System hardening through configuration management Preventive
    Configure the "Password must meet complexity requirements" to organizational standards. CC ID 07743
    [{be unguessable}{not be identifiable}{be unique} The cardholder SHALL be guided in selecting a strong PIN value. The PIN SHALL be a minimum of six digits in length and SHOULD NOT be easily guessable, individually identifiable (e.g., part of a Social Security Number or phone number), or commonly used (e.g., 000000, 123456). 4.3.1 ¶ 2
    {be unguessable}{not be identifiable}{be unique} The cardholder SHALL be guided in selecting a strong PIN value. The PIN SHALL be a minimum of six digits in length and SHOULD NOT be easily guessable, individually identifiable (e.g., part of a Social Security Number or phone number), or commonly used (e.g., 000000, 123456). 4.3.1 ¶ 2]
    System hardening through configuration management Preventive
    Configure the "Check for server certificate revocation" to organizational standards. CC ID 08120
    [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. 5.5.2 ¶ 1]
    System hardening through configuration management Preventive
    Configure the "Allow the use of biometrics" to organizational standards. CC ID 08435
    [{refrain from exceeding} Previously collected biometric data MAY be reused with the new PIV Card if the expiration date of the new PIV Card is no later than 12 years after the date that the biometric data was obtained. As biometric system error rates generally increase with the time elapsed since initial collection (reference aging, [ISO 2382-37]), issuers MAY refresh biometric data in the PIV enrollment record during the re-issuance process. Even if the same biometric data is reused with the new PIV Card, the digital signature must be recomputed with the new FASC-N and card UUID. 2.9.1 ¶ 7]
    System hardening through configuration management Preventive
    Configure the "Number of attempts allowed" to organizational standards. CC ID 08569
    [{maximum number of attempts} The PIN on a PIV Card may need to be reset if the cardholder has forgotten the PIN or if PIN-based cardholder authentication has been disabled by the usage of an invalid PIN more than the allowed number of retries. Fingers might need to be re-enrolled for OCC if the cardholder has experienced epidermal scarring or similar physical changes, resulting in false negative biometric verification decisions, or if OCC has been disabled by exceeding the allowed number of negative biometric verification decisions. No more than 10 consecutive activation retries for each of the activation methods (i.e., PIN and OCC attempts) SHALL be permitted. Card issuers MAY further restrict the maximum retry limit to a lower value. 2.9.3 ¶ 2
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1]
    System hardening through configuration management Preventive
    Terminate an individual's restriction agreement under specific circumstances. CC ID 06260 Privacy protection for information and data Preventive
  • Data and Information Management
    84
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Include the date and time that access was reviewed in the system record. CC ID 16416 Technical security Preventive
    Disseminate and communicate user identifiers and authenticators using secure communication protocols. CC ID 06791
    [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 to a website or other server), the input device is not required to be integrated with the PIV Card reader. If the input device is not integrated with the PIV Card reader, the PIN or OCC data SHALL be transmitted securely and directly to the PIV Card for card activation. 4.4.4 ¶ 1]
    Technical security Preventive
    Protect data from modification or loss while transmitting between separate parts of the system. CC ID 04554
    [{data in transit}{data at rest} PIV enrollment records contain Personally Identifiable Information (PII). PII SHALL be protected in a manner that protects the individual’s privacy and maintains the integrity of the records both in transit and at rest. 2.6 ¶ 5]
    Technical security Preventive
    Establish, implement, and maintain digital signatures. CC ID 13828
    [{refrain from exceeding} Previously collected biometric data MAY be reused with the new PIV Card if the expiration date of the new PIV Card is no later than 12 years after the date that the biometric data was obtained. As biometric system error rates generally increase with the time elapsed since initial collection (reference aging, [ISO 2382-37]), issuers MAY refresh biometric data in the PIV enrollment record during the re-issuance process. Even if the same biometric data is reused with the new PIV Card, the digital signature must be recomputed with the new FASC-N and card UUID. 2.9.1 ¶ 7
    The public key required to verify the digital signature SHALL be in a content signing certificate, which SHALL be issued under the id-fpki-common-piv-contentSigning policy of [COMMON] and SHALL include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. The signature on the biometric data record SHOULD be generated with the same signing key as the signature on the CHUID data object. The public key required to verify the digital signature is contained in the CHUID data object’s content signing certificate33 as detailed in Section 4.2.1. 4.2.3.2 ¶ 4]
    Technical security Preventive
    Include the expiration date in digital signatures. CC ID 13833 Technical security Preventive
    Include audience restrictions in digital signatures. CC ID 13834 Technical security Preventive
    Include the subject in digital signatures. CC ID 13832 Technical security Preventive
    Include the issuer in digital signatures. CC ID 13831 Technical security Preventive
    Include identifiers in the digital signature. CC ID 13829 Technical security Preventive
    Establish, implement, and maintain a registration database. CC ID 15048
    [{PIV enrollment records} The card issuer SHALL maintain the enrollment record for each issued ground-color:#CBD0E5;" class="term_secondary-verb">PIV Card. These enrollment records are created and maintained through the methods of contemporaneous acquisition at each step of the PIV issuance process—typically including identity proofing, registration, and biometric enrollment. 2.6 ¶ 1
    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-PKI derived PIV credentials are not required to be updated or reissued in these situations. 2.10.3 ¶ 1
    {PIV enrollment records} The card issuer SHALL maintain the enrollment record for each issued ground-color:#CBD0E5;" class="term_secondary-verb">PIV Card. These enrollment records are created and maintained through the methods of contemporaneous acquisition at each step of the PIV issuance process—typically including identity proofing, registration, and biometric enrollment. 2.6 ¶ 1
    The requirements for identity proofing and registration also apply to citizens of foreign countries who are working for the U.S. Federal Government overseas. However, a process for identity proofing and registration SHALL be established using a method approved by the U.S. Department of State's Bureau of Diplomatic Security, except for employees under the command of a U.S. area military commander. These procedures vary depending on the country. The requirements for identity proofing and registration also apply to citizens of foreign countries who are working for the U.S. Federal Government overseas. However, a process for identity proofing and registration SHALL be established using a method approved by the U.S. Department of State's Bureau of Diplomatic Security, except for employees under the command of a U.S. area military commander. These procedures vary depending on the country. 2.7 ¶ 12]
    Operational management Preventive
    Publish the IP addresses being used by each external customer in the registration database. CC ID 16403 Operational management Preventive
    Maintain the accuracy of registry information published in registration databases. CC ID 16402 Operational management Preventive
    Include all required information in the registration database. CC ID 15106
    [{individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    PIV enrollment records SHOULD include the following data: Unique identifiers issued to the individual, such as the Federal Agency Smart Credential Number (FASC-N), the cardholder Universally Unique Identifier (UUID), and the card UUID. The record MAY contain historical unique identifiers. 2.6 ¶ 3 Bullet 3
    PIV enrollment records SHOULD include the following data: Information about the authorizing entity that has approved the issuance of a credential. 2.6 ¶ 3 Bullet 4
    PIV enrollment records SHOULD include the following data: Current status of the background investigation, including the results of the investigation once completed. 2.6 ¶ 3 Bullet 5
    PIV enrollment records SHOULD include the following data: Current status of the background investigation, including the results of the investigation once completed. 2.6 ¶ 3 Bullet 5
    PIV enrollment records SHOULD include the following data: The evidence of authorization if the credential is issued under a pseudonym. 2.6 ¶ 3 Bullet 6
    PIV enrollment records SHOULD include the following data: Any data about the cardholder, including subsequent changes in the data (e.g., cardholder name changes per Section 2.9.1.1). 2.6 ¶ 3 Bullet 7
    {applicable requirements} If there is any data change about the cardholder, the issuer SHALL record this data change in the PIV enrollment record, if applicable. If the changed data is the cardholder’s name, then the issuer SHALL meet the requirements in Section 2.9.1.1. 2.9.1 ¶ 6
    {applicable requirements} If there is any data change about the cardholder, the issuer SHALL record this data change in the PIV enrollment record, if applicable. If the changed data is the cardholder’s name, then the issuer SHALL meet the requirements in Section 2.9.1.1. 2.9.1 ¶ 6
    PIV enrollment records SHOULD include the following data: An enrollment data record that contains the most recent collection of each of the biometric data collected. The enrollment data record describes the circumstances of biometric acquisition including the name and role of the acquiring agent, the office and organization, time, place, and acquisition method. The enrollment data record MAY also document unavailable biometric data or failed attempts to collect biometric data. The enrollment data record MAY contain historical biometric data records. 2.6 ¶ 3 Bullet 2
    PIV enrollment records SHALL maintain an auditable sequence of enrollment events to facilitate binding an applicant to multiple transactions that might take place at different times and locations. These records are generally stored as part of the cardholder’s PIV identity account, either as part of the issuer’s IDMS or through links to records in other related systems (e.g., card management systems). 2.6 ¶ 2]
    Operational management Preventive
    Establish, implement, and maintain a repository of authenticators. CC ID 16372 System hardening through configuration management Preventive
    Ensure the root account is the first entry in password files. CC ID 16323 System hardening through configuration management Detective
    Establish, implement, and maintain a personal data transparency program. CC ID 00375 Privacy protection for information and data Preventive
    Refrain from using restricted data collected for research and statistics for other purposes. CC ID 00096 Privacy protection for information and data Preventive
    Process personal data pertaining to a patient's health in order to treat those patients. CC ID 00200 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for a covered entity's own use. CC ID 00211 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for a healthcare provider's treatment activities by a covered entity. CC ID 00212 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for payment activities between covered entities or healthcare providers. CC ID 00213 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for Treatment, Payment, and Health Care Operations activities when both covered entities have a relationship with the data subject. CC ID 00214 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for Treatment, Payment, and Health Care Operations activities between a covered entity and a participating healthcare provider when the information is collected from the data subject and a third party. CC ID 00215 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information in accordance with agreed upon restrictions. CC ID 06249 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information in accordance with the privacy notice. CC ID 06250 Privacy protection for information and data Preventive
    Disclose permitted Individually Identifiable Health Information for facility directories. CC ID 06251 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for cadaveric organ donation purposes, eye donation purposes, or tissue donation purposes. CC ID 06252 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for medical suitability determinations. CC ID 06253 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for armed forces personnel appropriately. CC ID 06254 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information in order to provide public benefits by government agencies. CC ID 06255 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for fundraising. CC ID 06256 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information when the data subject cannot physically or legally provide consent and the disclosing organization is a healthcare provider. CC ID 00202 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information to provide appropriate treatment to the data subject when the disclosing organization is a healthcare provider. CC ID 00203 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information when it is not contrary to the data subject's wish prior to becoming unable to provide consent and the disclosing organization is a healthcare provider. CC ID 00204 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information that is reasonable or necessary for the disclosure purpose when the disclosing organization is a healthcare provider. CC ID 00205 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information consistent with the law when the disclosing organization is a healthcare provider. CC ID 00206 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information in order to carry out treatment when the disclosing organization is a healthcare provider. CC ID 00207 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information in order to carry out treatment when the data subject has provided consent and the disclosing organization is a healthcare provider. CC ID 00208 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information in order to carry out treatment when the data subject's guardian or representative has provided consent and the disclosing organization is a healthcare provider. CC ID 00209 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information when the disclosing organization is a healthcare provider that supports public health and safety activities. CC ID 06248 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information in order to report abuse or neglect when the disclosing organization is a healthcare provider. CC ID 06819 Privacy protection for information and data Preventive
    Obtain explicit consent for authorization to release Individually Identifiable Health Information. CC ID 00217 Privacy protection for information and data Preventive
    Obtain explicit consent for authorization to release psychotherapy notes. CC ID 00218 Privacy protection for information and data Preventive
    Refrain from using Individually Identifiable Health Information to determine eligibility or continued eligibility for credit. CC ID 00219 Privacy protection for information and data Preventive
    Process personal data after the data subject has granted explicit consent. CC ID 00180 Privacy protection for information and data Preventive
    Process personal data in order to perform a legal obligation or exercise a legal right. CC ID 00182 Privacy protection for information and data Preventive
    Process personal data relating to criminal offenses when required by law. CC ID 00237 Privacy protection for information and data Preventive
    Process personal data in order to prevent personal injury or damage to the data subject's health. CC ID 00183 Privacy protection for information and data Preventive
    Process personal data in order to prevent personal injury or damage to a third party's health. CC ID 00184 Privacy protection for information and data Preventive
    Process personal data for statistical purposes or scientific purposes. CC ID 00256 Privacy protection for information and data Preventive
    Process personal data during legitimate activities with safeguards for the data subject's legal rights. CC ID 00185 Privacy protection for information and data Preventive
    Process traffic data in a controlled manner. CC ID 00130 Privacy protection for information and data Preventive
    Process personal data for health insurance, social insurance, state social benefits, social welfare, or child protection. CC ID 00186 Privacy protection for information and data Preventive
    Process personal data when it is publicly accessible. CC ID 00187 Privacy protection for information and data Preventive
    Process personal data for direct marketing and other personalized mail programs. CC ID 00188 Privacy protection for information and data Preventive
    Process personal data for the purposes of employment. CC ID 16527 Privacy protection for information and data Preventive
    Process personal data for justice administration, lawsuits, judicial decisions, and investigations. CC ID 00189 Privacy protection for information and data Preventive
    Process personal data for debt collection or benefit payments. CC ID 00190 Privacy protection for information and data Preventive
    Process personal data in order to advance the public interest. CC ID 00191 Privacy protection for information and data Preventive
    Process personal data for surveys, archives, or scientific research. CC ID 00192 Privacy protection for information and data Preventive
    Process personal data absent consent for journalistic purposes, artistic purposes, or literary purposes. CC ID 00193 Privacy protection for information and data Preventive
    Process personal data for academic purposes or religious purposes. CC ID 00194 Privacy protection for information and data Preventive
    Process personal data when it is used by a public authority for National Security policy or criminal policy. CC ID 00195 Privacy protection for information and data Preventive
    Refrain from storing data in newly created files or registers which directly or indirectly reveals the restricted data. CC ID 00196 Privacy protection for information and data Preventive
    Follow legal obligations while processing personal data. CC ID 04794 Privacy protection for information and data Preventive
    Start personal data processing only after the needed notifications are submitted. CC ID 04791 Privacy protection for information and data Preventive
    Manage Personal Identification Numbers and PIN verification code numbers. CC ID 00058
    [The remote PIN reset operation SHALL satisfy the requirements for remote, postissuance updates specified in Section 2.9.2. The remote PIN reset operation SHALL satisfy the requirements for remote, postissuance updates specified in Section 2.9.2. 2.9.3.1 ¶ 10
    Remote PIN reset on a general computing platform (e.g., desktop, laptop) SHALL only be performed if all the following requirements are met: The cardholder initiates a ;" class="term_primary-noun">PIN reset with the issuer operator. 2.9.3.1 ¶ 9 Bullet 1
    Remote PIN reset on a general computing platform (e.g., desktop, laptop) SHALL only be performed if all the following requirements are met: The operator authenticates the owner of the round-color:#F0BBBC;" class="term_primary-noun">PIV Card through an background-color:#F0BBBC;" class="term_primary-noun">independent procedure, for example by authenticating the cardholder with an associated derived PIV credential or by confirming reset via email to the on-record government-issued email address. 2.9.3.1 ¶ 9 Bullet 2
    {appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is D8ED;" class="term_primary-verb">authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT reset the PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5
    {appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT reset the PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5]
    Privacy protection for information and data Preventive
    Collect Personal Identification Numbers with the individual's consent. CC ID 00059 Privacy protection for information and data Preventive
    Collect Personal Identification Numbers absent consent when the law mandates. CC ID 00061 Privacy protection for information and data Preventive
    Collect Personal Identification Numbers absent consent for research purposes. CC ID 00065 Privacy protection for information and data Preventive
    Collect Personal Identification Numbers absent consent to realize the rights or duties of the data subject or data controller. CC ID 04792 Privacy protection for information and data Preventive
    Develop remedies and sanctions for privacy policy violations. CC ID 00474
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Coordinate with appropriate department or agency officials to define consequences for violating privacy policies of the PIV system. 2.11 ¶ 3 Bullet 8]
    Privacy protection for information and data Preventive
    Implement procedures to file privacy rights violation complaints. CC ID 00476 Privacy protection for information and data Corrective
    Change or destroy any personal data that is incorrect. CC ID 00462 Privacy protection for information and data Corrective
    Refrain from updating personal data on a regular basis, unless it is necessary for the purposes it was collected. CC ID 13610 Privacy protection for information and data Preventive
    Escalate the appeal process to change personal data when the data controller fails to make changes to the disputed data. CC ID 00465 Privacy protection for information and data Corrective
    Notify individuals of their right to challenge personal data. CC ID 00457 Privacy protection for information and data Preventive
    Notify individuals of their right to object to personal data for legitimate reasons. CC ID 00458 Privacy protection for information and data Preventive
    Notify individuals of their ability to object to personal data processing, absent cost. CC ID 00459 Privacy protection for information and data Preventive
    Investigate the disputed accuracy of personal data. CC ID 00461 Privacy protection for information and data Preventive
    Order the cessation of data processing when a violation of the privacy policy is detected. CC ID 00475 Privacy protection for information and data Corrective
    Destroy personal data that breaches privacy after the privacy breach has been detected. CC ID 00503 Privacy protection for information and data Corrective
    Establish, implement, and maintain a Customer Information Management program. CC ID 00084 Privacy protection for information and data Preventive
    Check the data accuracy of new accounts. CC ID 04859 Privacy protection for information and data Preventive
  • Establish Roles
    6
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Use biometric authentication for identification and authentication, as necessary. CC ID 06857
    [If the identity proofing and enrollment process is performed over multiple visits, an automated biometric verification attempt comparing the applicant’s newly captured biometric characteristics against biometric data collected during a previous visit SHALL be performed at each visit and return a positive verification decision. 2.4 ¶ 3
    If biometric data was collected as specified in Section 2.3 and if collection of biometric data as specified in this section and in Section 2.3 occur on separate occasions, a biometric comparison SHALL be performed to confirm that the two fingerprints collected for off-card one-to-one comparisons elicit a positive biometric verification decision when compared to the same two fingerprints from the original set of ten fingerprints. 2.4 ¶ 4
    PIV background investigation, identity proofing, registration, and issuance processes MAY be performed across multiple sessions at different facilities. If multiple sessions are needed, the applicant SHALL be linked through a positive biometric verification decision obtained from an automated comparison of biometric characteristics captured at a previous session to biometric characteristics captured during the current session. Issuers SHALL follow applicable federal laws and regulations regarding the retention and destruction of biometric data. 2.5 ¶ 6
    For linking to background investigations, only fingerprints SHALL be used, since fingerprints are the only biometric characteristic used for background investigations. For all other purposes, verification attempts MAY be performed against any available biometric characteristic stored electronically on the PIV Card or in the enrollment record. 2.5 ¶ 7
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {negative biometric verification decision} {are not available} The issuer SHALL perform a biometric verification of the applicant to the biometric data records of the PIV enrollment record or to the biometric data records of the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. Minimum accuracy requirements for the biometric verification are specified in [SP 800-76]. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.9.1 ¶ 3
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {appear in person}{not be successful}{not be available} When OCC reset is performed in person at the issuing facility, before the reset, the issuer SHALL perform a biometric verification of the cardholder to the biometric data records in the PIV enrollment record. If the biometric verification decision is negative or no alternative biometric data records are available, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 4
    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 card to perform CTC authentication, and the card responds with a positive or negative biometric verification decision. The response includes information that allows the reader to authenticate the card. Entry of the cardholder PIN is not required for OCC-AUTH. The PIV Card SHALL include a mechanism to block this authentication mechanism after a number of consecutive failed authentication attempts as stipulated by the department or agency. As with BIO and BIO-A, if agencies choose to implement OCC, it SHALL be implemented as defined in [SP 800-73] and [SP 800-76]. 6.2.2 ¶ 1
    {not acquire} When PIN reset is performed in person at the issuing facility, before providing the reset PIV Card back to the cardholder, the issuer SHALL color:#B7D8ED;" class="term_primary-verb">performpan> a pan style="background-color:#F0BBBC;" class="term_primary-noun">biometric verification to ensure that the cardholder’s biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect the identity document and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the card. 2.9.3.1 ¶ 3
    {applicable requirements}{remote proofing procedure}{not acquire} PIN reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a ">positive biometric verification decision when ="term_secondary-verb">compared to biometric data records secondary-verb">stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCCAUTH authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.1 ¶ 7
    {not be successful}{not acquire} OCC reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a ">positive biometric verification decision when BD0E5;" class="term_secondary-verb">compared to biometric data records secondary-verb">stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 6]
    Technical security Preventive
    Define and assign roles and responsibilities for malicious code protection. CC ID 15474 Technical security Preventive
    Establish, implement, and maintain high level operational roles and responsibilities. CC ID 00806 Human Resources management Preventive
    Define and assign the Privacy Officer's roles and responsibilities. CC ID 00714
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Assign an individual to the role of privacy official. The privacy official is the individual who oversees privacy-related matters in the PIV system and is responsible for implementing the privacy requirements in the Standard. The individual serving in this role SHALL NOT assume any other operational role in the PIV system. 2.11 ¶ 3 Bullet 1]
    Human Resources management Preventive
    Establish and maintain the staff structure in line with the strategic plan. CC ID 00764 Human Resources management Preventive
    Process restricted data lawfully and carefully. CC ID 00086
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that systems that contain PII for the purpose of enabling the implementation of PIV are handled in full compliance with fair information practices, as defined in [PRIVACY]. 2.11 ¶ 3 Bullet 5]
    Privacy protection for information and data Preventive
  • Establish/Maintain Documentation
    157
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Establish, implement, and maintain communication protocols. CC ID 12245 Leadership and high level objectives Preventive
    Establish, implement, and maintain alert procedures that follow the organization's communication protocol. CC ID 12406
    [{be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2]
    Leadership and high level objectives Preventive
    Establish, implement, and maintain a stress test program for identification cards or badges. CC ID 15424
    [{PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5]
    Monitoring and measurement Preventive
    Establish, implement, and maintain a compliance monitoring policy. CC ID 00671 Monitoring and measurement Preventive
    Establish, implement, and maintain a metrics policy. CC ID 01654 Monitoring and measurement Preventive
    Establish, implement, and maintain an approach for compliance monitoring. CC ID 01653 Monitoring and measurement Preventive
    Identify and document instances of non-compliance with the compliance framework. CC ID 06499 Monitoring and measurement Preventive
    Identify and document events surrounding non-compliance with the organizational compliance framework. CC ID 12935 Monitoring and measurement Preventive
    Establish, implement, and maintain disciplinary action notices. CC ID 16577 Monitoring and measurement Preventive
    Include a copy of the order in the disciplinary action notice. CC ID 16606 Monitoring and measurement Preventive
    Include the sanctions imposed in the disciplinary action notice. CC ID 16599 Monitoring and measurement Preventive
    Include the effective date of the sanctions in the disciplinary action notice. CC ID 16589 Monitoring and measurement Preventive
    Include the requirements that were violated in the disciplinary action notice. CC ID 16588 Monitoring and measurement Preventive
    Include responses to charges from interested personnel and affected parties in the disciplinary action notice. CC ID 16587 Monitoring and measurement Preventive
    Include the reasons for imposing sanctions in the disciplinary action notice. CC ID 16586 Monitoring and measurement Preventive
    Include required information in the disciplinary action notice. CC ID 16584 Monitoring and measurement Preventive
    Include a justification for actions taken in the disciplinary action notice. CC ID 16583 Monitoring and measurement Preventive
    Include a statement on the conclusions of the investigation in the disciplinary action notice. CC ID 16582 Monitoring and measurement Preventive
    Include the investigation results in the disciplinary action notice. CC ID 16581 Monitoring and measurement Preventive
    Include a description of the causes of the actions taken in the disciplinary action notice. CC ID 16580 Monitoring and measurement Preventive
    Include the name of the person responsible for the charges in the disciplinary action notice. CC ID 16579 Monitoring and measurement Preventive
    Include contact information in the disciplinary action notice. CC ID 16578 Monitoring and measurement Preventive
    Establish, implement, and maintain a digital identity management program. CC ID 13713 Technical security Preventive
    Establish, implement, and maintain digital identification procedures. CC ID 13714
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that 2.1 ¶ 2
    The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. 2.7 ¶ 11]
    Technical security Preventive
    Establish, implement, and maintain remote proofing procedures. CC ID 13796
    [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 issuercontrolled station at a remote location that is connected to a trained operator at a central location. The goal of this arrangement is to permit identity proofing and enrollment of individuals in remote locations where it is not practical for them to travel to the agency for in-person identity proofing. 2.7.1 ¶ 1
    Supervised remote identity proofing SHALL meet the following requirements: The issuer SHALL ensure that all communications occur over a mutually authenticated protected channel. 2.7.1 ¶ 4 Bullet 7
    The following forms of protection SHALL be provided by either inherent capabilities of the station or staff at the station location: ensuring that the physical integrity of the station (e.g., door locks and restricted access) and integral nature of its sensor devices (e.g., fingerprint readers and cameras) are maintained at all times to protect against tampering, removal, or replacement; 2.7.1 ¶ 3 Bullet 2
    Supervised remote identity proofing SHALL meet the following requirements: The station SHALL be maintained in a controlled-access environment and SHALL be monitored by staff at the station location while it is being used. 2.7.1 ¶ 4 Bullet 1]
    Technical security Preventive
    Establish, implement, and maintain an access control program. CC ID 11702 Technical security Preventive
    Include instructions to change authenticators as often as necessary in the access control program. CC ID 11931
    [{previously used PIN} Cardholders MAY change their PINs at any time by providing the current PIN and the new PIN values, as specified in [SP 800-73]. 2.9.3 ¶ 3]
    Technical security Preventive
    Include guidance for how users should protect their authentication credentials in the access control program. CC ID 11929
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that An issued credential is not modified by an unauthorized entity. 2.1 ¶ 2 Bullet 12]
    Technical security Preventive
    Include guidance on selecting authentication credentials in the access control program. CC ID 11928
    [{be unguessable}{not be identifiable}{be unique} The cardholder SHALL be guided in selecting a strong PIN value. The PIN SHALL be a minimum of six digits in length and SHOULD NOT be easily guessable, individually identifiable (e.g., part of a Social Security Number or phone number), or commonly used (e.g., 000000, 123456). 4.3.1 ¶ 2]
    Technical security Preventive
    Establish, implement, and maintain an access rights management plan. CC ID 00513 Technical security Preventive
    Establish, implement, and maintain biometric collection procedures. CC ID 15419
    [A full set of fingerprints SHALL be collected from each PIV applicant who is lacking an on-record background investigation. 2.3 ¶ 2
    The following biometric data MAY be collected from a PIV applicant: An electronic image of the right iris. 2.4 ¶ 2 Bullet 2
    The full set of fingerprints SHALL be collected for biometric identification against databases of fingerprints maintained by the FBI. 2.5 ¶ 1
    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. 2.4 ¶ 1 Bullet 1
    Fingerprint collection SHALL conform to the procedural and technical specifications of [SP 800-76]. 2.3 ¶ 4
    Biometric data collection SHALL conform to the procedural and technical specifications of [SP 800-76]. The choice of fingers to use for mandatory fingerprint templates and optional fingerprint templates MAY vary between persons. The recommended selection and order is specified in [SP 800-76]. 2.4 ¶ 5
    The following biometric data SHALL be collected from each PIV applicant: An electronic facial image. 2.4 ¶ 1 Bullet 2
    The following biometric data MAY be collected from a PIV applicant: Two fingerprints for on-card comparison (OCC). These fingerprints MAY be taken from the full set of fingerprints collected in Section 2.3 and SHOULD be imaged from fingers not imaged for off-card one-to-one comparison. 2.4 ¶ 2 Bullet 3
    The following biometric data MAY be collected from a PIV applicant: An electronic image of the left iris. 2.4 ¶ 2 Bullet 1]
    Technical security Preventive
    Establish, implement, and maintain access control procedures. CC ID 11663
    [Parties responsible for controlling access to federal resources (both physical and logical) SHALL determine the appropriate assurance levels required for access based on the harm and impact to individuals and organizations that could occur as a result of errors in the authentication of the PIV cardholder. Once the required assurance level has been determined, one of the authentication mechanisms specified in Section 6.2 SHALL be applied to achieve that assurance level. 6.1 ¶ 3]
    Technical security Preventive
    Document approving and granting access in the access control log. CC ID 06786 Technical security Preventive
    Include the user identifiers of all personnel who are authorized to access a system in the system record. CC ID 15171 Technical security Preventive
    Include identity information of all personnel who are authorized to access a system in the system record. CC ID 16406 Technical security Preventive
    Include the date and time that access rights were changed in the system record. CC ID 16415 Technical security Preventive
    Establish, implement, and maintain an identification and authentication policy. CC ID 14033 Technical security Preventive
    Include roles and responsibilities in the identification and authentication policy. CC ID 14230
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A single corrupt official in the process cannot issue a credential with an incorrect identity or to a person not entitled to the credential. 2.1 ¶ 2 Bullet 10
    PIV Cards that contain topographical defects (e.g., scratches, poor color, fading, etc.) or that are not properly printed SHALL be destroyed. The PIV Card issuer is responsible for the card stock, its management, and its integrity. 2.8 ¶ 2
    {applicable requirements} Remote issuance SHALL satisfy all of the requirements of Section 2.8. The issuer SHALL have local trained staff to securely maintain custody of card stock received by the remote station when the station is used for PIV Card issuance. 2.8.3 ¶ 2]
    Technical security Preventive
    Establish, implement, and maintain identification and authentication procedures. CC ID 14053
    [Federal departments and agencies SHALL use the credentialing eligibility standards issued by the Director of the Office of Personnel Management (OPM) and OMB. 2.2 ¶ 1
    Parties responsible for controlling access to federal resources (both physical and logical) SHALL determine the appropriate assurance levels required for access based on the harm and impact to individuals and organizations that could occur as a result of errors in the authentication of the PIV cardholder. Once the required assurance level has been determined, one of the authentication mechanisms specified in Section 6.2 SHALL be applied to achieve that assurance level. 6.1 ¶ 3
    {be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2]
    Technical security Preventive
    Include instructions to refrain from using previously used authenticators in the access control program. CC ID 11930 Technical security Preventive
    Establish and maintain a memorized secret list. CC ID 13791 Technical security Preventive
    Establish, implement, and maintain information flow control policies inside the system and between interconnected systems. CC ID 01410 Technical security Preventive
    Establish, implement, and maintain information exchange procedures. CC ID 11782 Technical security Preventive
    Generate and protect a secret random number for each digital signature. CC ID 06577 Technical security Preventive
    Establish the security strength requirements for the digital signature process. CC ID 06578 Technical security Preventive
    Establish, implement, and maintain an encryption management and cryptographic controls policy. CC ID 04546 Technical security Preventive
    Establish, implement, and maintain cryptographic key management procedures. CC ID 00571 Technical security Preventive
    Establish, implement, and maintain requirements for Personal Identity Verification authentication certificates. CC ID 06587
    [If the derived PIV credential to be invalidated contains a derived PIV authentication certificate and the corresponding private key cannot be securely zeroized or destroyed, the CA SHALL be informed and the certificate corresponding to the derived PIV authentication key SHALL be revoked. 2.10.2 ¶ 2]
    Technical security Preventive
    Establish, implement, and maintain Public Key certificate application procedures. CC ID 07079 Technical security Preventive
    Include the Identification and Authentication of individuals or entities in the Public Key certificate application procedures. CC ID 07080
    [{refrain from expiring}{not be revoked} The relying system validates the card authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.2 ¶ 1 Bullet 2]
    Technical security Preventive
    Include revocation of Public Key certificates in the Public Key certificate procedures. CC ID 07082
    [If the PIV authentication key (Section 4.2.2.1), asymmetric card authentication key (Section 4.2.2.2), digital signature key (Section 4.2.2.1), or key management key (Section 4.2.2.5) was compromised, the corresponding certificate SHALL be revoked. 2.9.2 ¶ 4
    {not be destroyed} {not be collected} The revocation process SHALL include the following: If the old PIV Card cannot be collected and destroyed, or if the old PIV Card has been compromised or damaged, then the Certification Authority (CA) SHALL be informed and the certificates corresponding to the PIV authentication key (Section 4.2.2.1) and asymmetric card authentication key (Section 4.2.2.2) on the old PIV Card SHALL be revoked. If present, the certificates corresponding to the digital signature key (Section 4.2.2.1) and the key management key (Section 4.2.2.5) SHALL also be revoked. 2.9.1 ¶ 4 Bullet 3
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: If the PIV Card cannot be collected and destroyed, the CA SHALL be informed and the certificates corresponding to the PIV authentication key and the asymmetric card authentication key on the PIV Card SHALL be revoked. The certificates corresponding to the digital signature and key management keys SHALL also be revoked, if present. 2.9.4 ¶ 2 Bullet 4
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: If the PIV Card cannot be collected and destroyed, the CA SHALL be informed and the certificates corresponding to the PIV authentication key and the asymmetric card authentication key on the PIV Card SHALL be revoked. The certificates corresponding to the digital signature and key management keys SHALL also be revoked, if present. 2.9.4 ¶ 2 Bullet 4
    Departments and agencies SHALL notify CAs when certificates need to be revoked. 5.5 ¶ 3
    If the derived PIV credential to be invalidated contains a derived PIV authentication certificate and the corresponding private key cannot be securely zeroized or destroyed, the CA SHALL be informed and the certificate corresponding to the derived PIV authentication key SHALL be revoked. 2.10.2 ¶ 2]
    Technical security Preventive
    Publish revoked Public Key certificates in the Certificate Revocation List. CC ID 07089
    [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 service that publishes the CRLs for the PIV certificates that it issues, as specified in [PROF]; 5.5 ¶ 1 Bullet 1
    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]. 5.3 ¶ 1
    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]. 5.3 ¶ 1
    {refrain from expiring}{not be revoked} The relying system validates the card authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.2 ¶ 1 Bullet 2]
    Technical security Preventive
    Establish, implement, and maintain Public Key certificate procedures. CC ID 07085
    [{applicable requirements} 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 be operated by departments and agencies or be outsourced to PKI service providers. For a list of PKI service providers that have been approved to operate under [COMMON], see https://www.idmanagement.gov. 5.2 ¶ 1
    CAs that issue certificates corresponding to PIV private keys (i.e., PIV authentication, card authentication, digital signature, or key management certificates) SHALL maintain an HTTP-accessible service that publishes any CA certificates issued to it, as specified in [PROF]; and 5.5 ¶ 1 Bullet 2
    operate Online Certificate Status Protocol (OCSP, specified in [RFC 6960]) services for the PIV certificates that it issues, as specified in [PROF]. 5.5 ¶ 1 Bullet 3
    PIV authentication, card authentication, digital signature, and key management certificates SHALL contain the authorityInfoAccess extension needed to locate the authoritative OCSP responder. 5.5 ¶ 2 Bullet 2
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7
    Certificates containing the public key associated with a key management private key SHALL conform to the Key Management Certificate Profile in [PROF] and SHALL specify the id-fpki-common-policy or id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.5), except as provided below. 5.2.1 ¶ 1 Bullet 4
    Certificates containing the public key associated with a key management private key SHALL conform to the Key Management Certificate Profile in [PROF] and SHALL specify the id-fpki-common-policy or id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.5), except as provided below. 5.2.1 ¶ 1 Bullet 4
    The public key required to verify the digital signature SHALL be in a content signing certificate, which SHALL be issued under the id-fpki-common-piv-contentSigning policy of [COMMON] and SHALL include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. The signature on the biometric data record SHOULD be generated with the same signing key as the signature on the CHUID data object. The public key required to verify the digital signature is contained in the CHUID data object’s content signing certificate33 as detailed in Section 4.2.1. 4.2.3.2 ¶ 4
    The public key required to verify the digital signature SHALL be in a content signing certificate, which SHALL be issued under the id-fpki-common-piv-contentSigning policy of [COMMON] and SHALL include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. The signature on the biometric data record SHOULD be generated with the same signing key as the signature on the CHUID data object. The public key required to verify the digital signature is contained in the CHUID data object’s content signing certificate33 as detailed in Section 4.2.1. 4.2.3.2 ¶ 4
    Certificates that contain the public key associated with a PIV authentication private key SHALL conform to the PIV Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-authentication policy of [COMMON] in the certificate policies extension (Section 4.2.2.1). 5.2.1 ¶ 1 Bullet 1
    Certificates that contain the public key associated with a PIV authentication private key SHALL conform to the PIV Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-authentication policy of [COMMON] in the certificate policies extension (Section 4.2.2.1). 5.2.1 ¶ 1 Bullet 1
    Certificates that contain the public key associated with a digital signature private key SHALL conform to the End Entity Signature Certificate Profile in [PROF] and SHALL specify the id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.4), except as provided below. 5.2.1 ¶ 1 Bullet 3
    Certificates that contain the public key associated with a digital signature private key SHALL conform to the End Entity Signature Certificate Profile in [PROF] and SHALL specify the id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.4), except as provided below. 5.2.1 ¶ 1 Bullet 3
    {asymmetric card authentication key} Certificates that contain the public key associated with an asymmetric card authentication private key SHALL conform to the Card Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-cardAuth policy of [COMMON] in the certificate policies extension (Section 4.2.2.2). 5.2.1 ¶ 1 Bullet 2
    {asymmetric card authentication key} Certificates that contain the public key associated with an asymmetric card authentication private key SHALL conform to the Card Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-cardAuth policy of [COMMON] in the certificate policies extension (Section 4.2.2.2). 5.2.1 ¶ 1 Bullet 2
    {applicable requirements} CA certificates SHALL conform to [COMMON]. 5.1 ¶ 2
    Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.3.2 ¶ 6]
    Technical security Preventive
    Include signing and issuing Public Key certificates in the Public Key certificate procedures. CC ID 11817
    [{electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7]
    Technical security Preventive
    Include publishing Public Key certificates in the Public Key certificate procedures. CC ID 07087 Technical security Preventive
    Include access to issued Public Key certificates in the Public Key certificate procedures. CC ID 07086
    [Certificates that contain the FASC-N or card UUID in the SAN extension, such as PIV authentication certificates and card authentication certificates, SHALL NOT be distributed publicly (e.g., via HTTP accessible from the public internet). Individual departments and agencies can decide whether digital signature and key management certificates can be distributed publicly by the CA. 5.5.1 ¶ 2
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7]
    Technical security Preventive
    Establish, implement, and maintain a malicious code protection program. CC ID 00574
    [{do not introduce} The following forms of protection SHALL be provided by either inherent capabilities of the station or staff at the station location: ensuring that no malicious code is introduced to compromise or otherwise impair the station and the PIV Card; and 2.7.1 ¶ 3 Bullet 3]
    Technical security Preventive
    Establish, implement, and maintain malicious code protection procedures. CC ID 15483 Technical security Preventive
    Establish, implement, and maintain a malicious code protection policy. CC ID 15478 Technical security Preventive
    Establish, implement, and maintain a malicious code outbreak recovery plan. CC ID 01310 Technical security Corrective
    Establish, implement, and maintain a physical security program. CC ID 11757 Physical and environmental protection Preventive
    Establish, implement, and maintain a facility physical security program. CC ID 00711 Physical and environmental protection Preventive
    Identify and document physical access controls for all physical entry points. CC ID 01637 Physical and environmental protection Preventive
    Establish, implement, and maintain physical identification procedures. CC ID 00713 Physical and environmental protection Preventive
    Establish, implement, and maintain lost or damaged identification card procedures, as necessary. CC ID 14819
    [Derived PIV credentials SHALL be invalidated in any of the following circumstances at the determination of the issuer upon reported loss or suspected compromise of a derived PIV credential; 2.10.2 ¶ 1 Bullet 2
    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; 2.10.2 ¶ 1 Bullet 1
    {lost identification card or badge}{stolen identification card or badge}{stipulated time frame} In the case of a lost, stolen, or compromised card, normal revocation procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay, and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.1 ¶ 5]
    Physical and environmental protection Preventive
    Document all lost badges in a lost badge list. CC ID 12448 Physical and environmental protection Corrective
    Establish, implement, and maintain identification issuance procedures for identification cards or badges. CC ID 06598
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A person suspected or known to the government as being a terrorist is not issued a credential. 2.1 ¶ 2 Bullet 5
    {stipulated time frame} The PIV Card SHALL be valid for no more than six years. 2.8 ¶ 1 Bullet 7
    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 identity proofing and registration process that meets the requirements defined below when issuing PIV Cards. 2.7 ¶ 1
    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 writing by the head or deputy (or equivalent) of the federal department or agency. 2.8 ¶ 1
    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 writing by the head or deputy (or equivalent) of the federal department or agency. 2.8 ¶ 1
    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 writing by the head or deputy (or equivalent) of the federal department or agency. 2.8 ¶ 1
    {applicable requirements} The department or agency SHALL use an approved PIV credential issuance process in accordance with [SP 800-79]. 2.8 ¶ 1 Bullet 2
    The department or agency SHALL issue PIV credentials only through systems and providers whose reliability has been established by the agency and so documented and approved in writing (i.e., accredited) in accordance with [SP 800-79]. 2.8 ¶ 1 Bullet 6
    PIV Cards SHALL be issued only after the adjudicative entity has authorized issuance of the credential. 2.8 ¶ 1 Bullet 1
    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 necessary to protect an employee or contractor (e.g., from physical harm, severe distress, or harassment), the agency may formally authorize the issuance of a PIV Card to the employee or contractor using the agency-approved pseudonym. The issuance of a PIV Card using an authorized pseudonym SHALL follow the procedures in Section 2.8 except that the card issuer SHALL receive satisfactory evidence that the pseudonym is authorized by the agency. 2.8.1 ¶ 1
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {negative biometric verification decision} {are not available} The issuer SHALL perform a biometric verification of the applicant to the biometric data records of the PIV enrollment record or to the biometric data records of the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. Minimum accuracy requirements for the biometric verification are specified in [SP 800-76]. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.9.1 ¶ 3
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {applicable requirements} Remote issuance SHALL satisfy all of the requirements of Section 2.8. The issuer SHALL have local trained staff to securely maintain custody of card stock received by the remote station when the station is used for PIV Card issuance. 2.8.3 ¶ 2
    {issuing organization} Derived PIV credentials SHALL be bound to the cardholder’s PIV identity account only by the issuing department or agency responsible for managing that PIV identity account. If the issuing department or agency relies on shared services for portions of the PIV Card or Derived PIV credential issuance process, it is the responsibility of the issuing department or agency to ensure that all credentials and IDMS records are properly maintained throughout the PIV lifecycle. 2.10.1 ¶ 3
    {issuing organization} Derived PIV credentials SHALL be bound to the cardholder’s PIV identity account only by the issuing department or agency responsible for managing that PIV identity account. If the issuing department or agency relies on shared services for portions of the PIV Card or Derived PIV credential issuance process, it is the responsibility of the issuing department or agency to ensure that all credentials and IDMS records are properly maintained throughout the PIV lifecycle. 2.10.1 ¶ 3
    {appear in person} If biometric data cannot be positively verified per the criteria defined in [SP 800-76], remote issuance SHALL NOT be used and issuance will be performed in person at the issuer’s facility. The trained operator SHALL terminate a remote issuance session and require in-person issuance at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.8.3 ¶ 3
    {appear in person} If biometric data cannot be positively verified per the criteria defined in [SP 800-76], remote issuance SHALL NOT be used and issuance will be performed in person at the issuer’s facility. The trained operator SHALL terminate a remote issuance session and require in-person issuance at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.8.3 ¶ 3]
    Physical and environmental protection Preventive
    Include error handling controls in identification issuance procedures. CC ID 13709
    [PIV Cards that contain topographical defects (e.g., scratches, poor color, fading, etc.) or that are not properly printed SHALL be destroyed. The PIV Card issuer is responsible for the card stock, its management, and its integrity. 2.8 ¶ 2]
    Physical and environmental protection Preventive
    Include information security in the identification issuance procedures. CC ID 15425
    [{refrain from implementing}{not be consistent} Departments and agencies may have a wide variety of uses for the PIV system and its components that were not intended or anticipated by the President in issuing [HSPD-12]. In considering whether a proposed use of the PIV system is appropriate, departments and agencies SHALL consider the aforementioned control objectives and the purpose of this Standard, namely “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy” as per [HSPD-12]. No department or agency SHALL implement a use of the identity credential inconsistent with these control objectives. 2.11 ¶ 2]
    Physical and environmental protection Preventive
    Establish, implement, and maintain post-issuance update procedures for identification cards or badges. CC ID 15426
    [{be equivalent} A PIV Card post-issuance update MAY be done locally (i.e., performed with the issuer in physical custody of the PIV Card) or remotely (i.e., performed with the PIV Card at a remote location). Post-issuance updates SHALL be performed with issuer security controls equivalent to those applied during PIV Card reissuance. For remote postissuance updates, the following SHALL apply: 2.9.2 ¶ 2
    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, keys, biometric data records, or signed data objects are updated. A post-issuance update SHALL NOT modify the PIV Card expiration date, FASC-N, card UUID, or cardholder UUID. 2.9.2 ¶ 1
    For remote post-issuance updates, the following SHALL apply: Data transmitted between the PIV Card issuer and PIV Card SHALL be encrypted and contain data integrity checks. 2.9.2 ¶ 2 Bullet 2
    For remote post-issuance updates, the following SHALL apply: Communication between the PIV Card issuer and the PIV Card SHALL occur only over mutually authenticated secure sessions between tested and validated cryptographic modules (one being the PIV Card). 2.9.2 ¶ 2 Bullet 1
    For remote post-issuance updates, the following SHALL apply: The PIV Card application SHALL communicate with no endpoint entity other than the PIV Card issuer during the remote post-issuance update. 2.9.2 ¶ 2 Bullet 3
    For remote post-issuance updates, the following SHALL apply: Data transmitted between the PIV Card issuer and PIV Card SHALL be encrypted and contain data integrity checks. 2.9.2 ¶ 2 Bullet 2
    {after}{card issuance} The FASC-N, card UUID, expiration date, and, if present, cardholder UUID SHALL NOT be modified post-issuance. 4.2.1 ¶ 5
    {contact interface} All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL ound-color:#B7D8ED;" class="term_primary-verb">include all cryptographic operations performed over both the contact and contactless interfaces as part of -color:#CBD0E5;" class="term_secondary-verb">an style="background-color:#F0BBBC;" class="term_primary-noun">remote post issuance updates, as specified in Section 2.9.2. 4.2.2 ¶ 19 Bullet 3]
    Physical and environmental protection Preventive
    Include an identity registration process in the identification issuance procedures. CC ID 11671
    [Before issuing the PIV Card, the issuer SHALL ensure that the individual receiving it has been properly processed per Section 2.1, Section 2.2, and Section 2.7. 2.8 ¶ 1 Bullet 3
    {identity proofing} {registration} The department or agency SHALL follow investigative requirements as outlined in Section 2.2. 2.7 ¶ 3
    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 necessary to protect an employee or contractor (e.g., from physical harm, severe distress, or harassment), the agency may formally authorize the issuance of a PIV Card to the employee or contractor using the agency-approved pseudonym. The issuance of a PIV Card using an authorized pseudonym SHALL follow the procedures in Section 2.8 except that the card issuer SHALL receive satisfactory evidence that the pseudonym is authorized by the agency. 2.8.1 ¶ 1
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6]
    Physical and environmental protection Preventive
    Establish, implement, and maintain identification renewal procedures for identification cards or badges. CC ID 06599
    [If the expiration date of the new PIV Card is later than the expiration date of the old card, or if any data about the cardholder is being changed, the card issuer SHALL ensure that an adjudicative entity has authorized the issuance of the new PIV Card. The issuer SHALL ensure that the adjudicative entity has verified that there is a PIV eligibility determination in an authoritative record, such as the agency’s IDMS or the Central Verification System (or successor). 2.9.1 ¶ 2
    If the expiration date of the new PIV Card is later than the expiration date of the old card, or if any data about the cardholder is being changed, the card issuer SHALL ensure that an adjudicative entity has authorized the issuance of the new PIV Card. The issuer SHALL ensure that the adjudicative entity has verified that there is a PIV eligibility determination in an authoritative record, such as the agency’s IDMS or the Central Verification System (or successor). 2.9.1 ¶ 2
    {appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT pan style="background-color:#B7D8ED;" class="term_pri class="term_secondary-verb">mary-verb">resetspackground-color:#CBD0E5;" class="term_secondary-verb">n> the <span style="background-color:#F0BBBC;" class="term_primary-noun">PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5]
    Physical and environmental protection Preventive
    Establish, implement, and maintain identification re-issuing procedures for identification cards or badges. CC ID 06596
    [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 formal name change—such as a marriage certificate, a divorce decree, judicial recognition of a name change, or other mechanism permitted by state law or regulation—the card issuer SHALL issue the cardholder a new card following the procedures set out in Section 2.9.1 and notify the respective adjudicative entity of the name change to ensure that appropriate records are updated. If the expiration date of the new card is no later than the expiration date of the old PIV Card and no data about the cardholder other than the cardholder’s name is being changed, then the new PIV Card MAY be issued without obtaining the approval of the adjudicative entity and without performing a re-investigation. 2.9.1.1 ¶ 1
    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 formal name change—such as a marriage certificate, a divorce decree, judicial recognition of a name change, or other mechanism permitted by state law or regulation—the card issuer SHALL issue the cardholder a new card following the procedures set out in Section 2.9.1 and notify the respective adjudicative entity of the name change to ensure that appropriate records are updated. If the expiration date of the new card is no later than the expiration date of the old PIV Card and no data about the cardholder other than the cardholder’s name is being changed, then the new PIV Card MAY be issued without obtaining the approval of the adjudicative entity and without performing a re-investigation. 2.9.1.1 ¶ 1
    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 PIV Card needs to be invalidated when the cardholder changes their name or employment status. In this regard, procedures for PIV Card maintenance must be integrated into department and agency procedures to ensure effective card maintenance. In order to maintain operational readiness of a cardholder’s PIV Card, agencies may require PIV Card update, reissuance, or biometric enrollment more frequently than the maximum PIV Card and biometric characteristic lifetimes stated in this Standard. Shorter lifetimes MAY be specified by agency policy. 2.9 ¶ 2
    Departments and agencies MAY adopt more stringent procedures for PIN or OCC reset (including disallowing resets); such procedures SHALL be formally documented by each department and agency. 2.9.3 ¶ 4
    Both fingerprints used for OCC SHALL be replaced during an OCC reset. 2.9.3.2 ¶ 1
    Post-issuance updates to biometric data records, other than to the digital signature blocks within the biometric data records, SHALL satisfy the requirements for PIV Card activation reset specified in Section 2.9.3. 2.9.2 ¶ 3]
    Physical and environmental protection Preventive
    Establish, implement, and maintain identification mechanism termination procedures. CC ID 06306
    [The revocation process SHALL include the following: The old PIV Card SHALL be collected and destroyed, if possible. 2.9.1 ¶ 4 Bullet 1
    The old PIV Card SHALL be revoked when the new PIV Card is issued. The revocation process SHALL include the following: 2.9.1 ¶ 4
    Derived PIV credentials SHALL be invalidated in any of the following circumstances at the determination of the issuer upon observation of possible fraudulent activity; or 2.10.2 ¶ 1 Bullet 3
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: The PIV Card SHALL be collected and destroyed, if possible. 2.9.4 ¶ 2 Bullet 1
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Per OPM guidance, the Central Verification System (or successor) SHALL be updated to reflect the change in status (see Section 2.2). 2.9.4 ¶ 2 Bullet 2
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: 2.9.4 ¶ 2
    {be fraudulent} 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 cardholder is determined to hold a fraudulent identity. 2.9.4 ¶ 1 Bullet 5
    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: An authorized adjudicative entity determines that the cardholder is ineligible for a PIV Card after completion of a cardholder’s background investigation or review of developed information (see [FCS] and [CSP]). 2.9.4 ¶ 1 Bullet 4
    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 cardholder passes away. 2.9.4 ¶ 1 Bullet 3
    {federal government} 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 contractor changes positions and no longer needs access to federal buildings or systems. 2.9.4 ¶ 1 Bullet 2
    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: 2.9.4 ¶ 1
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Any databases maintained by the PIV Card issuer that indicate current valid or invalid FASC-N or card UUID values SHALL be updated to reflect the change in status. 2.9.4 ¶ 2 Bullet 3
    In addition, the PIV Card termination procedures SHALL ensure that all derived PIV credentials bound to the PIV identity account are invalidated as specified in Section 2.10.2. 2.9.4 ¶ 3
    {PIV card} If the card cannot be collected, normal termination procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.4 ¶ 4
    {PIV card} If the card cannot be collected, normal termination procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.4 ¶ 4
    {not be destroyed} {not be collected} The revocation process SHALL include the following: If the old PIV Card cannot be collected and destroyed, or if the old PIV Card has been compromised or damaged, then the Certification Authority (CA) SHALL be informed and the certificates corresponding to the PIV authentication key (Section 4.2.2.1) and asymmetric card authentication key (Section 4.2.2.2) on the old PIV Card SHALL be revoked. If present, the certificates corresponding to the digital signature key (Section 4.2.2.1) and the key management key (Section 4.2.2.5) SHALL also be revoked. 2.9.1 ¶ 4 Bullet 3
    {not be destroyed} {not be collected} The revocation process SHALL include the following: If the old PIV Card cannot be collected and destroyed, or if the old PIV Card has been compromised or damaged, then the Certification Authority (CA) SHALL be informed and the certificates corresponding to the PIV authentication key (Section 4.2.2.1) and asymmetric card authentication key (Section 4.2.2.2) on the old PIV Card SHALL be revoked. If present, the certificates corresponding to the digital signature key (Section 4.2.2.1) and the key management key (Section 4.2.2.5) SHALL also be revoked. 2.9.1 ¶ 4 Bullet 3
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: If the PIV Card cannot be collected and destroyed, the CA SHALL be informed and the certificates corresponding to the PIV authentication key and the asymmetric card authentication key on the PIV Card SHALL be revoked. The certificates corresponding to the digital signature and key management keys SHALL also be revoked, if present. 2.9.4 ¶ 2 Bullet 4
    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 employee separates (voluntarily or involuntarily) from federal service. 2.9.4 ¶ 1 Bullet 1
    Derived PIV credentials SHALL be invalidated in any of the following circumstances: when the associated PIV Card is terminated as specified in Section 2.9.4—in this situation, all derived PIV credentials associated with the PIV identity account SHALL be invalidated. 2.10.2 ¶ 1 Bullet 4
    The revocation process SHALL include the following: Any databases maintained by the PIV Card issuer that contain FASC-N or card UUID values from the old PIV Card must be updated to reflect the change in status. 2.9.1 ¶ 4 Bullet 2
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Card management systems SHALL be updated to reflect PIV Card termination and method of termination (e.g., PIV Card destruction for collected PIV Cards or certificate revocations for uncollected PIV Cards). 2.9.4 ¶ 2 Bullet 5
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Card management systems SHALL be updated to reflect PIV Card termination and method of termination (e.g., PIV Card destruction for collected PIV Cards or certificate revocations for uncollected PIV Cards). 2.9.4 ¶ 2 Bullet 5]
    Physical and environmental protection Preventive
    Establish, implement, and maintain a personnel management program. CC ID 14018 Human Resources management Preventive
    Establish, implement, and maintain a personnel security program. CC ID 10628 Human Resources management Preventive
    Establish, implement, and maintain security clearance level criteria. CC ID 00780 Human Resources management Preventive
    Establish, implement, and maintain personnel screening procedures. CC ID 11700
    [For full guidance on PIV credentialing investigative and adjudicative requirements, to include continuous vetting, issuers must work closely with their personnel security/suitability offices to ensure adherence to the latest federal personnel vetting guidance as provided by the Executive Agents. 2.2 ¶ 6
    Federal departments and agencies must follow investigative requirements established by the Suitability and Credentialing Executive Agent and the Security Executive Agent. Departments and agencies SHALL use position designation guidance issued by the Executive Agents. The designation of the position determines the prerequisite investigative requirement. Individuals being processed for a PIV Card SHALL receive the required investigation and are subject to any applicable reinvestigation or continuous vetting requirements to maintain their PIV eligibility. 2.2 ¶ 2]
    Human Resources management Preventive
    Perform a criminal records check during personnel screening. CC ID 06643
    [Biometric identification using fingerprints is the primary input to law enforcement checks. In cases where ten fingerprints are not available, then as many fingers as possible SHALL be imaged as per guidance in [SP 800-76]. In cases where no fingers are available to be imaged, agencies SHALL seek guidance from their respective investigative service provider for alternative means of performing law enforcement checks. 2.3 ¶ 3]
    Human Resources management Preventive
    Document any reasons a full criminal records check could not be performed. CC ID 13305 Human Resources management Preventive
    Perform an academic records check during personnel screening. CC ID 06647 Human Resources management Preventive
    Establish, implement, and maintain security clearance procedures. CC ID 00783
    [For linking to background investigations, only fingerprints SHALL be used, since fingerprints are the only biometric characteristic used for background investigations. For all other purposes, verification attempts MAY be performed against any available biometric characteristic stored electronically on the PIV Card or in the enrollment record. 2.5 ¶ 7]
    Human Resources management Preventive
    Document the security clearance procedure results. CC ID 01635 Human Resources management Detective
    Establish, implement, and maintain training plans. CC ID 00828 Human Resources management Preventive
    Establish, implement, and maintain a disability accessibility program. CC ID 06191
    [There are methods by which proper card orientation can be indicated. Section 4.1.4.3, for example, defines Zones 21F and 22F, where card orientation features MAY be applied. Note: If an agency determines that tactilely discernible markers for PIV Cards impose an undue burden, the agency SHALL implement policies and procedures to accommodate employees and contractors with disabilities in accordance with Sections 501 and 504 of the Rehabilitation Act. 4.1.3 ¶ 6]
    Operational management Preventive
    Establish, implement, and maintain web content accessibility guidelines. CC ID 14949 Operational management Preventive
    Refrain from creating instructions for content that rely on sensory characteristics of components. CC ID 15124 Operational management Preventive
    Include contact details in the registration database. CC ID 15109 Operational management Preventive
    Include personal data in the registration database, as necessary. CC ID 15108
    [{data in transit}{data at rest} PIV enrollment records contain Personally Identifiable Information (PII). PII SHALL be protected in a manner that protects the individual’s privacy and maintains the integrity of the records both in transit and at rest. 2.6 ¶ 5]
    Operational management Preventive
    Establish, implement, and maintain system hardening procedures. CC ID 12001 System hardening through configuration management Preventive
    Establish, implement, and maintain an authenticator standard. CC ID 01702
    [{be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2]
    System hardening through configuration management Preventive
    Establish, implement, and maintain an authenticator management system. CC ID 12031 System hardening through configuration management Preventive
    Establish, implement, and maintain authenticator procedures. CC ID 12002 System hardening through configuration management Preventive
    Configure the "minimum number of digits required for new passwords" setting to organizational standards. CC ID 08717 System hardening through configuration management Preventive
    Configure the "minimum number of upper case characters required for new passwords" setting to organizational standards. CC ID 08718 System hardening through configuration management Preventive
    Configure the "minimum number of lower case characters required for new passwords" setting to organizational standards. CC ID 08719 System hardening through configuration management Preventive
    Configure the "minimum number of special characters required for new passwords" setting to organizational standards. CC ID 08720 System hardening through configuration management Preventive
    Configure the "require new passwords to differ from old ones by the appropriate minimum number of characters" setting to organizational standards. CC ID 08722 System hardening through configuration management Preventive
    Configure the "password reuse" setting to organizational standards. CC ID 08724 System hardening through configuration management Preventive
    Configure the "shadow password for all accounts in /etc/passwd" setting to organizational standards. CC ID 08721 System hardening through configuration management Preventive
    Configure the "password hashing algorithm" setting to organizational standards. CC ID 08723 System hardening through configuration management Preventive
    Establish, implement, and maintain records management policies. CC ID 00903 Records management Preventive
    Define each system's preservation requirements for records and logs. CC ID 00904 Records management Detective
    Establish, implement, and maintain a data retention program. CC ID 00906 Records management Detective
    Establish, implement, and maintain a system design specification. CC ID 04557 Systems design, build, and implementation Preventive
    Establish, implement, and maintain a privacy framework that protects restricted data. CC ID 11850 Privacy protection for information and data Preventive
    Establish and maintain privacy notices, as necessary. CC ID 13443 Privacy protection for information and data Preventive
    Include the types of third parties to which personal data is disclosed in the privacy notice. CC ID 13459
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Preventive
    Include the organization's policies, standards, and procedures in the privacy notice. CC ID 13455 Privacy protection for information and data Preventive
    Include the organization's privacy framework in the privacy notice, as necessary. CC ID 13456
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Preventive
    Include the types of personal data disclosed in the privacy notice. CC ID 13446
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Preventive
    Include descriptions of each type of personal data disclosed in the privacy notice. CC ID 13458 Privacy protection for information and data Preventive
    Provide adequate structures, policies, procedures, and mechanisms to support direct access by the data subject to personal data that is provided upon request. CC ID 00393 Privacy protection for information and data Preventive
    Provide the data subject with a description of the type of information held by the organization and a general account of its use. CC ID 00397
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3
    {parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Preventive
    Establish, implement, and maintain a personal data accountability program. CC ID 13432 Privacy protection for information and data Preventive
    Establish, implement, and maintain a personal data use limitation program. CC ID 13428 Privacy protection for information and data Preventive
    Establish, implement, and maintain a personal data use purpose specification. CC ID 00093 Privacy protection for information and data Preventive
    Establish, implement, and maintain restricted data use limitation procedures. CC ID 00128 Privacy protection for information and data Preventive
    Document the conditions for the use or disclosure of Individually Identifiable Health Information by a covered entity to another covered entity. CC ID 00210 Privacy protection for information and data Preventive
    Disclose Individually Identifiable Health Information for research use when the appropriate requirements are included in the approval documentation or waiver documentation. CC ID 06257 Privacy protection for information and data Preventive
    Document the conditions for the disclosure of Individually Identifiable Health Information by an organization providing healthcare services to organizations other than business associates or other covered entities. CC ID 00201 Privacy protection for information and data Preventive
    Document how Individually Identifiable Health Information is used and disclosed when authorization has been granted. CC ID 00216 Privacy protection for information and data Preventive
    Define and implement valid authorization control requirements. CC ID 06258 Privacy protection for information and data Preventive
    Establish, implement, and maintain restricted data retention procedures. CC ID 00167
    [PIV background investigation, identity proofing, registration, and issuance processes MAY be performed across multiple sessions at different facilities. If multiple sessions are needed, the applicant SHALL be linked through a positive biometric verification decision obtained from an automated comparison of biometric characteristics captured at a previous session to biometric characteristics captured during the current session. Issuers SHALL follow applicable federal laws and regulations regarding the retention and destruction of biometric data. 2.5 ¶ 6]
    Privacy protection for information and data Preventive
    Establish, implement, and maintain personal data disposition procedures. CC ID 13498
    [PIV background investigation, identity proofing, registration, and issuance processes MAY be performed across multiple sessions at different facilities. If multiple sessions are needed, the applicant SHALL be linked through a positive biometric verification decision obtained from an automated comparison of biometric characteristics captured at a previous session to biometric characteristics captured during the current session. Issuers SHALL follow applicable federal laws and regulations regarding the retention and destruction of biometric data. 2.5 ¶ 6
    {privacy policy} The PII collected from the cardholder SHALL be disposed of in accordance with the stated privacy and data retention policies of the department or agency. 2.9.4 ¶ 5]
    Privacy protection for information and data Preventive
    Establish, implement, and maintain a personal data collection program. CC ID 06487 Privacy protection for information and data Preventive
    Establish, implement, and maintain personal data collection limitation boundaries. CC ID 00507 Privacy protection for information and data Preventive
    Establish, implement, and maintain a data handling program. CC ID 13427 Privacy protection for information and data Preventive
    Establish, implement, and maintain data handling policies. CC ID 00353 Privacy protection for information and data Preventive
    Establish, implement, and maintain data and information confidentiality policies. CC ID 00361 Privacy protection for information and data Preventive
    Establish, implement, and maintain a privacy impact assessment. CC ID 13712
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Conduct a comprehensive Privacy Impact Assessment (PIA) and a periodic review and update of the assessment on systems containing PII for the purpose of implementing PIV consistent with the methodology of [E-Gov] and the requirements of [M-03-22]. Consult with appropriate personnel responsible for privacy issues at the department or agency (e.g., Chief Information Officer) implementing the PIV system. 2.11 ¶ 3 Bullet 2
    To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Conduct a comprehensive Privacy Impact Assessment (PIA) and a periodic review and update of the assessment on systems containing PII for the purpose of implementing PIV consistent with the methodology of [E-Gov] and the requirements of [M-03-22]. Consult with appropriate personnel responsible for privacy issues at the department or agency (e.g., Chief Information Officer) implementing the PIV system. 2.11 ¶ 3 Bullet 2]
    Privacy protection for information and data Preventive
    Include the individuals with whom information is shared in the privacy impact assessment. CC ID 15520 Privacy protection for information and data Preventive
    Include how to grant consent in the privacy impact assessment. CC ID 15519 Privacy protection for information and data Preventive
    Include the opportunities for individuals to consent to using their information in the privacy impact assessment. CC ID 15518 Privacy protection for information and data Preventive
    Include the opportunities for opting out of information collection in the privacy impact assessment. CC ID 15517 Privacy protection for information and data Preventive
    Include data handling procedures in the privacy impact assessment. CC ID 15516 Privacy protection for information and data Preventive
    Include the intended use of information in the privacy impact assessment. CC ID 15515 Privacy protection for information and data Preventive
    Include the reason information is being collected in the privacy impact assessment. CC ID 15514 Privacy protection for information and data Preventive
    File privacy rights violation complaints in writing. CC ID 00477 Privacy protection for information and data Corrective
    Include the acts or omissions that are in violation of privacy rights in the privacy rights violation complaint. CC ID 14360 Privacy protection for information and data Corrective
    Include the individual's name who is the subject of the complaint in the privacy rights violation complaint. CC ID 14359 Privacy protection for information and data Preventive
    Establish, implement, and maintain a privacy dispute resolution program. CC ID 12526 Privacy protection for information and data Preventive
    Include potential remedies in the privacy dispute resolution program. CC ID 12531 Privacy protection for information and data Preventive
    Provide the data subject with the name, title, and address to whom complaints are forwarded. CC ID 00395 Privacy protection for information and data Preventive
    Include the time frames in which privacy rights violation complaints are processed in the privacy dispute resolution program. CC ID 12529 Privacy protection for information and data Preventive
    Document unresolved challenges. CC ID 13568 Privacy protection for information and data Preventive
    Establish, implement, and maintain an accuracy resolution policy. CC ID 00460 Privacy protection for information and data Preventive
    Document disagreements as to whether personal data is complete and accurate. CC ID 06952 Privacy protection for information and data Preventive
    Include the change to the personal data that the data subject requested and the reason the organization refused to make the change in the statement of disagreement. CC ID 06954 Privacy protection for information and data Preventive
    Include the allegations against the organization in the notice of investigation. CC ID 13031 Privacy protection for information and data Preventive
    Create an investigative report in regards to a privacy rights violation complaint. CC ID 00495 Privacy protection for information and data Corrective
    Define the available administrative remedies in regards to a privacy rights violation complaint. CC ID 00497 Privacy protection for information and data Detective
    Define the organization's liability based on the applicable law. CC ID 00504 Privacy protection for information and data Preventive
    Define the sanctions and fines available for privacy rights violations based on applicable law. CC ID 00505 Privacy protection for information and data Preventive
    Define the appeal process based on the applicable law. CC ID 00506 Privacy protection for information and data Preventive
    Provide notice of proposed penalties. CC ID 06216 Privacy protection for information and data Preventive
    Establish, implement, and maintain customer data authentication procedures. CC ID 13187 Privacy protection for information and data Preventive
  • Human Resources Management
    20
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Align disciplinary actions with the level of compliance violation. CC ID 12404 Monitoring and measurement Preventive
    Assign roles and responsibilities for administering user account management. CC ID 11900 Technical security Preventive
    Require multiple forms of personal identification prior to issuing user identifiers. CC ID 08712
    [{does not occur} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that No substitution occurs in the identity proofing process. More specifically, the individual who appears for identity proofing and whose fingerprints are checked against databases is the person to whom the credential is issued. 2.1 ¶ 2 Bullet 6
    Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that An individual is issued a credential only after presenting two identity source documents, at least one of which is a Federal or State Government-issued picture ID. 2.1 ¶ 2 Bullet 3
    Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential is issued to an individual only after a proper authority has authorized issuance of the credential, the individual’s identity has been verified, and the individual has been vetted per Section 2.2. 2.1 ¶ 2 Bullet 1]
    Technical security Preventive
    Establish and maintain Personnel Files for all employees. CC ID 12438 Human Resources management Preventive
    Include background check results in each employee's personnel file. CC ID 12439
    [{background investigation} Once the investigation is completed, the authorized adjudicative entity SHALL adjudicate the investigation and report the final eligibility determination to the Central Verification System (or successor) and, if applicable, their enrollment in the Continuous Vetting Program as defined in [EO 13764]. This determination SHALL be recorded in or referenced by the PIV enrollment record to reflect PIV eligibility for the PIV cardholder. 2.2 ¶ 5
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2]
    Human Resources management Preventive
    Establish, implement, and maintain staff position risk designations. CC ID 14280
    [Federal departments and agencies must follow investigative requirements established by the Suitability and Credentialing Executive Agent and the Security Executive Agent. Departments and agencies SHALL use position designation guidance issued by the Executive Agents. The designation of the position determines the prerequisite investigative requirement. Individuals being processed for a PIV Card SHALL receive the required investigation and are subject to any applicable reinvestigation or continuous vetting requirements to maintain their PIV eligibility. 2.2 ¶ 2]
    Human Resources management Preventive
    Perform a background check during personnel screening. CC ID 11758
    [{does not exist} For individuals for whom no prior investigation exists, the appropriate required investigation SHALL be initiated with the authorized federal investigative service provider and the FBI NCHC portion of the background investigation SHALL be completed and favorably adjudicated prior to PIV Card issuance. 2.2 ¶ 4]
    Human Resources management Detective
    Perform a personal identification check during personnel screening. CC ID 06721 Human Resources management Preventive
    Perform a personal references check during personnel screening. CC ID 06645 Human Resources management Preventive
    Perform a credit check during personnel screening. CC ID 06646 Human Resources management Preventive
    Perform a resume check during personnel screening. CC ID 06659 Human Resources management Preventive
    Perform a curriculum vitae check during personnel screening. CC ID 06660 Human Resources management Preventive
    Allow personnel being screened to appeal findings and appeal decisions. CC ID 06720 Human Resources management Preventive
    Perform personnel screening procedures, as necessary. CC ID 11763
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential is issued to an individual only after a proper authority has authorized issuance of the credential, the individual’s identity has been verified, and the individual has been vetted per Section 2.2. 2.1 ¶ 2 Bullet 1]
    Human Resources management Preventive
    Perform periodic background checks on designated roles, as necessary. CC ID 11759
    [{are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2]
    Human Resources management Detective
    Perform security clearance procedures, as necessary. CC ID 06644 Human Resources management Preventive
    Establish and maintain security clearances. CC ID 01634 Human Resources management Preventive
    Include duties and responsibilities in the training plan, as necessary. CC ID 12800 Human Resources management Preventive
    Assign ownership of the privacy program to the appropriate organizational role. CC ID 11848
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Assign an individual to the role of privacy official. The privacy official is the individual who oversees privacy-related matters in the PIV system and is responsible for implementing the privacy requirements in the Standard. The individual serving in this role SHALL NOT assume any other operational role in the PIV system. 2.11 ¶ 3 Bullet 1]
    Privacy protection for information and data Preventive
    Notify individuals of their ability to challenge personal behavioral assessments on record. CC ID 04798 Privacy protection for information and data Preventive
  • IT Impact Zone
    11
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Leadership and high level objectives CC ID 00597 Leadership and high level objectives IT Impact Zone
    Monitoring and measurement CC ID 00636 Monitoring and measurement IT Impact Zone
    Technical security CC ID 00508 Technical security IT Impact Zone
    Physical and environmental protection CC ID 00709 Physical and environmental protection IT Impact Zone
    Human Resources management CC ID 00763 Human Resources management IT Impact Zone
    Operational management CC ID 00805 Operational management IT Impact Zone
    System hardening through configuration management CC ID 00860 System hardening through configuration management IT Impact Zone
    Records management CC ID 00902 Records management IT Impact Zone
    Systems design, build, and implementation CC ID 00989 Systems design, build, and implementation IT Impact Zone
    Privacy protection for information and data CC ID 00008 Privacy protection for information and data IT Impact Zone
    Third Party and supply chain oversight CC ID 08807 Third Party and supply chain oversight IT Impact Zone
  • Investigate
    6
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Determine the causes of compliance violations. CC ID 12401 Monitoring and measurement Corrective
    Determine if multiple compliance violations of the same type could occur. CC ID 12402 Monitoring and measurement Detective
    Review the effectiveness of disciplinary actions carried out for compliance violations. CC ID 12403 Monitoring and measurement Detective
    Verify proof of identity records. CC ID 13761
    [During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    {refrain from implementing}{not be consistent} Departments and agencies may have a wide variety of uses for the PIV system and its components that were not intended or anticipated by the President in issuing [HSPD-12]. In considering whether a proposed use of the PIV system is appropriate, departments and agencies SHALL consider the aforementioned control objectives and the purpose of this Standard, namely “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy” as per [HSPD-12]. No department or agency SHALL implement a use of the identity credential inconsistent with these control objectives. 2.11 ¶ 2
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    Departments and agencies SHALL ensure that driver’s licenses and ID cards presented by applicants comply with [REAL-ID] when required pursuant to DHS regulations. Stateissued driver’s licenses and ID cards that are not [REAL-ID] compliant MAY be used until the full enforcement date under [6 CFR § 37.5]. Departments and agencies SHALL ensure that driver’s licenses and ID cards presented by applicants comply with [REAL-ID] when required pursuant to DHS regulations. Stateissued driver’s licenses and ID cards that are not [REAL-ID] compliant MAY be used until the full enforcement date under [6 CFR § 37.5]. 2.7 ¶ 9
    {not be successful}{not acquire} OCC reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operatorground-color:#CBD0E5;" class="term_secondary-verb"> SHALL <span style="background-color:#B7D8ED;" class="term_primary-verb">inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 6]
    Technical security Detective
    Scan for malicious code, as necessary. CC ID 11941 Technical security Detective
    Analyze requirements for processing personal data in contracts. CC ID 12550 Privacy protection for information and data Detective
  • Monitor and Evaluate Occurrences
    9
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Include the capturing and alerting of compliance violations in the notification system. CC ID 12962 Leadership and high level objectives Preventive
    Include the capturing and alerting of unethical conduct in the notification system. CC ID 12932 Leadership and high level objectives Preventive
    Include the capturing and alerting of performance variances in the notification system. CC ID 12929 Leadership and high level objectives Preventive
    Include the capturing and alerting of weaknesses in the notification system. CC ID 12928 Leadership and high level objectives Preventive
    Include the capturing and alerting of account activity in the notification system. CC ID 15314 Leadership and high level objectives Preventive
    Monitor personnel and third parties for compliance to the organizational compliance framework. CC ID 04726
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that the technologies used in the department or agency’s implementation of the PIV system allow for continuous auditing of compliance with stated privacy policies and with practices governing the collection, use, and distribution of information in the operation of the program. 2.11 ¶ 3 Bullet 9]
    Monitoring and measurement Detective
    Enforce information flow control. CC ID 11781 Technical security Preventive
    Log and react to all malicious code activity. CC ID 07072 Technical security Detective
    Establish, implement, and maintain an anti-tamper protection program. CC ID 10638 Physical and environmental protection Detective
  • Physical and Environmental Protection
    4
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Protect assets from tampering or unapproved substitution. CC ID 11902
    [{PIV Card}{anti-counterfeiting technique} All security features SHOULD maintain their function for the life of the card. As a generally accepted security procedure, federal departments and agencies SHOULD periodically review the viability, effectiveness, and currency of employed tamper resistance and anti-counterfeiting methods. 4.1.2 ¶ 10]
    Physical and environmental protection Preventive
    Control physical access to (and within) the facility. CC ID 01329 Physical and environmental protection Preventive
    Report lost badges, stolen badges, and broken badges to the Security Manager. CC ID 12334
    [{lost identification card or badge}{stolen identification card or badge}{stipulated time frame} In the case of a lost, stolen, or compromised card, normal revocation procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay, and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.1 ¶ 5]
    Physical and environmental protection Preventive
    Include environmental impacts of product information in anti-counterfeit testing. CC ID 11617 Third Party and supply chain oversight Preventive
  • Process or Activity
    50
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Correct compliance violations. CC ID 13515 Monitoring and measurement Corrective
    Implement digital identification processes. CC ID 13731 Technical security Preventive
    Implement identity proofing processes. CC ID 13719
    [The department or agency SHALL adopt and use an identity proofing and registration process that is approved in accordance with [SP 800-79]. 2.7 ¶ 2
    [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 specified in this Standard, as well as those specified in federal privacy laws and policies including but not limited to the E-Government Act of 2002 [E-Gov], the Privacy Act of 1974 [PRIVACY], and OMB [M-03-22], as applicable. 2.11 ¶ 1
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    {refrain from implementing}{not be consistent} Departments and agencies may have a wide variety of uses for the PIV system and its components that were not intended or anticipated by the President in issuing [HSPD-12]. In considering whether a proposed use of the PIV system is appropriate, departments and agencies SHALL consider the aforementioned control objectives and the purpose of this Standard, namely “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy” as per [HSPD-12]. No department or agency SHALL implement a use of the identity credential inconsistent with these control objectives. 2.11 ¶ 2
    The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. 2.7 ¶ 11]
    Technical security Preventive
    Verify the identity of the organization's authorized representative during the identity proofing process. CC ID 13786 Technical security Preventive
    Allow authorized representatives to act on behalf of the data subject during the identity proofing process. CC ID 13787 Technical security Preventive
    Refrain from performing identity proofing as a means of providing access to systems or services. CC ID 13776 Technical security Detective
    Support the identity proofing process through in-person proofing or remote proofing. CC ID 13750 Technical security Preventive
    Interact with the data subject when performing remote proofing. CC ID 13777
    [{identity proofing} The following forms of protection SHALL be provided by either inherent capabilities of the station or staff at the station location: ensuring that only the applicant interacts with the station during any session; 2.7.1 ¶ 3 Bullet 1
    Supervised remote identity proofing SHALL meet the following requirements: The issuer SHALL have a live operator participate remotely with the applicant for the entirety of the identity proofing session. 2.7.1 ¶ 4 Bullet 2]
    Technical security Detective
    Use valid activation codes to complete the identity proofing process when performing remote proofing. CC ID 13742 Technical security Preventive
    View all applicant actions when performing remote proofing. CC ID 13804
    [Supervised remote identity proofing SHALL meet the following requirements: The operator SHALL monitor the entire identity proofing session—from which the applicant SHALL NOT depart—by at least one continuous, high-resolution video transmission of the applicant. 2.7.1 ¶ 4 Bullet 4
    Supervised remote identity proofing SHALL meet the following requirements: The operator SHALL require all actions taken by the applicant during the identity proofing session to be clearly visible to the operator. 2.7.1 ¶ 4 Bullet 5
    Supervised remote identity proofing SHALL meet the following requirements: The station SHALL be maintained in a controlled-access environment and SHALL be monitored by staff at the station location while it is being used. 2.7.1 ¶ 4 Bullet 1
    {not be successful}{not acquire} OCC reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 6]
    Technical security Detective
    Employ knowledge-based authentication tools to aid the identity proofing process. CC ID 13741 Technical security Preventive
    Verify transaction history as part of the knowledge-based authentication questions during the identity proofing process. CC ID 13755 Technical security Detective
    Base the knowledge-based authentication for the identity proofing process on authoritative sources. CC ID 13743 Technical security Detective
    Refrain from using publicly available information for knowledge-based authentication during the identity proofing process. CC ID 13752 Technical security Preventive
    Refrain from using knowledge-based authentication questions that hint at their own answers during the identity proofing process. CC ID 13785 Technical security Preventive
    Refrain from revealing the data subject's personal data in knowledge-based authentication questions for the identity proofing process. CC ID 13774 Technical security Detective
    Refrain from using static knowledge-based authentication questions during the identity proofing process. CC ID 13773 Technical security Preventive
    Use information from authoritative sources or the applicant for knowledge-based authentication during the identity proofing process. CC ID 13749 Technical security Preventive
    Refrain from using diversionary knowledge-based authentication questions during the identity proofing processes. CC ID 13744 Technical security Detective
    Validate proof of identity during the identity proofing process. CC ID 13756
    [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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1]
    Technical security Detective
    Inspect for the presence of man-made materials when performing biometric authentication during the identity proofing process. CC ID 13803 Technical security Detective
    Refrain from using knowledge-based authentication to verify an individual's identity against more than one proof of identity during the identity proofing process. CC ID 13784 Technical security Detective
    Allow records that relate to the data subject as proof of identity. CC ID 13772
    [During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6]
    Technical security Preventive
    Conduct in-person proofing with physical interactions. CC ID 13775
    [{appear in person} If biometric data cannot be collected per the criteria defined in [SP 800-76] or if validation of the identity evidence is inadequate, supervised remote identity proofing SHALL NOT be used and the identity proofing and enrollment will be performed in person at the issuer’s facility. The trained operator SHALL terminate a supervised remote identity proofing session and require in-person identity proofing at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.7.1 ¶ 5
    {appear in person} If biometric data cannot be collected per the criteria defined in [SP 800-76] or if validation of the identity evidence is inadequate, supervised remote identity proofing SHALL NOT be used and the identity proofing and enrollment will be performed in person at the issuer’s facility. The trained operator SHALL terminate a supervised remote identity proofing session and require in-person identity proofing at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.7.1 ¶ 5]
    Technical security Detective
    Include the consequences of refraining from providing attributes in the identity proofing process. CC ID 13748 Technical security Preventive
    Send a notification of proofing to a confirmed address of record when performing in-person proofing. CC ID 13739 Technical security Preventive
    Refrain from using unconfirmed self-asserted address data during the identity proofing process. CC ID 13738 Technical security Preventive
    Refrain from approving attributes in the identity proofing process. CC ID 13716 Technical security Preventive
    Reperform the identity proofing process for each individual, as necessary. CC ID 13762 Technical security Detective
    Define the activation requirements for identification cards or badges. CC ID 06583
    [{does not exist} For individuals for whom no prior investigation exists, the appropriate required investigation SHALL be initiated with the authorized federal investigative service provider and the FBI NCHC portion of the background investigation SHALL be completed and favorably adjudicated prior to PIV Card issuance. 2.2 ¶ 4
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1]
    Technical security Preventive
    Disallow self-enrollment of biometric information. CC ID 11834 Technical security Preventive
    Define the asymmetric signature field for the CHUID container on identification cards or badges. CC ID 06584
    [This Standard requires inclusion of the asymmetric signature field in the CHUID container. The asymmetric signature data element of the CHUID SHALL be encoded as a Cryptographic Message Syntax (CMS) external digital signature, as specified in [SP 800-73]. Algorithm and key size requirements for the asymmetric signature and digest algorithm are detailed in [SP 800-78]. 4.2.1 ¶ 6
    This Standard requires inclusion of the asymmetric signature field in the CHUID container. The asymmetric signature data element of the CHUID SHALL be encoded as a Cryptographic Message Syntax (CMS) external digital signature, as specified in [SP 800-73]. Algorithm and key size requirements for the asymmetric signature and digest algorithm are detailed in [SP 800-78]. 4.2.1 ¶ 6]
    Technical security Preventive
    Implement cryptographic operations and support functions on identification cards or badges. CC ID 06585
    [This Standard also defines two data elements for the PIV Card data model that are mandatory if the cardholder has a government-issued email account at the time of PIV Card issuance. These data elements are an asymmetric private key and corresponding certificate for digital signatures, and 4.2 ¶ 3 Bullet 1
    The PIV Card SHALL implement the cryptographic operations and support functions defined in [SP 800-78] and [SP 800-73]. 4.2.2 ¶ 1
    {be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1
    {be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1
    {be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1
    PIV Cards consistent with this specification SHALL have two or more asymmetric private keys. To manage the public keys associated with the asymmetric private keys, departments and agencies SHALL issue and manage X.509 public key certificates as specified in this section. 5 ¶ 2
    PIV Cards consistent with this specification SHALL have two or more asymmetric private keys. To manage the public keys associated with the asymmetric private keys, departments and agencies SHALL issue and manage X.509 public key certificates as specified in this section. 5 ¶ 2
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 be available through the contact and contactless interfaces of the PIV Card and SHALL NOT be available through the virtual contact interface of the PIV Card. Private key operations MAY be performed using this key without card activation (e.g., the PIN need not be supplied for operations with this key). 4.2.2.2 ¶ 1
    {contact interface} 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 be available through the contact and contactless interfaces of the PIV Card and SHALL NOT be available through the virtual contact interface of the PIV Card. Private key operations MAY be performed using this key without card activation (e.g., the PIN need not be supplied for operations with this key). 4.2.2.2 ¶ 1
    {contact interface} 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 be available through the contact and contactless interfaces of the PIV Card and SHALL NOT be available through the virtual contact interface of the PIV Card. Private key operations MAY be performed using this key without card activation (e.g., the PIN need not be supplied for operations with this key). 4.2.2.2 ¶ 1
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17
    With the exception of the card authentication key and keys used to establish secure messaging, cryptographic private key operations SHALL be performed only through the contact interface or the virtual contact interface. Any operation that MAY be performed over the contact interface of the PIV Card MAY also be performed over the virtual contact interface. Requirements for the virtual contact interface are specified in [SP 800-73]. With the exception of the card authentication key and keys used to establish secure messaging, cryptographic private key operations SHALL be performed only through the contact interface or the virtual contact interface. Any operation that MAY be performed over the contact interface of the PIV Card MAY also be performed over the virtual contact interface. Requirements for the virtual contact interface are specified in [SP 800-73]. 4.2.2 ¶ 18]
    Technical security Preventive
    Define the format of the biometric data on identification cards or badges. CC ID 06586
    [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 4.2.3.3 ¶ 1 Bullet 1
    OCC MAY be performed over the contact and contactless interfaces of the PIV Card to support card activation (Section 4.3.1) and cardholder authentication (Section 6.2.2). The fingerprint biometric templates for OCC SHALL NOT be exportable. If implemented, OCC SHALL be implemented and used in accordance with [SP 800-73] and [SP 800-76]. 4.2.3.3 ¶ 2
    OCC MAY be performed over the contact and contactless interfaces of the PIV Card to support card activation (Section 4.3.1) and cardholder authentication (Section 6.2.2). The fingerprint biometric templates for OCC SHALL NOT be exportable. If implemented, OCC SHALL be implemented and used in accordance with [SP 800-73] and [SP 800-76]. 4.2.3.3 ¶ 2]
    Technical security Preventive
    Remove malware when malicious code is discovered. CC ID 13691 Technical security Corrective
    Record the assigned identification card or badge serial number when issuing an identification card or badge. CC ID 06714 Physical and environmental protection Preventive
    Include identity proofing processes in the identification issuance procedures. CC ID 06597
    [Biometric data used to personalize the PIV Card SHALL be those captured during the identity proofing and registration process. 2.8 ¶ 1 Bullet 4
    The applicant SHALL appear in person at least once before the issuance of a PIV Card, either at the issuing facility or at a supervised remote identity proofing station (as described in Section 2.7.1). 2.7 ¶ 5
    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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {negative biometric verification decision} {are not available} The issuer SHALL perform a biometric verification of the applicant to the biometric data records of the PIV enrollment record or to the biometric data records of the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. Minimum accuracy requirements for the biometric verification are specified in [SP 800-76]. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.9.1 ¶ 3
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2
    {not acquire} When PIN reset is performed in person at the issuing facility, before providing the reset PIV Card back to the cardholder, the issuer SHALL perform a biometric verification to ensure that the cardholder’s biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect the identity document and <span style="background-color:#B7D8ED;" claground-color:#CBD0E5;" class="term_secondary-verb">ss="term_primary-verb">compare the "background-color:#F0BBBC;" class="term_primary-noun">cardholder with the electronic facial image retrieved from the enrollment data record and the ass="term_primary-noun">photograph printed on the card. 2.9.3.1 ¶ 3]
    Physical and environmental protection Preventive
    Include all residences in the criminal records check. CC ID 13306 Human Resources management Preventive
    Establish, implement, and maintain identification card or badge architectural designs. CC ID 06591
    [{applicable requirements} The PIV Card SHALL be maintained using processes that comply with this section. 2.9 ¶ 1
    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 Card Design Standard classifies security features into three categories, depending on the inspection level required for verification: 4.1.2 ¶ 1
    As noted in Section 4.1.3, the PIV Card SHALL contain a contact and a contactless ICC interface. This Standard does not specify the number of chips used to support the mandated contact and contactless interfaces. 4.1.4 ¶ 2
    The PIV Card SHALL contain a contact and a contactless ICC interface. 4.1.3 ¶ 2
    To achieve a common PIV Card appearance and provide departments and agencies with the flexibility to augment the card with department-or agency-specific requirements, the card SHALL contain printed information and machine-readable technologies. Mandated and optional items SHALL be placed as described and depicted. Printed data SHALL NOT interfere with machine-readable technology. 4.1.4 ¶ 3
    {PIV Card} Areas that are marked as reserved SHOULD NOT be used for printing. The reason for the recommended reserved areas is that placement of the embedded contactless ICC module may vary between manufacturers, and there are constraints that prohibit printing over the embedded contactless module. The PIV Card topography provides flexibility for placement of the embedded module, either in the upper right corner or in the lower portion. Printing restrictions apply only to the area where the embedded module is located. 4.1.4 ¶ 4
    {contact interface}{not require} The CHUID SHALL be accessible from both the contact and contactless interfaces of the PIV Card without card activation. 4.2.1 ¶ 4
    {PIV Card} 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 SHALL follow recommendations set forth in [SP 800-76]. 4.1.4.1 ¶ 2
    {PIV Card}{anti-counterfeiting technique} All security features SHOULD maintainspan> their function for the life of the card. As a generally accepted security procedure, federal departments and agencies SHOULD periodically review the viability, effectiveness, and currency of employed tamper resistance and anti-counterfeiting methods. 4.1.2 ¶ 10
    {pre-determined and authorized location} If used, the department or agency SHALL place the cardholder signature below the photograph and cardholder name, as depicted in Figure 4-3. The space for the signature SHALL NOT interfere with the placement of the ICCs and related components. Because of card surface space constraints, placement of a signature may limit the size of the optional two-dimensional bar code. 4.1.4.3 ¶ 3
    {issuing organization}{pre-determined and authorized location}{be visible} The Agency seal in Zone 11F may become a mandatory field in the next revision of the Standard. If used, the seal selected by the issuing department, agency, or organization SHALL be printed in the area depicted. It SHALL be printed using the n">guidelines provided in Figure 4-2 to ensure that information printed on the seal ss="term_secondary-verb">is legible and clearly visible. 4.1.4.3 ¶ 13
    If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process s="term_secondary-verb">are not adversely impacted. If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 29]
    Systems design, build, and implementation Preventive
    Define the physical requirements for identification cards or badges in the identification card or badge architectural designs. CC ID 06592
    [{PIV Card} Decals SHALL NOT be adhered to the card. 4.1.3 ¶ 9
    {applicable requirements} The PIV Card SHALL comply with the physical characteristics described in [ISO 7810], [ISO 10373], and [ISO 7816] for contact cards in addition to [ISO 14443] for contactless cards. 4.1 ¶ 3
    The PIV Card SHALL NOT be embossed other than for security and accessibility features. 4.1.3 ¶ 8
    {PIV Card}{thickness}{applicable requirements} The card SHALL be 27 mil to 33 mil (0.68 mm to 0.84 mm) thick before lamination, in accordance with [ISO 7810]. 4.1.3 ¶ 7
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not alter or interfere with printed information, including the photograph; or 4.1.3 ¶ 10 Bullet 3
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not invalidate card manufacturer warranties or other product claims; 4.1.3 ¶ 10 Bullet 2
    {machine readable format} Incorporation of security features SHALL not impede access to machine-readable information. 4.1.2 ¶ 9 Bullet 4
    {PIV Card} The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security features, as described in Section 4.1.2, may modify the perceived color slightly. The presence of security features SHALL NOT prevent the recognition of white as the principal card body color by a person with normal vision (corrected or uncorrected) at a working distance of 50 cm to 200 cm. 4.1.3 ¶ 3
    {PIV Card} The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security features, as described in Section 4.1.2, may modify the perceived color slightly. The presence of security features SHALL NOT prevent the recognition of white as the principal card body color by a person with normal vision (corrected or uncorrected) at a working distance of 50 cm to 200 cm. 4.1.3 ¶ 3
    {PIV Card} The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security features, as described in Section 4.1.2, may modify the perceived color slightly. The presence of security features SHALL NOT prevent the recognition of white as the principal card body color by a person with normal vision (corrected or uncorrected) at a working distance of 50 cm to 200 cm. 4.1.3 ¶ 3
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not 4.1.3 ¶ 10
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not compromise card body durability requirements and characteristics; 4.1.3 ¶ 10 Bullet 1
    {PIV Card}{refrain from interfering} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not damage or interfere with machine-readable technology, such as the embedded antenna. 4.1.3 ¶ 10 Bullet 4
    {PIV Card} The card material SHALL withstand the effects of temperatures required by the application of a polyester laminate on one or both sides of the card by commercial off-the-shelf (COTS) equipment. The thickness added due to a laminate layer SHALL NOT interfere with the smart card reader operation. The card material SHALL allow production of a flat card in accordance with [ISO 7810] after lamination of one or both sides of the card. 4.1.3 ¶ 11
    {PIV Card} The card material SHALL withstand the effects of temperatures required by the application of a polyester laminate on one or both sides of the card by commercial off-the-shelf (COTS) equipment. The thickness added due to a laminate layer SHALL NOT interfere with the smart card reader operation. The card material SHALL allow production of a flat card in accordance with [ISO 7810] after lamination of one or both sides of the card. 4.1.3 ¶ 11
    {PIV Card} The card material SHALL withstand the effects of temperatures required by the application of a polyester laminate on one or both sides of the card by commercial off-the-shelf (COTS) equipment. The thickness added due to a laminate layer SHALL NOT interfere with the smart card reader operation. The card material SHALL allow production of a flat card in accordance with [ISO 7810] after lamination of one or both sides of the card. 4.1.3 ¶ 11
    To achieve a common PIV Card appearance and provide departments and agencies with the flexibility to augment the card with department-or agency-specific requirements, the card SHALL contain printed information and machine-readable technologies. Mandated and optional items SHALL be placed as described and depicted. Printed data SHALL NOT interfere with machine-readable technology. 4.1.4 ¶ 3
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    {PIV Card} 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 pan style="background-color:#F0BBBC;" class="term_primary-noun">background SHALL follow recommendations set forth in [SP 800-76]. 4.1.4.1 ¶ 2
    {PIV Card} 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 minimumspan> of 300 dots per inch (DPI) resolution SHALL be used. The background SHALL follow recommendations set forth in [SP 800-76]. 4.1.4.1 ¶ 2
    Incorporation of security features SHALL be free of defects, such as fading and discoloration; 4.1.2 ¶ 9 Bullet 2
    Incorporation of security features SHALL be in accordance with durability requirements; 4.1.2 ¶ 9 Bullet 1
    The electronic contact interface for the card as defined by [ISO 7816]. Printed items SHALL NOT cover the contact surface. The total size of the contact surface can vary between manufacturers. The area shown in Figure 4-1 roughly represents the minimal possible size. The electronic contact interface for the card as defined by [ISO 7816]. Printed items SHALL NOT cover the contact surface. The total size of the contact surface can vary between manufacturers. The area shown in Figure 4-1 roughly represents the minimal possible size. 4.1.4.1 ¶ 7
    {refrain from using} Foreign national color-coding has precedence over government employee and contractor color-coding. These colors SHALL be reserved and SHALL NOT be employed for other purposes. These colors SHALL be printed in accordance with the color specifications provided in Section 4.1.5. Zone 15F MAY be a solid or patterned line at the department or agency’s discretion. 4.1.4.1 ¶ 16
    {refrain from using} Foreign national color-coding has precedence over government employee and contractor color-coding. These colors SHALL be reserved and SHALL NOT be employed for other purposes. These colors SHALL:#CBD0E5;" class="term_secondary-verb"> be n style="background-color:#B7D8ED;" class="term_primary-verb">printed
    in accordance with the color specifications provided in Section 4.1.5. Zone 15F MAY be a solid or patterned line at the department or agency’s discretion. 4.1.4.1 ¶ 16
    {PIV Card} Color-coding SHALL be used for additional identification of employee affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be n style="background-color:#B7D8ED;" class="term_primary-verb">usedn>: tyle="background-color:#F0BBBC;" class="term_primary-noun">green: contractor. 4.1.4.1 ¶ 15 Bullet 3
    Color-coding SHALL be used for additional identification of employee affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be usedn>: tyle="background-color:#F0BBBC;" class="term_primary-noun">white: government employee, or 4.1.4.1 ¶ 15 Bullet 2
    {PIV Card} Color-coding SHALL be used for additional identification of employee affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be n style="background-color:#B7D8ED;" class="term_primary-verb">usedn>: tyle="background-color:#F0BBBC;" class="term_primary-noun">blue: foreign national, 4.1.4.1 ¶ 15 Bullet 1
    If used, this area SHALL incorporate edge ridging or a notched corner to indicate card -noun">orientation
    , as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. If used, this area SHALL incorporate edge ridging or a notched corner to indicate card orientation, as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 27
    If used, this area SHALL incorporate edge ridging or a notched corner to indicate card orientation, as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and class="term_primary-noun">manufacturer
    to ensure that the card material integrity and printing process s="term_secondary-verb">are not adversely impacted
    . If used, this area SHALL incorporate edge ridging or a notched corner to indicate card orientation, as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 27
    {PIV Card}{reserved area}{machine-readable information} Departments and agencies MAY choose to provide additional information to identify emergency response officials or to better identify the cardholder’s authorized access. If used, this additional text SHALL be in the general area depicted in Figure 4-7 and <span style="background-color:#B7D8ED;" class="term_primary-verb">SHALL NOT interfere
    with other printed text or machine-readable components. An example of a printed statement is provided in Figure 4-7. 4.1.4.4 ¶ 8]
    Systems design, build, and implementation Preventive
    Define the mandatory items that must appear on identification cards or badges in the identification card or badge architectural designs. CC ID 06593
    [To achieve a common PIV Card appearance and provide departments and agencies with the flexibility to augment the card with department-or agency-specific requirements, the card SHALL contain printed information and machine-readable technologies. Mandated and optional items SHALL be placed as described and depicted. Printed data SHALL NOT interfere with machine-readable technology. 4.1.4 ¶ 3
    {approved font} Unless otherwise specified, all data labels SHALL be printed in 5 pt Arial with the corresponding data in 6 pt Arial Bold. If the Arial font is not available, a visually similar font, such as Public Sans [PublicSans], MAY be substituted for all references to Arial within this Standard. If such a substitution is made, the substitution SHALL be consistently applied to all uses of the Arial font on the PIV Card. Unless otherwise specified, all text SHALL be printed in black. 4.1.4 ¶ 5
    {approved font} Unless otherwise specified, all data labels SHALL be printed in 5 pt Arial with the corresponding data in 6 pt Arial Bold. If the Arial font is not available, a visually similar font, such as Public Sans [PublicSans], MAY be substituted for all references to Arial within this Standard. If such a substitution is made, the substitution SHALL be consistently applied to all uses of the Arial font on the PIV Card. Unless otherwise specified, all text SHALL be printed in black. 4.1.4 ¶ 5
    {approved font} Unless otherwise specified, all data labels SHALL be printed in 5 pt Arial with the corresponding data in 6 pt Arial Bold. If the Arial font is not available, a visually similar font, such as Public Sans [PublicSans], MAY be substituted for all references to Arial within this Standard. If such a substitution is made, the substitution SHALL be consistently applied to all uses of the Arial font on the PIV Card. Unless otherwise specified, all text SHALL be printed in black. 4.1.4 ¶ 5
    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 other possible machine-readable technologies. Logically stored data elements are discussed in Section 4.2. 4.1.4 ¶ 1
    {applicable requirements} {biometric authentication} The electronic facial image SHALL be stored on the PIV Card as described in Section 4.2.3.1. It SHALL be printed on the PIV Card according to Section 4.1.4.1. The image MAY be used for cardholder authentication (BIO or BIO-A) as described in Section 6.2.1. It MAY be retrieved and displayed on guard workstations to augment other authentication processes from Section 6.2. The electronic facial image is an additional means of authentication during PIV issuance and maintenance processes when used with an automated facial comparison algorithm. 2.5 ¶ 5
    Incorporation of security features SHALL not obscure printed information; and 4.1.2 ¶ 9 Bullet 3
    {PIV Card} The organizational affiliation SHALL be -color:#B7D8ED;" class="term_primary-verb">printed as depicted in Figure 4-1. 4.1.4.1 ¶ 11
    {PIV Card} An employee affiliation SHALL be #B7D8ED;" class="term_primary-verb">printed on the card as depicted in Figure 4-1. Examples of employee affiliation include “Employee,” “Contractor,” “Active Duty,” and “Civilian.” 4.1.4.1 ¶ 9
    Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL olor:#CBD0E5;" class="term_secondary-verb">s="term_primary-verb">indicate> such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. 4.1.4.1 ¶ 5
    Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. 4.1.4.1 ¶ 5
    Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. 4.1.4.1 ¶ 5
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be ry-verb">printed
    . Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be style="background-color:#B7D8ED;" class="term_primary-verb">printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {appropriate format}{refrain from exceeding} The affiliation color codes “B” for blue, “W” for white, and “G” for green SHALL be printed in a white circle on the right side of Zone 15F, as depicted in Figure 4-1. The diameter of the circle SHALL NOT be more than 5 mm. The lettering SHALL correspond to the printed >color</span> in Zone 15F. 4.1.4.1 ¶ 18
    {appropriate format}{refrain from exceeding} The affiliation color codes “B” for blue, “W” for white, and “G” for green SHALL be olor:#B7D8ED;" class="term_primary-verb">printed in a white circle on the right side of Zone 15F, as depicted in Figure 4-1. The diameter of the circle SHALL NOT be more than 5 mm. The lettering SHALL correspond to the printed color in Zone 15F. 4.1.4.1 ¶ 18
    {appropriate format}{refrain from exceeding} The affiliation color codes “B” for blue, “W” for white, and “G” for green SHALL be printed in a white circle on the right side of Zone 15F, as depicted in Figure 4-1. The diameter of the tyle="background-color:#CBD0E5;" class="term_secondary-verb">ass="term_primary-noun">circle SHALL NOT be more than 5 mm. The lettering SHALL correspond to the printed color in Zone 15F. 4.1.4.1 ¶ 18
    {appropriate format}{approved font} The card expiration date SHALL be printed in a MMMYYYY format in the upper right-hand corner as depicted in Figure 4-1. The YYYY characters represent the fourdigit year and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 19F expiration date SHALL be printed in 12 pt Arial Bold. 4.1.4.1 ¶ 20
    {appropriate format}{approved font} The card expiration date SHALL be printed in a MMMYYYY format in the upper right-hand corner as depicted in Figure 4-1. The YYYY characters represent the fourdigit year and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 19F expiration date SHALL be printed in 12 pt Arial Bold. 4.1.4.1 ¶ 20
    {PIV Card}{issuing organization} 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 preferred placement is as depicted in Figure 4-6, but variable placement along the outer edge is allowed in accordance with other FIPS 201 requirements, as shown in Figure 4-8. 4.1.4.2 ¶ 2
    {pre-determined and authorized location} If used, the department or agency SHALL place the cardholder un">signature below the photograph and cardholder name, as depicted in Figure 4-3. The space for the signature SHALL NOT interfere with the placement of the ICCs and related components. Because of card surface space constraints, placement of a signature may limit the size of the optional two-dimensional bar code. 4.1.4.3 ¶ 3
    {PIV Card}{issuing organization} 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 preferred placement is as depicted in Figure 4-6, but variable placement along the outer edge is allowed in accordance with other FIPS 201 requirements, as shown in Figure 4-8. 4.1.4.2 ¶ 2
    {PIV Card} Color-coding SHALL be used for additional identification of employee pan style="background-color:#F0BBBC;" class="term_primary-noun">affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be used: 4.1.4.1 ¶ 15
    {PIV Card}{appropriate format}{approved font} The card expiration date SHALL be printed on the card as depicted in Figure 4-1. The card expiration date SHALL be in a YYYYMMMDD format. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 14F expiration date SHALL be printed in 6 pt to 9 pt Arial Bold. 4.1.4.1 ¶ 13
    {PIV Card}{appropriate format}{approved font} The card expiration date SHALL be printed on the card as depicted in Figure 4-1. The card expiration date SHALL be in a YYYYMMMDD format. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 14F expiration date SHALL be printed in 6 pt to 9 pt Arial Bold. 4.1.4.1 ¶ 13
    {PIV Card}{appropriate format}{approved font} The card expiration date SHALL be pan style="background-color:#B7D8ED;" class="term_primary-verb">printed on the card as depicted in Figure 4-1. The card expiration date SHALL be in a YYYYMMMDD format. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 14F expiration date SHALL be printed in 6 pt to 9 pt Arial Bold. 4.1.4.1 ¶ 13
    {PIV Card}{pre-determined and authorized location} If used, the cardholder’s rank SHALL be "term_primary-verb">printed in the area, as illustrated in Figure 4-2. Data format is at the department or agency’s discretion. 4.1.4.3 ¶ 7
    {issuing organization}{pre-determined and authorized location}{be visible} The Agency seal in Zone 11F may become a mandatory field in the next revision of the Standard. If used, the class="term_primary-noun">seal selected by the issuing department, agency, or organization SHALL be n style="background-color:#B7D8ED;" class="term_primary-verb">printed in the area depicted. It SHALL be printed using the guidelines provided in Figure 4-2 to ensure that information printed on the seal is legible and clearly visible. 4.1.4.3 ¶ 13
    {appropriate format} If the PIV Card is used to identify a federal emergency response official, a department or agency SHALL priondary-verb">nt> “Federal Emergency Response Official” as depicted in Figure 4-2. The label SHOULD be in white lettering on a red background. Additional information regarding the federal emergency responder role MAY be included in Zone 9F, as depicted in Figure 4-2. 4.1.4.3 ¶ 15
    {approved font} The organizational affiliation abbreviation MAY be printed in the upper right-hand corner below the Zone 19F expiration date as shown in Figure 4-2. If printed, the organizational affiliation abbreviation SHALL be printed in 12 pt Arial Bold. 4.1.4.3 ¶ 25
    {appropriate format} If the PIV Card is used to identify a federal emergency response official, a department or agency SHALL print “Federal Emergency Response Official” as depicted in Figure 4-2. The label SHOULD be in white lettering on a red background. Additional information regarding the federal emergency responder role MAY be included in Zone 9F, as depicted in Figure 4-2. 4.1.4.3 ¶ 15
    If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 29
    {header} If used, the text “United States Government” SHALL be ="background-color:#B7D8ED;" class="term_primary-verb">placed
    as depicted in Figure 4-3, Figure 4-4, and Figure 4-5. Departments and agencies MAY instead use this zone for other department or agency-specific information, such as identifying a federal emergency responder role, as depicted in Figure 4-2. Some examples of official roles are “Law Enforcement,” “Fire Fighter,” and “Emergency Response Team (ERT).” 4.1.4.3 ¶ 11
    {appropriate format} A CHUID MAY also include a Cardholder UUID that represents a persistent identifier of the cardholder, as specified in [SP 800-73]. The value of the cardholder UUID SHALL _primary-verb">be
    the 16 byte binary representation of a valid UUID, as specified in [RFC 4122]. 4.2.1 ¶ 3
    {issuer identification number}{appropriate format} This item SHALL be printed as depicted in Figure 4-6 and consist of six characters for the department code, four characters for the agency code, and a five-digit number that uniquely identifies the issuing facility within the department or agency. 4.1.4.2 ¶ 4]
    Systems design, build, and implementation Preventive
    Define the optional items that may appear on identification cards or badges in the identification card or badge architectural designs. CC ID 06594
    [{applicable requirements} When Zone 15F indicates foreign national affiliation and the department or agency does not need to highlight emergency response official status, Zone 12F MAY be used to denote the country or countries of citizenship. If so used, the department or agency SHALL le="background-color:#B7D8ED;" class="term_primary-verb">printpan> the country name or the three-letter country abbreviation (alpha3 format) in accordance with [ISO 3166]. Figure 4-4 illustrates an example of using country abbreviations for a card issued to a foreign national. 4.1.4.3 ¶ 16
    {appropriate format} If used, the card issuance date SHALL be printed above the Zone 14F expiration date in YYYYMMMDD format, as depicted in Figure 4-3. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. 4.1.4.3 ¶ 19
    A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. 4.1.4.3 ¶ 21
    A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. 4.1.4.3 ¶ 21
    If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 29
    If used, this area can be used for printing agency-specific requirements, such as employee status, as shown in Figure 4-2. Note that this zone overlaps with an area that some card manufacturers might not allow to be used for printing. If used, this area can be used for printing agency-specific requirements, such as employee status, as shown in Figure 4-2. Note that this zone overlaps with an area that some card manufacturers might not allow to be used for printing. 4.1.4.3 ¶ 5
    {PIV Card} If used, the “return if lost” language SHALL be placed on the olor:#F0BBlass="term_secondary-verb">BC;"
    class="term_primary-noun">back of the card in the general area depicted in Figure 4-7. 4.1.4.4 ¶ 4
    {PIV Card} If used, the cardholder physical characteristics (e.g., height, eye color, hair color) SHALL be class="term_primary-verb">printed in the general area illustrated in Figure 4-7. 4.1.4.4 ¶ 6
    {PIV Card}{be necessary} In cases in which other defined optional elements are not used, these zones MAY be used for other department or agency-specific information, as depicted in Figure 4-8. Departments and agencies SHOULD style="background-color:#B7D8ED;" class="term_primary-verb">minimize printed >textspan> to that which is absolutely necessary. 4.1.4.4 ¶ 14
    {PIV Card}{reserved area}{machine-readable information} Departments and agencies MAY choose to provide additional information to identify emergency response officials or to better identify the cardholder’s authorized access. If used, this additional text SHALL round-color:#B7D8ED;" class="term_primary-verb">be
    in the general area depicted in Figure 4-7 and SHALL NOT interfere with other printed text or machine-readable components. An example of a printed statement is provided in Figure 4-7. 4.1.4.4 ¶ 8
    If used, standard Section 499, Title 18, language warning against counterfeiting, altering, or misusing the card SHALL be printed in the general yle="background-color:#F0BBBC;" class="term_primary-noun">area depicted in Figure 4-7. If used, standard Section 499, Title 18, language warning against counterfeiting, altering, or misusing the card SHALL be printed in the general area depicted in Figure 4-7. 4.1.4.4 ¶ 10]
    Systems design, build, and implementation Preventive
    Include the logical credential data model for identification cards or badges in the identification card or badge architectural designs. CC ID 06595
    [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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: a Cardholder Unique Identifier (CHUID). 4.2 ¶ 2 Bullet 6
    A new PIV authentication certificate and a new card authentication certificate SHALL be generated. The corresponding certificates SHALL be populated with the new FASCN and card UUID. For cardholders with government-issued email accounts, the digital signature and key management keys and associated certificates SHALL be populated. A new digital signature key and associated certificate SHALL be generated on the new PIV Card, while key management keys and associated certificates MAY be imported to the new PIV Card. 2.9.1 ¶ 8
    A new PIV authentication certificate and a new card authentication certificate SHALL be generated. The corresponding certificates SHALL be populated with the new FASCN and card UUID. For cardholders with government-issued email accounts, the digital signature and key management keys and associated certificates SHALL be populated. A new digital signature key and associated certificate SHALL be generated on the new PIV Card, while key management keys and associated certificates MAY be imported to the new PIV Card. 2.9.1 ¶ 8
    A new PIV authentication certificate and a new card authentication certificate SHALL be generated. The corresponding certificates SHALL be populated with the new FASCN and card UUID. For cardholders with government-issued email accounts, the digital signature and key management keys and associated certificates SHALL be populated. A new digital signature key and associated certificate SHALL be generated on the new PIV Card, while key management keys and associated certificates MAY be imported to the new PIV Card. 2.9.1 ¶ 8
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    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 contact interface of the PIV Card. Operations that use the key management key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.5 ¶ 1
    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 contact interface of the PIV Card. Operations that use the key management key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.5 ¶ 1
    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 interface unless otherwise specified by [SP 800-73]. 4.2.2.6 ¶ 1
    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 interface unless otherwise specified by [SP 800-73]. 4.2.2.6 ¶ 1
    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 and appended with the CBEFF signature block [NISTIR 6529-A]. 4.2.3.2 ¶ 1
    The PIV Card SHALL be activated to perform privileged 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 authenticating the cardholder or the appropriate card management system. Cardholder activation is described in Section 4.3.1 and card management system activation is described in Section 4.3.2. 4.3 ¶ 1
    The PIV Card SHALL be activated to perform privileged 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 authenticating the cardholder or the appropriate card management system. Cardholder activation is described in Section 4.3.1 and card management system activation is described in Section 4.3.2. 4.3 ¶ 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: an electronic facial image, and 4.2 ¶ 2 Bullet 5
    This Standard also defines two data elements for the PIV Card data model that are mandatory if the cardholder has a government-issued email account at the time of PIV Card issuance. These data elements are an asymmetric private key and corresponding certificate for key management. 4.2 ¶ 3 Bullet 2
    The expiration date of the PIV authentication and card authentication certificates SHALL NOT be after the expiration date of the PIV Card. The expiration date of the PIV Card is printed on the card in Zone 14F (see Section 4.1.4) and is contained in the CHUID data object (see Section 4.2.1). If the card is revoked, the PIV authentication and card authentication certificates SHALL be revoked in cases where the card cannot be collected and destroyed. However, a PIV authentication or card authentication certificate MAY be revoked and subsequently replaced without revoking the PIV Card. The presence of a valid, unexpired, and unrevoked authentication certificate on a card is sufficient proof that the card was issued and is not revoked. 5.2.1 ¶ 2
    The expiration date of the PIV authentication and card authentication certificates SHALL NOT be after the expiration date of the PIV Card. The expiration date of the PIV Card is printed on the card in Zone 14F (see Section 4.1.4) and is contained in the CHUID data object (see Section 4.2.1). If the card is revoked, the PIV authentication and card authentication certificates SHALL be revoked in cases where the card cannot be collected and destroyed. However, a PIV authentication or card authentication certificate MAY be revoked and subsequently replaced without revoking the PIV Card. The presence of a valid, unexpired, and unrevoked authentication certificate on a card is sufficient proof that the card was issued and is not revoked. 5.2.1 ¶ 2
    All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces 4.2.2 ¶ 19
    All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces 4.2.2 ¶ 19]
    Systems design, build, and implementation Preventive
    Provide the data subject with references to the appropriate safeguards used to protect the privacy of personal data. CC ID 12585 Privacy protection for information and data Preventive
    Provide the data subject with copies of the appropriate safeguards used to protect the privacy of personal data. CC ID 12608
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Provide PIV applicants with full disclosure of the intended uses of the information associated with the PIV Card and the related privacy implications. 2.11 ¶ 3 Bullet 4]
    Privacy protection for information and data Preventive
    Rely upon the warranty of the covered entity that the record disclosure request for Individually Identifiable Health Information is to support the treatment of the individual. CC ID 11969 Privacy protection for information and data Preventive
    Refrain from erasing personal data upon receiving a personal data removal request when it is necessary for maintaining information assets. CC ID 13789 Privacy protection for information and data Preventive
    Refrain from erasing personal data upon receiving a personal data removal request when it is necessary to complete a payment transaction. CC ID 13788 Privacy protection for information and data Preventive
    Define the fee structure for the appeal process. CC ID 16532 Privacy protection for information and data Preventive
    Define the time requirements for the appeal process. CC ID 16531 Privacy protection for information and data Preventive
  • Records Management
    5
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Archive Public Key certificate records according to organizational Records Management rules. CC ID 07090 Technical security Preventive
    Refrain from disclosing Individually Identifiable Health Information when in violation of territorial or federal law. CC ID 11966 Privacy protection for information and data Preventive
    Rely upon the warranty of the covered entity that the record disclosure request for Individually Identifiable Health Information is permitted with the consent of the data subject. CC ID 11970 Privacy protection for information and data Preventive
    Rely upon the warranty of the covered entity that the record disclosure request for Individually Identifiable Health Information is permitted by law. CC ID 11976 Privacy protection for information and data Preventive
    Remove personal data from records after receiving a personal data removal request. CC ID 11972 Privacy protection for information and data Preventive
  • Systems Design, Build, and Implementation
    6
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Separate foreground from background when designing and building content. CC ID 15125 Operational management Preventive
    Initiate the System Development Life Cycle development phase or System Development Life Cycle build phase. CC ID 06267 Systems design, build, and implementation Preventive
    Develop systems in accordance with the system design specifications and system design standards. CC ID 01094 Systems design, build, and implementation Preventive
    Develop new products based on best practices. CC ID 01095 Systems design, build, and implementation Preventive
    Define the data elements to be stored on identification cards or badges in the identification card or badge architectural designs. CC ID 15427
    [The two mandatory fingerprints SHALL be used for the preparation of biometric templates to be stored on the PIV Card as described in Section 4.2.3.1. The fingerprints provide an interoperable authentication mechanism through an off-card comparison scheme (BIO or BIO-A) as described in Section 6.2.1. These fingerprints are also the primary means of authentication during PIV issuance and maintenance processes. 2.5 ¶ 2
    {not meet} 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 templates, as specified in [SP 800-76]. 4.2.3.1 ¶ 1 Bullet 1
    {not meet} 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 templates, as specified in [SP 800-76]. 4.2.3.1 ¶ 1 Bullet 1
    The following biometric data SHALL be stored on the PIV Card: An electronic facial image. 4.2.3.1 ¶ 1 Bullet 2
    All biometric data SHALL be stored in the data elements referenced by [SP 800-73] and in conformance with the preparation and formatting specifications of [SP 800-76]. 4.2.3.1 ¶ 3
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder’s identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: 4.2 ¶ 2
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: a PIN, 4.2 ¶ 2 Bullet 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: PIV authentication data (one asymmetric private key and corresponding certificate), 4.2 ¶ 2 Bullet 2
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: two fingerprint biometric templates, 4.2 ¶ 2 Bullet 4
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: card authentication data (one asymmetric private key and corresponding certificate), 4.2 ¶ 2 Bullet 3
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. Section 5 of this document specifies the certificate format and the key management infrastructure for key management keys. 4.2.2.5 ¶ 2
    {applicable requirements} Agencies MAY choose to collect electronic iris images as an additional biometric characteristic. If collected, the electronic iris images SHALL be stored on the PIV Card as described in Section 4.2.3.1. The images MAY be used for cardholder authentication (BIO or BIO-A) as described in Section 6.2.1. Electronic iris images are an additional means of authentication during PIV issuance and maintenance processes. 2.5 ¶ 4
    {applicable requirements} {biometric authentication} The electronic facial image SHALL be stored on the PIV Card as described in Section 4.2.3.1. It SHALL be printed on the PIV Card according to Section 4.1.4.1. The image MAY be used for cardholder authentication (BIO or BIO-A) as described in Section 6.2.1. It MAY be retrieved and displayed on guard workstations to augment other authentication processes from Section 6.2. The electronic facial image is an additional means of authentication during PIV issuance and maintenance processes when used with an automated facial comparison algorithm. 2.5 ¶ 5
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    All biometric data SHALL be stored in the data elements referenced by [SP 800-73] and in conformance with the preparation and formatting specifications of [SP 800-76]. 4.2.3.1 ¶ 3
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for PIV digital signature keys. 4.2.2.4 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for PIV digital signature keys. 4.2.2.4 ¶ 2
    A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. 4.1.2 ¶ 8
    A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. 4.1.2 ¶ 8
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder rb">does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17]
    Systems design, build, and implementation Preventive
    Include security measures in the identification card or badge architectural designs. CC ID 15423
    [All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces 4.2.2 ¶ 19]
    Systems design, build, and implementation Preventive
  • Technical Security
    91
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Establish the requirements for Identity Assurance Levels. CC ID 13857
    [The selection of authentication assurance levels SHALL be made in accordance with the applicable policies for a facility’s security level [RISK-MGMT-FACILITIES]. Additional guidelines for the selection and use of PIV authentication mechanisms for facility access can be found in NIST [SP 800-116]. 6.3.1 ¶ 3]
    Technical security Preventive
    Establish, implement, and maintain federated identity systems. CC ID 13837
    [The IAL, AAL, and FAL SHALL be known to the RP at the conclusion of the federation transaction. This information MAY be pre-established or the IdP MAY communicate this at runtime in the assertion. For example, the information can be presented using technologies defined in [RFC 8485], [OIDC4IA], or [SAML-AC]. 7.2 ¶ 2]
    Technical security Preventive
    Authenticate all systems in a federated identity system. CC ID 13835 Technical security Preventive
    Send and receive authentication assertions, as necessary. CC ID 13839
    [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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1]
    Technical security Preventive
    Make the assertion reference for authentication assertions single-use. CC ID 13843 Technical security Preventive
    Validate the issuer in the authentication assertion. CC ID 13878 Technical security Detective
    Limit the lifetime of the assertion reference. CC ID 13874 Technical security Preventive
    Refrain from using authentication assertions that have expired. CC ID 13872
    [A derived PIV credential SHALL NOT be accepted for authentication once the credential has been invalidated. When invalidation occurs, the issuer SHALL notify the cardholder of the change. 2.10.2 ¶ 3]
    Technical security Preventive
    Protect the authentication assertion from unauthorized access or unauthorized disclosure. CC ID 16836 Technical security Preventive
    Include the issuer identifier in the authentication assertion. CC ID 13865 Technical security Preventive
    Include attribute metadata in the authentication assertion. CC ID 13856 Technical security Preventive
    Include the authentication time in the authentication assertion. CC ID 13855 Technical security Preventive
    Validate each element within the authentication assertion. CC ID 13853
    [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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1]
    Technical security Preventive
    Validate the timestamp in the authentication assertion. CC ID 13875 Technical security Detective
    Validate the digital signature in the authentication assertion. CC ID 13869 Technical security Detective
    Validate the signature validation element in the authentication assertion. CC ID 13867 Technical security Detective
    Validate the audience restriction element in the authentication assertion. CC ID 13866 Technical security Detective
    Include the subject in the authentication assertion. CC ID 13852 Technical security Preventive
    Include the target audience in the authentication assertion. CC ID 13851 Technical security Preventive
    Include audience restrictions in the authentication assertion. CC ID 13870 Technical security Preventive
    Include the issue date in the authentication assertion. CC ID 13850 Technical security Preventive
    Revoke authentication assertions, as necessary. CC ID 16534 Technical security Preventive
    Include the expiration date in the authentication assertion. CC ID 13849 Technical security Preventive
    Include identifiers in the authentication assertion. CC ID 13848 Technical security Preventive
    Include digital signatures in the authentication assertion. CC ID 13847 Technical security Preventive
    Include key binding in the authentication assertion. CC ID 13846 Technical security Preventive
    Include attribute references in the authentication assertion. CC ID 13845 Technical security Preventive
    Include attribute values in the authentication assertion. CC ID 13844 Technical security Preventive
    Limit the use of the assertion reference to a single organization. CC ID 13841 Technical security Preventive
    Request attribute references instead of attribute values during the presentation of an authentication assertion. CC ID 13840 Technical security Preventive
    Define the assertion level for authentication assertions. CC ID 13873 Technical security Preventive
    Refrain from assigning assertion levels for authentication assertions when not defined. CC ID 13879 Technical security Preventive
    Authenticate systems referenced in the whitelist. CC ID 13838 Technical security Preventive
    Place nonmembers of whitelists and blacklists into a gray area until a runtime decision is made during the authentication assertion. CC ID 13854 Technical security Preventive
    Require runtime decisions regarding authentication for organizations that are excluded from the whitelist. CC ID 13842 Technical security Preventive
    Control access rights to organizational assets. CC ID 00004 Technical security Preventive
    Establish, implement, and maintain lockout procedures or lockout mechanisms to be triggered after a predetermined number of consecutive logon attempts. CC ID 01412
    [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 card to perform CTC authentication, and the card responds with a positive or negative biometric verification decision. The response includes information that allows the reader to authenticate the card. Entry of the cardholder PIN is not required for OCC-AUTH. The PIV Card SHALL include a mechanism to block this authentication mechanism after a number of consecutive failed authentication attempts as stipulated by the department or agency. As with BIO and BIO-A, if agencies choose to implement OCC, it SHALL be implemented as defined in [SP 800-73] and [SP 800-76]. 6.2.2 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1]
    Technical security Preventive
    Disallow unlocking user accounts absent system administrator approval. CC ID 01413 Technical security Preventive
    Establish, implement, and maintain User Access Management procedures. CC ID 00514 Technical security Preventive
    Control the addition and modification of user identifiers, user credentials, or other authenticators. CC ID 00515
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A process exists to invalidate, revoke, or destroy credentials when the cardholder loses eligibility or when the credential is lost, stolen, or compromised. 2.1 ¶ 2 Bullet 9
    Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential remains serviceable only up to its expiration date. 2.1 ¶ 2 Bullet 8
    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 requirements in this section. 2.10.1 ¶ 1]
    Technical security Preventive
    Automate access control methods, as necessary. CC ID 11838 Technical security Preventive
    Automate Access Control Systems, as necessary. CC ID 06854 Technical security Preventive
    Refrain from storing logon credentials for third party applications. CC ID 13690 Technical security Preventive
    Refrain from allowing user access to identifiers and authenticators used by applications. CC ID 10048 Technical security Preventive
    Protect and manage biometric systems and biometric data. CC ID 01261
    [The biometric data records in the PIV enrollment records SHALL be valid for a maximum of 12 years. In order to mitigate aging effects and thereby maintain operational readiness of a cardholder’s PIV Card, agencies MAY require biometric enrollment more frequently than 12 years. 2.6 ¶ 4
    The CBEFF signature block contains the digital signature of the biometric data record and facilitates the verification of the integrity of the biometric data record. The CBEFF signature block SHALL be encoded as a CMS external digital signature as specified in [SP 800-76]. The algorithm and key size requirements for the digital signature and digest algorithm are detailed in [SP 800-78]. 4.2.3.2 ¶ 3]
    Technical security Preventive
    Implement out-of-band authentication, as necessary. CC ID 10606 Technical security Corrective
    Include digital identification procedures in the access control program. CC ID 11841
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential is issued to an individual only after a proper authority has authorized issuance of the credential, the individual’s identity has been verified, and the individual has been vetted per Section 2.2. 2.1 ¶ 2 Bullet 1]
    Technical security Preventive
    Disallow the use of Personal Identification Numbers as user identifiers. CC ID 06785 Technical security Preventive
    Require proper authentication for user identifiers. CC ID 11785
    [{be genuine} {is not altered} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that Fraudulent identity source documents are not accepted as genuine or unaltered. 2.1 ¶ 2 Bullet 4]
    Technical security Preventive
    Refrain from allowing individuals to share authentication mechanisms. CC ID 11932 Technical security Preventive
    Refrain from assigning authentication mechanisms for shared accounts. CC ID 11910 Technical security Preventive
    Employ live scans to verify biometric authentication. CC ID 06847
    [{identity proofing} {registration} Biometric data SHALL be captured as specified in Section 2.3 and Section 2.4. 2.7 ¶ 4
    Biometric identification using fingerprints is the primary input to law enforcement checks. In cases where ten fingerprints are not available, then as many fingers as possible SHALL be imaged as per guidance in [SP 800-76]. In cases where no fingers are available to be imaged, agencies SHALL seek guidance from their respective investigative service provider for alternative means of performing law enforcement checks. 2.3 ¶ 3]
    Technical security Preventive
    Manage the use of encryption controls and cryptographic controls. CC ID 00570 Technical security Preventive
    Accept only trusted keys and/or certificates. CC ID 11988
    [{refrain from expiring}{not be revoked} The relying system validates the card authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.2 ¶ 1 Bullet 2]
    Technical security Preventive
    Establish a Root Certification Authority to support the Public Key Infrastructure. CC ID 07084
    [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. 5.1 ¶ 1]
    Technical security Preventive
    Connect the Public Key Infrastructure to the organization's identity and access management system. CC ID 07091 Technical security Preventive
    Use strong data encryption to transmit in scope data or in scope information, as necessary. CC ID 00564 Technical security Preventive
    Configure the encryption strength to be appropriate for the encryption methodology of the cryptographic controls. CC ID 12492
    [{be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1]
    Technical security Preventive
    Install and maintain container security solutions. CC ID 16178 Technical security Preventive
    Protect the system against replay attacks. CC ID 04552 Technical security Preventive
    Analyze the behavior and characteristics of the malicious code. CC ID 10672 Technical security Detective
    Incorporate the malicious code analysis into the patch management program. CC ID 10673 Technical security Corrective
    Establish, implement, and maintain segregation of duties compensating controls if segregation of duties is not practical. CC ID 06960 Human Resources management Preventive
    Establish, implement, and maintain authenticators. CC ID 15305 System hardening through configuration management Preventive
    Disallow personal data in authenticators. CC ID 13864 System hardening through configuration management Preventive
    Restrict access to authentication files to authorized personnel, as necessary. CC ID 12127 System hardening through configuration management Preventive
    Implement safeguards to protect authenticators from unauthorized access. CC ID 15310
    [{applicable requirements}{remote proofing procedure}{not acquire} PIN reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCCAUTH authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.1 ¶ 7]
    System hardening through configuration management Preventive
    Implement technical controls that limit processing restricted data for specific purposes. CC ID 12646 Privacy protection for information and data Preventive
    Employ a random number generator to create authenticators. CC ID 13782 Privacy protection for information and data Preventive
    Implement security measures to protect personal data. CC ID 13606
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Utilize security controls described in [SP 800-53] to accomplish privacy goals, where applicable. 2.11 ¶ 3 Bullet 10
    To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that the technologies used to implement PIV sustain and do not erode privacy protections relating to the use, collection, and disclosure of PII. Agencies MAY choose to deploy PIV Cards with electromagnetically opaque holders or other technology to protect against any unauthorized contactless access to information stored on a PIV Card. 2.11 ¶ 3 Bullet 11]
    Privacy protection for information and data Preventive
    Establish, implement, and maintain anti-counterfeit measures. CC ID 11522
    [{PIV Card}{anti-counterfeiting technique} All security features SHOULD maintain their function for the life of the card. As a generally accepted security procedure, federal departments and agencies SHOULD periodically review the viability, effectiveness, and currency of employed tamper resistance and anti-counterfeiting methods. 4.1.2 ¶ 10]
    Third Party and supply chain oversight Preventive
    Establish, implement, and maintain electronic marketplace terms of service guidelines. CC ID 11523 Third Party and supply chain oversight Preventive
    Include the prohibition of counterfeiting in the electronic marketplace terms of service guidelines. CC ID 11524 Third Party and supply chain oversight Preventive
    Enforce the electronic marketplace terms of service guidelines. CC ID 11525 Third Party and supply chain oversight Preventive
    Post anti-counterfeiting warnings within the electronic marketplace. CC ID 11526 Third Party and supply chain oversight Preventive
    Establish, implement, and maintain a counterfeit product reporting system. CC ID 11527 Third Party and supply chain oversight Preventive
    Respond to counterfeit product reports. CC ID 11528 Third Party and supply chain oversight Preventive
    Establish, implement, and maintain a trademark infringement reporting system. CC ID 11532 Third Party and supply chain oversight Preventive
    Allow anti-counterfeit testing of products. CC ID 11533 Third Party and supply chain oversight Preventive
    Categorize product information for anti-counterfeit testing to be either for a general audience or restricted audience. CC ID 11534 Third Party and supply chain oversight Preventive
    Include static characteristics of product information in anti-counterfeit testing. CC ID 11543 Third Party and supply chain oversight Preventive
    Include usage conditions of product information in anti-counterfeit testing. CC ID 11544 Third Party and supply chain oversight Preventive
    Include health impacts of product information in anti-counterfeit testing. CC ID 11545 Third Party and supply chain oversight Preventive
    Include feature-linked physical characteristics of product information in anti-counterfeit testing. CC ID 11546 Third Party and supply chain oversight Preventive
    Allow anti-counterfeit testing to use either authentication tools or human senses. CC ID 11535 Third Party and supply chain oversight Preventive
    Establish and maintain anti-counterfeit test authentication elements. CC ID 11542 Third Party and supply chain oversight Preventive
    Allow either online anti-counterfeit authentication tools or stand-alone anti-counterfeit authentication tools for anti-counterfeit testing. CC ID 11536 Third Party and supply chain oversight Preventive
    Allow either bespoke anti-counterfeit authentication tools or commercial off-the-shelf anti-counterfeit authentication tools for anti-counterfeit testing. CC ID 11537 Third Party and supply chain oversight Preventive
    Use overt authentication elements when using human senses for anti-counterfeit testing. CC ID 11538 Third Party and supply chain oversight Preventive
    Disallow covert authentication elements when using human senses for anti-counterfeit testing. CC ID 11539 Third Party and supply chain oversight Preventive
    Review the performance criteria of anti-counterfeit testing authentication tools. CC ID 11541 Third Party and supply chain oversight Preventive
  • Testing
    19
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Employ unique identifiers. CC ID 01273 Technical security Detective
    Authenticate user identities before unlocking an account. CC ID 11837 Technical security Detective
    Authenticate user identities before manually resetting an authenticator. CC ID 04567
    [{appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT reset the PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5]
    Technical security Detective
    Identify the user when enrolling them in the biometric system. CC ID 06882
    [{does not occur} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that No substitution occurs in the identity proofing process. More specifically, the individual who appears for identity proofing and whose fingerprints are checked against databases is the person to whom the credential is issued. 2.1 ¶ 2 Bullet 6
    {be different} The use of an different content signing key from that which signs the CHUID is deprecated in this revision of the Standard. If the signature on the biometric data record was generated with a different key than the signature on the CHUID, the certificates field of the CMS external digital signature SHALL include the content signing certificate required to verify the signature on the biometric data record. Otherwise, the certificates field SHALL be omitted. 4.2.3.2 ¶ 5]
    Technical security Detective
    Test all removable storage media for viruses and malicious code. CC ID 11861 Technical security Detective
    Test all untrusted files or unverified files for viruses and malicious code. CC ID 01311 Technical security Detective
    Implement operational requirements for card readers. CC ID 02225
    [{applicable 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 desktop computing systems and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.1 ¶ 1
    {applicable 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 desktop computing systems and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.1 ¶ 1
    {applicable 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 desktop computing systems and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.1 ¶ 1
    {applicable 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 computing systems, they SHALL conform to [PCSC] for the reader-to-host system interface and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.2 ¶ 1
    {applicable 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 computing systems, they SHALL conform to [PCSC] for the reader-to-host system interface and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.2 ¶ 1
    {applicable 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 computing systems, they SHALL conform to [PCSC] for the reader-to-host system interface and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.2 ¶ 1
    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 to a website or other server), the input device is not required to be integrated with the PIV Card reader. If the input device is not integrated with the PIV Card reader, the PIN or OCC data SHALL be transmitted securely and directly to the PIV Card for card activation. 4.4.4 ¶ 1]
    Physical and environmental protection Preventive
    Employ individuals who have the appropriate staff qualifications, staff clearances, and staff competencies. CC ID 00782 Human Resources management Detective
    Perform a drug test during personnel screening. CC ID 06648 Human Resources management Preventive
    Implement segregation of duties in roles and responsibilities. CC ID 00774
    [The PIV identity proofing, registration, issuance, and reissuance processes SHALL adhere to the y-noun">principlespan> of an style="background-color:#F0BBBC;" class="term_primary-noun">separation of duties to ensure that no single individual has the capability to issue a PIV Card without the cooperation of another authorized person. The PIV identity proofing, registration, issuance, and reissuance processes SHALL adhere to the principle of separation of duties to ensure that no single individual has the capability to issue a PIV Card without the cooperation of another authorized person. 2.7 ¶ 10]
    Human Resources management Detective
    Include disability accessibility standards in the disability accessibility program. CC ID 06192 Operational management Detective
    Follow disability accessibility standards when designing and building content. CC ID 06193 Operational management Detective
    Install telecommunications equipment that meets the disability accessibility standards. CC ID 06194 Operational management Detective
    Install audio and visual equipment that meets the disability accessibility standards. CC ID 06195 Operational management Detective
    Acquire commercial off the shelf products that meet the disability accessibility standards. CC ID 06196 Operational management Detective
    Acquire workstations and laptops that meet the disability accessibility standards. CC ID 06197 Operational management Detective
    Maintain continued integrity for all stored data and stored records. CC ID 00969
    [{data in transit}{data at rest} PIV enrollment records contain Personally Identifiable Information (PII). PII SHALL be protected in a manner that protects the individual’s privacy and maintains the integrity of the records both in transit and at rest. 2.6 ¶ 5]
    Records management Detective
    Refrain from subjecting individuals to retaliation or intimidation after a complaint is created. CC ID 06218 Privacy protection for information and data Detective
    Compare the photograph on the customer's identification card or badge with the customer's physical appearance. CC ID 04861
    [{appear in person}{not be successful}{not be available} When OCC reset is performed in person at the issuing facility, before the reset, the issuer SHALL perform a biometric verification of the cardholder to the biometric data records in the PIV enrollment record. If the biometric verification decision is negative or no alternative biometric data records are available, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 4
    Remote PIN reset on a general computing platform (e.g., desktop, laptop) SHALL only be performed if all the following requirements are met: The cardholder’s biometric characteristics elicit a "background-color:#F0BBBC;" class="term_primary-noun">positive biometric verification decision> when compared to the stored biometric data records on the PIV Card through the OCC-AUTH authentication mechanism. 2.9.3.1 ¶ 9 Bullet 3
    {applicable requirements}{remote proofing procedure}{not acquire} PIN reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCCAUTH authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and D0E5;" class="term_secondary-verb">#B7D8ED;" cl
    ass="term_primary-verb">comparespan> the _pristyle="background-color:#CBD0E5;" class="term_secondary-verb">mary-noun">video feed of the cardholder with the style="background-color:#F0BBBC;" class="term_primary-noun">electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.1 ¶ 7]
    Privacy protection for information and data Detective
  • Training
    1
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE CLASS
    Conduct bespoke roles and responsibilities training, as necessary. CC ID 13192
    [Supervised remote identity proofing SHALL meet the following requirements: The issuer SHALL require operators to have undergone a training program to detect potential fraud and to properly perform a supervised remote identity proofing session. 2.7.1 ¶ 4 Bullet 3]
    Human Resources management Preventive
Common Controls and
mandates by Classification
118 Mandated Controls - bold    
83 Implied Controls - italic     457 Implementation

There are three types of Common Control classifications; corrective, detective, and preventive. Common Controls at the top level have the default assignment of Impact Zone.

Number of Controls
658 Total
  • Corrective
    42
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE TYPE
    Determine the causes of compliance violations. CC ID 12401 Monitoring and measurement Investigate
    Correct compliance violations. CC ID 13515 Monitoring and measurement Process or Activity
    Carry out disciplinary actions when a compliance violation is detected. CC ID 06675 Monitoring and measurement Behavior
    Notify the user when an authentication is attempted using an expired authenticator. CC ID 13818
    [A derived PIV credential SHALL NOT be accepted for authentication once the credential has been invalidated. When invalidation occurs, the issuer SHALL notify the cardholder of the change. 2.10.2 ¶ 3]
    Technical security Communicate
    Implement out-of-band authentication, as necessary. CC ID 10606 Technical security Technical Security
    Disseminate and communicate the access control procedures to all interested personnel and affected parties. CC ID 14123 Technical security Communicate
    Tune the biometric identification equipment, as necessary. CC ID 07077 Technical security Configuration
    Remove malware when malicious code is discovered. CC ID 13691 Technical security Process or Activity
    Notify interested personnel and affected parties when malware is detected. CC ID 13689 Technical security Communicate
    Establish, implement, and maintain a malicious code outbreak recovery plan. CC ID 01310 Technical security Establish/Maintain Documentation
    Incorporate the malicious code analysis into the patch management program. CC ID 10673 Technical security Technical Security
    Document all lost badges in a lost badge list. CC ID 12448 Physical and environmental protection Establish/Maintain Documentation
    Change the authenticator for shared accounts when the group membership changes. CC ID 14249 System hardening through configuration management Business Processes
    Configure the look-up secret authenticator to dispose of memorized secrets after their use. CC ID 13817 System hardening through configuration management Configuration
    Notify the subject of care when a lack of availability of health information systems might have adversely affected their care. CC ID 13990 Privacy protection for information and data Communicate
    Refrain from disseminating and communicating with individuals that have opted out of direct marketing communications. CC ID 13708 Privacy protection for information and data Communicate
    Implement procedures to file privacy rights violation complaints. CC ID 00476 Privacy protection for information and data Data and Information Management
    File privacy rights violation complaints in writing. CC ID 00477 Privacy protection for information and data Establish/Maintain Documentation
    Include the acts or omissions that are in violation of privacy rights in the privacy rights violation complaint. CC ID 14360 Privacy protection for information and data Establish/Maintain Documentation
    Provide assistance to data subjects for filing privacy rights violation complaints. CC ID 00478 Privacy protection for information and data Behavior
    File privacy rights violation complaints inside the mandate stipulated from the refusal. CC ID 00479 Privacy protection for information and data Behavior
    Change or destroy any personal data that is incorrect. CC ID 00462 Privacy protection for information and data Data and Information Management
    Notify the data subject of changes made to personal data as the result of a dispute. CC ID 00463 Privacy protection for information and data Behavior
    Escalate the appeal process to change personal data when the data controller fails to make changes to the disputed data. CC ID 00465 Privacy protection for information and data Data and Information Management
    Notify the data subject of which and why disputed changes were not made to personal data. CC ID 00466 Privacy protection for information and data Behavior
    Notify entities to whom personal data was transferred that the personal data is wrong, along with the corrections. CC ID 00467 Privacy protection for information and data Behavior
    Order the cessation of data processing when a violation of the privacy policy is detected. CC ID 00475 Privacy protection for information and data Data and Information Management
    Cooperate with authorities during a privacy rights violation complaint investigation. CC ID 14364 Privacy protection for information and data Business Processes
    Notify respondents after a privacy rights violation complaint investigation has been resolved. CC ID 13513 Privacy protection for information and data Communicate
    Create an investigative report in regards to a privacy rights violation complaint. CC ID 00495 Privacy protection for information and data Establish/Maintain Documentation
    Respond to an investigative report in regards to a privacy rights violation complaint. CC ID 00496 Privacy protection for information and data Behavior
    Order the organization to change to be in compliance with applicable law. CC ID 00499 Privacy protection for information and data Behavior
    Order the organization to publish a notice with the corrections or actions taken. CC ID 00500 Privacy protection for information and data Behavior
    Award damages based on applicable law. CC ID 00501 Privacy protection for information and data Behavior
    Destroy personal data that breaches privacy after the privacy breach has been detected. CC ID 00503 Privacy protection for information and data Data and Information Management
    Include required information in the counterfeit product report. CC ID 11518 Third Party and supply chain oversight Business Processes
    Include evidence that the counterfeit product was purchased in the counterfeit product report. CC ID 11519 Third Party and supply chain oversight Business Processes
    Include evidence of what was counterfeited in the counterfeit product report. CC ID 11529 Third Party and supply chain oversight Business Processes
    Include damages caused by counterfeiting in the counterfeit product report. CC ID 11530 Third Party and supply chain oversight Business Processes
    Include suggested remediation steps in the counterfeit product report. CC ID 11531 Third Party and supply chain oversight Business Processes
    Disseminate and communicate ethics complaint reports to interested personnel and affected parties. CC ID 11521 Third Party and supply chain oversight Business Processes
    Include response times in ethics complaint reports. CC ID 11520 Third Party and supply chain oversight Business Processes
  • Detective
    59
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE TYPE
    Monitor personnel and third parties for compliance to the organizational compliance framework. CC ID 04726
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that the technologies used in the department or agency’s implementation of the PIV system allow for continuous auditing of compliance with stated privacy policies and with practices governing the collection, use, and distribution of information in the operation of the program. 2.11 ¶ 3 Bullet 9]
    Monitoring and measurement Monitor and Evaluate Occurrences
    Align enforcement reviews for non-compliance with organizational risk tolerance. CC ID 13063 Monitoring and measurement Business Processes
    Determine if multiple compliance violations of the same type could occur. CC ID 12402 Monitoring and measurement Investigate
    Review the effectiveness of disciplinary actions carried out for compliance violations. CC ID 12403 Monitoring and measurement Investigate
    Refrain from performing identity proofing as a means of providing access to systems or services. CC ID 13776 Technical security Process or Activity
    Interact with the data subject when performing remote proofing. CC ID 13777
    [{identity proofing} The following forms of protection SHALL be provided by either inherent capabilities of the station or staff at the station location: ensuring that only the applicant interacts with the station during any session; 2.7.1 ¶ 3 Bullet 1
    Supervised remote identity proofing SHALL meet the following requirements: The issuer SHALL have a live operator participate remotely with the applicant for the entirety of the identity proofing session. 2.7.1 ¶ 4 Bullet 2]
    Technical security Process or Activity
    View all applicant actions when performing remote proofing. CC ID 13804
    [Supervised remote identity proofing SHALL meet the following requirements: The operator SHALL monitor the entire identity proofing session—from which the applicant SHALL NOT depart—by at least one continuous, high-resolution video transmission of the applicant. 2.7.1 ¶ 4 Bullet 4
    Supervised remote identity proofing SHALL meet the following requirements: The operator SHALL require all actions taken by the applicant during the identity proofing session to be clearly visible to the operator. 2.7.1 ¶ 4 Bullet 5
    Supervised remote identity proofing SHALL meet the following requirements: The station SHALL be maintained in a controlled-access environment and SHALL be monitored by staff at the station location while it is being used. 2.7.1 ¶ 4 Bullet 1
    {not be successful}{not acquire} OCC reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 6]
    Technical security Process or Activity
    Verify transaction history as part of the knowledge-based authentication questions during the identity proofing process. CC ID 13755 Technical security Process or Activity
    Base the knowledge-based authentication for the identity proofing process on authoritative sources. CC ID 13743 Technical security Process or Activity
    Refrain from revealing the data subject's personal data in knowledge-based authentication questions for the identity proofing process. CC ID 13774 Technical security Process or Activity
    Refrain from using diversionary knowledge-based authentication questions during the identity proofing processes. CC ID 13744 Technical security Process or Activity
    Validate proof of identity during the identity proofing process. CC ID 13756
    [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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1]
    Technical security Process or Activity
    Allow biometric authentication for proof of identity during the identity proofing process. CC ID 13797 Technical security Business Processes
    Inspect for the presence of man-made materials when performing biometric authentication during the identity proofing process. CC ID 13803 Technical security Process or Activity
    Verify proof of identity records. CC ID 13761
    [During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    {refrain from implementing}{not be consistent} Departments and agencies may have a wide variety of uses for the PIV system and its components that were not intended or anticipated by the President in issuing [HSPD-12]. In considering whether a proposed use of the PIV system is appropriate, departments and agencies SHALL consider the aforementioned control objectives and the purpose of this Standard, namely “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy” as per [HSPD-12]. No department or agency SHALL implement a use of the identity credential inconsistent with these control objectives. 2.11 ¶ 2
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    Departments and agencies SHALL ensure that driver’s licenses and ID cards presented by applicants comply with [REAL-ID] when required pursuant to DHS regulations. Stateissued driver’s licenses and ID cards that are not [REAL-ID] compliant MAY be used until the full enforcement date under [6 CFR § 37.5]. Departments and agencies SHALL ensure that driver’s licenses and ID cards presented by applicants comply with [REAL-ID] when required pursuant to DHS regulations. Stateissued driver’s licenses and ID cards that are not [REAL-ID] compliant MAY be used until the full enforcement date under [6 CFR § 37.5]. 2.7 ¶ 9
    {not be successful}{not acquire} OCC reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operatorground-color:#CBD0E5;" class="term_secondary-verb"> SHALL <span style="background-color:#B7D8ED;" class="term_primary-verb">inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 6]
    Technical security Investigate
    Refrain from using knowledge-based authentication to verify an individual's identity against more than one proof of identity during the identity proofing process. CC ID 13784 Technical security Process or Activity
    Conduct in-person proofing with physical interactions. CC ID 13775
    [{appear in person} If biometric data cannot be collected per the criteria defined in [SP 800-76] or if validation of the identity evidence is inadequate, supervised remote identity proofing SHALL NOT be used and the identity proofing and enrollment will be performed in person at the issuer’s facility. The trained operator SHALL terminate a supervised remote identity proofing session and require in-person identity proofing at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.7.1 ¶ 5
    {appear in person} If biometric data cannot be collected per the criteria defined in [SP 800-76] or if validation of the identity evidence is inadequate, supervised remote identity proofing SHALL NOT be used and the identity proofing and enrollment will be performed in person at the issuer’s facility. The trained operator SHALL terminate a supervised remote identity proofing session and require in-person identity proofing at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.7.1 ¶ 5]
    Technical security Process or Activity
    Reperform the identity proofing process for each individual, as necessary. CC ID 13762 Technical security Process or Activity
    Validate the issuer in the authentication assertion. CC ID 13878 Technical security Technical Security
    Validate the timestamp in the authentication assertion. CC ID 13875 Technical security Technical Security
    Validate the digital signature in the authentication assertion. CC ID 13869 Technical security Technical Security
    Validate the signature validation element in the authentication assertion. CC ID 13867 Technical security Technical Security
    Validate the audience restriction element in the authentication assertion. CC ID 13866 Technical security Technical Security
    Notify interested personnel when user accounts are added or deleted. CC ID 14327 Technical security Communicate
    Employ unique identifiers. CC ID 01273 Technical security Testing
    Authenticate user identities before unlocking an account. CC ID 11837 Technical security Testing
    Authenticate user identities before manually resetting an authenticator. CC ID 04567
    [{appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT reset the PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5]
    Technical security Testing
    Identify the user when enrolling them in the biometric system. CC ID 06882
    [{does not occur} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that No substitution occurs in the identity proofing process. More specifically, the individual who appears for identity proofing and whose fingerprints are checked against databases is the person to whom the credential is issued. 2.1 ¶ 2 Bullet 6
    {be different} The use of an different content signing key from that which signs the CHUID is deprecated in this revision of the Standard. If the signature on the biometric data record was generated with a different key than the signature on the CHUID, the certificates field of the CMS external digital signature SHALL include the content signing certificate required to verify the signature on the biometric data record. Otherwise, the certificates field SHALL be omitted. 4.2.3.2 ¶ 5]
    Technical security Testing
    Scan for malicious code, as necessary. CC ID 11941 Technical security Investigate
    Test all removable storage media for viruses and malicious code. CC ID 11861 Technical security Testing
    Test all untrusted files or unverified files for viruses and malicious code. CC ID 01311 Technical security Testing
    Log and react to all malicious code activity. CC ID 07072 Technical security Monitor and Evaluate Occurrences
    Analyze the behavior and characteristics of the malicious code. CC ID 10672 Technical security Technical Security
    Establish, implement, and maintain an anti-tamper protection program. CC ID 10638 Physical and environmental protection Monitor and Evaluate Occurrences
    Employ individuals who have the appropriate staff qualifications, staff clearances, and staff competencies. CC ID 00782 Human Resources management Testing
    Perform a background check during personnel screening. CC ID 11758
    [{does not exist} For individuals for whom no prior investigation exists, the appropriate required investigation SHALL be initiated with the authorized federal investigative service provider and the FBI NCHC portion of the background investigation SHALL be completed and favorably adjudicated prior to PIV Card issuance. 2.2 ¶ 4]
    Human Resources management Human Resources Management
    Perform periodic background checks on designated roles, as necessary. CC ID 11759
    [{are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2]
    Human Resources management Human Resources Management
    Document the security clearance procedure results. CC ID 01635 Human Resources management Establish/Maintain Documentation
    Implement segregation of duties in roles and responsibilities. CC ID 00774
    [The PIV identity proofing, registration, issuance, and reissuance processes SHALL adhere to the y-noun">principlespan> of an style="background-color:#F0BBBC;" class="term_primary-noun">separation of duties to ensure that no single individual has the capability to issue a PIV Card without the cooperation of another authorized person. The PIV identity proofing, registration, issuance, and reissuance processes SHALL adhere to the principle of separation of duties to ensure that no single individual has the capability to issue a PIV Card without the cooperation of another authorized person. 2.7 ¶ 10]
    Human Resources management Testing
    Include disability accessibility standards in the disability accessibility program. CC ID 06192 Operational management Testing
    Follow disability accessibility standards when designing and building content. CC ID 06193 Operational management Testing
    Install telecommunications equipment that meets the disability accessibility standards. CC ID 06194 Operational management Testing
    Install audio and visual equipment that meets the disability accessibility standards. CC ID 06195 Operational management Testing
    Acquire commercial off the shelf products that meet the disability accessibility standards. CC ID 06196 Operational management Testing
    Acquire workstations and laptops that meet the disability accessibility standards. CC ID 06197 Operational management Testing
    Grant registration after competence and integrity is verified. CC ID 16802 Operational management Behavior
    Ensure the root account is the first entry in password files. CC ID 16323 System hardening through configuration management Data and Information Management
    Define each system's preservation requirements for records and logs. CC ID 00904 Records management Establish/Maintain Documentation
    Establish, implement, and maintain a data retention program. CC ID 00906 Records management Establish/Maintain Documentation
    Maintain continued integrity for all stored data and stored records. CC ID 00969
    [{data in transit}{data at rest} PIV enrollment records contain Personally Identifiable Information (PII). PII SHALL be protected in a manner that protects the individual’s privacy and maintains the integrity of the records both in transit and at rest. 2.6 ¶ 5]
    Records management Testing
    Analyze requirements for processing personal data in contracts. CC ID 12550 Privacy protection for information and data Investigate
    Investigate privacy rights violation complaints. CC ID 00480 Privacy protection for information and data Behavior
    Notify respondents after a privacy rights violation complaint investigation begins. CC ID 00491 Privacy protection for information and data Behavior
    Investigate privacy rights violation complaints in private. CC ID 00492 Privacy protection for information and data Behavior
    Make appropriate inquiries and obtain appropriate information regarding privacy rights violation complaints. CC ID 00493 Privacy protection for information and data Behavior
    Allow the complainant to appear before the commissioner and make a submission, orally or in writing, about the privacy rights violation complaint investigation prior to an adverse decision to the complainant is reached. CC ID 00494 Privacy protection for information and data Behavior
    Define the available administrative remedies in regards to a privacy rights violation complaint. CC ID 00497 Privacy protection for information and data Establish/Maintain Documentation
    Refrain from subjecting individuals to retaliation or intimidation after a complaint is created. CC ID 06218 Privacy protection for information and data Testing
    Compare the photograph on the customer's identification card or badge with the customer's physical appearance. CC ID 04861
    [{appear in person}{not be successful}{not be available} When OCC reset is performed in person at the issuing facility, before the reset, the issuer SHALL perform a biometric verification of the cardholder to the biometric data records in the PIV enrollment record. If the biometric verification decision is negative or no alternative biometric data records are available, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 4
    Remote PIN reset on a general computing platform (e.g., desktop, laptop) SHALL only be performed if all the following requirements are met: The cardholder’s biometric characteristics elicit a "background-color:#F0BBBC;" class="term_primary-noun">positive biometric verification decision> when compared to the stored biometric data records on the PIV Card through the OCC-AUTH authentication mechanism. 2.9.3.1 ¶ 9 Bullet 3
    {applicable requirements}{remote proofing procedure}{not acquire} PIN reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCCAUTH authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and D0E5;" class="term_secondary-verb">#B7D8ED;" cl
    ass="term_primary-verb">comparespan> the _pristyle="background-color:#CBD0E5;" class="term_secondary-verb">mary-noun">video feed of the cardholder with the style="background-color:#F0BBBC;" class="term_primary-noun">electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.1 ¶ 7]
    Privacy protection for information and data Testing
  • IT Impact Zone
    11
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE TYPE
    Leadership and high level objectives CC ID 00597 Leadership and high level objectives IT Impact Zone
    Monitoring and measurement CC ID 00636 Monitoring and measurement IT Impact Zone
    Technical security CC ID 00508 Technical security IT Impact Zone
    Physical and environmental protection CC ID 00709 Physical and environmental protection IT Impact Zone
    Human Resources management CC ID 00763 Human Resources management IT Impact Zone
    Operational management CC ID 00805 Operational management IT Impact Zone
    System hardening through configuration management CC ID 00860 System hardening through configuration management IT Impact Zone
    Records management CC ID 00902 Records management IT Impact Zone
    Systems design, build, and implementation CC ID 00989 Systems design, build, and implementation IT Impact Zone
    Privacy protection for information and data CC ID 00008 Privacy protection for information and data IT Impact Zone
    Third Party and supply chain oversight CC ID 08807 Third Party and supply chain oversight IT Impact Zone
  • Preventive
    546
    KEY:    Primary Verb     Primary Noun     Secondary Verb     Secondary Noun     Limiting Term
    Mandated - bold    Implied - italic    Implementation - regular IMPACT ZONE TYPE
    Establish, implement, and maintain a reporting methodology program. CC ID 02072 Leadership and high level objectives Business Processes
    Establish, implement, and maintain communication protocols. CC ID 12245 Leadership and high level objectives Establish/Maintain Documentation
    Establish, implement, and maintain alert procedures that follow the organization's communication protocol. CC ID 12406
    [{be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2]
    Leadership and high level objectives Establish/Maintain Documentation
    Include the capturing and alerting of compliance violations in the notification system. CC ID 12962 Leadership and high level objectives Monitor and Evaluate Occurrences
    Include the capturing and alerting of unethical conduct in the notification system. CC ID 12932 Leadership and high level objectives Monitor and Evaluate Occurrences
    Include the capturing and alerting of performance variances in the notification system. CC ID 12929 Leadership and high level objectives Monitor and Evaluate Occurrences
    Include the capturing and alerting of weaknesses in the notification system. CC ID 12928 Leadership and high level objectives Monitor and Evaluate Occurrences
    Include the capturing and alerting of account activity in the notification system. CC ID 15314 Leadership and high level objectives Monitor and Evaluate Occurrences
    Establish, implement, and maintain a testing program. CC ID 00654 Monitoring and measurement Behavior
    Establish, implement, and maintain a stress test program for identification cards or badges. CC ID 15424
    [{PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5
    Sample cards SHALL be subjected to sunlight exposure in accordance with Section 5.12 of [ISO 10373] or to ultraviolet and daylight fading exposure in accordance with [ANSI 322]. Sunlight exposure in accordance with [ISO 10373] SHALL be in the form of actual, concentrated, or artificial sunlight that appropriately reflect 2 000 hours of southwestern United States’ sunlight. Concentrated sunlight exposure SHALL be performed in accordance with [G90-17] and accelerated exposure in accordance with [G155-2013]. Sample cards SHALL be subjected to the [ISO 10373] dynamic bending test and SHALL have no visible cracks or failures after the [ISO 10373] or [ANSI 322] exposure. 4.1.3 ¶ 5]
    Monitoring and measurement Establish/Maintain Documentation
    Establish, implement, and maintain a compliance monitoring policy. CC ID 00671 Monitoring and measurement Establish/Maintain Documentation
    Establish, implement, and maintain a metrics policy. CC ID 01654 Monitoring and measurement Establish/Maintain Documentation
    Establish, implement, and maintain an approach for compliance monitoring. CC ID 01653 Monitoring and measurement Establish/Maintain Documentation
    Identify and document instances of non-compliance with the compliance framework. CC ID 06499 Monitoring and measurement Establish/Maintain Documentation
    Identify and document events surrounding non-compliance with the organizational compliance framework. CC ID 12935 Monitoring and measurement Establish/Maintain Documentation
    Align disciplinary actions with the level of compliance violation. CC ID 12404 Monitoring and measurement Human Resources Management
    Establish, implement, and maintain disciplinary action notices. CC ID 16577 Monitoring and measurement Establish/Maintain Documentation
    Include a copy of the order in the disciplinary action notice. CC ID 16606 Monitoring and measurement Establish/Maintain Documentation
    Include the sanctions imposed in the disciplinary action notice. CC ID 16599 Monitoring and measurement Establish/Maintain Documentation
    Include the effective date of the sanctions in the disciplinary action notice. CC ID 16589 Monitoring and measurement Establish/Maintain Documentation
    Include the requirements that were violated in the disciplinary action notice. CC ID 16588 Monitoring and measurement Establish/Maintain Documentation
    Include responses to charges from interested personnel and affected parties in the disciplinary action notice. CC ID 16587 Monitoring and measurement Establish/Maintain Documentation
    Include the reasons for imposing sanctions in the disciplinary action notice. CC ID 16586 Monitoring and measurement Establish/Maintain Documentation
    Disseminate and communicate the disciplinary action notice to interested personnel and affected parties. CC ID 16585 Monitoring and measurement Communicate
    Include required information in the disciplinary action notice. CC ID 16584 Monitoring and measurement Establish/Maintain Documentation
    Include a justification for actions taken in the disciplinary action notice. CC ID 16583 Monitoring and measurement Establish/Maintain Documentation
    Include a statement on the conclusions of the investigation in the disciplinary action notice. CC ID 16582 Monitoring and measurement Establish/Maintain Documentation
    Include the investigation results in the disciplinary action notice. CC ID 16581 Monitoring and measurement Establish/Maintain Documentation
    Include a description of the causes of the actions taken in the disciplinary action notice. CC ID 16580 Monitoring and measurement Establish/Maintain Documentation
    Include the name of the person responsible for the charges in the disciplinary action notice. CC ID 16579 Monitoring and measurement Establish/Maintain Documentation
    Include contact information in the disciplinary action notice. CC ID 16578 Monitoring and measurement Establish/Maintain Documentation
    Establish, implement, and maintain a digital identity management program. CC ID 13713 Technical security Establish/Maintain Documentation
    Establish the requirements for Identity Assurance Levels. CC ID 13857
    [The selection of authentication assurance levels SHALL be made in accordance with the applicable policies for a facility’s security level [RISK-MGMT-FACILITIES]. Additional guidelines for the selection and use of PIV authentication mechanisms for facility access can be found in NIST [SP 800-116]. 6.3.1 ¶ 3]
    Technical security Technical Security
    Establish, implement, and maintain digital identification procedures. CC ID 13714
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that 2.1 ¶ 2
    The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. 2.7 ¶ 11]
    Technical security Establish/Maintain Documentation
    Implement digital identification processes. CC ID 13731 Technical security Process or Activity
    Implement identity proofing processes. CC ID 13719
    [The department or agency SHALL adopt and use an identity proofing and registration process that is approved in accordance with [SP 800-79]. 2.7 ¶ 2
    [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 specified in this Standard, as well as those specified in federal privacy laws and policies including but not limited to the E-Government Act of 2002 [E-Gov], the Privacy Act of 1974 [PRIVACY], and OMB [M-03-22], as applicable. 2.11 ¶ 1
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6
    {refrain from implementing}{not be consistent} Departments and agencies may have a wide variety of uses for the PIV system and its components that were not intended or anticipated by the President in issuing [HSPD-12]. In considering whether a proposed use of the PIV system is appropriate, departments and agencies SHALL consider the aforementioned control objectives and the purpose of this Standard, namely “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy” as per [HSPD-12]. No department or agency SHALL implement a use of the identity credential inconsistent with these control objectives. 2.11 ¶ 2
    The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. The identity proofing and registration process used when verifying the identity of the applicant SHALL be accredited by the department or agency as satisfying the requirements above and approved in writing by the head or deputy (or equivalent) of the federal department or agency. 2.7 ¶ 11]
    Technical security Process or Activity
    Verify the identity of the organization's authorized representative during the identity proofing process. CC ID 13786 Technical security Process or Activity
    Allow authorized representatives to act on behalf of the data subject during the identity proofing process. CC ID 13787 Technical security Process or Activity
    Support the identity proofing process through in-person proofing or remote proofing. CC ID 13750 Technical security Process or Activity
    Establish, implement, and maintain remote proofing procedures. CC ID 13796
    [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 issuercontrolled station at a remote location that is connected to a trained operator at a central location. The goal of this arrangement is to permit identity proofing and enrollment of individuals in remote locations where it is not practical for them to travel to the agency for in-person identity proofing. 2.7.1 ¶ 1
    Supervised remote identity proofing SHALL meet the following requirements: The issuer SHALL ensure that all communications occur over a mutually authenticated protected channel. 2.7.1 ¶ 4 Bullet 7
    The following forms of protection SHALL be provided by either inherent capabilities of the station or staff at the station location: ensuring that the physical integrity of the station (e.g., door locks and restricted access) and integral nature of its sensor devices (e.g., fingerprint readers and cameras) are maintained at all times to protect against tampering, removal, or replacement; 2.7.1 ¶ 3 Bullet 2
    Supervised remote identity proofing SHALL meet the following requirements: The station SHALL be maintained in a controlled-access environment and SHALL be monitored by staff at the station location while it is being used. 2.7.1 ¶ 4 Bullet 1]
    Technical security Establish/Maintain Documentation
    Require digital authentication of evidence by integrated scanners when performing remote proofing. CC ID 13805
    [Supervised remote identity proofing SHALL meet the following requirements: The operator SHALL validate the physical or cryptographic security features of primary and secondary identity source documents using scanners and sensors that are integrated into the station. 2.7.1 ¶ 4 Bullet 6]
    Technical security Configuration
    Use valid activation codes to complete the identity proofing process when performing remote proofing. CC ID 13742 Technical security Process or Activity
    Employ knowledge-based authentication tools to aid the identity proofing process. CC ID 13741 Technical security Process or Activity
    Refrain from using publicly available information for knowledge-based authentication during the identity proofing process. CC ID 13752 Technical security Process or Activity
    Refrain from using knowledge-based authentication questions that hint at their own answers during the identity proofing process. CC ID 13785 Technical security Process or Activity
    Refrain from using static knowledge-based authentication questions during the identity proofing process. CC ID 13773 Technical security Process or Activity
    Require a minimum number of knowledge-based authentication questions for the identity proofing process. CC ID 13745 Technical security Configuration
    Require free-form response knowledge-based authentication questions for the identity proofing process. CC ID 13746 Technical security Configuration
    Set a maximum number of attempts to complete the knowledge-based authentication for the identity proofing process. CC ID 13747 Technical security Configuration
    Use information from authoritative sources or the applicant for knowledge-based authentication during the identity proofing process. CC ID 13749 Technical security Process or Activity
    Allow records that relate to the data subject as proof of identity. CC ID 13772
    [During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6]
    Technical security Process or Activity
    Include the consequences of refraining from providing attributes in the identity proofing process. CC ID 13748 Technical security Process or Activity
    Send a notification of proofing to a confirmed address of record when performing in-person proofing. CC ID 13739 Technical security Process or Activity
    Refrain from using unconfirmed self-asserted address data during the identity proofing process. CC ID 13738 Technical security Process or Activity
    Refrain from approving attributes in the identity proofing process. CC ID 13716 Technical security Process or Activity
    Establish, implement, and maintain federated identity systems. CC ID 13837
    [The IAL, AAL, and FAL SHALL be known to the RP at the conclusion of the federation transaction. This information MAY be pre-established or the IdP MAY communicate this at runtime in the assertion. For example, the information can be presented using technologies defined in [RFC 8485], [OIDC4IA], or [SAML-AC]. 7.2 ¶ 2]
    Technical security Technical Security
    Authenticate all systems in a federated identity system. CC ID 13835 Technical security Technical Security
    Send and receive authentication assertions, as necessary. CC ID 13839
    [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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1]
    Technical security Technical Security
    Make the assertion reference for authentication assertions single-use. CC ID 13843 Technical security Technical Security
    Limit the lifetime of the assertion reference. CC ID 13874 Technical security Technical Security
    Refrain from using authentication assertions that have expired. CC ID 13872
    [A derived PIV credential SHALL NOT be accepted for authentication once the credential has been invalidated. When invalidation occurs, the issuer SHALL notify the cardholder of the change. 2.10.2 ¶ 3]
    Technical security Technical Security
    Protect the authentication assertion from unauthorized access or unauthorized disclosure. CC ID 16836 Technical security Technical Security
    Include the issuer identifier in the authentication assertion. CC ID 13865 Technical security Technical Security
    Include attribute metadata in the authentication assertion. CC ID 13856 Technical security Technical Security
    Include the authentication time in the authentication assertion. CC ID 13855 Technical security Technical Security
    Validate each element within the authentication assertion. CC ID 13853
    [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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1]
    Technical security Technical Security
    Include the subject in the authentication assertion. CC ID 13852 Technical security Technical Security
    Include the target audience in the authentication assertion. CC ID 13851 Technical security Technical Security
    Include audience restrictions in the authentication assertion. CC ID 13870 Technical security Technical Security
    Include the issue date in the authentication assertion. CC ID 13850 Technical security Technical Security
    Revoke authentication assertions, as necessary. CC ID 16534 Technical security Technical Security
    Include the expiration date in the authentication assertion. CC ID 13849 Technical security Technical Security
    Include identifiers in the authentication assertion. CC ID 13848 Technical security Technical Security
    Include digital signatures in the authentication assertion. CC ID 13847 Technical security Technical Security
    Include key binding in the authentication assertion. CC ID 13846 Technical security Technical Security
    Include attribute references in the authentication assertion. CC ID 13845 Technical security Technical Security
    Include attribute values in the authentication assertion. CC ID 13844 Technical security Technical Security
    Limit the use of the assertion reference to a single organization. CC ID 13841 Technical security Technical Security
    Request attribute references instead of attribute values during the presentation of an authentication assertion. CC ID 13840 Technical security Technical Security
    Define the assertion level for authentication assertions. CC ID 13873 Technical security Technical Security
    Refrain from assigning assertion levels for authentication assertions when not defined. CC ID 13879 Technical security Technical Security
    Authenticate systems referenced in the whitelist. CC ID 13838 Technical security Technical Security
    Place nonmembers of whitelists and blacklists into a gray area until a runtime decision is made during the authentication assertion. CC ID 13854 Technical security Technical Security
    Require runtime decisions regarding authentication for organizations that are excluded from the whitelist. CC ID 13842 Technical security Technical Security
    Establish, implement, and maintain an access control program. CC ID 11702 Technical security Establish/Maintain Documentation
    Include instructions to change authenticators as often as necessary in the access control program. CC ID 11931
    [{previously used PIN} Cardholders MAY change their PINs at any time by providing the current PIN and the new PIN values, as specified in [SP 800-73]. 2.9.3 ¶ 3]
    Technical security Establish/Maintain Documentation
    Include guidance for how users should protect their authentication credentials in the access control program. CC ID 11929
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that An issued credential is not modified by an unauthorized entity. 2.1 ¶ 2 Bullet 12]
    Technical security Establish/Maintain Documentation
    Include guidance on selecting authentication credentials in the access control program. CC ID 11928
    [{be unguessable}{not be identifiable}{be unique} The cardholder SHALL be guided in selecting a strong PIN value. The PIN SHALL be a minimum of six digits in length and SHOULD NOT be easily guessable, individually identifiable (e.g., part of a Social Security Number or phone number), or commonly used (e.g., 000000, 123456). 4.3.1 ¶ 2]
    Technical security Establish/Maintain Documentation
    Establish, implement, and maintain an access rights management plan. CC ID 00513 Technical security Establish/Maintain Documentation
    Control access rights to organizational assets. CC ID 00004 Technical security Technical Security
    Establish, implement, and maintain lockout procedures or lockout mechanisms to be triggered after a predetermined number of consecutive logon attempts. CC ID 01412
    [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 card to perform CTC authentication, and the card responds with a positive or negative biometric verification decision. The response includes information that allows the reader to authenticate the card. Entry of the cardholder PIN is not required for OCC-AUTH. The PIV Card SHALL include a mechanism to block this authentication mechanism after a number of consecutive failed authentication attempts as stipulated by the department or agency. As with BIO and BIO-A, if agencies choose to implement OCC, it SHALL be implemented as defined in [SP 800-73] and [SP 800-76]. 6.2.2 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1]
    Technical security Technical Security
    Configure the lockout procedure to disregard failed logon attempts after the user is authenticated. CC ID 13822 Technical security Configuration
    Disallow unlocking user accounts absent system administrator approval. CC ID 01413 Technical security Technical Security
    Establish, implement, and maintain User Access Management procedures. CC ID 00514 Technical security Technical Security
    Control the addition and modification of user identifiers, user credentials, or other authenticators. CC ID 00515
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A process exists to invalidate, revoke, or destroy credentials when the cardholder loses eligibility or when the credential is lost, stolen, or compromised. 2.1 ¶ 2 Bullet 9
    Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential remains serviceable only up to its expiration date. 2.1 ¶ 2 Bullet 8
    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 requirements in this section. 2.10.1 ¶ 1]
    Technical security Technical Security
    Assign roles and responsibilities for administering user account management. CC ID 11900 Technical security Human Resources Management
    Automate access control methods, as necessary. CC ID 11838 Technical security Technical Security
    Automate Access Control Systems, as necessary. CC ID 06854 Technical security Technical Security
    Refrain from storing logon credentials for third party applications. CC ID 13690 Technical security Technical Security
    Refrain from allowing user access to identifiers and authenticators used by applications. CC ID 10048 Technical security Technical Security
    Protect and manage biometric systems and biometric data. CC ID 01261
    [The biometric data records in the PIV enrollment records SHALL be valid for a maximum of 12 years. In order to mitigate aging effects and thereby maintain operational readiness of a cardholder’s PIV Card, agencies MAY require biometric enrollment more frequently than 12 years. 2.6 ¶ 4
    The CBEFF signature block contains the digital signature of the biometric data record and facilitates the verification of the integrity of the biometric data record. The CBEFF signature block SHALL be encoded as a CMS external digital signature as specified in [SP 800-76]. The algorithm and key size requirements for the digital signature and digest algorithm are detailed in [SP 800-78]. 4.2.3.2 ¶ 3]
    Technical security Technical Security
    Establish, implement, and maintain biometric collection procedures. CC ID 15419
    [A full set of fingerprints SHALL be collected from each PIV applicant who is lacking an on-record background investigation. 2.3 ¶ 2
    The following biometric data MAY be collected from a PIV applicant: An electronic image of the right iris. 2.4 ¶ 2 Bullet 2
    The full set of fingerprints SHALL be collected for biometric identification against databases of fingerprints maintained by the FBI. 2.5 ¶ 1
    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. 2.4 ¶ 1 Bullet 1
    Fingerprint collection SHALL conform to the procedural and technical specifications of [SP 800-76]. 2.3 ¶ 4
    Biometric data collection SHALL conform to the procedural and technical specifications of [SP 800-76]. The choice of fingers to use for mandatory fingerprint templates and optional fingerprint templates MAY vary between persons. The recommended selection and order is specified in [SP 800-76]. 2.4 ¶ 5
    The following biometric data SHALL be collected from each PIV applicant: An electronic facial image. 2.4 ¶ 1 Bullet 2
    The following biometric data MAY be collected from a PIV applicant: Two fingerprints for on-card comparison (OCC). These fingerprints MAY be taken from the full set of fingerprints collected in Section 2.3 and SHOULD be imaged from fingers not imaged for off-card one-to-one comparison. 2.4 ¶ 2 Bullet 3
    The following biometric data MAY be collected from a PIV applicant: An electronic image of the left iris. 2.4 ¶ 2 Bullet 1]
    Technical security Establish/Maintain Documentation
    Establish, implement, and maintain access control procedures. CC ID 11663
    [Parties responsible for controlling access to federal resources (both physical and logical) SHALL determine the appropriate assurance levels required for access based on the harm and impact to individuals and organizations that could occur as a result of errors in the authentication of the PIV cardholder. Once the required assurance level has been determined, one of the authentication mechanisms specified in Section 6.2 SHALL be applied to achieve that assurance level. 6.1 ¶ 3]
    Technical security Establish/Maintain Documentation
    Grant access to authorized personnel or systems. CC ID 12186
    [{is not issued} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that No credential is issued unless requested by the proper authority. 2.1 ¶ 2 Bullet 7
    To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that only personnel with a legitimate need for access to PII in the PIV system are authorized to access the PII, including but not limited to information and databases maintained for registration and credential issuance. 2.11 ¶ 3 Bullet 7]
    Technical security Configuration
    Document approving and granting access in the access control log. CC ID 06786 Technical security Establish/Maintain Documentation
    Disseminate and communicate the access control log to interested personnel and affected parties. CC ID 16442 Technical security Communicate
    Include the user identifiers of all personnel who are authorized to access a system in the system record. CC ID 15171 Technical security Establish/Maintain Documentation
    Include identity information of all personnel who are authorized to access a system in the system record. CC ID 16406 Technical security Establish/Maintain Documentation
    Include the date and time that access was reviewed in the system record. CC ID 16416 Technical security Data and Information Management
    Include the date and time that access rights were changed in the system record. CC ID 16415 Technical security Establish/Maintain Documentation
    Establish, implement, and maintain an identification and authentication policy. CC ID 14033 Technical security Establish/Maintain Documentation
    Include roles and responsibilities in the identification and authentication policy. CC ID 14230
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A single corrupt official in the process cannot issue a credential with an incorrect identity or to a person not entitled to the credential. 2.1 ¶ 2 Bullet 10
    PIV Cards that contain topographical defects (e.g., scratches, poor color, fading, etc.) or that are not properly printed SHALL be destroyed. The PIV Card issuer is responsible for the card stock, its management, and its integrity. 2.8 ¶ 2
    {applicable requirements} Remote issuance SHALL satisfy all of the requirements of Section 2.8. The issuer SHALL have local trained staff to securely maintain custody of card stock received by the remote station when the station is used for PIV Card issuance. 2.8.3 ¶ 2]
    Technical security Establish/Maintain Documentation
    Establish, implement, and maintain identification and authentication procedures. CC ID 14053
    [Federal departments and agencies SHALL use the credentialing eligibility standards issued by the Director of the Office of Personnel Management (OPM) and OMB. 2.2 ¶ 1
    Parties responsible for controlling access to federal resources (both physical and logical) SHALL determine the appropriate assurance levels required for access based on the harm and impact to individuals and organizations that could occur as a result of errors in the authentication of the PIV cardholder. Once the required assurance level has been determined, one of the authentication mechanisms specified in Section 6.2 SHALL be applied to achieve that assurance level. 6.1 ¶ 3
    {be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2]
    Technical security Establish/Maintain Documentation
    Disseminate and communicate the identification and authentication procedures to interested personnel and affected parties. CC ID 14223 Technical security Communicate
    Include digital identification procedures in the access control program. CC ID 11841
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential is issued to an individual only after a proper authority has authorized issuance of the credential, the individual’s identity has been verified, and the individual has been vetted per Section 2.2. 2.1 ¶ 2 Bullet 1]
    Technical security Technical Security
    Disseminate and communicate user identifiers and authenticators using secure communication protocols. CC ID 06791
    [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 to a website or other server), the input device is not required to be integrated with the PIV Card reader. If the input device is not integrated with the PIV Card reader, the PIN or OCC data SHALL be transmitted securely and directly to the PIV Card for card activation. 4.4.4 ¶ 1]
    Technical security Data and Information Management
    Include instructions to refrain from using previously used authenticators in the access control program. CC ID 11930 Technical security Establish/Maintain Documentation
    Disallow the use of Personal Identification Numbers as user identifiers. CC ID 06785 Technical security Technical Security
    Define the activation requirements for identification cards or badges. CC ID 06583
    [{does not exist} For individuals for whom no prior investigation exists, the appropriate required investigation SHALL be initiated with the authorized federal investigative service provider and the FBI NCHC portion of the background investigation SHALL be completed and favorably adjudicated prior to PIV Card issuance. 2.2 ¶ 4
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1]
    Technical security Process or Activity
    Require multiple forms of personal identification prior to issuing user identifiers. CC ID 08712
    [{does not occur} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that No substitution occurs in the identity proofing process. More specifically, the individual who appears for identity proofing and whose fingerprints are checked against databases is the person to whom the credential is issued. 2.1 ¶ 2 Bullet 6
    Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that An individual is issued a credential only after presenting two identity source documents, at least one of which is a Federal or State Government-issued picture ID. 2.1 ¶ 2 Bullet 3
    Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential is issued to an individual only after a proper authority has authorized issuance of the credential, the individual’s identity has been verified, and the individual has been vetted per Section 2.2. 2.1 ¶ 2 Bullet 1]
    Technical security Human Resources Management
    Require proper authentication for user identifiers. CC ID 11785
    [{be genuine} {is not altered} Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that Fraudulent identity source documents are not accepted as genuine or unaltered. 2.1 ¶ 2 Bullet 4]
    Technical security Technical Security
    Assign authenticators to user accounts. CC ID 06855 Technical security Configuration
    Assign authentication mechanisms for user account authentication. CC ID 06856 Technical security Configuration
    Refrain from allowing individuals to share authentication mechanisms. CC ID 11932 Technical security Technical Security
    Establish and maintain a memorized secret list. CC ID 13791 Technical security Establish/Maintain Documentation
    Limit account credential reuse as a part of digital identification procedures. CC ID 12357
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that An issued credential is not duplicated or forged. 2.1 ¶ 2 Bullet 11]
    Technical security Configuration
    Refrain from assigning authentication mechanisms for shared accounts. CC ID 11910 Technical security Technical Security
    Use biometric authentication for identification and authentication, as necessary. CC ID 06857
    [If the identity proofing and enrollment process is performed over multiple visits, an automated biometric verification attempt comparing the applicant’s newly captured biometric characteristics against biometric data collected during a previous visit SHALL be performed at each visit and return a positive verification decision. 2.4 ¶ 3
    If biometric data was collected as specified in Section 2.3 and if collection of biometric data as specified in this section and in Section 2.3 occur on separate occasions, a biometric comparison SHALL be performed to confirm that the two fingerprints collected for off-card one-to-one comparisons elicit a positive biometric verification decision when compared to the same two fingerprints from the original set of ten fingerprints. 2.4 ¶ 4
    PIV background investigation, identity proofing, registration, and issuance processes MAY be performed across multiple sessions at different facilities. If multiple sessions are needed, the applicant SHALL be linked through a positive biometric verification decision obtained from an automated comparison of biometric characteristics captured at a previous session to biometric characteristics captured during the current session. Issuers SHALL follow applicable federal laws and regulations regarding the retention and destruction of biometric data. 2.5 ¶ 6
    For linking to background investigations, only fingerprints SHALL be used, since fingerprints are the only biometric characteristic used for background investigations. For all other purposes, verification attempts MAY be performed against any available biometric characteristic stored electronically on the PIV Card or in the enrollment record. 2.5 ¶ 7
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {negative biometric verification decision} {are not available} The issuer SHALL perform a biometric verification of the applicant to the biometric data records of the PIV enrollment record or to the biometric data records of the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. Minimum accuracy requirements for the biometric verification are specified in [SP 800-76]. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.9.1 ¶ 3
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {appear in person}{not be successful}{not be available} When OCC reset is performed in person at the issuing facility, before the reset, the issuer SHALL perform a biometric verification of the cardholder to the biometric data records in the PIV enrollment record. If the biometric verification decision is negative or no alternative biometric data records are available, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 4
    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 card to perform CTC authentication, and the card responds with a positive or negative biometric verification decision. The response includes information that allows the reader to authenticate the card. Entry of the cardholder PIN is not required for OCC-AUTH. The PIV Card SHALL include a mechanism to block this authentication mechanism after a number of consecutive failed authentication attempts as stipulated by the department or agency. As with BIO and BIO-A, if agencies choose to implement OCC, it SHALL be implemented as defined in [SP 800-73] and [SP 800-76]. 6.2.2 ¶ 1
    {not acquire} When PIN reset is performed in person at the issuing facility, before providing the reset PIV Card back to the cardholder, the issuer SHALL color:#B7D8ED;" class="term_primary-verb">performpan> a pan style="background-color:#F0BBBC;" class="term_primary-noun">biometric verification to ensure that the cardholder’s biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect the identity document and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the card. 2.9.3.1 ¶ 3
    {applicable requirements}{remote proofing procedure}{not acquire} PIN reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a ">positive biometric verification decision when ="term_secondary-verb">compared to biometric data records secondary-verb">stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCCAUTH authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.1 ¶ 7
    {not be successful}{not acquire} OCC reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a ">positive biometric verification decision when BD0E5;" class="term_secondary-verb">compared to biometric data records secondary-verb">stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.2 ¶ 6]
    Technical security Establish Roles
    Employ live scans to verify biometric authentication. CC ID 06847
    [{identity proofing} {registration} Biometric data SHALL be captured as specified in Section 2.3 and Section 2.4. 2.7 ¶ 4
    Biometric identification using fingerprints is the primary input to law enforcement checks. In cases where ten fingerprints are not available, then as many fingers as possible SHALL be imaged as per guidance in [SP 800-76]. In cases where no fingers are available to be imaged, agencies SHALL seek guidance from their respective investigative service provider for alternative means of performing law enforcement checks. 2.3 ¶ 3]
    Technical security Technical Security
    Disallow self-enrollment of biometric information. CC ID 11834 Technical security Process or Activity
    Notify a user when an authenticator for a user account is changed. CC ID 13820 Technical security Communicate
    Enforce information flow control. CC ID 11781 Technical security Monitor and Evaluate Occurrences
    Establish, implement, and maintain information flow control policies inside the system and between interconnected systems. CC ID 01410 Technical security Establish/Maintain Documentation
    Establish, implement, and maintain information exchange procedures. CC ID 11782 Technical security Establish/Maintain Documentation
    Protect data from modification or loss while transmitting between separate parts of the system. CC ID 04554
    [{data in transit}{data at rest} PIV enrollment records contain Personally Identifiable Information (PII). PII SHALL be protected in a manner that protects the individual’s privacy and maintains the integrity of the records both in transit and at rest. 2.6 ¶ 5]
    Technical security Data and Information Management
    Manage the use of encryption controls and cryptographic controls. CC ID 00570 Technical security Technical Security
    Establish, implement, and maintain digital signatures. CC ID 13828
    [{refrain from exceeding} Previously collected biometric data MAY be reused with the new PIV Card if the expiration date of the new PIV Card is no later than 12 years after the date that the biometric data was obtained. As biometric system error rates generally increase with the time elapsed since initial collection (reference aging, [ISO 2382-37]), issuers MAY refresh biometric data in the PIV enrollment record during the re-issuance process. Even if the same biometric data is reused with the new PIV Card, the digital signature must be recomputed with the new FASC-N and card UUID. 2.9.1 ¶ 7
    The public key required to verify the digital signature SHALL be in a content signing certificate, which SHALL be issued under the id-fpki-common-piv-contentSigning policy of [COMMON] and SHALL include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. The signature on the biometric data record SHOULD be generated with the same signing key as the signature on the CHUID data object. The public key required to verify the digital signature is contained in the CHUID data object’s content signing certificate33 as detailed in Section 4.2.1. 4.2.3.2 ¶ 4]
    Technical security Data and Information Management
    Include the expiration date in digital signatures. CC ID 13833 Technical security Data and Information Management
    Include audience restrictions in digital signatures. CC ID 13834 Technical security Data and Information Management
    Include the subject in digital signatures. CC ID 13832 Technical security Data and Information Management
    Include the issuer in digital signatures. CC ID 13831 Technical security Data and Information Management
    Include identifiers in the digital signature. CC ID 13829 Technical security Data and Information Management
    Generate and protect a secret random number for each digital signature. CC ID 06577 Technical security Establish/Maintain Documentation
    Establish the security strength requirements for the digital signature process. CC ID 06578 Technical security Establish/Maintain Documentation
    Establish, implement, and maintain an encryption management and cryptographic controls policy. CC ID 04546 Technical security Establish/Maintain Documentation
    Accept only trusted keys and/or certificates. CC ID 11988
    [{refrain from expiring}{not be revoked} The relying system validates the card authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.2 ¶ 1 Bullet 2]
    Technical security Technical Security
    Define the asymmetric signature field for the CHUID container on identification cards or badges. CC ID 06584
    [This Standard requires inclusion of the asymmetric signature field in the CHUID container. The asymmetric signature data element of the CHUID SHALL be encoded as a Cryptographic Message Syntax (CMS) external digital signature, as specified in [SP 800-73]. Algorithm and key size requirements for the asymmetric signature and digest algorithm are detailed in [SP 800-78]. 4.2.1 ¶ 6
    This Standard requires inclusion of the asymmetric signature field in the CHUID container. The asymmetric signature data element of the CHUID SHALL be encoded as a Cryptographic Message Syntax (CMS) external digital signature, as specified in [SP 800-73]. Algorithm and key size requirements for the asymmetric signature and digest algorithm are detailed in [SP 800-78]. 4.2.1 ¶ 6]
    Technical security Process or Activity
    Implement cryptographic operations and support functions on identification cards or badges. CC ID 06585
    [This Standard also defines two data elements for the PIV Card data model that are mandatory if the cardholder has a government-issued email account at the time of PIV Card issuance. These data elements are an asymmetric private key and corresponding certificate for digital signatures, and 4.2 ¶ 3 Bullet 1
    The PIV Card SHALL implement the cryptographic operations and support functions defined in [SP 800-78] and [SP 800-73]. 4.2.2 ¶ 1
    {be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1
    {be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1
    {be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1
    PIV Cards consistent with this specification SHALL have two or more asymmetric private keys. To manage the public keys associated with the asymmetric private keys, departments and agencies SHALL issue and manage X.509 public key certificates as specified in this section. 5 ¶ 2
    PIV Cards consistent with this specification SHALL have two or more asymmetric private keys. To manage the public keys associated with the asymmetric private keys, departments and agencies SHALL issue and manage X.509 public key certificates as specified in this section. 5 ¶ 2
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 operations that use the PIV secure messaging key SHALL be available through the contact and contactless interfaces of the PIV Card. Private key operations can be performed without access control restrictions. The PIV Card SHALL store a corresponding secure messaging card verifiable certificate (CVC) to support validation of the public key by the relying system. The use of the PIV secure messaging key and the CVC is further specified in [SP 800-73] and [SP 800-78]. 4.2.2.7 ¶ 1
    {contact interface} 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 be available through the contact and contactless interfaces of the PIV Card and SHALL NOT be available through the virtual contact interface of the PIV Card. Private key operations MAY be performed using this key without card activation (e.g., the PIN need not be supplied for operations with this key). 4.2.2.2 ¶ 1
    {contact interface} 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 be available through the contact and contactless interfaces of the PIV Card and SHALL NOT be available through the virtual contact interface of the PIV Card. Private key operations MAY be performed using this key without card activation (e.g., the PIN need not be supplied for operations with this key). 4.2.2.2 ¶ 1
    {contact interface} 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 be available through the contact and contactless interfaces of the PIV Card and SHALL NOT be available through the virtual contact interface of the PIV Card. Private key operations MAY be performed using this key without card activation (e.g., the PIN need not be supplied for operations with this key). 4.2.2.2 ¶ 1
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17
    With the exception of the card authentication key and keys used to establish secure messaging, cryptographic private key operations SHALL be performed only through the contact interface or the virtual contact interface. Any operation that MAY be performed over the contact interface of the PIV Card MAY also be performed over the virtual contact interface. Requirements for the virtual contact interface are specified in [SP 800-73]. With the exception of the card authentication key and keys used to establish secure messaging, cryptographic private key operations SHALL be performed only through the contact interface or the virtual contact interface. Any operation that MAY be performed over the contact interface of the PIV Card MAY also be performed over the virtual contact interface. Requirements for the virtual contact interface are specified in [SP 800-73]. 4.2.2 ¶ 18]
    Technical security Process or Activity
    Define the format of the biometric data on identification cards or badges. CC ID 06586
    [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 4.2.3.3 ¶ 1 Bullet 1
    OCC MAY be performed over the contact and contactless interfaces of the PIV Card to support card activation (Section 4.3.1) and cardholder authentication (Section 6.2.2). The fingerprint biometric templates for OCC SHALL NOT be exportable. If implemented, OCC SHALL be implemented and used in accordance with [SP 800-73] and [SP 800-76]. 4.2.3.3 ¶ 2
    OCC MAY be performed over the contact and contactless interfaces of the PIV Card to support card activation (Section 4.3.1) and cardholder authentication (Section 6.2.2). The fingerprint biometric templates for OCC SHALL NOT be exportable. If implemented, OCC SHALL be implemented and used in accordance with [SP 800-73] and [SP 800-76]. 4.2.3.3 ¶ 2]
    Technical security Process or Activity
    Establish, implement, and maintain cryptographic key management procedures. CC ID 00571 Technical security Establish/Maintain Documentation
    Establish, implement, and maintain requirements for Personal Identity Verification authentication certificates. CC ID 06587
    [If the derived PIV credential to be invalidated contains a derived PIV authentication certificate and the corresponding private key cannot be securely zeroized or destroyed, the CA SHALL be informed and the certificate corresponding to the derived PIV authentication key SHALL be revoked. 2.10.2 ¶ 2]
    Technical security Establish/Maintain Documentation
    Establish, implement, and maintain Public Key certificate application procedures. CC ID 07079 Technical security Establish/Maintain Documentation
    Include the Identification and Authentication of individuals or entities in the Public Key certificate application procedures. CC ID 07080
    [{refrain from expiring}{not be revoked} The relying system validates the card authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.2 ¶ 1 Bullet 2]
    Technical security Establish/Maintain Documentation
    Include revocation of Public Key certificates in the Public Key certificate procedures. CC ID 07082
    [If the PIV authentication key (Section 4.2.2.1), asymmetric card authentication key (Section 4.2.2.2), digital signature key (Section 4.2.2.1), or key management key (Section 4.2.2.5) was compromised, the corresponding certificate SHALL be revoked. 2.9.2 ¶ 4
    {not be destroyed} {not be collected} The revocation process SHALL include the following: If the old PIV Card cannot be collected and destroyed, or if the old PIV Card has been compromised or damaged, then the Certification Authority (CA) SHALL be informed and the certificates corresponding to the PIV authentication key (Section 4.2.2.1) and asymmetric card authentication key (Section 4.2.2.2) on the old PIV Card SHALL be revoked. If present, the certificates corresponding to the digital signature key (Section 4.2.2.1) and the key management key (Section 4.2.2.5) SHALL also be revoked. 2.9.1 ¶ 4 Bullet 3
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: If the PIV Card cannot be collected and destroyed, the CA SHALL be informed and the certificates corresponding to the PIV authentication key and the asymmetric card authentication key on the PIV Card SHALL be revoked. The certificates corresponding to the digital signature and key management keys SHALL also be revoked, if present. 2.9.4 ¶ 2 Bullet 4
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: If the PIV Card cannot be collected and destroyed, the CA SHALL be informed and the certificates corresponding to the PIV authentication key and the asymmetric card authentication key on the PIV Card SHALL be revoked. The certificates corresponding to the digital signature and key management keys SHALL also be revoked, if present. 2.9.4 ¶ 2 Bullet 4
    Departments and agencies SHALL notify CAs when certificates need to be revoked. 5.5 ¶ 3
    If the derived PIV credential to be invalidated contains a derived PIV authentication certificate and the corresponding private key cannot be securely zeroized or destroyed, the CA SHALL be informed and the certificate corresponding to the derived PIV authentication key SHALL be revoked. 2.10.2 ¶ 2]
    Technical security Establish/Maintain Documentation
    Publish revoked Public Key certificates in the Certificate Revocation List. CC ID 07089
    [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 service that publishes the CRLs for the PIV certificates that it issues, as specified in [PROF]; 5.5 ¶ 1 Bullet 1
    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]. 5.3 ¶ 1
    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]. 5.3 ¶ 1
    {refrain from expiring}{not be revoked} The relying system validates the card authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.2 ¶ 1 Bullet 2]
    Technical security Establish/Maintain Documentation
    Establish a Root Certification Authority to support the Public Key Infrastructure. CC ID 07084
    [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. 5.1 ¶ 1]
    Technical security Technical Security
    Establish, implement, and maintain Public Key certificate procedures. CC ID 07085
    [{applicable requirements} 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 be operated by departments and agencies or be outsourced to PKI service providers. For a list of PKI service providers that have been approved to operate under [COMMON], see https://www.idmanagement.gov. 5.2 ¶ 1
    CAs that issue certificates corresponding to PIV private keys (i.e., PIV authentication, card authentication, digital signature, or key management certificates) SHALL maintain an HTTP-accessible service that publishes any CA certificates issued to it, as specified in [PROF]; and 5.5 ¶ 1 Bullet 2
    operate Online Certificate Status Protocol (OCSP, specified in [RFC 6960]) services for the PIV certificates that it issues, as specified in [PROF]. 5.5 ¶ 1 Bullet 3
    PIV authentication, card authentication, digital signature, and key management certificates SHALL contain the authorityInfoAccess extension needed to locate the authoritative OCSP responder. 5.5 ¶ 2 Bullet 2
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7
    Certificates containing the public key associated with a key management private key SHALL conform to the Key Management Certificate Profile in [PROF] and SHALL specify the id-fpki-common-policy or id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.5), except as provided below. 5.2.1 ¶ 1 Bullet 4
    Certificates containing the public key associated with a key management private key SHALL conform to the Key Management Certificate Profile in [PROF] and SHALL specify the id-fpki-common-policy or id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.5), except as provided below. 5.2.1 ¶ 1 Bullet 4
    The public key required to verify the digital signature SHALL be in a content signing certificate, which SHALL be issued under the id-fpki-common-piv-contentSigning policy of [COMMON] and SHALL include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. The signature on the biometric data record SHOULD be generated with the same signing key as the signature on the CHUID data object. The public key required to verify the digital signature is contained in the CHUID data object’s content signing certificate33 as detailed in Section 4.2.1. 4.2.3.2 ¶ 4
    The public key required to verify the digital signature SHALL be in a content signing certificate, which SHALL be issued under the id-fpki-common-piv-contentSigning policy of [COMMON] and SHALL include an extended key usage (extKeyUsage) extension asserting id-PIV-content-signing. The signature on the biometric data record SHOULD be generated with the same signing key as the signature on the CHUID data object. The public key required to verify the digital signature is contained in the CHUID data object’s content signing certificate33 as detailed in Section 4.2.1. 4.2.3.2 ¶ 4
    Certificates that contain the public key associated with a PIV authentication private key SHALL conform to the PIV Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-authentication policy of [COMMON] in the certificate policies extension (Section 4.2.2.1). 5.2.1 ¶ 1 Bullet 1
    Certificates that contain the public key associated with a PIV authentication private key SHALL conform to the PIV Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-authentication policy of [COMMON] in the certificate policies extension (Section 4.2.2.1). 5.2.1 ¶ 1 Bullet 1
    Certificates that contain the public key associated with a digital signature private key SHALL conform to the End Entity Signature Certificate Profile in [PROF] and SHALL specify the id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.4), except as provided below. 5.2.1 ¶ 1 Bullet 3
    Certificates that contain the public key associated with a digital signature private key SHALL conform to the End Entity Signature Certificate Profile in [PROF] and SHALL specify the id-fpki-common-hardware policy of [COMMON] in the certificate policies extension (Section 4.2.2.4), except as provided below. 5.2.1 ¶ 1 Bullet 3
    {asymmetric card authentication key} Certificates that contain the public key associated with an asymmetric card authentication private key SHALL conform to the Card Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-cardAuth policy of [COMMON] in the certificate policies extension (Section 4.2.2.2). 5.2.1 ¶ 1 Bullet 2
    {asymmetric card authentication key} Certificates that contain the public key associated with an asymmetric card authentication private key SHALL conform to the Card Authentication Certificate Profile in [PROF] and SHALL specify the id-fpki-common-cardAuth policy of [COMMON] in the certificate policies extension (Section 4.2.2.2). 5.2.1 ¶ 1 Bullet 2
    {applicable requirements} CA certificates SHALL conform to [COMMON]. 5.1 ¶ 2
    Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.3.2 ¶ 6]
    Technical security Establish/Maintain Documentation
    Include signing and issuing Public Key certificates in the Public Key certificate procedures. CC ID 11817
    [{electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7]
    Technical security Establish/Maintain Documentation
    Include publishing Public Key certificates in the Public Key certificate procedures. CC ID 07087 Technical security Establish/Maintain Documentation
    Include access to issued Public Key certificates in the Public Key certificate procedures. CC ID 07086
    [Certificates that contain the FASC-N or card UUID in the SAN extension, such as PIV authentication certificates and card authentication certificates, SHALL NOT be distributed publicly (e.g., via HTTP accessible from the public internet). Individual departments and agencies can decide whether digital signature and key management certificates can be distributed publicly by the CA. 5.5.1 ¶ 2
    {electronic signature policy} The public key required to verify the digital signature SHALL be contained in a content signing certificate, which SHALL be issued under the id-fpki-common-pivcontentSigning policy of [COMMON]. The content signing certificate SHALL also include an extended key usage (extKeyUsage) extension asserting id-PIV-contentsigning. The public key SHALL be included in the certificates field of the CMS external digital signature in a content signing certificate. Additional descriptions for the PIV object identifiers are provided in Appendix B. The content signing certificate SHALL NOT expire before the expiration of the card authentication certificate. 4.2.1 ¶ 7]
    Technical security Establish/Maintain Documentation
    Connect the Public Key Infrastructure to the organization's identity and access management system. CC ID 07091 Technical security Technical Security
    Archive Public Key certificate records according to organizational Records Management rules. CC ID 07090 Technical security Records Management
    Use strong data encryption to transmit in scope data or in scope information, as necessary. CC ID 00564 Technical security Technical Security
    Configure the encryption strength to be appropriate for the encryption methodology of the cryptographic controls. CC ID 12492
    [{be unique} 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 response protocol using cryptographic keys stored on the card in accordance with [SP 800-73]. When cards are personalized, each PIV Card SHALL contain a unique PIV Card application administration key specific to that PIV Card. PIV Card application administration keys SHALL meet the algorithm and key size requirements stated in [SP 800-78]. 4.3.2 ¶ 1]
    Technical security Technical Security
    Establish, implement, and maintain a malicious code protection program. CC ID 00574
    [{do not introduce} The following forms of protection SHALL be provided by either inherent capabilities of the station or staff at the station location: ensuring that no malicious code is introduced to compromise or otherwise impair the station and the PIV Card; and 2.7.1 ¶ 3 Bullet 3]
    Technical security Establish/Maintain Documentation
    Disseminate and communicate the malicious code protection policy to all interested personnel and affected parties. CC ID 15485 Technical security Communicate
    Disseminate and communicate the malicious code protection procedures to all interested personnel and affected parties. CC ID 15484 Technical security Communicate
    Establish, implement, and maintain malicious code protection procedures. CC ID 15483 Technical security Establish/Maintain Documentation
    Establish, implement, and maintain a malicious code protection policy. CC ID 15478 Technical security Establish/Maintain Documentation
    Restrict downloading to reduce malicious code attacks. CC ID 04576 Technical security Behavior
    Install security and protection software, as necessary. CC ID 00575 Technical security Configuration
    Install and maintain container security solutions. CC ID 16178 Technical security Technical Security
    Protect the system against replay attacks. CC ID 04552 Technical security Technical Security
    Define and assign roles and responsibilities for malicious code protection. CC ID 15474 Technical security Establish Roles
    Lock antivirus configurations. CC ID 10047 Technical security Configuration
    Establish, implement, and maintain a physical security program. CC ID 11757 Physical and environmental protection Establish/Maintain Documentation
    Protect assets from tampering or unapproved substitution. CC ID 11902
    [{PIV Card}{anti-counterfeiting technique} All security features SHOULD maintain their function for the life of the card. As a generally accepted security procedure, federal departments and agencies SHOULD periodically review the viability, effectiveness, and currency of employed tamper resistance and anti-counterfeiting methods. 4.1.2 ¶ 10]
    Physical and environmental protection Physical and Environmental Protection
    Establish, implement, and maintain a facility physical security program. CC ID 00711 Physical and environmental protection Establish/Maintain Documentation
    Identify and document physical access controls for all physical entry points. CC ID 01637 Physical and environmental protection Establish/Maintain Documentation
    Control physical access to (and within) the facility. CC ID 01329 Physical and environmental protection Physical and Environmental Protection
    Establish, implement, and maintain physical identification procedures. CC ID 00713 Physical and environmental protection Establish/Maintain Documentation
    Implement operational requirements for card readers. CC ID 02225
    [{applicable 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 desktop computing systems and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.1 ¶ 1
    {applicable 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 desktop computing systems and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.1 ¶ 1
    {applicable 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 desktop computing systems and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.1 ¶ 1
    {applicable 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 computing systems, they SHALL conform to [PCSC] for the reader-to-host system interface and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.2 ¶ 1
    {applicable 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 computing systems, they SHALL conform to [PCSC] for the reader-to-host system interface and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.2 ¶ 1
    {applicable 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 computing systems, they SHALL conform to [PCSC] for the reader-to-host system interface and SHALL conform to the requirements specified in [SP 800-96]. In systems where the readers are not connected to general-purpose desktop computing systems, the reader-to-host system interface is not specified in this Standard. 4.4.2 ¶ 1
    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 to a website or other server), the input device is not required to be integrated with the PIV Card reader. If the input device is not integrated with the PIV Card reader, the PIN or OCC data SHALL be transmitted securely and directly to the PIV Card for card activation. 4.4.4 ¶ 1]
    Physical and environmental protection Testing
    Establish, implement, and maintain lost or damaged identification card procedures, as necessary. CC ID 14819
    [Derived PIV credentials SHALL be invalidated in any of the following circumstances at the determination of the issuer upon reported loss or suspected compromise of a derived PIV credential; 2.10.2 ¶ 1 Bullet 2
    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; 2.10.2 ¶ 1 Bullet 1
    {lost identification card or badge}{stolen identification card or badge}{stipulated time frame} In the case of a lost, stolen, or compromised card, normal revocation procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay, and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.1 ¶ 5]
    Physical and environmental protection Establish/Maintain Documentation
    Report lost badges, stolen badges, and broken badges to the Security Manager. CC ID 12334
    [{lost identification card or badge}{stolen identification card or badge}{stipulated time frame} In the case of a lost, stolen, or compromised card, normal revocation procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay, and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.1 ¶ 5]
    Physical and environmental protection Physical and Environmental Protection
    Establish, implement, and maintain identification issuance procedures for identification cards or badges. CC ID 06598
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A person suspected or known to the government as being a terrorist is not issued a credential. 2.1 ¶ 2 Bullet 5
    {stipulated time frame} The PIV Card SHALL be valid for no more than six years. 2.8 ¶ 1 Bullet 7
    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 identity proofing and registration process that meets the requirements defined below when issuing PIV Cards. 2.7 ¶ 1
    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 writing by the head or deputy (or equivalent) of the federal department or agency. 2.8 ¶ 1
    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 writing by the head or deputy (or equivalent) of the federal department or agency. 2.8 ¶ 1
    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 writing by the head or deputy (or equivalent) of the federal department or agency. 2.8 ¶ 1
    {applicable requirements} The department or agency SHALL use an approved PIV credential issuance process in accordance with [SP 800-79]. 2.8 ¶ 1 Bullet 2
    The department or agency SHALL issue PIV credentials only through systems and providers whose reliability has been established by the agency and so documented and approved in writing (i.e., accredited) in accordance with [SP 800-79]. 2.8 ¶ 1 Bullet 6
    PIV Cards SHALL be issued only after the adjudicative entity has authorized issuance of the credential. 2.8 ¶ 1 Bullet 1
    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 necessary to protect an employee or contractor (e.g., from physical harm, severe distress, or harassment), the agency may formally authorize the issuance of a PIV Card to the employee or contractor using the agency-approved pseudonym. The issuance of a PIV Card using an authorized pseudonym SHALL follow the procedures in Section 2.8 except that the card issuer SHALL receive satisfactory evidence that the pseudonym is authorized by the agency. 2.8.1 ¶ 1
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {negative biometric verification decision} {are not available} The issuer SHALL perform a biometric verification of the applicant to the biometric data records of the PIV enrollment record or to the biometric data records of the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. Minimum accuracy requirements for the biometric verification are specified in [SP 800-76]. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.9.1 ¶ 3
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {applicable requirements} Remote issuance SHALL satisfy all of the requirements of Section 2.8. The issuer SHALL have local trained staff to securely maintain custody of card stock received by the remote station when the station is used for PIV Card issuance. 2.8.3 ¶ 2
    {issuing organization} Derived PIV credentials SHALL be bound to the cardholder’s PIV identity account only by the issuing department or agency responsible for managing that PIV identity account. If the issuing department or agency relies on shared services for portions of the PIV Card or Derived PIV credential issuance process, it is the responsibility of the issuing department or agency to ensure that all credentials and IDMS records are properly maintained throughout the PIV lifecycle. 2.10.1 ¶ 3
    {issuing organization} Derived PIV credentials SHALL be bound to the cardholder’s PIV identity account only by the issuing department or agency responsible for managing that PIV identity account. If the issuing department or agency relies on shared services for portions of the PIV Card or Derived PIV credential issuance process, it is the responsibility of the issuing department or agency to ensure that all credentials and IDMS records are properly maintained throughout the PIV lifecycle. 2.10.1 ¶ 3
    {appear in person} If biometric data cannot be positively verified per the criteria defined in [SP 800-76], remote issuance SHALL NOT be used and issuance will be performed in person at the issuer’s facility. The trained operator SHALL terminate a remote issuance session and require in-person issuance at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.8.3 ¶ 3
    {appear in person} If biometric data cannot be positively verified per the criteria defined in [SP 800-76], remote issuance SHALL NOT be used and issuance will be performed in person at the issuer’s facility. The trained operator SHALL terminate a remote issuance session and require in-person issuance at an issuing facility if there is reasonable basis to believe that the applicant is attempting to bypass protection capabilities of the station. 2.8.3 ¶ 3]
    Physical and environmental protection Establish/Maintain Documentation
    Record the assigned identification card or badge serial number when issuing an identification card or badge. CC ID 06714 Physical and environmental protection Process or Activity
    Include error handling controls in identification issuance procedures. CC ID 13709
    [PIV Cards that contain topographical defects (e.g., scratches, poor color, fading, etc.) or that are not properly printed SHALL be destroyed. The PIV Card issuer is responsible for the card stock, its management, and its integrity. 2.8 ¶ 2]
    Physical and environmental protection Establish/Maintain Documentation
    Include an appeal process in the identification issuance procedures. CC ID 15428
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Maintain appeal procedures for those who are denied a credential or whose credentials are revoked. 2.11 ¶ 3 Bullet 6]
    Physical and environmental protection Business Processes
    Include information security in the identification issuance procedures. CC ID 15425
    [{refrain from implementing}{not be consistent} Departments and agencies may have a wide variety of uses for the PIV system and its components that were not intended or anticipated by the President in issuing [HSPD-12]. In considering whether a proposed use of the PIV system is appropriate, departments and agencies SHALL consider the aforementioned control objectives and the purpose of this Standard, namely “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy” as per [HSPD-12]. No department or agency SHALL implement a use of the identity credential inconsistent with these control objectives. 2.11 ¶ 2]
    Physical and environmental protection Establish/Maintain Documentation
    Include identity proofing processes in the identification issuance procedures. CC ID 06597
    [Biometric data used to personalize the PIV Card SHALL be those captured during the identity proofing and registration process. 2.8 ¶ 1 Bullet 4
    The applicant SHALL appear in person at least once before the issuance of a PIV Card, either at the issuing facility or at a supervised remote identity proofing station (as described in Section 2.7.1). 2.7 ¶ 5
    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 federation system. The IdP SHALL associate this authentication event with the PIV identity account of the cardholder and SHALL create an assertion representing the cardholder to be sent to the RP, potentially including attributes of the cardholder stored in the PIV identity account. Upon receipt, the RP SHALL validate the assertion and use the attributes provided in the federation transaction to match the cardholder information to the information on record, as discussed in Section 3.1.3. The connections and components of a federated protocol are shown in Figure 3-4. 7.1 ¶ 1
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {are not available} {negative biometric verification decision} During the issuance process, the issuer SHALL verify that the individual to whom the PIV Card is to be issued is the same as the intended applicant/recipient as approved by the appropriate authority. Before the PIV Card is provided to the applicant, the issuer SHALL perform a one-to-one comparison of the applicant against biometric data records available on the PIV Card or in the PIV enrollment record. Minimum accuracy requirements for biometric verification and presentation attack detection are specified in [SP 800-76]. On a positive biometric verification decision, the PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the photograph printed on the PIV Card. 2.8 ¶ 1 Bullet 5
    {negative biometric verification decision} {are not available} The issuer SHALL perform a biometric verification of the applicant to the biometric data records of the PIV enrollment record or to the biometric data records of the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. Minimum accuracy requirements for the biometric verification are specified in [SP 800-76]. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.9.1 ¶ 3
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2
    {be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2
    {not acquire} When PIN reset is performed in person at the issuing facility, before providing the reset PIV Card back to the cardholder, the issuer SHALL perform a biometric verification to ensure that the cardholder’s biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the BIO-A or OCC-AUTH authentication mechanisms. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide another primary identity source document (as specified in Section 2.7). An attending operator SHALL inspect the identity document and <span style="background-color:#B7D8ED;" claground-color:#CBD0E5;" class="term_secondary-verb">ss="term_primary-verb">compare the "background-color:#F0BBBC;" class="term_primary-noun">cardholder with the electronic facial image retrieved from the enrollment data record and the ass="term_primary-noun">photograph printed on the card. 2.9.3.1 ¶ 3]
    Physical and environmental protection Process or Activity
    Establish, implement, and maintain post-issuance update procedures for identification cards or badges. CC ID 15426
    [{be equivalent} A PIV Card post-issuance update MAY be done locally (i.e., performed with the issuer in physical custody of the PIV Card) or remotely (i.e., performed with the PIV Card at a remote location). Post-issuance updates SHALL be performed with issuer security controls equivalent to those applied during PIV Card reissuance. For remote postissuance updates, the following SHALL apply: 2.9.2 ¶ 2
    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, keys, biometric data records, or signed data objects are updated. A post-issuance update SHALL NOT modify the PIV Card expiration date, FASC-N, card UUID, or cardholder UUID. 2.9.2 ¶ 1
    For remote post-issuance updates, the following SHALL apply: Data transmitted between the PIV Card issuer and PIV Card SHALL be encrypted and contain data integrity checks. 2.9.2 ¶ 2 Bullet 2
    For remote post-issuance updates, the following SHALL apply: Communication between the PIV Card issuer and the PIV Card SHALL occur only over mutually authenticated secure sessions between tested and validated cryptographic modules (one being the PIV Card). 2.9.2 ¶ 2 Bullet 1
    For remote post-issuance updates, the following SHALL apply: The PIV Card application SHALL communicate with no endpoint entity other than the PIV Card issuer during the remote post-issuance update. 2.9.2 ¶ 2 Bullet 3
    For remote post-issuance updates, the following SHALL apply: Data transmitted between the PIV Card issuer and PIV Card SHALL be encrypted and contain data integrity checks. 2.9.2 ¶ 2 Bullet 2
    {after}{card issuance} The FASC-N, card UUID, expiration date, and, if present, cardholder UUID SHALL NOT be modified post-issuance. 4.2.1 ¶ 5
    {contact interface} All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL ound-color:#B7D8ED;" class="term_primary-verb">include all cryptographic operations performed over both the contact and contactless interfaces as part of -color:#CBD0E5;" class="term_secondary-verb">an style="background-color:#F0BBBC;" class="term_primary-noun">remote post issuance updates, as specified in Section 2.9.2. 4.2.2 ¶ 19 Bullet 3]
    Physical and environmental protection Establish/Maintain Documentation
    Include an identity registration process in the identification issuance procedures. CC ID 11671
    [Before issuing the PIV Card, the issuer SHALL ensure that the individual receiving it has been properly processed per Section 2.1, Section 2.2, and Section 2.7. 2.8 ¶ 1 Bullet 3
    {identity proofing} {registration} The department or agency SHALL follow investigative requirements as outlined in Section 2.2. 2.7 ¶ 3
    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 necessary to protect an employee or contractor (e.g., from physical harm, severe distress, or harassment), the agency may formally authorize the issuance of a PIV Card to the employee or contractor using the agency-approved pseudonym. The issuance of a PIV Card using an authorized pseudonym SHALL follow the procedures in Section 2.8 except that the card issuer SHALL receive satisfactory evidence that the pseudonym is authorized by the agency. 2.8.1 ¶ 1
    During identity proofing, the applicant SHALL be required to provide two original forms of identity source documents. These documents SHALL be validated to ensure that they are genuine and authentic, not counterfeit, fake, or forgeries. Validation of physical security features SHALL be performed by trained staff. When they are available, cryptographic security features SHOULD be used to validate evidence. The identity source documents SHALL relate to the applicant. The identity source documents SHALL NOT be expired or cancelled. If the two identity source documents bear different names, evidence of a formal name change SHALL be provided. At least one identity source document SHALL meet the requirements of Strong evidence as specified in [SP 800-63A] and be one of the following forms of identification: 2.7 ¶ 6]
    Physical and environmental protection Establish/Maintain Documentation
    Establish, implement, and maintain identification renewal procedures for identification cards or badges. CC ID 06599
    [If the expiration date of the new PIV Card is later than the expiration date of the old card, or if any data about the cardholder is being changed, the card issuer SHALL ensure that an adjudicative entity has authorized the issuance of the new PIV Card. The issuer SHALL ensure that the adjudicative entity has verified that there is a PIV eligibility determination in an authoritative record, such as the agency’s IDMS or the Central Verification System (or successor). 2.9.1 ¶ 2
    If the expiration date of the new PIV Card is later than the expiration date of the old card, or if any data about the cardholder is being changed, the card issuer SHALL ensure that an adjudicative entity has authorized the issuance of the new PIV Card. The issuer SHALL ensure that the adjudicative entity has verified that there is a PIV eligibility determination in an authoritative record, such as the agency’s IDMS or the Central Verification System (or successor). 2.9.1 ¶ 2
    {appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT pan style="background-color:#B7D8ED;" class="term_pri class="term_secondary-verb">mary-verb">resetspackground-color:#CBD0E5;" class="term_secondary-verb">n> the <span style="background-color:#F0BBBC;" class="term_primary-noun">PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5]
    Physical and environmental protection Establish/Maintain Documentation
    Establish, implement, and maintain identification re-issuing procedures for identification cards or badges. CC ID 06596
    [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 formal name change—such as a marriage certificate, a divorce decree, judicial recognition of a name change, or other mechanism permitted by state law or regulation—the card issuer SHALL issue the cardholder a new card following the procedures set out in Section 2.9.1 and notify the respective adjudicative entity of the name change to ensure that appropriate records are updated. If the expiration date of the new card is no later than the expiration date of the old PIV Card and no data about the cardholder other than the cardholder’s name is being changed, then the new PIV Card MAY be issued without obtaining the approval of the adjudicative entity and without performing a re-investigation. 2.9.1.1 ¶ 1
    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 formal name change—such as a marriage certificate, a divorce decree, judicial recognition of a name change, or other mechanism permitted by state law or regulation—the card issuer SHALL issue the cardholder a new card following the procedures set out in Section 2.9.1 and notify the respective adjudicative entity of the name change to ensure that appropriate records are updated. If the expiration date of the new card is no later than the expiration date of the old PIV Card and no data about the cardholder other than the cardholder’s name is being changed, then the new PIV Card MAY be issued without obtaining the approval of the adjudicative entity and without performing a re-investigation. 2.9.1.1 ¶ 1
    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 PIV Card needs to be invalidated when the cardholder changes their name or employment status. In this regard, procedures for PIV Card maintenance must be integrated into department and agency procedures to ensure effective card maintenance. In order to maintain operational readiness of a cardholder’s PIV Card, agencies may require PIV Card update, reissuance, or biometric enrollment more frequently than the maximum PIV Card and biometric characteristic lifetimes stated in this Standard. Shorter lifetimes MAY be specified by agency policy. 2.9 ¶ 2
    Departments and agencies MAY adopt more stringent procedures for PIN or OCC reset (including disallowing resets); such procedures SHALL be formally documented by each department and agency. 2.9.3 ¶ 4
    Both fingerprints used for OCC SHALL be replaced during an OCC reset. 2.9.3.2 ¶ 1
    Post-issuance updates to biometric data records, other than to the digital signature blocks within the biometric data records, SHALL satisfy the requirements for PIV Card activation reset specified in Section 2.9.3. 2.9.2 ¶ 3]
    Physical and environmental protection Establish/Maintain Documentation
    Establish, implement, and maintain identification mechanism termination procedures. CC ID 06306
    [The revocation process SHALL include the following: The old PIV Card SHALL be collected and destroyed, if possible. 2.9.1 ¶ 4 Bullet 1
    The old PIV Card SHALL be revoked when the new PIV Card is issued. The revocation process SHALL include the following: 2.9.1 ¶ 4
    Derived PIV credentials SHALL be invalidated in any of the following circumstances at the determination of the issuer upon observation of possible fraudulent activity; or 2.10.2 ¶ 1 Bullet 3
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: The PIV Card SHALL be collected and destroyed, if possible. 2.9.4 ¶ 2 Bullet 1
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Per OPM guidance, the Central Verification System (or successor) SHALL be updated to reflect the change in status (see Section 2.2). 2.9.4 ¶ 2 Bullet 2
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: 2.9.4 ¶ 2
    {be fraudulent} 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 cardholder is determined to hold a fraudulent identity. 2.9.4 ¶ 1 Bullet 5
    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: An authorized adjudicative entity determines that the cardholder is ineligible for a PIV Card after completion of a cardholder’s background investigation or review of developed information (see [FCS] and [CSP]). 2.9.4 ¶ 1 Bullet 4
    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 cardholder passes away. 2.9.4 ¶ 1 Bullet 3
    {federal government} 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 contractor changes positions and no longer needs access to federal buildings or systems. 2.9.4 ¶ 1 Bullet 2
    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: 2.9.4 ¶ 1
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Any databases maintained by the PIV Card issuer that indicate current valid or invalid FASC-N or card UUID values SHALL be updated to reflect the change in status. 2.9.4 ¶ 2 Bullet 3
    In addition, the PIV Card termination procedures SHALL ensure that all derived PIV credentials bound to the PIV identity account are invalidated as specified in Section 2.10.2. 2.9.4 ¶ 3
    {PIV card} If the card cannot be collected, normal termination procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.4 ¶ 4
    {PIV card} If the card cannot be collected, normal termination procedures SHALL be completed within 18 hours of notification. In certain cases, 18 hours is an unacceptable delay and in those cases emergency procedures SHOULD be executed to disseminate the information as rapidly as possible. 2.9.4 ¶ 4
    {not be destroyed} {not be collected} The revocation process SHALL include the following: If the old PIV Card cannot be collected and destroyed, or if the old PIV Card has been compromised or damaged, then the Certification Authority (CA) SHALL be informed and the certificates corresponding to the PIV authentication key (Section 4.2.2.1) and asymmetric card authentication key (Section 4.2.2.2) on the old PIV Card SHALL be revoked. If present, the certificates corresponding to the digital signature key (Section 4.2.2.1) and the key management key (Section 4.2.2.5) SHALL also be revoked. 2.9.1 ¶ 4 Bullet 3
    {not be destroyed} {not be collected} The revocation process SHALL include the following: If the old PIV Card cannot be collected and destroyed, or if the old PIV Card has been compromised or damaged, then the Certification Authority (CA) SHALL be informed and the certificates corresponding to the PIV authentication key (Section 4.2.2.1) and asymmetric card authentication key (Section 4.2.2.2) on the old PIV Card SHALL be revoked. If present, the certificates corresponding to the digital signature key (Section 4.2.2.1) and the key management key (Section 4.2.2.5) SHALL also be revoked. 2.9.1 ¶ 4 Bullet 3
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: If the PIV Card cannot be collected and destroyed, the CA SHALL be informed and the certificates corresponding to the PIV authentication key and the asymmetric card authentication key on the PIV Card SHALL be revoked. The certificates corresponding to the digital signature and key management keys SHALL also be revoked, if present. 2.9.4 ¶ 2 Bullet 4
    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 employee separates (voluntarily or involuntarily) from federal service. 2.9.4 ¶ 1 Bullet 1
    Derived PIV credentials SHALL be invalidated in any of the following circumstances: when the associated PIV Card is terminated as specified in Section 2.9.4—in this situation, all derived PIV credentials associated with the PIV identity account SHALL be invalidated. 2.10.2 ¶ 1 Bullet 4
    The revocation process SHALL include the following: Any databases maintained by the PIV Card issuer that contain FASC-N or card UUID values from the old PIV Card must be updated to reflect the change in status. 2.9.1 ¶ 4 Bullet 2
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Card management systems SHALL be updated to reflect PIV Card termination and method of termination (e.g., PIV Card destruction for collected PIV Cards or certificate revocations for uncollected PIV Cards). 2.9.4 ¶ 2 Bullet 5
    Similar to the situation in which the PIV Card is compromised, normal termination procedures must be in place. The PIV Card SHALL be revoked through the following procedure: Card management systems SHALL be updated to reflect PIV Card termination and method of termination (e.g., PIV Card destruction for collected PIV Cards or certificate revocations for uncollected PIV Cards). 2.9.4 ¶ 2 Bullet 5]
    Physical and environmental protection Establish/Maintain Documentation
    Establish, implement, and maintain high level operational roles and responsibilities. CC ID 00806 Human Resources management Establish Roles
    Define and assign the Privacy Officer's roles and responsibilities. CC ID 00714
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Assign an individual to the role of privacy official. The privacy official is the individual who oversees privacy-related matters in the PIV system and is responsible for implementing the privacy requirements in the Standard. The individual serving in this role SHALL NOT assume any other operational role in the PIV system. 2.11 ¶ 3 Bullet 1]
    Human Resources management Establish Roles
    Establish, implement, and maintain a personnel management program. CC ID 14018 Human Resources management Establish/Maintain Documentation
    Establish and maintain Personnel Files for all employees. CC ID 12438 Human Resources management Human Resources Management
    Include background check results in each employee's personnel file. CC ID 12439
    [{background investigation} Once the investigation is completed, the authorized adjudicative entity SHALL adjudicate the investigation and report the final eligibility determination to the Central Verification System (or successor) and, if applicable, their enrollment in the Continuous Vetting Program as defined in [EO 13764]. This determination SHALL be recorded in or referenced by the PIV enrollment record to reflect PIV eligibility for the PIV cardholder. 2.2 ¶ 5
    {are not available} {negative biometric verification decision} When issuing a PIV Card under the grace period, the card issuer SHALL verify that PIV Card issuance has been authorized by a proper authority and that the employee or contractor’s background investigation is valid. Re-investigations SHALL be performed, if required, in accordance with the federal investigative standards. At the time of issuance, the card issuer SHALL perform biometric verification of the applicant to the biometric data records in the applicant’s previous PIV enrollment record. On a positive biometric verification decision, the new PIV Card SHALL be released to the applicant. If the biometric verification decision is negative, or if no biometric data records are available, the cardholder SHALL provide two identity source documents (as specified in Section 2.7), and an attending operator SHALL inspect these and compare the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the new PIV Card. 2.8.2 ¶ 2]
    Human Resources management Human Resources Management
    Establish, implement, and maintain a personnel security program. CC ID 10628 Human Resources management Establish/Maintain Documentation
    Establish, implement, and maintain security clearance level criteria. CC ID 00780 Human Resources management Establish/Maintain Documentation
    Establish, implement, and maintain staff position risk designations. CC ID 14280
    [Federal departments and agencies must follow investigative requirements established by the Suitability and Credentialing Executive Agent and the Security Executive Agent. Departments and agencies SHALL use position designation guidance issued by the Executive Agents. The designation of the position determines the prerequisite investigative requirement. Individuals being processed for a PIV Card SHALL receive the required investigation and are subject to any applicable reinvestigation or continuous vetting requirements to maintain their PIV eligibility. 2.2 ¶ 2]
    Human Resources management Human Resources Management
    Establish, implement, and maintain personnel screening procedures. CC ID 11700
    [For full guidance on PIV credentialing investigative and adjudicative requirements, to include continuous vetting, issuers must work closely with their personnel security/suitability offices to ensure adherence to the latest federal personnel vetting guidance as provided by the Executive Agents. 2.2 ¶ 6
    Federal departments and agencies must follow investigative requirements established by the Suitability and Credentialing Executive Agent and the Security Executive Agent. Departments and agencies SHALL use position designation guidance issued by the Executive Agents. The designation of the position determines the prerequisite investigative requirement. Individuals being processed for a PIV Card SHALL receive the required investigation and are subject to any applicable reinvestigation or continuous vetting requirements to maintain their PIV eligibility. 2.2 ¶ 2]
    Human Resources management Establish/Maintain Documentation
    Perform a personal identification check during personnel screening. CC ID 06721 Human Resources management Human Resources Management
    Perform a criminal records check during personnel screening. CC ID 06643
    [Biometric identification using fingerprints is the primary input to law enforcement checks. In cases where ten fingerprints are not available, then as many fingers as possible SHALL be imaged as per guidance in [SP 800-76]. In cases where no fingers are available to be imaged, agencies SHALL seek guidance from their respective investigative service provider for alternative means of performing law enforcement checks. 2.3 ¶ 3]
    Human Resources management Establish/Maintain Documentation
    Include all residences in the criminal records check. CC ID 13306 Human Resources management Process or Activity
    Document any reasons a full criminal records check could not be performed. CC ID 13305 Human Resources management Establish/Maintain Documentation
    Perform a personal references check during personnel screening. CC ID 06645 Human Resources management Human Resources Management
    Perform a credit check during personnel screening. CC ID 06646 Human Resources management Human Resources Management
    Perform an academic records check during personnel screening. CC ID 06647 Human Resources management Establish/Maintain Documentation
    Perform a drug test during personnel screening. CC ID 06648 Human Resources management Testing
    Perform a resume check during personnel screening. CC ID 06659 Human Resources management Human Resources Management
    Perform a curriculum vitae check during personnel screening. CC ID 06660 Human Resources management Human Resources Management
    Allow personnel being screened to appeal findings and appeal decisions. CC ID 06720 Human Resources management Human Resources Management
    Disseminate and communicate screening results to interested personnel and affected parties. CC ID 16445 Human Resources management Communicate
    Perform personnel screening procedures, as necessary. CC ID 11763
    [Each agency’s PIV implementation SHALL meet the control objectives listed above including, but not limited to, processes that ensure that A credential is issued to an individual only after a proper authority has authorized issuance of the credential, the individual’s identity has been verified, and the individual has been vetted per Section 2.2. 2.1 ¶ 2 Bullet 1]
    Human Resources management Human Resources Management
    Establish, implement, and maintain security clearance procedures. CC ID 00783
    [For linking to background investigations, only fingerprints SHALL be used, since fingerprints are the only biometric characteristic used for background investigations. For all other purposes, verification attempts MAY be performed against any available biometric characteristic stored electronically on the PIV Card or in the enrollment record. 2.5 ¶ 7]
    Human Resources management Establish/Maintain Documentation
    Perform security clearance procedures, as necessary. CC ID 06644 Human Resources management Human Resources Management
    Establish and maintain security clearances. CC ID 01634 Human Resources management Human Resources Management
    Establish and maintain the staff structure in line with the strategic plan. CC ID 00764 Human Resources management Establish Roles
    Establish, implement, and maintain segregation of duties compensating controls if segregation of duties is not practical. CC ID 06960 Human Resources management Technical Security
    Train all personnel and third parties, as necessary. CC ID 00785 Human Resources management Behavior
    Establish, implement, and maintain training plans. CC ID 00828 Human Resources management Establish/Maintain Documentation
    Include duties and responsibilities in the training plan, as necessary. CC ID 12800 Human Resources management Human Resources Management
    Conduct bespoke roles and responsibilities training, as necessary. CC ID 13192
    [Supervised remote identity proofing SHALL meet the following requirements: The issuer SHALL require operators to have undergone a training program to detect potential fraud and to properly perform a supervised remote identity proofing session. 2.7.1 ¶ 4 Bullet 3]
    Human Resources management Training
    Establish, implement, and maintain a disability accessibility program. CC ID 06191
    [There are methods by which proper card orientation can be indicated. Section 4.1.4.3, for example, defines Zones 21F and 22F, where card orientation features MAY be applied. Note: If an agency determines that tactilely discernible markers for PIV Cards impose an undue burden, the agency SHALL implement policies and procedures to accommodate employees and contractors with disabilities in accordance with Sections 501 and 504 of the Rehabilitation Act. 4.1.3 ¶ 6]
    Operational management Establish/Maintain Documentation
    Write functional requirements for new systems to meet the disability accessibility standards. CC ID 06198 Operational management Business Processes
    Separate foreground from background when designing and building content. CC ID 15125 Operational management Systems Design, Build, and Implementation
    Establish, implement, and maintain web content accessibility guidelines. CC ID 14949 Operational management Establish/Maintain Documentation
    Configure focus order in a meaningful way. CC ID 15206 Operational management Configuration
    Configure keyboard interfaces to provide all the functionality that is available for the associated website content. CC ID 15151 Operational management Configuration
    Programmatically set the states, properties, and values of user interface components. CC ID 15150 Operational management Configuration
    Notify users of changes to user interface components. CC ID 15149 Operational management Configuration
    Refrain from designing content in a way that is known to cause seizures or physical reactions. CC ID 15203 Operational management Configuration
    Configure content to be compatible with various user agents and assistive technologies. CC ID 15147 Operational management Configuration
    Configure content to be interpreted by various user agents and assistive technologies. CC ID 15146 Operational management Configuration
    Provide captions for prerecorded audio content. CC ID 15204 Operational management Configuration
    Ensure user interface component names include the same text that is presented visually. CC ID 15145 Operational management Configuration
    Configure user interface components to operate device motion and user motion functionality. CC ID 15144 Operational management Configuration
    Configure single pointer functionality to organizational standards. CC ID 15143 Operational management Configuration
    Configure the keyboard operable user interface so the keyboard focus indicator is visible. CC ID 15142 Operational management Configuration
    Provide users the ability to disable user motion and device motion. CC ID 15205 Operational management Configuration
    Refrain from duplicating attributes in website content using markup languages. CC ID 15141 Operational management Configuration
    Use unique identifiers when using markup languages. CC ID 15140 Operational management Configuration
    Programmatically determine the status messages to convey to users. CC ID 15139 Operational management Configuration
    Advise users on how to navigate content. CC ID 15138 Operational management Communicate
    Allow users the ability to move focus with the keyboard. CC ID 15136 Operational management Configuration
    Avoid using images of text to convey information. CC ID 15202 Operational management Configuration
    Allow users to pause, stop, or hide moving, blinking or scrolling information. CC ID 15135 Operational management Configuration
    Display website content without loss of information or functionality and without requiring scrolling in two dimensions. CC ID 15134 Operational management Configuration
    Use images of text to convey information, as necessary. CC ID 15132 Operational management Configuration
    Refrain from using color as the only visual means to distinguish content. CC ID 15130 Operational management Configuration
    Refrain from restricting content to a single display orientation. CC ID 15129 Operational management Configuration
    Use text to convey information on web pages, as necessary. CC ID 15128 Operational management Configuration
    Configure the contrast ratio to organizational standards. CC ID 15127 Operational management Configuration
    Programmatically determine the correct reading sequence. CC ID 15126 Operational management Configuration
    Refrain from creating instructions for content that rely on sensory characteristics of components. CC ID 15124 Operational management Establish/Maintain Documentation
    Programmatically determine the information, structure, and relationships conveyed through the presentation. CC ID 15123 Operational management Configuration
    Provide audio descriptions for all prerecorded video content. CC ID 15122 Operational management Configuration
    Provide alternative forms of CAPTCHA, as necessary. CC ID 15121 Operational management Configuration
    Provide alternatives for time-based media. CC ID 15119 Operational management Configuration
    Configure non-text content to be ignored by assistive technology when it is pure decoration or not presented to users. CC ID 15118 Operational management Configuration
    Configure non-text content with a descriptive identification. CC ID 15117 Operational management Configuration
    Provide text alternatives for non-text content, as necessary. CC ID 15078 Operational management Configuration
    Implement functionality for a single pointer so an up-event reverses the outcome of a down-event. CC ID 15076 Operational management Configuration
    Implement functionality for a single pointer so the completion of a down-event is essential. CC ID 15075 Operational management Configuration
    Implement functionality to abort or undo the function when using a single pointer. CC ID 15074 Operational management Configuration
    Implement functionality for a single pointer so the up-event signals the completion of a function. CC ID 15073 Operational management Configuration
    Implement functionality for a single pointer so the down-event is not used to execute any part of a function. CC ID 15072 Operational management Configuration
    Allow users the ability to use various input devices. CC ID 15071 Operational management Configuration
    Implement mechanisms to allow users the ability to bypass repeated blocks of website content. CC ID 15068 Operational management Configuration
    Implement flashes below the general flash and red flash thresholds on web pages. CC ID 15067 Operational management Configuration
    Configure content to be presentable in a manner that is clear and conspicuous to all users. CC ID 15066 Operational management Configuration
    Configure non-text content that is a control or accepts user input with a name that describes its purpose. CC ID 15065 Operational management Configuration
    Allow users the ability to modify time limits in website content a defined number of times. CC ID 15064 Operational management Configuration
    Provide users with a simple method to extend the time limits set by content. CC ID 15063 Operational management Configuration
    Allow users the ability to disable time limits set by content. CC ID 15062 Operational management Configuration
    Warn users before time limits set by content are about to expire. CC ID 15061 Operational management Configuration
    Allow users the ability to modify time limits set by website or native applications. CC ID 15060 Operational management Configuration
    Provide users time to read and use website content, as necessary. CC ID 15059 Operational management Configuration
    Activate keyboard shortcuts on user interface components only when the appropriate component has focus. CC ID 15058 Operational management Configuration
    Provide users a mechanism to turn off keyboard shortcuts, as necessary. CC ID 15057 Operational management Configuration
    Configure all functionality to be accessible with a keyboard. CC ID 15056 Operational management Configuration
    Establish, implement, and maintain a registration database. CC ID 15048
    [{PIV enrollment records} The card issuer SHALL maintain the enrollment record for each issued ground-color:#CBD0E5;" class="term_secondary-verb">PIV Card. These enrollment records are created and maintained through the methods of contemporaneous acquisition at each step of the PIV issuance process—typically including identity proofing, registration, and biometric enrollment. 2.6 ¶ 1
    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-PKI derived PIV credentials are not required to be updated or reissued in these situations. 2.10.3 ¶ 1
    {PIV enrollment records} The card issuer SHALL maintain the enrollment record for each issued ground-color:#CBD0E5;" class="term_secondary-verb">PIV Card. These enrollment records are created and maintained through the methods of contemporaneous acquisition at each step of the PIV issuance process—typically including identity proofing, registration, and biometric enrollment. 2.6 ¶ 1
    The requirements for identity proofing and registration also apply to citizens of foreign countries who are working for the U.S. Federal Government overseas. However, a process for identity proofing and registration SHALL be established using a method approved by the U.S. Department of State's Bureau of Diplomatic Security, except for employees under the command of a U.S. area military commander. These procedures vary depending on the country. The requirements for identity proofing and registration also apply to citizens of foreign countries who are working for the U.S. Federal Government overseas. However, a process for identity proofing and registration SHALL be established using a method approved by the U.S. Department of State's Bureau of Diplomatic Security, except for employees under the command of a U.S. area military commander. These procedures vary depending on the country. 2.7 ¶ 12]
    Operational management Data and Information Management
    Include contact details in the registration database. CC ID 15109 Operational management Establish/Maintain Documentation
    Include personal data in the registration database, as necessary. CC ID 15108
    [{data in transit}{data at rest} PIV enrollment records contain Personally Identifiable Information (PII). PII SHALL be protected in a manner that protects the individual’s privacy and maintains the integrity of the records both in transit and at rest. 2.6 ¶ 5]
    Operational management Establish/Maintain Documentation
    Make the registration database available to the public. CC ID 15107 Operational management Communicate
    Impose conditions or restrictions on the termination or suspension of a registration. CC ID 16796 Operational management Business Processes
    Publish the IP addresses being used by each external customer in the registration database. CC ID 16403 Operational management Data and Information Management
    Maintain the accuracy of registry information published in registration databases. CC ID 16402 Operational management Data and Information Management
    Include all required information in the registration database. CC ID 15106
    [{individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    {individual} {location} PIV enrollment records SHOULD include the following data: A log of activities that documents who took the action, what action was taken, when and where the action took place, and what data was collected. 2.6 ¶ 3 Bullet 1
    PIV enrollment records SHOULD include the following data: Unique identifiers issued to the individual, such as the Federal Agency Smart Credential Number (FASC-N), the cardholder Universally Unique Identifier (UUID), and the card UUID. The record MAY contain historical unique identifiers. 2.6 ¶ 3 Bullet 3
    PIV enrollment records SHOULD include the following data: Information about the authorizing entity that has approved the issuance of a credential. 2.6 ¶ 3 Bullet 4
    PIV enrollment records SHOULD include the following data: Current status of the background investigation, including the results of the investigation once completed. 2.6 ¶ 3 Bullet 5
    PIV enrollment records SHOULD include the following data: Current status of the background investigation, including the results of the investigation once completed. 2.6 ¶ 3 Bullet 5
    PIV enrollment records SHOULD include the following data: The evidence of authorization if the credential is issued under a pseudonym. 2.6 ¶ 3 Bullet 6
    PIV enrollment records SHOULD include the following data: Any data about the cardholder, including subsequent changes in the data (e.g., cardholder name changes per Section 2.9.1.1). 2.6 ¶ 3 Bullet 7
    {applicable requirements} If there is any data change about the cardholder, the issuer SHALL record this data change in the PIV enrollment record, if applicable. If the changed data is the cardholder’s name, then the issuer SHALL meet the requirements in Section 2.9.1.1. 2.9.1 ¶ 6
    {applicable requirements} If there is any data change about the cardholder, the issuer SHALL record this data change in the PIV enrollment record, if applicable. If the changed data is the cardholder’s name, then the issuer SHALL meet the requirements in Section 2.9.1.1. 2.9.1 ¶ 6
    PIV enrollment records SHOULD include the following data: An enrollment data record that contains the most recent collection of each of the biometric data collected. The enrollment data record describes the circumstances of biometric acquisition including the name and role of the acquiring agent, the office and organization, time, place, and acquisition method. The enrollment data record MAY also document unavailable biometric data or failed attempts to collect biometric data. The enrollment data record MAY contain historical biometric data records. 2.6 ¶ 3 Bullet 2
    PIV enrollment records SHALL maintain an auditable sequence of enrollment events to facilitate binding an applicant to multiple transactions that might take place at different times and locations. These records are generally stored as part of the cardholder’s PIV identity account, either as part of the issuer’s IDMS or through links to records in other related systems (e.g., card management systems). 2.6 ¶ 2]
    Operational management Data and Information Management
    Establish, implement, and maintain system hardening procedures. CC ID 12001 System hardening through configuration management Establish/Maintain Documentation
    Establish, implement, and maintain authenticators. CC ID 15305 System hardening through configuration management Technical Security
    Establish, implement, and maintain an authenticator standard. CC ID 01702
    [{be valid} The binding and issuance of derived PIV credentials SHALL use valid PIV Cards to establish cardholder identity in accordance with [SP 800-157]. Derived PIV credentials SHALL meet the requirements for Authenticator Assurance Level (AAL) 2 or 3 specified in [SP 800-63B]. All derived PIV credentials meeting AAL2 but not AAL3 requirements SHALL allow authentication at AAL2 only. Derived PIV credentials meeting AAL3 requirements also fulfill the requirements of AAL2 and can be used in circumstances requiring AAL2. The issuer SHALL attempt to promptly notify the cardholder of the binding of a derived PIV credential through an independent means that would not afford an attacker an opportunity to erase the notification. More than one independent notification method MAY be used to ensure prompt receipt by the cardholder. 2.10.1 ¶ 2]
    System hardening through configuration management Establish/Maintain Documentation
    Disallow personal data in authenticators. CC ID 13864 System hardening through configuration management Technical Security
    Establish, implement, and maintain an authenticator management system. CC ID 12031 System hardening through configuration management Establish/Maintain Documentation
    Establish, implement, and maintain a repository of authenticators. CC ID 16372 System hardening through configuration management Data and Information Management
    Establish, implement, and maintain authenticator procedures. CC ID 12002 System hardening through configuration management Establish/Maintain Documentation
    Restrict access to authentication files to authorized personnel, as necessary. CC ID 12127 System hardening through configuration management Technical Security
    Configure authenticators to comply with organizational standards. CC ID 06412 System hardening through configuration management Configuration
    Configure the system to require new users to change their authenticator on first use. CC ID 05268 System hardening through configuration management Configuration
    Configure authenticators so that group authenticators or shared authenticators are prohibited. CC ID 00519 System hardening through configuration management Configuration
    Configure the system to prevent unencrypted authenticator use. CC ID 04457 System hardening through configuration management Configuration
    Disable store passwords using reversible encryption. CC ID 01708 System hardening through configuration management Configuration
    Configure the system to encrypt authenticators. CC ID 06735 System hardening through configuration management Configuration
    Configure the system to mask authenticators. CC ID 02037 System hardening through configuration management Configuration
    Configure the authenticator policy to ban the use of usernames or user identifiers in authenticators. CC ID 05992 System hardening through configuration management Configuration
    Configure the "minimum number of digits required for new passwords" setting to organizational standards. CC ID 08717 System hardening through configuration management Establish/Maintain Documentation
    Configure the "minimum number of upper case characters required for new passwords" setting to organizational standards. CC ID 08718 System hardening through configuration management Establish/Maintain Documentation
    Configure the system to refrain from specifying the type of information used as password hints. CC ID 13783 System hardening through configuration management Configuration
    Configure the "minimum number of lower case characters required for new passwords" setting to organizational standards. CC ID 08719 System hardening through configuration management Establish/Maintain Documentation
    Disable machine account password changes. CC ID 01737 System hardening through configuration management Configuration
    Configure the "minimum number of special characters required for new passwords" setting to organizational standards. CC ID 08720 System hardening through configuration management Establish/Maintain Documentation
    Configure the "require new passwords to differ from old ones by the appropriate minimum number of characters" setting to organizational standards. CC ID 08722 System hardening through configuration management Establish/Maintain Documentation
    Configure the "password reuse" setting to organizational standards. CC ID 08724 System hardening through configuration management Establish/Maintain Documentation
    Configure the "Disable Remember Password" setting. CC ID 05270 System hardening through configuration management Configuration
    Configure the "Minimum password age" to organizational standards. CC ID 01703 System hardening through configuration management Configuration
    Configure the LILO/GRUB password. CC ID 01576 System hardening through configuration management Configuration
    Configure the system to use Apple's Keychain Access to store passwords and certificates. CC ID 04481 System hardening through configuration management Configuration
    Change the default password to Apple's Keychain. CC ID 04482 System hardening through configuration management Configuration
    Configure Apple's Keychain items to ask for the Keychain password. CC ID 04483 System hardening through configuration management Configuration
    Configure the Syskey Encryption Key and associated password. CC ID 05978 System hardening through configuration management Configuration
    Configure the "Accounts: Limit local account use of blank passwords to console logon only" setting. CC ID 04505 System hardening through configuration management Configuration
    Configure the "System cryptography: Force strong key protection for user keys stored in the computer" setting. CC ID 04534 System hardening through configuration management Configuration
    Configure interactive logon for accounts that do not have assigned authenticators in accordance with organizational standards. CC ID 05267 System hardening through configuration management Configuration
    Enable or disable remote connections from accounts with empty authenticators, as appropriate. CC ID 05269 System hardening through configuration management Configuration
    Configure the "Send LanMan compatible password" setting. CC ID 05271 System hardening through configuration management Configuration
    Configure the authenticator policy to ban or allow authenticators as words found in dictionaries, as appropriate. CC ID 05993 System hardening through configuration management Configuration
    Set the most number of characters required for the BitLocker Startup PIN correctly. CC ID 06054 System hardening through configuration management Configuration
    Set the default folder for BitLocker recovery passwords correctly. CC ID 06055 System hardening through configuration management Configuration
    Notify affected parties to keep authenticators confidential. CC ID 06787 System hardening through configuration management Behavior
    Discourage affected parties from recording authenticators. CC ID 06788 System hardening through configuration management Behavior
    Configure the "shadow password for all accounts in /etc/passwd" setting to organizational standards. CC ID 08721 System hardening through configuration management Establish/Maintain Documentation
    Configure the "password hashing algorithm" setting to organizational standards. CC ID 08723 System hardening through configuration management Establish/Maintain Documentation
    Configure the "Disable password strength validation for Peer Grouping" setting to organizational standards. CC ID 10866 System hardening through configuration management Configuration
    Configure the "Set the interval between synchronization retries for Password Synchronization" setting to organizational standards. CC ID 11185 System hardening through configuration management Configuration
    Configure the "Set the number of synchronization retries for servers running Password Synchronization" setting to organizational standards. CC ID 11187 System hardening through configuration management Configuration
    Configure the "Turn off password security in Input Panel" setting to organizational standards. CC ID 11296 System hardening through configuration management Configuration
    Configure the "Turn on the Windows to NIS password synchronization for users that have been migrated to Active Directory" setting to organizational standards. CC ID 11355 System hardening through configuration management Configuration
    Configure the authenticator display screen to organizational standards. CC ID 13794 System hardening through configuration management Configuration
    Configure the authenticator field to disallow memorized secrets found in the memorized secret list. CC ID 13808 System hardening through configuration management Configuration
    Configure the authenticator display screen to display the memorized secret as an option. CC ID 13806 System hardening through configuration management Configuration
    Disseminate and communicate with the end user when a memorized secret entered into an authenticator field matches one found in the memorized secret list. CC ID 13807 System hardening through configuration management Communicate
    Configure the memorized secret verifiers to refrain from allowing anonymous users to access memorized secret hints. CC ID 13823 System hardening through configuration management Configuration
    Configure the system to allow paste functionality for the authenticator field. CC ID 13819 System hardening through configuration management Configuration
    Configure the system to require successful authentication before an authenticator for a user account is changed. CC ID 13821 System hardening through configuration management Configuration
    Implement safeguards to protect authenticators from unauthorized access. CC ID 15310
    [{applicable requirements}{remote proofing procedure}{not acquire} PIN reset at a supervised remote identity proofing station combines the assurance of an in-person reset with the convenience of a kiosk reset. All protections and requirements of Section 2.7.1 SHALL be observed during the procedure. The operator SHALL initiate a biometric verification to ensure that the cardholder’s biometric characteristics captured at the station elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCCAUTH authentication mechanism. In cases where a negative biometric verification decision is returned or the cardholder’s biometric characteristics are not successfully acquired, the cardholder SHALL provide the PIV Card to be reset and another primary identity source document (as specified in Section 2.7) via the scanners and sensors integrated into the station. The remote operator SHALL inspect these items and compare the video feed of the cardholder with the electronic facial image retrieved from the enrollment data record and the photograph printed on the PIV Card. 2.9.3.1 ¶ 7]
    System hardening through configuration management Technical Security
    Configure Microsoft Office to Organizational Standards. CC ID 07147 System hardening through configuration management Configuration
    Configure Microsoft Outlook settings for Microsoft Office in accordance with organizational standards. CC ID 07341 System hardening through configuration management Configuration
    Configure the "Retrieving CRLs (Certificate Revocation Lists)" to organizational standards. CC ID 07417
    [PIV authentication, card authentication, digital signature, and key management certificates SHALL contain the crlDistributionPoints extension needed to locate CRLs, and 5.5 ¶ 2 Bullet 1]
    System hardening through configuration management Configuration
    Configure Logging settings in accordance with organizational standards. CC ID 07611 System hardening through configuration management Configuration
    Configure all logs to capture auditable events or actionable events. CC ID 06332 System hardening through configuration management Configuration
    Configure the log to capture configuration changes. CC ID 06881 System hardening through configuration management Configuration
    Configure the log to capture all changes to certificates. CC ID 05595
    [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. 5.5.2 ¶ 1]
    System hardening through configuration management Configuration
    Configure Key, Certificate, Password, Authentication and Identity Management settings in accordance with organizational standards. CC ID 07621 System hardening through configuration management Configuration
    Configure "client certificate authentication" to organizational standards. CC ID 14608
    [The relying system validates the PIV authentication certificate from the PIV Card application using certificate path validation as specified in [RFC 5280] to ensure that it is neither expired nor revoked and that it is from a trusted source. Path validation SHOULD be configured to specify which policy OIDs are trusted. 6.2.3.1 ¶ 1 Bullet 2]
    System hardening through configuration management Configuration
    Configure the "Password must meet complexity requirements" to organizational standards. CC ID 07743
    [{be unguessable}{not be identifiable}{be unique} The cardholder SHALL be guided in selecting a strong PIN value. The PIN SHALL be a minimum of six digits in length and SHOULD NOT be easily guessable, individually identifiable (e.g., part of a Social Security Number or phone number), or commonly used (e.g., 000000, 123456). 4.3.1 ¶ 2
    {be unguessable}{not be identifiable}{be unique} The cardholder SHALL be guided in selecting a strong PIN value. The PIN SHALL be a minimum of six digits in length and SHOULD NOT be easily guessable, individually identifiable (e.g., part of a Social Security Number or phone number), or commonly used (e.g., 000000, 123456). 4.3.1 ¶ 2]
    System hardening through configuration management Configuration
    Configure the "Check for server certificate revocation" to organizational standards. CC ID 08120
    [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. 5.5.2 ¶ 1]
    System hardening through configuration management Configuration
    Configure the "Allow the use of biometrics" to organizational standards. CC ID 08435
    [{refrain from exceeding} Previously collected biometric data MAY be reused with the new PIV Card if the expiration date of the new PIV Card is no later than 12 years after the date that the biometric data was obtained. As biometric system error rates generally increase with the time elapsed since initial collection (reference aging, [ISO 2382-37]), issuers MAY refresh biometric data in the PIV enrollment record during the re-issuance process. Even if the same biometric data is reused with the new PIV Card, the digital signature must be recomputed with the new FASC-N and card UUID. 2.9.1 ¶ 7]
    System hardening through configuration management Configuration
    Configure the "Number of attempts allowed" to organizational standards. CC ID 08569
    [{maximum number of attempts} The PIN on a PIV Card may need to be reset if the cardholder has forgotten the PIN or if PIN-based cardholder authentication has been disabled by the usage of an invalid PIN more than the allowed number of retries. Fingers might need to be re-enrolled for OCC if the cardholder has experienced epidermal scarring or similar physical changes, resulting in false negative biometric verification decisions, or if OCC has been disabled by exceeding the allowed number of negative biometric verification decisions. No more than 10 consecutive activation retries for each of the activation methods (i.e., PIN and OCC attempts) SHALL be permitted. Card issuers MAY further restrict the maximum retry limit to a lower value. 2.9.3 ¶ 2
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1]
    System hardening through configuration management Configuration
    Establish, implement, and maintain records management policies. CC ID 00903 Records management Establish/Maintain Documentation
    Initiate the System Development Life Cycle development phase or System Development Life Cycle build phase. CC ID 06267 Systems design, build, and implementation Systems Design, Build, and Implementation
    Develop systems in accordance with the system design specifications and system design standards. CC ID 01094 Systems design, build, and implementation Systems Design, Build, and Implementation
    Develop new products based on best practices. CC ID 01095 Systems design, build, and implementation Systems Design, Build, and Implementation
    Establish, implement, and maintain a system design specification. CC ID 04557 Systems design, build, and implementation Establish/Maintain Documentation
    Establish, implement, and maintain identification card or badge architectural designs. CC ID 06591
    [{applicable requirements} The PIV Card SHALL be maintained using processes that comply with this section. 2.9 ¶ 1
    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 Card Design Standard classifies security features into three categories, depending on the inspection level required for verification: 4.1.2 ¶ 1
    As noted in Section 4.1.3, the PIV Card SHALL contain a contact and a contactless ICC interface. This Standard does not specify the number of chips used to support the mandated contact and contactless interfaces. 4.1.4 ¶ 2
    The PIV Card SHALL contain a contact and a contactless ICC interface. 4.1.3 ¶ 2
    To achieve a common PIV Card appearance and provide departments and agencies with the flexibility to augment the card with department-or agency-specific requirements, the card SHALL contain printed information and machine-readable technologies. Mandated and optional items SHALL be placed as described and depicted. Printed data SHALL NOT interfere with machine-readable technology. 4.1.4 ¶ 3
    {PIV Card} Areas that are marked as reserved SHOULD NOT be used for printing. The reason for the recommended reserved areas is that placement of the embedded contactless ICC module may vary between manufacturers, and there are constraints that prohibit printing over the embedded contactless module. The PIV Card topography provides flexibility for placement of the embedded module, either in the upper right corner or in the lower portion. Printing restrictions apply only to the area where the embedded module is located. 4.1.4 ¶ 4
    {contact interface}{not require} The CHUID SHALL be accessible from both the contact and contactless interfaces of the PIV Card without card activation. 4.2.1 ¶ 4
    {PIV Card} 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 SHALL follow recommendations set forth in [SP 800-76]. 4.1.4.1 ¶ 2
    {PIV Card}{anti-counterfeiting technique} All security features SHOULD maintainspan> their function for the life of the card. As a generally accepted security procedure, federal departments and agencies SHOULD periodically review the viability, effectiveness, and currency of employed tamper resistance and anti-counterfeiting methods. 4.1.2 ¶ 10
    {pre-determined and authorized location} If used, the department or agency SHALL place the cardholder signature below the photograph and cardholder name, as depicted in Figure 4-3. The space for the signature SHALL NOT interfere with the placement of the ICCs and related components. Because of card surface space constraints, placement of a signature may limit the size of the optional two-dimensional bar code. 4.1.4.3 ¶ 3
    {issuing organization}{pre-determined and authorized location}{be visible} The Agency seal in Zone 11F may become a mandatory field in the next revision of the Standard. If used, the seal selected by the issuing department, agency, or organization SHALL be printed in the area depicted. It SHALL be printed using the n">guidelines provided in Figure 4-2 to ensure that information printed on the seal ss="term_secondary-verb">is legible and clearly visible. 4.1.4.3 ¶ 13
    If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process s="term_secondary-verb">are not adversely impacted. If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 29]
    Systems design, build, and implementation Process or Activity
    Define the physical requirements for identification cards or badges in the identification card or badge architectural designs. CC ID 06592
    [{PIV Card} Decals SHALL NOT be adhered to the card. 4.1.3 ¶ 9
    {applicable requirements} The PIV Card SHALL comply with the physical characteristics described in [ISO 7810], [ISO 10373], and [ISO 7816] for contact cards in addition to [ISO 14443] for contactless cards. 4.1 ¶ 3
    The PIV Card SHALL NOT be embossed other than for security and accessibility features. 4.1.3 ¶ 8
    {PIV Card}{thickness}{applicable requirements} The card SHALL be 27 mil to 33 mil (0.68 mm to 0.84 mm) thick before lamination, in accordance with [ISO 7810]. 4.1.3 ¶ 7
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not alter or interfere with printed information, including the photograph; or 4.1.3 ¶ 10 Bullet 3
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not invalidate card manufacturer warranties or other product claims; 4.1.3 ¶ 10 Bullet 2
    {machine readable format} Incorporation of security features SHALL not impede access to machine-readable information. 4.1.2 ¶ 9 Bullet 4
    {PIV Card} The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security features, as described in Section 4.1.2, may modify the perceived color slightly. The presence of security features SHALL NOT prevent the recognition of white as the principal card body color by a person with normal vision (corrected or uncorrected) at a working distance of 50 cm to 200 cm. 4.1.3 ¶ 3
    {PIV Card} The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security features, as described in Section 4.1.2, may modify the perceived color slightly. The presence of security features SHALL NOT prevent the recognition of white as the principal card body color by a person with normal vision (corrected or uncorrected) at a working distance of 50 cm to 200 cm. 4.1.3 ¶ 3
    {PIV Card} The card body SHALL be white in accordance with color representation in Section 4.1.5. Only security features, as described in Section 4.1.2, may modify the perceived color slightly. The presence of security features SHALL NOT prevent the recognition of white as the principal card body color by a person with normal vision (corrected or uncorrected) at a working distance of 50 cm to 200 cm. 4.1.3 ¶ 3
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not 4.1.3 ¶ 10
    {PIV Card} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not compromise card body durability requirements and characteristics; 4.1.3 ¶ 10 Bullet 1
    {PIV Card}{refrain from interfering} Departments and agencies MAY choose to punch an opening in the card body to enable the card to be oriented by touch or to be worn on a lanyard. Departments and agencies should ensure such alterations are closely coordinated with the card vendor and manufacturer to ensure the card material integrity and printing process are not adversely impacted. Departments and agencies SHOULD ensure such alterations do not damage or interfere with machine-readable technology, such as the embedded antenna. 4.1.3 ¶ 10 Bullet 4
    {PIV Card} The card material SHALL withstand the effects of temperatures required by the application of a polyester laminate on one or both sides of the card by commercial off-the-shelf (COTS) equipment. The thickness added due to a laminate layer SHALL NOT interfere with the smart card reader operation. The card material SHALL allow production of a flat card in accordance with [ISO 7810] after lamination of one or both sides of the card. 4.1.3 ¶ 11
    {PIV Card} The card material SHALL withstand the effects of temperatures required by the application of a polyester laminate on one or both sides of the card by commercial off-the-shelf (COTS) equipment. The thickness added due to a laminate layer SHALL NOT interfere with the smart card reader operation. The card material SHALL allow production of a flat card in accordance with [ISO 7810] after lamination of one or both sides of the card. 4.1.3 ¶ 11
    {PIV Card} The card material SHALL withstand the effects of temperatures required by the application of a polyester laminate on one or both sides of the card by commercial off-the-shelf (COTS) equipment. The thickness added due to a laminate layer SHALL NOT interfere with the smart card reader operation. The card material SHALL allow production of a flat card in accordance with [ISO 7810] after lamination of one or both sides of the card. 4.1.3 ¶ 11
    To achieve a common PIV Card appearance and provide departments and agencies with the flexibility to augment the card with department-or agency-specific requirements, the card SHALL contain printed information and machine-readable technologies. Mandated and optional items SHALL be placed as described and depicted. Printed data SHALL NOT interfere with machine-readable technology. 4.1.4 ¶ 3
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    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 components, nor SHALL it obstruct access to machine-readable information. 4.1.1 ¶ 1
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    {PIV Card}{stress-strain analysis}{plasticizer exposure test}{impact test} The card body structure SHALL consist of card materials that satisfy the card characteristics in [ISO 7810] and test methods in [ANSI 322]. Although the [ANSI 322] test methods do not currently specify compliance requirements, the tests SHALL be used to evaluate card material durability and performance. These tests SHALL include card flexure, static stress, plasticizer exposure, impact resistance, card structural integrity, surface abrasion, temperature and humidity-induced dye migration, ultraviolet light exposure, and laundry test. Cards SHALL NOT malfunction or delaminate after hand cleaning with a mild soap and water mixture. 4.1.3 ¶ 4
    {PIV Card} 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 pan style="background-color:#F0BBBC;" class="term_primary-noun">background SHALL follow recommendations set forth in [SP 800-76]. 4.1.4.1 ¶ 2
    {PIV Card} 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 minimumspan> of 300 dots per inch (DPI) resolution SHALL be used. The background SHALL follow recommendations set forth in [SP 800-76]. 4.1.4.1 ¶ 2
    Incorporation of security features SHALL be free of defects, such as fading and discoloration; 4.1.2 ¶ 9 Bullet 2
    Incorporation of security features SHALL be in accordance with durability requirements; 4.1.2 ¶ 9 Bullet 1
    The electronic contact interface for the card as defined by [ISO 7816]. Printed items SHALL NOT cover the contact surface. The total size of the contact surface can vary between manufacturers. The area shown in Figure 4-1 roughly represents the minimal possible size. The electronic contact interface for the card as defined by [ISO 7816]. Printed items SHALL NOT cover the contact surface. The total size of the contact surface can vary between manufacturers. The area shown in Figure 4-1 roughly represents the minimal possible size. 4.1.4.1 ¶ 7
    {refrain from using} Foreign national color-coding has precedence over government employee and contractor color-coding. These colors SHALL be reserved and SHALL NOT be employed for other purposes. These colors SHALL be printed in accordance with the color specifications provided in Section 4.1.5. Zone 15F MAY be a solid or patterned line at the department or agency’s discretion. 4.1.4.1 ¶ 16
    {refrain from using} Foreign national color-coding has precedence over government employee and contractor color-coding. These colors SHALL be reserved and SHALL NOT be employed for other purposes. These colors SHALL:#CBD0E5;" class="term_secondary-verb"> be n style="background-color:#B7D8ED;" class="term_primary-verb">printed
    in accordance with the color specifications provided in Section 4.1.5. Zone 15F MAY be a solid or patterned line at the department or agency’s discretion. 4.1.4.1 ¶ 16
    {PIV Card} Color-coding SHALL be used for additional identification of employee affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be n style="background-color:#B7D8ED;" class="term_primary-verb">usedn>: tyle="background-color:#F0BBBC;" class="term_primary-noun">green: contractor. 4.1.4.1 ¶ 15 Bullet 3
    Color-coding SHALL be used for additional identification of employee affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be usedn>: tyle="background-color:#F0BBBC;" class="term_primary-noun">white: government employee, or 4.1.4.1 ¶ 15 Bullet 2
    {PIV Card} Color-coding SHALL be used for additional identification of employee affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be n style="background-color:#B7D8ED;" class="term_primary-verb">usedn>: tyle="background-color:#F0BBBC;" class="term_primary-noun">blue: foreign national, 4.1.4.1 ¶ 15 Bullet 1
    If used, this area SHALL incorporate edge ridging or a notched corner to indicate card -noun">orientation
    , as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. If used, this area SHALL incorporate edge ridging or a notched corner to indicate card orientation, as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 27
    If used, this area SHALL incorporate edge ridging or a notched corner to indicate card orientation, as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and class="term_primary-noun">manufacturer
    to ensure that the card material integrity and printing process s="term_secondary-verb">are not adversely impacted
    . If used, this area SHALL incorporate edge ridging or a notched corner to indicate card orientation, as depicted in Figure 4-4. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 27
    {PIV Card}{reserved area}{machine-readable information} Departments and agencies MAY choose to provide additional information to identify emergency response officials or to better identify the cardholder’s authorized access. If used, this additional text SHALL be in the general area depicted in Figure 4-7 and <span style="background-color:#B7D8ED;" class="term_primary-verb">SHALL NOT interfere
    with other printed text or machine-readable components. An example of a printed statement is provided in Figure 4-7. 4.1.4.4 ¶ 8]
    Systems design, build, and implementation Process or Activity
    Define the mandatory items that must appear on identification cards or badges in the identification card or badge architectural designs. CC ID 06593
    [To achieve a common PIV Card appearance and provide departments and agencies with the flexibility to augment the card with department-or agency-specific requirements, the card SHALL contain printed information and machine-readable technologies. Mandated and optional items SHALL be placed as described and depicted. Printed data SHALL NOT interfere with machine-readable technology. 4.1.4 ¶ 3
    {approved font} Unless otherwise specified, all data labels SHALL be printed in 5 pt Arial with the corresponding data in 6 pt Arial Bold. If the Arial font is not available, a visually similar font, such as Public Sans [PublicSans], MAY be substituted for all references to Arial within this Standard. If such a substitution is made, the substitution SHALL be consistently applied to all uses of the Arial font on the PIV Card. Unless otherwise specified, all text SHALL be printed in black. 4.1.4 ¶ 5
    {approved font} Unless otherwise specified, all data labels SHALL be printed in 5 pt Arial with the corresponding data in 6 pt Arial Bold. If the Arial font is not available, a visually similar font, such as Public Sans [PublicSans], MAY be substituted for all references to Arial within this Standard. If such a substitution is made, the substitution SHALL be consistently applied to all uses of the Arial font on the PIV Card. Unless otherwise specified, all text SHALL be printed in black. 4.1.4 ¶ 5
    {approved font} Unless otherwise specified, all data labels SHALL be printed in 5 pt Arial with the corresponding data in 6 pt Arial Bold. If the Arial font is not available, a visually similar font, such as Public Sans [PublicSans], MAY be substituted for all references to Arial within this Standard. If such a substitution is made, the substitution SHALL be consistently applied to all uses of the Arial font on the PIV Card. Unless otherwise specified, all text SHALL be printed in black. 4.1.4 ¶ 5
    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 other possible machine-readable technologies. Logically stored data elements are discussed in Section 4.2. 4.1.4 ¶ 1
    {applicable requirements} {biometric authentication} The electronic facial image SHALL be stored on the PIV Card as described in Section 4.2.3.1. It SHALL be printed on the PIV Card according to Section 4.1.4.1. The image MAY be used for cardholder authentication (BIO or BIO-A) as described in Section 6.2.1. It MAY be retrieved and displayed on guard workstations to augment other authentication processes from Section 6.2. The electronic facial image is an additional means of authentication during PIV issuance and maintenance processes when used with an automated facial comparison algorithm. 2.5 ¶ 5
    Incorporation of security features SHALL not obscure printed information; and 4.1.2 ¶ 9 Bullet 3
    {PIV Card} The organizational affiliation SHALL be -color:#B7D8ED;" class="term_primary-verb">printed as depicted in Figure 4-1. 4.1.4.1 ¶ 11
    {PIV Card} An employee affiliation SHALL be #B7D8ED;" class="term_primary-verb">printed on the card as depicted in Figure 4-1. Examples of employee affiliation include “Employee,” “Contractor,” “Active Duty,” and “Civilian.” 4.1.4.1 ¶ 9
    Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL olor:#CBD0E5;" class="term_secondary-verb">s="term_primary-verb">indicate> such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. 4.1.4.1 ¶ 5
    Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. 4.1.4.1 ¶ 5
    Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. Names in the primary identifier and the first name in the secondary identifier SHALL NOT be abbreviated. If other names and conventional prefixes and suffixes are included, they SHALL be included in the secondary identifier and MAY be abbreviated. The special character “.” (period) SHALL indicate such abbreviations, as shown in Figure 4-2. Other uses of special symbols (e.g., the apostrophe in “O’BRIEN”) are at the discretion of the issuer. 4.1.4.1 ¶ 5
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be ry-verb">printed
    . Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {PIV Card}{appropriate format}{approved font} The full name SHALL be style="background-color:#B7D8ED;" class="term_primary-verb">printed directly under the photograph in capital letters from the American Standard Code for Information Interchange (ASCII) character set specified in [RFC 20]. The full name SHALL be composed of a primary identifier (i.e., surnames or family names) and a secondary identifier (i.e., pre-names or given names). The printed name SHALL match the name on the identity source documents provided during identity proofing and registration to the extent possible. The full name SHALL be printed in the PRIMARY IDENTIFIER, SECONDARY IDENTIFIER format. The entire full name SHOULD be printed on available lines of Zone 2F and either identifier MAY be wrapped. The wrapped identifier SHALL be indicated with the “>” character at the end of the line. The identifiers MAY be printed on separate lines if each fits on one line. Departments and agencies SHALL use the largest font in the range of 7 pt to 10 pt Arial Bold that allows the full name to be printed. Using 7 pt Arial Bold allows space for three lines and SHALL only be used if the full name does not fit on two lines in 8 pt Arial Bold. Table 4-1 provides examples of separate primary and secondary identifier lines, single line with identifiers, wrapped full names, and the full name in three lines. Note that truncation SHOULD only occur if the full name cannot be printed in 7 pt Arial Bold. 4.1.4.1 ¶ 4
    {appropriate format}{refrain from exceeding} The affiliation color codes “B” for blue, “W” for white, and “G” for green SHALL be printed in a white circle on the right side of Zone 15F, as depicted in Figure 4-1. The diameter of the circle SHALL NOT be more than 5 mm. The lettering SHALL correspond to the printed >color</span> in Zone 15F. 4.1.4.1 ¶ 18
    {appropriate format}{refrain from exceeding} The affiliation color codes “B” for blue, “W” for white, and “G” for green SHALL be olor:#B7D8ED;" class="term_primary-verb">printed in a white circle on the right side of Zone 15F, as depicted in Figure 4-1. The diameter of the circle SHALL NOT be more than 5 mm. The lettering SHALL correspond to the printed color in Zone 15F. 4.1.4.1 ¶ 18
    {appropriate format}{refrain from exceeding} The affiliation color codes “B” for blue, “W” for white, and “G” for green SHALL be printed in a white circle on the right side of Zone 15F, as depicted in Figure 4-1. The diameter of the tyle="background-color:#CBD0E5;" class="term_secondary-verb">ass="term_primary-noun">circle SHALL NOT be more than 5 mm. The lettering SHALL correspond to the printed color in Zone 15F. 4.1.4.1 ¶ 18
    {appropriate format}{approved font} The card expiration date SHALL be printed in a MMMYYYY format in the upper right-hand corner as depicted in Figure 4-1. The YYYY characters represent the fourdigit year and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 19F expiration date SHALL be printed in 12 pt Arial Bold. 4.1.4.1 ¶ 20
    {appropriate format}{approved font} The card expiration date SHALL be printed in a MMMYYYY format in the upper right-hand corner as depicted in Figure 4-1. The YYYY characters represent the fourdigit year and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 19F expiration date SHALL be printed in 12 pt Arial Bold. 4.1.4.1 ¶ 20
    {PIV Card}{issuing organization} 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 preferred placement is as depicted in Figure 4-6, but variable placement along the outer edge is allowed in accordance with other FIPS 201 requirements, as shown in Figure 4-8. 4.1.4.2 ¶ 2
    {pre-determined and authorized location} If used, the department or agency SHALL place the cardholder un">signature below the photograph and cardholder name, as depicted in Figure 4-3. The space for the signature SHALL NOT interfere with the placement of the ICCs and related components. Because of card surface space constraints, placement of a signature may limit the size of the optional two-dimensional bar code. 4.1.4.3 ¶ 3
    {PIV Card}{issuing organization} 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 preferred placement is as depicted in Figure 4-6, but variable placement along the outer edge is allowed in accordance with other FIPS 201 requirements, as shown in Figure 4-8. 4.1.4.2 ¶ 2
    {PIV Card} Color-coding SHALL be used for additional identification of employee pan style="background-color:#F0BBBC;" class="term_primary-noun">affiliation as a background color for Zone 2F (name) as depicted in Figure 4-1, Figure 4-3, and Figure 4-4. The following color scheme SHALL be used: 4.1.4.1 ¶ 15
    {PIV Card}{appropriate format}{approved font} The card expiration date SHALL be printed on the card as depicted in Figure 4-1. The card expiration date SHALL be in a YYYYMMMDD format. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 14F expiration date SHALL be printed in 6 pt to 9 pt Arial Bold. 4.1.4.1 ¶ 13
    {PIV Card}{appropriate format}{approved font} The card expiration date SHALL be printed on the card as depicted in Figure 4-1. The card expiration date SHALL be in a YYYYMMMDD format. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 14F expiration date SHALL be printed in 6 pt to 9 pt Arial Bold. 4.1.4.1 ¶ 13
    {PIV Card}{appropriate format}{approved font} The card expiration date SHALL be pan style="background-color:#B7D8ED;" class="term_primary-verb">printed on the card as depicted in Figure 4-1. The card expiration date SHALL be in a YYYYMMMDD format. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. The Zone 14F expiration date SHALL be printed in 6 pt to 9 pt Arial Bold. 4.1.4.1 ¶ 13
    {PIV Card}{pre-determined and authorized location} If used, the cardholder’s rank SHALL be "term_primary-verb">printed in the area, as illustrated in Figure 4-2. Data format is at the department or agency’s discretion. 4.1.4.3 ¶ 7
    {issuing organization}{pre-determined and authorized location}{be visible} The Agency seal in Zone 11F may become a mandatory field in the next revision of the Standard. If used, the class="term_primary-noun">seal selected by the issuing department, agency, or organization SHALL be n style="background-color:#B7D8ED;" class="term_primary-verb">printed in the area depicted. It SHALL be printed using the guidelines provided in Figure 4-2 to ensure that information printed on the seal is legible and clearly visible. 4.1.4.3 ¶ 13
    {appropriate format} If the PIV Card is used to identify a federal emergency response official, a department or agency SHALL priondary-verb">nt> “Federal Emergency Response Official” as depicted in Figure 4-2. The label SHOULD be in white lettering on a red background. Additional information regarding the federal emergency responder role MAY be included in Zone 9F, as depicted in Figure 4-2. 4.1.4.3 ¶ 15
    {approved font} The organizational affiliation abbreviation MAY be printed in the upper right-hand corner below the Zone 19F expiration date as shown in Figure 4-2. If printed, the organizational affiliation abbreviation SHALL be printed in 12 pt Arial Bold. 4.1.4.3 ¶ 25
    {appropriate format} If the PIV Card is used to identify a federal emergency response official, a department or agency SHALL print “Federal Emergency Response Official” as depicted in Figure 4-2. The label SHOULD be in white lettering on a red background. Additional information regarding the federal emergency responder role MAY be included in Zone 9F, as depicted in Figure 4-2. 4.1.4.3 ¶ 15
    If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 29
    {header} If used, the text “United States Government” SHALL be ="background-color:#B7D8ED;" class="term_primary-verb">placed
    as depicted in Figure 4-3, Figure 4-4, and Figure 4-5. Departments and agencies MAY instead use this zone for other department or agency-specific information, such as identifying a federal emergency responder role, as depicted in Figure 4-2. Some examples of official roles are “Law Enforcement,” “Fire Fighter,” and “Emergency Response Team (ERT).” 4.1.4.3 ¶ 11
    {appropriate format} A CHUID MAY also include a Cardholder UUID that represents a persistent identifier of the cardholder, as specified in [SP 800-73]. The value of the cardholder UUID SHALL _primary-verb">be
    the 16 byte binary representation of a valid UUID, as specified in [RFC 4122]. 4.2.1 ¶ 3
    {issuer identification number}{appropriate format} This item SHALL be printed as depicted in Figure 4-6 and consist of six characters for the department code, four characters for the agency code, and a five-digit number that uniquely identifies the issuing facility within the department or agency. 4.1.4.2 ¶ 4]
    Systems design, build, and implementation Process or Activity
    Define the data elements to be stored on identification cards or badges in the identification card or badge architectural designs. CC ID 15427
    [The two mandatory fingerprints SHALL be used for the preparation of biometric templates to be stored on the PIV Card as described in Section 4.2.3.1. The fingerprints provide an interoperable authentication mechanism through an off-card comparison scheme (BIO or BIO-A) as described in Section 6.2.1. These fingerprints are also the primary means of authentication during PIV issuance and maintenance processes. 2.5 ¶ 2
    {not meet} 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 templates, as specified in [SP 800-76]. 4.2.3.1 ¶ 1 Bullet 1
    {not meet} 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 templates, as specified in [SP 800-76]. 4.2.3.1 ¶ 1 Bullet 1
    The following biometric data SHALL be stored on the PIV Card: An electronic facial image. 4.2.3.1 ¶ 1 Bullet 2
    All biometric data SHALL be stored in the data elements referenced by [SP 800-73] and in conformance with the preparation and formatting specifications of [SP 800-76]. 4.2.3.1 ¶ 3
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder’s identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: 4.2 ¶ 2
    {unsuccessful access attempts} 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 across departments and agencies. Other card activation mechanisms as specified in [SP 800-73] (e.g., OCC card activation) MAY be implemented and SHALL be discoverable. For PIN-based cardholder activation, the cardholder SHALL supply a numeric PIN. The PIN SHALL be transmitted to the PIV Card and checked by the card. If the PIN check is successful, the PIV Card is activated. The PIV Card SHALL include mechanisms to block activation of the card after a number of consecutive failed activation attempts. A maximum of 10 consecutive PIN retries SHALL be permitted unless a lower limit is imposed by the department or agency. 4.3.1 ¶ 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: a PIN, 4.2 ¶ 2 Bullet 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: PIV authentication data (one asymmetric private key and corresponding certificate), 4.2 ¶ 2 Bullet 2
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: two fingerprint biometric templates, 4.2 ¶ 2 Bullet 4
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: card authentication data (one asymmetric private key and corresponding certificate), 4.2 ¶ 2 Bullet 3
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. Section 5 of this document specifies the certificate format and the key management infrastructure for key management keys. 4.2.2.5 ¶ 2
    {applicable requirements} Agencies MAY choose to collect electronic iris images as an additional biometric characteristic. If collected, the electronic iris images SHALL be stored on the PIV Card as described in Section 4.2.3.1. The images MAY be used for cardholder authentication (BIO or BIO-A) as described in Section 6.2.1. Electronic iris images are an additional means of authentication during PIV issuance and maintenance processes. 2.5 ¶ 4
    {applicable requirements} {biometric authentication} The electronic facial image SHALL be stored on the PIV Card as described in Section 4.2.3.1. It SHALL be printed on the PIV Card according to Section 4.1.4.1. The image MAY be used for cardholder authentication (BIO or BIO-A) as described in Section 6.2.1. It MAY be retrieved and displayed on guard workstations to augment other authentication processes from Section 6.2. The electronic facial image is an additional means of authentication during PIV issuance and maintenance processes when used with an automated facial comparison algorithm. 2.5 ¶ 5
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    All biometric data SHALL be stored in the data elements referenced by [SP 800-73] and in conformance with the preparation and formatting specifications of [SP 800-76]. 4.2.3.1 ¶ 3
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for PIV digital signature keys. 4.2.2.4 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the SAN extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a URN, as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for asymmetric card authentication keys. 4.2.2.2 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. Section 5 of this document specifies the certificate format and the key management infrastructure for PIV digital signature keys. 4.2.2.4 ¶ 2
    A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. 4.1.2 ¶ 8
    A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. A PIV Card SHALL incorporate at least one security feature at inspection level 1 or inspection level 2. Federal departments and agencies SHOULD incorporate additional security features and include all three inspection levels. 4.1.2 ¶ 8
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17
    The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder rb">does not have a government-issued email account at the time of PIV Card issuance. The PIV Card SHALL store private keys and corresponding public key certificates and SHALL perform cryptographic operations using the asymmetric private keys. At a minimum, the PIV Card SHALL store the PIV authentication key, the asymmetric card authentication key, and the corresponding public key certificates. The PIV Card SHALL also store a digital signature key, a key management key, and the corresponding public key certificates unless the cardholder does not have a government-issued email account at the time of PIV Card issuance. 4.2.2 ¶ 17]
    Systems design, build, and implementation Systems Design, Build, and Implementation
    Define the optional items that may appear on identification cards or badges in the identification card or badge architectural designs. CC ID 06594
    [{applicable requirements} When Zone 15F indicates foreign national affiliation and the department or agency does not need to highlight emergency response official status, Zone 12F MAY be used to denote the country or countries of citizenship. If so used, the department or agency SHALL le="background-color:#B7D8ED;" class="term_primary-verb">printpan> the country name or the three-letter country abbreviation (alpha3 format) in accordance with [ISO 3166]. Figure 4-4 illustrates an example of using country abbreviations for a card issued to a foreign national. 4.1.4.3 ¶ 16
    {appropriate format} If used, the card issuance date SHALL be printed above the Zone 14F expiration date in YYYYMMMDD format, as depicted in Figure 4-3. The YYYY characters represent the four-digit year; the DD characters represent the two-digit day of the month; and the MMM characters represent the three-letter month abbreviation as follows: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, and DEC. 4.1.4.3 ¶ 19
    A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. 4.1.4.3 ¶ 21
    A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. A border MAY be used with the photograph to further identify employee affiliation, as depicted in Figure 4-3. This border MAY be used in conjunction with Zone 15F to enable departments and agencies to develop various employee categories. The photograph border SHALL NOT obscure the photograph. The border MAY be a solid or patterned line. For solid and patterned lines the following colors SHALL be reserved: red for emergency response officials, blue for foreign nationals, and green for contractors. All other colors MAY be used at the department or agency’s discretion. 4.1.4.3 ¶ 21
    If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. If used, tactilely discernible marks SHALL be created using laser engraving to indicate card orientation, as depicted in Figure 4-4. There SHALL be an opening in the lamination foil where laser engraving is performed. Departments and agencies SHOULD closely coordinate such alterations with the card vendor and manufacturer to ensure that the card material integrity and printing process are not adversely impacted. 4.1.4.3 ¶ 29
    If used, this area can be used for printing agency-specific requirements, such as employee status, as shown in Figure 4-2. Note that this zone overlaps with an area that some card manufacturers might not allow to be used for printing. If used, this area can be used for printing agency-specific requirements, such as employee status, as shown in Figure 4-2. Note that this zone overlaps with an area that some card manufacturers might not allow to be used for printing. 4.1.4.3 ¶ 5
    {PIV Card} If used, the “return if lost” language SHALL be placed on the olor:#F0BBlass="term_secondary-verb">BC;"
    class="term_primary-noun">back of the card in the general area depicted in Figure 4-7. 4.1.4.4 ¶ 4
    {PIV Card} If used, the cardholder physical characteristics (e.g., height, eye color, hair color) SHALL be class="term_primary-verb">printed in the general area illustrated in Figure 4-7. 4.1.4.4 ¶ 6
    {PIV Card}{be necessary} In cases in which other defined optional elements are not used, these zones MAY be used for other department or agency-specific information, as depicted in Figure 4-8. Departments and agencies SHOULD style="background-color:#B7D8ED;" class="term_primary-verb">minimize printed >textspan> to that which is absolutely necessary. 4.1.4.4 ¶ 14
    {PIV Card}{reserved area}{machine-readable information} Departments and agencies MAY choose to provide additional information to identify emergency response officials or to better identify the cardholder’s authorized access. If used, this additional text SHALL round-color:#B7D8ED;" class="term_primary-verb">be
    in the general area depicted in Figure 4-7 and SHALL NOT interfere with other printed text or machine-readable components. An example of a printed statement is provided in Figure 4-7. 4.1.4.4 ¶ 8
    If used, standard Section 499, Title 18, language warning against counterfeiting, altering, or misusing the card SHALL be printed in the general yle="background-color:#F0BBBC;" class="term_primary-noun">area depicted in Figure 4-7. If used, standard Section 499, Title 18, language warning against counterfeiting, altering, or misusing the card SHALL be printed in the general area depicted in Figure 4-7. 4.1.4.4 ¶ 10]
    Systems design, build, and implementation Process or Activity
    Include security measures in the identification card or badge architectural designs. CC ID 15423
    [All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces 4.2.2 ¶ 19]
    Systems design, build, and implementation Systems Design, Build, and Implementation
    Include the logical credential data model for identification cards or badges in the identification card or badge architectural designs. CC ID 06595
    [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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    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 additionally be available over the virtual contact interface of the PIV Card. Operations that use the PIV authentication key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.1 ¶ 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: a Cardholder Unique Identifier (CHUID). 4.2 ¶ 2 Bullet 6
    A new PIV authentication certificate and a new card authentication certificate SHALL be generated. The corresponding certificates SHALL be populated with the new FASCN and card UUID. For cardholders with government-issued email accounts, the digital signature and key management keys and associated certificates SHALL be populated. A new digital signature key and associated certificate SHALL be generated on the new PIV Card, while key management keys and associated certificates MAY be imported to the new PIV Card. 2.9.1 ¶ 8
    A new PIV authentication certificate and a new card authentication certificate SHALL be generated. The corresponding certificates SHALL be populated with the new FASCN and card UUID. For cardholders with government-issued email accounts, the digital signature and key management keys and associated certificates SHALL be populated. A new digital signature key and associated certificate SHALL be generated on the new PIV Card, while key management keys and associated certificates MAY be imported to the new PIV Card. 2.9.1 ¶ 8
    A new PIV authentication certificate and a new card authentication certificate SHALL be generated. The corresponding certificates SHALL be populated with the new FASCN and card UUID. For cardholders with government-issued email accounts, the digital signature and key management keys and associated certificates SHALL be populated. A new digital signature key and associated certificate SHALL be generated on the new PIV Card, while key management keys and associated certificates MAY be imported to the new PIV Card. 2.9.1 ¶ 8
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL store a corresponding X.509 certificate to support validation of the public key. The X.509 certificate SHALL include the FASC-N in the Subject Alternative Name (SAN) extension using the pivFASC-N attribute to support physical access procedures. The X.509 certificate SHALL also include the card UUID value from the GUID data element of the CHUID in the SAN extension. The card UUID SHALL be encoded as a Uniform Resource Name (URN), as specified in Section 3 of [RFC 4122]. The expiration date of the certificate SHALL be no later than the expiration date of the PIV Card. The PIV authentication certificate MAY include a PIV background investigation indicator (previously known as the NACI indicator) extension (see Appendix B.2). This non-critical extension indicates the status of the cardholder’s background investigation at the time of card issuance. Section 5 of this document specifies the certificate format and the key management infrastructure for the PIV authentication key. 4.2.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    The PIV Card SHALL include the CHUID, as defined in [SP 800-73]. The CHUID SHALL include two card identifiers: the Federal Agency Smart Credential Number (FASC-N) and the card UUID in the Global Unique Identification Number (GUID) data element of the CHUID. Each identifier uniquely identifies each card as specified in [SP 800-73]. The value of the card UUID SHALL be the 16 byte binary representation of a valid UUID as specified in [RFC 4122]. The CHUID SHALL also include an expiration date data element in machine-readable format that specifies when the card expires. The expiration date format and encoding rules are as specified in [SP 800-73]. 4.2.1 ¶ 2
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    {unless} 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 through the contact interface and MAY additionally be available over the virtual contact interface of the PIV Card. Operations that use the digital signature key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations SHALL NOT be performed without explicit user action, as this Standard requires the cardholder to authenticate to the PIV Card each time it performs a private key computation with the digital signature key. 4.2.2.4 ¶ 1
    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 contact interface of the PIV Card. Operations that use the key management key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.5 ¶ 1
    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 contact interface of the PIV Card. Operations that use the key management key SHALL NOT be available through the contactless interface of the PIV Card. Private key operations MAY be performed using an activated PIV Card without explicit user action (e.g., the PIN need not be supplied for each operation). 4.2.2.5 ¶ 1
    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 interface unless otherwise specified by [SP 800-73]. 4.2.2.6 ¶ 1
    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 interface unless otherwise specified by [SP 800-73]. 4.2.2.6 ¶ 1
    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 and appended with the CBEFF signature block [NISTIR 6529-A]. 4.2.3.2 ¶ 1
    The PIV Card SHALL be activated to perform privileged 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 authenticating the cardholder or the appropriate card management system. Cardholder activation is described in Section 4.3.1 and card management system activation is described in Section 4.3.2. 4.3 ¶ 1
    The PIV Card SHALL be activated to perform privileged 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 authenticating the cardholder or the appropriate card management system. Cardholder activation is described in Section 4.3.1 and card management system activation is described in Section 4.3.2. 4.3 ¶ 1
    To support a variety of authentication mechanisms, the PIV Card SHALL contain multiple data elements for the purpose of verifying the cardholder's identity at graduated assurance levels. The following mandatory data elements are part of the data model for PIV Card logical credentials that support authentication mechanisms that are interoperable across agencies: an electronic facial image, and 4.2 ¶ 2 Bullet 5
    This Standard also defines two data elements for the PIV Card data model that are mandatory if the cardholder has a government-issued email account at the time of PIV Card issuance. These data elements are an asymmetric private key and corresponding certificate for key management. 4.2 ¶ 3 Bullet 2
    The expiration date of the PIV authentication and card authentication certificates SHALL NOT be after the expiration date of the PIV Card. The expiration date of the PIV Card is printed on the card in Zone 14F (see Section 4.1.4) and is contained in the CHUID data object (see Section 4.2.1). If the card is revoked, the PIV authentication and card authentication certificates SHALL be revoked in cases where the card cannot be collected and destroyed. However, a PIV authentication or card authentication certificate MAY be revoked and subsequently replaced without revoking the PIV Card. The presence of a valid, unexpired, and unrevoked authentication certificate on a card is sufficient proof that the card was issued and is not revoked. 5.2.1 ¶ 2
    The expiration date of the PIV authentication and card authentication certificates SHALL NOT be after the expiration date of the PIV Card. The expiration date of the PIV Card is printed on the card in Zone 14F (see Section 4.1.4) and is contained in the CHUID data object (see Section 4.2.1). If the card is revoked, the PIV authentication and card authentication certificates SHALL be revoked in cases where the card cannot be collected and destroyed. However, a PIV authentication or card authentication certificate MAY be revoked and subsequently replaced without revoking the PIV Card. The presence of a valid, unexpired, and unrevoked authentication certificate on a card is sufficient proof that the card was issued and is not revoked. 5.2.1 ¶ 2
    All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces 4.2.2 ¶ 19
    All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces All PIV cryptographic keys SHALL be generated within a cryptographic module with overall validation at [FIPS 140] Level 2 or above. In addition to an overall validation of Level 2, the PIV Card SHALL provide Level 3 physical security to protect the PIV private keys in storage. The scope of the validation for the PIV Card SHALL include all cryptographic operations performed over both the contact and contactless interfaces 4.2.2 ¶ 19]
    Systems design, build, and implementation Process or Activity
    Establish, implement, and maintain a privacy framework that protects restricted data. CC ID 11850 Privacy protection for information and data Establish/Maintain Documentation
    Establish, implement, and maintain a personal data transparency program. CC ID 00375 Privacy protection for information and data Data and Information Management
    Establish and maintain privacy notices, as necessary. CC ID 13443 Privacy protection for information and data Establish/Maintain Documentation
    Include the types of third parties to which personal data is disclosed in the privacy notice. CC ID 13459
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Establish/Maintain Documentation
    Include the organization's policies, standards, and procedures in the privacy notice. CC ID 13455 Privacy protection for information and data Establish/Maintain Documentation
    Include the organization's privacy framework in the privacy notice, as necessary. CC ID 13456
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Establish/Maintain Documentation
    Include the types of personal data disclosed in the privacy notice. CC ID 13446
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Establish/Maintain Documentation
    Include descriptions of each type of personal data disclosed in the privacy notice. CC ID 13458 Privacy protection for information and data Establish/Maintain Documentation
    Provide adequate structures, policies, procedures, and mechanisms to support direct access by the data subject to personal data that is provided upon request. CC ID 00393 Privacy protection for information and data Establish/Maintain Documentation
    Provide the data subject with references to the appropriate safeguards used to protect the privacy of personal data. CC ID 12585 Privacy protection for information and data Process or Activity
    Provide the data subject with copies of the appropriate safeguards used to protect the privacy of personal data. CC ID 12608
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Provide PIV applicants with full disclosure of the intended uses of the information associated with the PIV Card and the related privacy implications. 2.11 ¶ 3 Bullet 4]
    Privacy protection for information and data Process or Activity
    Provide the data subject with a description of the type of information held by the organization and a general account of its use. CC ID 00397
    [{parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3
    {parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Establish/Maintain Documentation
    Establish, implement, and maintain a personal data accountability program. CC ID 13432 Privacy protection for information and data Establish/Maintain Documentation
    Assign ownership of the privacy program to the appropriate organizational role. CC ID 11848
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Assign an individual to the role of privacy official. The privacy official is the individual who oversees privacy-related matters in the PIV system and is responsible for implementing the privacy requirements in the Standard. The individual serving in this role SHALL NOT assume any other operational role in the PIV system. 2.11 ¶ 3 Bullet 1]
    Privacy protection for information and data Human Resources Management
    Establish, implement, and maintain a personal data use limitation program. CC ID 13428 Privacy protection for information and data Establish/Maintain Documentation
    Establish, implement, and maintain a personal data use purpose specification. CC ID 00093 Privacy protection for information and data Establish/Maintain Documentation
    Notify the data subject of the collection purpose. CC ID 00095
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Provide PIV applicants with full disclosure of the intended uses of the information associated with the PIV Card and the related privacy implications. 2.11 ¶ 3 Bullet 4
    {parties}To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Write, publish, and maintain a clear and comprehensive document listing the types of information that will be collected (e.g., transactional information, PII), the purpose of collection, what information may be disclosed to whom during the life of the credential, how the information will be protected, and the complete set of uses of the credential and related information at the department or agency. 2.11 ¶ 3 Bullet 3]
    Privacy protection for information and data Behavior
    Refrain from using restricted data collected for research and statistics for other purposes. CC ID 00096 Privacy protection for information and data Data and Information Management
    Establish, implement, and maintain restricted data use limitation procedures. CC ID 00128 Privacy protection for information and data Establish/Maintain Documentation
    Process restricted data lawfully and carefully. CC ID 00086
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that systems that contain PII for the purpose of enabling the implementation of PIV are handled in full compliance with fair information practices, as defined in [PRIVACY]. 2.11 ¶ 3 Bullet 5]
    Privacy protection for information and data Establish Roles
    Implement technical controls that limit processing restricted data for specific purposes. CC ID 12646 Privacy protection for information and data Technical Security
    Process personal data pertaining to a patient's health in order to treat those patients. CC ID 00200 Privacy protection for information and data Data and Information Management
    Refrain from disclosing Individually Identifiable Health Information when in violation of territorial or federal law. CC ID 11966 Privacy protection for information and data Records Management
    Document the conditions for the use or disclosure of Individually Identifiable Health Information by a covered entity to another covered entity. CC ID 00210 Privacy protection for information and data Establish/Maintain Documentation
    Disclose Individually Identifiable Health Information for a covered entity's own use. CC ID 00211 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information for a healthcare provider's treatment activities by a covered entity. CC ID 00212 Privacy protection for information and data Data and Information Management
    Rely upon the warranty of the covered entity that the record disclosure request for Individually Identifiable Health Information is permitted with the consent of the data subject. CC ID 11970 Privacy protection for information and data Records Management
    Rely upon the warranty of the covered entity that the record disclosure request for Individually Identifiable Health Information is to support the treatment of the individual. CC ID 11969 Privacy protection for information and data Process or Activity
    Rely upon the warranty of the covered entity that the record disclosure request for Individually Identifiable Health Information is permitted by law. CC ID 11976 Privacy protection for information and data Records Management
    Disclose Individually Identifiable Health Information for payment activities between covered entities or healthcare providers. CC ID 00213 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information for Treatment, Payment, and Health Care Operations activities when both covered entities have a relationship with the data subject. CC ID 00214 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information for Treatment, Payment, and Health Care Operations activities between a covered entity and a participating healthcare provider when the information is collected from the data subject and a third party. CC ID 00215 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information in accordance with agreed upon restrictions. CC ID 06249 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information in accordance with the privacy notice. CC ID 06250 Privacy protection for information and data Data and Information Management
    Disclose permitted Individually Identifiable Health Information for facility directories. CC ID 06251 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information for cadaveric organ donation purposes, eye donation purposes, or tissue donation purposes. CC ID 06252 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information for medical suitability determinations. CC ID 06253 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information for armed forces personnel appropriately. CC ID 06254 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information in order to provide public benefits by government agencies. CC ID 06255 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information for fundraising. CC ID 06256 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information for research use when the appropriate requirements are included in the approval documentation or waiver documentation. CC ID 06257 Privacy protection for information and data Establish/Maintain Documentation
    Document the conditions for the disclosure of Individually Identifiable Health Information by an organization providing healthcare services to organizations other than business associates or other covered entities. CC ID 00201 Privacy protection for information and data Establish/Maintain Documentation
    Disclose Individually Identifiable Health Information when the data subject cannot physically or legally provide consent and the disclosing organization is a healthcare provider. CC ID 00202 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information to provide appropriate treatment to the data subject when the disclosing organization is a healthcare provider. CC ID 00203 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information when it is not contrary to the data subject's wish prior to becoming unable to provide consent and the disclosing organization is a healthcare provider. CC ID 00204 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information that is reasonable or necessary for the disclosure purpose when the disclosing organization is a healthcare provider. CC ID 00205 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information consistent with the law when the disclosing organization is a healthcare provider. CC ID 00206 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information in order to carry out treatment when the disclosing organization is a healthcare provider. CC ID 00207 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information in order to carry out treatment when the data subject has provided consent and the disclosing organization is a healthcare provider. CC ID 00208 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information in order to carry out treatment when the data subject's guardian or representative has provided consent and the disclosing organization is a healthcare provider. CC ID 00209 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information when the disclosing organization is a healthcare provider that supports public health and safety activities. CC ID 06248 Privacy protection for information and data Data and Information Management
    Disclose Individually Identifiable Health Information in order to report abuse or neglect when the disclosing organization is a healthcare provider. CC ID 06819 Privacy protection for information and data Data and Information Management
    Document how Individually Identifiable Health Information is used and disclosed when authorization has been granted. CC ID 00216 Privacy protection for information and data Establish/Maintain Documentation
    Define and implement valid authorization control requirements. CC ID 06258 Privacy protection for information and data Establish/Maintain Documentation
    Obtain explicit consent for authorization to release Individually Identifiable Health Information. CC ID 00217 Privacy protection for information and data Data and Information Management
    Obtain explicit consent for authorization to release psychotherapy notes. CC ID 00218 Privacy protection for information and data Data and Information Management
    Refrain from using Individually Identifiable Health Information to determine eligibility or continued eligibility for credit. CC ID 00219 Privacy protection for information and data Data and Information Management
    Process personal data after the data subject has granted explicit consent. CC ID 00180 Privacy protection for information and data Data and Information Management
    Process personal data in order to perform a legal obligation or exercise a legal right. CC ID 00182 Privacy protection for information and data Data and Information Management
    Process personal data relating to criminal offenses when required by law. CC ID 00237 Privacy protection for information and data Data and Information Management
    Process personal data in order to prevent personal injury or damage to the data subject's health. CC ID 00183 Privacy protection for information and data Data and Information Management
    Process personal data in order to prevent personal injury or damage to a third party's health. CC ID 00184 Privacy protection for information and data Data and Information Management
    Process personal data for statistical purposes or scientific purposes. CC ID 00256 Privacy protection for information and data Data and Information Management
    Process personal data during legitimate activities with safeguards for the data subject's legal rights. CC ID 00185 Privacy protection for information and data Data and Information Management
    Process traffic data in a controlled manner. CC ID 00130 Privacy protection for information and data Data and Information Management
    Process personal data for health insurance, social insurance, state social benefits, social welfare, or child protection. CC ID 00186 Privacy protection for information and data Data and Information Management
    Process personal data when it is publicly accessible. CC ID 00187 Privacy protection for information and data Data and Information Management
    Process personal data for direct marketing and other personalized mail programs. CC ID 00188 Privacy protection for information and data Data and Information Management
    Refrain from processing personal data for marketing or advertising to children. CC ID 14010 Privacy protection for information and data Business Processes
    Process personal data for the purposes of employment. CC ID 16527 Privacy protection for information and data Data and Information Management
    Process personal data for justice administration, lawsuits, judicial decisions, and investigations. CC ID 00189 Privacy protection for information and data Data and Information Management
    Process personal data for debt collection or benefit payments. CC ID 00190 Privacy protection for information and data Data and Information Management
    Process personal data in order to advance the public interest. CC ID 00191 Privacy protection for information and data Data and Information Management
    Process personal data for surveys, archives, or scientific research. CC ID 00192 Privacy protection for information and data Data and Information Management
    Process personal data absent consent for journalistic purposes, artistic purposes, or literary purposes. CC ID 00193 Privacy protection for information and data Data and Information Management
    Process personal data for academic purposes or religious purposes. CC ID 00194 Privacy protection for information and data Data and Information Management
    Process personal data when it is used by a public authority for National Security policy or criminal policy. CC ID 00195 Privacy protection for information and data Data and Information Management
    Refrain from storing data in newly created files or registers which directly or indirectly reveals the restricted data. CC ID 00196 Privacy protection for information and data Data and Information Management
    Follow legal obligations while processing personal data. CC ID 04794 Privacy protection for information and data Data and Information Management
    Start personal data processing only after the needed notifications are submitted. CC ID 04791 Privacy protection for information and data Data and Information Management
    Establish, implement, and maintain restricted data retention procedures. CC ID 00167
    [PIV background investigation, identity proofing, registration, and issuance processes MAY be performed across multiple sessions at different facilities. If multiple sessions are needed, the applicant SHALL be linked through a positive biometric verification decision obtained from an automated comparison of biometric characteristics captured at a previous session to biometric characteristics captured during the current session. Issuers SHALL follow applicable federal laws and regulations regarding the retention and destruction of biometric data. 2.5 ¶ 6]
    Privacy protection for information and data Establish/Maintain Documentation
    Establish, implement, and maintain personal data disposition procedures. CC ID 13498
    [PIV background investigation, identity proofing, registration, and issuance processes MAY be performed across multiple sessions at different facilities. If multiple sessions are needed, the applicant SHALL be linked through a positive biometric verification decision obtained from an automated comparison of biometric characteristics captured at a previous session to biometric characteristics captured during the current session. Issuers SHALL follow applicable federal laws and regulations regarding the retention and destruction of biometric data. 2.5 ¶ 6
    {privacy policy} The PII collected from the cardholder SHALL be disposed of in accordance with the stated privacy and data retention policies of the department or agency. 2.9.4 ¶ 5]
    Privacy protection for information and data Establish/Maintain Documentation
    Capture personal data removal requests. CC ID 13507 Privacy protection for information and data Communicate
    Remove personal data from records after receiving a personal data removal request. CC ID 11972 Privacy protection for information and data Records Management
    Refrain from erasing personal data upon receiving a personal data removal request when it is necessary for maintaining information assets. CC ID 13789 Privacy protection for information and data Process or Activity
    Refrain from erasing personal data upon receiving a personal data removal request when it is necessary to complete a payment transaction. CC ID 13788 Privacy protection for information and data Process or Activity
    Establish, implement, and maintain a personal data collection program. CC ID 06487 Privacy protection for information and data Establish/Maintain Documentation
    Establish, implement, and maintain personal data collection limitation boundaries. CC ID 00507 Privacy protection for information and data Establish/Maintain Documentation
    Manage Personal Identification Numbers and PIN verification code numbers. CC ID 00058
    [The remote PIN reset operation SHALL satisfy the requirements for remote, postissuance updates specified in Section 2.9.2. The remote PIN reset operation SHALL satisfy the requirements for remote, postissuance updates specified in Section 2.9.2. 2.9.3.1 ¶ 10
    Remote PIN reset on a general computing platform (e.g., desktop, laptop) SHALL only be performed if all the following requirements are met: The cardholder initiates a ;" class="term_primary-noun">PIN reset with the issuer operator. 2.9.3.1 ¶ 9 Bullet 1
    Remote PIN reset on a general computing platform (e.g., desktop, laptop) SHALL only be performed if all the following requirements are met: The operator authenticates the owner of the round-color:#F0BBBC;" class="term_primary-noun">PIV Card through an background-color:#F0BBBC;" class="term_primary-noun">independent procedure, for example by authenticating the cardholder with an associated derived PIV credential or by confirming reset via email to the on-record government-issued email address. 2.9.3.1 ¶ 9 Bullet 2
    {appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is D8ED;" class="term_primary-verb">authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT reset the PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5
    {appear in person} PIN reset at an issuer-operated kiosk SHALL ensure that the PIV Card is authenticated and that the cardholder's biometric characteristics elicit a positive biometric verification decision when compared to biometric data records stored in the PIV enrollment record or when compared to the biometric data records on the PIV Card using the OCC-AUTH authentication mechanism. In cases where a negative biometric verification decision is returned, the cardholder's biometric characteristics are not successfully acquired, or card authentication is unsuccessful, the kiosk SHALL NOT reset the PIV Card. The session SHALL be terminated and the PIN reset SHALL be performed in person at the issuing facility or at a supervised remote identity proofing station. The kiosk MAY be unattended while used for PIN reset operations. 2.9.3.1 ¶ 5]
    Privacy protection for information and data Data and Information Management
    Employ a random number generator to create authenticators. CC ID 13782 Privacy protection for information and data Technical Security
    Collect Personal Identification Numbers with the individual's consent. CC ID 00059 Privacy protection for information and data Data and Information Management
    Collect Personal Identification Numbers absent consent when the law mandates. CC ID 00061 Privacy protection for information and data Data and Information Management
    Collect Personal Identification Numbers absent consent for research purposes. CC ID 00065 Privacy protection for information and data Data and Information Management
    Collect Personal Identification Numbers absent consent to realize the rights or duties of the data subject or data controller. CC ID 04792 Privacy protection for information and data Data and Information Management
    Refrain from requiring a Personal Identification Number to purchase goods or services. CC ID 00069 Privacy protection for information and data Behavior
    Establish, implement, and maintain a data handling program. CC ID 13427 Privacy protection for information and data Establish/Maintain Documentation
    Establish, implement, and maintain data handling policies. CC ID 00353 Privacy protection for information and data Establish/Maintain Documentation
    Establish, implement, and maintain data and information confidentiality policies. CC ID 00361 Privacy protection for information and data Establish/Maintain Documentation
    Implement security measures to protect personal data. CC ID 13606
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Utilize security controls described in [SP 800-53] to accomplish privacy goals, where applicable. 2.11 ¶ 3 Bullet 10
    To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Ensure that the technologies used to implement PIV sustain and do not erode privacy protections relating to the use, collection, and disclosure of PII. Agencies MAY choose to deploy PIV Cards with electromagnetically opaque holders or other technology to protect against any unauthorized contactless access to information stored on a PIV Card. 2.11 ¶ 3 Bullet 11]
    Privacy protection for information and data Technical Security
    Establish, implement, and maintain a privacy impact assessment. CC ID 13712
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Conduct a comprehensive Privacy Impact Assessment (PIA) and a periodic review and update of the assessment on systems containing PII for the purpose of implementing PIV consistent with the methodology of [E-Gov] and the requirements of [M-03-22]. Consult with appropriate personnel responsible for privacy issues at the department or agency (e.g., Chief Information Officer) implementing the PIV system. 2.11 ¶ 3 Bullet 2
    To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Conduct a comprehensive Privacy Impact Assessment (PIA) and a periodic review and update of the assessment on systems containing PII for the purpose of implementing PIV consistent with the methodology of [E-Gov] and the requirements of [M-03-22]. Consult with appropriate personnel responsible for privacy issues at the department or agency (e.g., Chief Information Officer) implementing the PIV system. 2.11 ¶ 3 Bullet 2]
    Privacy protection for information and data Establish/Maintain Documentation
    Include the individuals with whom information is shared in the privacy impact assessment. CC ID 15520 Privacy protection for information and data Establish/Maintain Documentation
    Include how to grant consent in the privacy impact assessment. CC ID 15519 Privacy protection for information and data Establish/Maintain Documentation
    Include the opportunities for individuals to consent to using their information in the privacy impact assessment. CC ID 15518 Privacy protection for information and data Establish/Maintain Documentation
    Include the opportunities for opting out of information collection in the privacy impact assessment. CC ID 15517 Privacy protection for information and data Establish/Maintain Documentation
    Include data handling procedures in the privacy impact assessment. CC ID 15516 Privacy protection for information and data Establish/Maintain Documentation
    Include the intended use of information in the privacy impact assessment. CC ID 15515 Privacy protection for information and data Establish/Maintain Documentation
    Include the reason information is being collected in the privacy impact assessment. CC ID 15514 Privacy protection for information and data Establish/Maintain Documentation
    Include the type of information to be collected in the privacy impact assessment. CC ID 15513 Privacy protection for information and data Business Processes
    Disseminate and communicate the results of the Privacy Impact Assessment to interested personnel and affected parties. CC ID 15458 Privacy protection for information and data Communicate
    Develop remedies and sanctions for privacy policy violations. CC ID 00474
    [To ensure privacy throughout the PIV lifecycle, departments and agencies SHALL do the following: Coordinate with appropriate department or agency officials to define consequences for violating privacy policies of the PIV system. 2.11 ¶ 3 Bullet 8]
    Privacy protection for information and data Data and Information Management
    Define the behaviors and actions that are included in privacy rights violations. CC ID 14852 Privacy protection for information and data Behavior
    Include the individual's name who is the subject of the complaint in the privacy rights violation complaint. CC ID 14359 Privacy protection for information and data Establish/Maintain Documentation
    Refrain from charging a fee to file a privacy rights violation complaint. CC ID 16807 Privacy protection for information and data Business Processes
    Refrain from updating personal data on a regular basis, unless it is necessary for the purposes it was collected. CC ID 13610 Privacy protection for information and data Data and Information Management
    Establish, implement, and maintain a privacy dispute resolution program. CC ID 12526 Privacy protection for information and data Establish/Maintain Documentation
    Include potential remedies in the privacy dispute resolution program. CC ID 12531 Privacy protection for information and data Establish/Maintain Documentation
    Provide the data subject with the name, title, and address to whom complaints are forwarded. CC ID 00395 Privacy protection for information and data Establish/Maintain Documentation
    Include the time frames in which privacy rights violation complaints are processed in the privacy dispute resolution program. CC ID 12529 Privacy protection for information and data Establish/Maintain Documentation
    Document unresolved challenges. CC ID 13568 Privacy protection for information and data Establish/Maintain Documentation
    Establish, implement, and maintain an accuracy resolution policy. CC ID 00460 Privacy protection for information and data Establish/Maintain Documentation
    Notify individuals of their right to challenge personal data. CC ID 00457 Privacy protection for information and data Data and Information Management
    Notify individuals of their right to object to personal data for legitimate reasons. CC ID 00458 Privacy protection for information and data Data and Information Management
    Terminate an individual's restriction agreement under specific circumstances. CC ID 06260 Privacy protection for information and data Configuration
    Notify individuals of their ability to challenge personal behavioral assessments on record. CC ID 04798 Privacy protection for information and data Human Resources Management
    Notify individuals of their ability to object to personal data processing, absent cost. CC ID 00459 Privacy protection for information and data Data and Information Management
    Investigate the disputed accuracy of personal data. CC ID 00461 Privacy protection for information and data Data and Information Management
    Notify third parties of unresolved challenges. CC ID 13559 Privacy protection for information and data Communicate
    Document disagreements as to whether personal data is complete and accurate. CC ID 06952 Privacy protection for information and data Establish/Maintain Documentation
    Include the change to the personal data that the data subject requested and the reason the organization refused to make the change in the statement of disagreement. CC ID 06954 Privacy protection for information and data Establish/Maintain Documentation
    Include the allegations against the organization in the notice of investigation. CC ID 13031 Privacy protection for information and data Establish/Maintain Documentation
    Refer privacy rights violation complaints to the Privacy Commissioner under certain conditions. CC ID 00481 Privacy protection for information and data Behavior
    Determine not to investigate privacy rights violation complaints under certain conditions. CC ID 00482 Privacy protection for information and data Behavior
    Refrain from investigating a privacy rights violation complaint when the act or practice does not interfere with an individual's privacy. CC ID 00483 Privacy protection for information and data Behavior
    Refrain from investigating a privacy rights violation complaint when the complaint is created outside the stipulated time frame after the complainant became aware of it. CC ID 00484 Privacy protection for information and data Behavior
    Refrain from investigating a privacy rights violation complaint when the complaint is frivolous, vexatious, misconceived, or lacking in substance. CC ID 00485 Privacy protection for information and data Behavior
    Refrain from investigating a privacy rights violation complaint if the act or practice is subject to an application under another commonwealth law, state law, or territory law, and the complaint was or is being dealt with adequately under the law. CC ID 00486 Privacy protection for information and data Behavior
    Defer privacy rights violation complaint investigations under certain conditions. CC ID 00487 Privacy protection for information and data Behavior
    Defer privacy rights violation complaint investigations when the respondent has made an application for a determination. CC ID 00488 Privacy protection for information and data Behavior
    Defer privacy rights violation complaint investigations when the Privacy Commissioner believes the data subject's interests would not be affected if the investigation or further investigation were deferred until the application was disposed of. CC ID 00489 Privacy protection for information and data Behavior
    Define the organization's liability based on the applicable law. CC ID 00504 Privacy protection for information and data Establish/Maintain Documentation
    Define the sanctions and fines available for privacy rights violations based on applicable law. CC ID 00505 Privacy protection for information and data Establish/Maintain Documentation
    Define the appeal process based on the applicable law. CC ID 00506 Privacy protection for information and data Establish/Maintain Documentation
    Define the fee structure for the appeal process. CC ID 16532 Privacy protection for information and data Process or Activity
    Define the time requirements for the appeal process. CC ID 16531 Privacy protection for information and data Process or Activity
    Disseminate and communicate instructions for the appeal process to interested personnel and affected parties. CC ID 16544 Privacy protection for information and data Communicate
    Disseminate and communicate a written explanation of the reasons for appeal decisions to interested personnel and affected parties. CC ID 16542 Privacy protection for information and data Communicate
    Provide notice of proposed penalties. CC ID 06216 Privacy protection for information and data Establish/Maintain Documentation
    Notify the public and other agencies after a penalty becomes final. CC ID 06217 Privacy protection for information and data Behavior
    Establish, implement, and maintain a Customer Information Management program. CC ID 00084 Privacy protection for information and data Data and Information Management
    Establish, implement, and maintain customer data authentication procedures. CC ID 13187 Privacy protection for information and data Establish/Maintain Documentation
    Check the data accuracy of new accounts. CC ID 04859 Privacy protection for information and data Data and Information Management
    Establish, implement, and maintain anti-counterfeit measures. CC ID 11522
    [{PIV Card}{anti-counterfeiting technique} All security features SHOULD maintain their function for the life of the card. As a generally accepted security procedure, federal departments and agencies SHOULD periodically review the viability, effectiveness, and currency of employed tamper resistance and anti-counterfeiting methods. 4.1.2 ¶ 10]
    Third Party and supply chain oversight Technical Security
    Establish, implement, and maintain electronic marketplace terms of service guidelines. CC ID 11523 Third Party and supply chain oversight Technical Security
    Include the prohibition of counterfeiting in the electronic marketplace terms of service guidelines. CC ID 11524 Third Party and supply chain oversight Technical Security
    Enforce the electronic marketplace terms of service guidelines. CC ID 11525 Third Party and supply chain oversight Technical Security
    Post anti-counterfeiting warnings within the electronic marketplace. CC ID 11526 Third Party and supply chain oversight Technical Security
    Establish, implement, and maintain a counterfeit product reporting system. CC ID 11527 Third Party and supply chain oversight Technical Security
    Respond to counterfeit product reports. CC ID 11528 Third Party and supply chain oversight Technical Security
    Establish, implement, and maintain a trademark infringement reporting system. CC ID 11532 Third Party and supply chain oversight Technical Security
    Allow anti-counterfeit testing of products. CC ID 11533 Third Party and supply chain oversight Technical Security
    Categorize product information for anti-counterfeit testing to be either for a general audience or restricted audience. CC ID 11534 Third Party and supply chain oversight Technical Security
    Include static characteristics of product information in anti-counterfeit testing. CC ID 11543 Third Party and supply chain oversight Technical Security
    Include usage conditions of product information in anti-counterfeit testing. CC ID 11544 Third Party and supply chain oversight Technical Security
    Include health impacts of product information in anti-counterfeit testing. CC ID 11545 Third Party and supply chain oversight Technical Security
    Include environmental impacts of product information in anti-counterfeit testing. CC ID 11617 Third Party and supply chain oversight Physical and Environmental Protection
    Include feature-linked physical characteristics of product information in anti-counterfeit testing. CC ID 11546 Third Party and supply chain oversight Technical Security
    Allow anti-counterfeit testing to use either authentication tools or human senses. CC ID 11535 Third Party and supply chain oversight Technical Security
    Establish and maintain anti-counterfeit test authentication elements. CC ID 11542 Third Party and supply chain oversight Technical Security
    Allow either online anti-counterfeit authentication tools or stand-alone anti-counterfeit authentication tools for anti-counterfeit testing. CC ID 11536 Third Party and supply chain oversight Technical Security
    Allow either bespoke anti-counterfeit authentication tools or commercial off-the-shelf anti-counterfeit authentication tools for anti-counterfeit testing. CC ID 11537 Third Party and supply chain oversight Technical Security
    Use overt authentication elements when using human senses for anti-counterfeit testing. CC ID 11538 Third Party and supply chain oversight Technical Security
    Disallow covert authentication elements when using human senses for anti-counterfeit testing. CC ID 11539 Third Party and supply chain oversight Technical Security
    Review the performance criteria of anti-counterfeit testing authentication tools. CC ID 11541 Third Party and supply chain oversight Technical Security