0003421
FIPS Pub 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors
US National Institute of Standards and Technology
International or National Standard
Free
FIPS Pub 201-3
FIPS Pub 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors
2022-01-25
The document as a whole was last reviewed and released on 2022-04-26T00:00:00-0700.
0003421
Free
US National Institute of Standards and Technology
International or National Standard
FIPS Pub 201-3
FIPS Pub 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors
2022-01-25
The document as a whole was last reviewed and released on 2022-04-26T00:00:00-0700.
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.
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.
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.
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.
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 | 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 |
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 |
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 |
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 |
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 | 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 | 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 |
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;" class="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 |
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 |
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 |
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 {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 {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 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 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 {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 {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 {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 |
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 {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 |
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 |
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.
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 |
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 |
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 |
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 |
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 |
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 {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 |
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 | 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 | 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 |
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 |
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 |
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 |
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 |
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 |
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 {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 {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 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 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 {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 {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 {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 |
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 |
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 |
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 |
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 | 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;" class="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 |
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 |
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.
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 |
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 | 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;" class="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 |
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 |
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 {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 | 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 | 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 {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 {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 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 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 {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 {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 {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 |