PCI PIN Security v3.1

PIN Security Requirements:
1-3 All hardware security modules (HSMs) shall be either: 

Note: PCI approved HSMs may have their approvals restricted whereby the approval is valid only when the HSM is deployed in controlled environments or more robust (e.g., secure ) environments as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy. This information is noted in the Additional Information column of approved PTS devices.
Testing Procedures:
1-3.a For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and examine the list of approved devices to verify that all HSMs are either: 

1-3.b Examine documented procedures and interview personnel to verify that all PIN-translation operations are performed only by the FIPS-approved and/or PTS-approved HSMs identified above 

PIN Security Requirements:
1-4 The approval listing must match the deployed devices in the following characteristics: 

Testing Procedures:
1-4.a For all PCI-approved HSMs used, examine HSM devices and examine the PCI SSC List of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM: 

1-4.b For all FIPS-approved HSMs used, examine HSM devices and examine the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 or FIPS 140-3 Level 3 (or higher) approval listing for each HSM: 

PIN Security Requirements:
2-1 Documented procedures exist and are followed that ensure any employee or agent neither requests a cardholder to divulge their PIN in an oral or written manner nor enters it for the cardholder—e.g., documented procedures state that the merchant, clerk, and/or teller will not request or accept the PIN from the cardholder.
Testing Procedures:
2-1.a Through interview of responsible personnel, demonstration at sample points of entry, and examination of documented procedures, determine that: 

PIN Security Requirements:
2-2 Online PIN translation must only occur using one of the allowed key-management methods: DUKPT, fixed key, master key/session key.
Note: Effective 1 January 2023: 

Testing Procedures:
2-2.a Interview responsible personnel to determine key-management methods used for online PIN acquisition.
2-2.b Examine system documentation, the summary of cryptographic keys, and the network schematic (see “Overview” section) to determine keymanagement methods used within each zone—e.g., terminal to host, host to next node, etc. Confirm only approved methods are in use 

PIN Security Requirements:
2-3 Online PINs must be encrypted using an algorithm and key size that is specified in ISO 9564. Currently, the only approved algorithms for online PIN are: 

Note: The effective dates for supporting ISO Format 4 PIN Blocks that were previously communicated in v3.0 of the PCI PIN Security Requirements and Testing Procedures have been suspended at this time.
Due to the nature of TDEA-to-AES migration and its effect across the payment ecosystem, PCI SSC is reevaluating these dates. Revised effective dates will be communicated at a later time.
PCI SSC encourages all parties to continue their migration efforts to support ISO Format 4 PIN Blocks.
Testing Procedures:
2-3.a Interview responsible personnel to determine encryption algorithms utilized in connection with “not-on-us” acquisitions of PIN blocks.
2-3.b Examine system documentation, the list of cryptographic keys, and the network schematic to verify information provided during the aforementioned interviews: 

2-3.c Examine the HSM configuration to ensure that the PIN translation encryption algorithms are only TDEA and/or AES.
2-3.d Examine the algorithm type parameter (to ensure it denotes TDEA and/or AES) and hardware-encryption-required parameter (if applicable, to ensure it indicates hardware encryption—not software encryption) on every terminal link, network link, and if applicable, internal path (i.e., if using an intermediate key) for the host application. 

PIN Security Requirements:
2-4 All cardholder PINs processed offline using IC card technology must be protected in accordance with the requirements in Book 2 of the EMV IC Card Specifications for Payment Systems and ISO 9564. 
See Book 2, Section 7, of the EMV IC Card Specifications for Payment Systems, and ISO 9564
PIN submission method 

PIN entry device and IC reader integrated as a device meeting the requirements of ISO 9564 

PIN entry device and IC reader not integrated as a device meeting the requirements of ISO 9564 

2-4.a Interview the responsible personnel to determine which POI device models identified in Requirement 1 summary are used for offline PIN acquiring.
2-4.b Validate that the POI device models used for offline PIN—including both the ICCR and the PIN entry device where non-integrated—are approved for “Offline PIN” on the PTS Approved Devices Listing at www.pcisecuritystandards.org 

PIN Security Requirements:
3-1 For secure transmission of the PIN from the point of PIN entry to the card issuer, the encrypted PIN-block format must comply with ISO 9564 format 0, ISO 9564 format 1, ISO 9564 format 3, or ISO 9564 format 4.
Testing Procedures:
3-1.a Interview responsible personnel to determine the PIN-block format(s) utilized for “not-on-us” traffic from point of acquisition through routing of the transaction to another entity. Examine and verify the accuracy of the network schematic.
3-1.b Examine system documentation to verify information provided during interviews. This is mandatory, especially if personnel have indicated the use of a compliant PIN-block format: 

PIN Security Requirements:
3-3 Standard PIN-block formats (i.e., ISO formats 0, 1, 2, 3, and 4) shall not be translated into non-standard PIN-block formats.
PINs enciphered using ISO format 0, ISO format 3, or ISO format 4 must not be translated into any other PIN-block format other than ISO format 0, 3, or 4 except when translated to ISO format 2 as specified in the table below. PINs enciphered using ISO format 1 may be translated into ISO format 0, 3, or 4, but must not be translated back into ISO format 1. ISO format 1 may be translated into ISO format 2 as specified in the table below.
Translations between PIN-block formats that both include the PAN shall not support a change in the PAN. The PIN-translation capability between ISO formats 0, 3, or 4 (including translations from ISO format 0 to ISO format 0, from ISO format 3 to ISO format 3, or from ISO format 4 to ISO format 4) must not allow a change of PAN. The following illustrates translations from formats 0, 1, 3 and 4:
Note: This translation restriction is not applicable to surrogate PANs used in tokenization implementations.
Translation 
from: ISO Format 0, 3, 4 
to:  ISO Format 0, 3, 4 

from: ISO Format 1
to:  ISO Format 0, 3, 4 

from: ISO Format 2
to:  ISO Format 0, 3, 4 

from: ISO Format 0, 3, 4 
to: ISO Format 1

from: ISO Format 1
to: ISO Format 1

from: ISO Format 2
to: ISO Format 1

from: ISO Format 0, 3, 4 
to: ISO Format 2

from: ISO Format 1
to: ISO Format 2

from: ISO Format 2
to: ISO Format 2

PIN Security Requirements:
5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Generation of cryptographic keys or key components must occur within an SCD. They must be generated by one of the following: 

Note: Random number generation is critical to the security and integrity of all cryptographic systems. All cryptographic key generation relies upon good quality, randomly generated, values.
Testing Procedures:
5-1.a Examine key-management policy documentation to verify that it requires that all devices used to generate cryptographic keys meet one of the following: 

5-1.b Examine certification letters or technical documentation to verify that all devices used to generate cryptographic keys or key components meet one of the following: 

5-1.c Examine procedures to be used for future generations and logs of past key generations to verify devices used for key generation are those as noted above, including validation of the firmware used. 

PIN Security Requirements:
6-1.1 Any clear-text output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the clear text of any key component/share. Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.
Testing Procedures:
6-1.1.a Examine documented procedures to verify the following. 

6-1.1.b Observe key-generation process demonstration and interview responsible personnel to verify: 

PIN Security Requirements:
6-1.2 There must be no point in the key-generation process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
Note: Key shares derived using a recognized secret-sharing algorithm or full-length key components are not considered key parts and do not provide any information regarding the actual cryptographic key.
Testing Procedures:
6-1.2.a Examine documented procedures for all key-generation methods and observe demonstrations of the key-generation process from end-to-end to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
6-1.2.b Examine key-generation logs to verify that: 

PIN Security Requirements:
6-1.3 Devices used for generation of clear-text key components that are output in the clear must either be powered off when not in use or require re-authentication whenever key generation is invoked. Logically partitioned devices used concurrently for other processes— e.g., providing services simultaneously to host systems, such as for transaction processing—must have key-generation capabilities disabled when not in use and other activities are continuing.
Testing Procedures:
6-1.3 Examine documented procedures for all key-generation methods. Verify procedures require that: 

PIN Security Requirements:
6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (for example, unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.
Note: This does not apply to logically partitioned devices located in data centers that are concurrently used for other purposes, such as transaction processing.
Testing Procedures:
6-1.4.a Examine documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering prior to use. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
6-1.4.b Observe key-generation set-up processes for all key types to verify that key-generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering. Verify procedures include a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device). 

PIN Security Requirements:
6-3.1 The room must have walls made of solid materials. The walls do not have to extend from true floor to true ceiling but do need to extend from floor to ceiling.
Testing Procedures:
6-3.1 Inspect the secure room designated for printing clear-text key components to verify that the walls are made of solid materials and extend from floor to ceiling 

PIN Security Requirements:
6-3.2 Any windows into the secure room must be: 

6-3.2.a Observe all windows in the secure room to verify they are: 

6-3.2.b Examine configuration of window sensors to verify that the alarm mechanism is active. 

PIN Security Requirements:
6-3.3 An electronic access control system (for example, badge and/or biometrics) must be in place that: 

6-3.3.a Observe authorized personnel entering the secure room to verify that a badge-control system is in place that enforces the following requirements: 

6-3.3.b Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds. 

PIN Security Requirements:
6-3.4 CCTV cameras must record all activity, including recording events during dark periods through the use of infrared CCTV cameras or automatic activation of floodlights in case of any detected activity. This recording may be motion-activated, in which case the recording must continue for at least a minute after the last pixel of activity subsides.
Testing Procedures:
6-3.4 Inspect CCTV configuration and examine a sample of recordings to verify that CCTV monitoring is in place on a 24/7, including the ability to record events during dark periods, basis and verify that, if motion-activated, recording continues for at least a minute after the last pixel of activity subsides. 

PIN Security Requirements:
6-3.5 Monitoring must be supported on a continuous (24/7) basis such that alarms can be resolved by authorized personnel.
Testing Procedures:
6-3.5 Inspect configuration of monitoring systems and interview monitoring personnel to verify that monitoring is supported on a continuous (24/7) basis and alarms can be resolved by authorized personnel. 

PIN Security Requirements:
6-3.6 The CCTV server and digital storage must be secured in a separate secure location that is not accessible to personnel who have access to the secure room.
Testing Procedures:
6-3.6.a Inspect location of the CCTV server and digital storage to verify they are located in a secure location that is separate from the secure room.
6-3.6.b Inspect access-control configurations for the CCTV server/storage secure location and the key-injection secure room to identify all personnel who have access to each area. Compare access lists to verify that personnel with access to the secure room do not have access to the CCTV server/storage secure location. 

PIN Security Requirements:
6-3.7 The CCTV cameras must be positioned to monitor: 

Testing Procedures:
6-3.7 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor: 

PIN Security Requirements:
6-3.8 CCTV cameras must be positioned so they do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
Testing Procedures:
6-3.8 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials. 

PIN Security Requirements:
6-3.9 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days. If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
Testing Procedures:
6-3.9.a If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
6-3.9.b Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived. 

PIN Security Requirements:
6-4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted—depending on media—immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual. Examples of where such key residue may exist include (but are not limited to): 

6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures ensure the following: 

Examine logs of past destructions and deletions to verify that procedures are followed
6-4.b Observe the destruction process of each identified type of key residue and verify the following: 

PIN Security Requirements:
6-5 Asymmetric-key pairs must either be: 

Testing Procedures:
6-5.a Examine documented procedures for asymmetric key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either: 

6-5.b Observe key-generation processes to verify that asymmetric-key pairs are either: 

PIN Security Requirements:
6-6 Policy and procedures must exist to ensure that clear-text private or secret keys or their components/shares are not transmitted across insecure channels. Preclusions include but are not limited to: 

6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting clear-text private or secret keys or their components/shares across insecure channels, including but not limited to: 

6-6.b From observation of key-management processes verify that clear-text private or secret keys or their components are not transmitted across insecure channels, including but not limited to: 

PIN Security Requirements:
7-1 Written key-generation policies and procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. Procedures for creating all keys must be documented.
Testing Procedures:
7-1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations and address all keys in scope.
7-1.b Interview those responsible for the key-generation processes (including key custodians, supervisory staff, technical management, etc.) to verify that the documented procedures are known and understood by all affected parties.
7-1.c Observe key-generation ceremonies, whether actual or for demonstration purposes, and verify that the documented procedures are demonstrably in use. 

PIN Security Requirements:
7-2 Logs must exist for the generation of higher-level keys, such as KEKs exchanged with other organizations, and MFKs and BDKs. The minimum log contents include date and time, object name/identifier, purpose, name and signature of individual(s) involved, tamper-evident package number(s), and serial number(s) of device(s) involved.
Testing Procedures:
7-2.a Examine documented key-generation procedures to verify that all key-generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components, and MFKs and BDKs) must be logged.
7-2.b Observe demonstrations for the generation of higher-level keys to verify that all key-generation events are logged.
7-2.c Examine logs of key generation to verify that exchanges of higher-level keys with other organizations have been recorded and that all required elements were captured.

PIN Security Requirements:
8-1 Keys must be transferred either encrypted, as two or more full-length clear-text components, key shares, or within an SCD. 
Clear-text key components/shares must be conveyed in SCDs or using tamper- evident, authenticable packaging. 

Testing Procedures:
8-1.a Determine whether keys are transmitted encrypted, as clear-text components/shares, or within an SCD.
8-1.b If key components are transmitted in clear text using pre-numbered, tamperevident, authenticable packaging, perform the following: 

8-1.c Where SCDs are used to convey components/shares: 

8-1.d Where an SCD is conveyed with pre-loaded secret and/or private keys, perform the following: 

PIN Security Requirements:
8-2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
Note: An m-of-n scheme is a component- or share-allocation scheme where m is the number of shares or components necessary to form the key, and n is the number of the total set of shares or components related to the key. Management of the shares or components must be sufficient to ensure that no one person can gain access to enough of the item to form the key alone.
E.g., in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such that any three key components or shares (i.e., m = 3) can be used to derive the key, no single individual can have access to more than two components/shares.
Testing Procedures:
8-2.a Examine documented procedures to verify they include controls to ensure that no single person can gain access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify procedures include: 

8-2.b Observe key-transfer processes and interview personnel to verify that controls are implemented to ensure that no single person can gain access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify the implemented controls ensure the following: 

8-2.c Examine records of past key transfers to verify that the method used did not allow for any personnel to have access to components or shares sufficient to form the key. 

PIN Security Requirements:
8-3 E-mail shall not be used for the conveyance of secret or private keys or their components/shares, even if encrypted, unless the key (or component/share) has already been encrypted in accordance with these requirements—i.e., in an SCD. This is due to the existence of these key values in memory just prior to encryption or subsequent to decryption. In addition, corporate e-mail systems allow the recovery by support staff of the clear text of any encrypted text or files conveyed through those systems.
Other similar mechanisms, such as SMS, fax, or telephone shall not be used to convey clear-text key values.
Testing Procedures:
8-3 Validate through interviews, observation, and log inspection that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components/shares. 

PIN Security Requirements:
8-4 Public keys must be conveyed in a manner that protects their integrity and authenticity. Examples of acceptable methods include: 

PIN Security Requirements:
9-1 During the process to convey it, any single clear-text secret or private key component/share must at all times be either: 

Note: No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key.
Testing Procedures:
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text key component must at all times be either:

9-1.b Observe key-management processes, examine associated logs, and interview responsible personnel to verify processes implemented ensure that any single clear-text key component is at all times either: 

PIN Security Requirements:
9-2 Packaging or mailers (i.e., pre-numbered, tamper-evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and replacement of: 

9-2.a Verify documented procedures include requirements for all packaging or mailers containing clear-text key components to be examined for evidence of tampering before being opened.
9-2.b Interview responsible personnel and observe processes to verify that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened.
9-2.c Verify documented procedures require that any sign of package tampering is identified, reported, and, if compromise is confirmed, ultimately results in the destruction and replacement of both: 

9-2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering indicating a component was potentially compromised, processes are implemented to identify the tampering, report/escalate it, and, if compromise is confirmed, ultimately results in the destruction and replacement of both: 

9-2.e Examine records related to any escalated transmittal events. Verify that if compromise is confirmed it resulted in the destruction and replacement of both: 

PIN Security Requirements:
9-3 Only an authorized key custodian⎯and designated backup(s)⎯shall have physical access to a key component prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
Testing Procedures:
9-3.a Verify the existence of a list(s) of key custodians⎯and designated backup(s)⎯authorized to have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
9-3.b Observe implemented access controls and processes to verify that only those authorized key custodians⎯and designated backup(s)⎯have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging
9-3.c Examine physical access logs (e.g., to security containers for key components) to verify that only the authorized individual(s) have access to each component. 

PIN Security Requirements:
9-4 Mechanisms must exist to ensure that only authorized custodians: 

PIN Security Requirements:
9-5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components not in an SCD. Out-ofband mechanisms must be used to verify receipt of the appropriate bag numbers.
Note: Numbered courier bags are not sufficient for this purpose
Testing Procedures:
9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following: 

PIN Security Requirements:
9-6 If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that: 

9-6.a If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that: 

9-6.b Examine logs to verify that procedures are followed. 

PIN Security Requirements:
11-1 Written procedures must exist and be known to all affected parties.
Testing Procedures:
11-1.a Verify documented procedures exist for all key transmission and conveyance processing.
11-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for key transmission and conveyance processing. 

PIN Security Requirements:
11-2 Methods used for the conveyance or receipt of keys must be documented.
Testing Procedures:
11-2 Verify documented procedures include all methods used for the conveyance or receipt of keys. 

PIN Security Requirements:
12-1 The loading of secret or private keys, when from the individual key components or shares, must be performed using the principles of dual control and split knowledge.
Note: Manual key loading may involve the use of media such as paper, smart cards, or other physical tokens.
Testing Procedures:
12-1.a Using the summary of cryptographic keys, identify keys that are loaded from components and examine documented process to load each key type (MFK, TMK, PEK, etc.) from components to ensure dual control and split knowledge are required.
12-1.b Interview appropriate personnel to determine the number of key components for each manually loaded key.
12-1.c Witness a structured walk-through/demonstration of various key-loading processes for all key types (MFKs, AWKs, TMKs, PEKs, etc. Verify the number and length of the key components against information provided through verbal discussion and written documentation.
12-1.d Verify that the process includes the entry of individual key components by the designated key custodians.
12-1.e Ensure key-loading devices can only be accessed and used under dual control.
12-1.f Examine locations where keys may have been recorded that don't meet this requirement. As applicable, perform the following: 

PIN Security Requirements:
12-2 Procedures must be established that will prohibit any one person from having access to components sufficient to form an encryption key when components are removed from and returned to storage for key loading.
Testing Procedures:
12-2. Examine logs of access to security containers for key components/shares to verify that only the authorized custodian(s) have accessed. Compare the number on the current tamper-evident and authenticable package for each component to the last log entry for that component. 
Trace historical movement of higher-order keys (MFK, KEK, and BDK) in and out of secure storage to ensure there is no break in the package-number chain that would call into question authorized handling and sufficient storage of the component or share. This must address at a minimum the time frame from the date of the prior audit 

PIN Security Requirements:
12-3 The loading of clear-text cryptographic keys using a key-loading device requires dual control to authorize any key-loading session. It shall not be possible for a single person to use the key-loading device to load clear keys alone. Dual control must be implemented using one or more of, but not limited to, the following techniques: 

PIN Security Requirements:
12-4 Key components for symmetric keys must be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components⎯for example, via XOR‘ing of full-length components.
The resulting key must only exist within the SCD.
Note: Concatenation of key components together to form the key is unacceptable; e.g., concatenating two 8-hexadecimal character halves to form a 16-hexadecimal secret key.
Testing Procedures:
12-4.a Examine documented procedures for combining symmetric-key components and observe processes to verify that key components are combined using a process such that no active bit of the key can be determined without knowledge of the remaining components⎯e.g., only within an SCD.
12-4.b Confirm key-component lengths through interview and examination of blank component forms and documented procedures. Examine device configuration settings and interview personnel to verify that key components used to create a key are the same length as the resultant key. 

PIN Security Requirements:
12-5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least double-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits.
Testing Procedures:
12-5 Examine vendor documentation describing options for how the HSM MFK is created and verify the current MFK was created using AES or double- or triple-length TDEA. Corroborate this via observation of processes, with information gathered during the interview process, and procedural documentation provided by the entity under review. 

PIN Security Requirements:
12-6 Any other SCD loaded with the same key components must combine all entered key components using the identical process.
Testing Procedures:
12-6 Through examination of documented procedures, interviews, and observation, confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key. 

PIN Security Requirements:
12-7 The initial terminal master key (TMK) or initial DUKPT key must be loaded to the device using either asymmetric key-loading techniques or manual techniques—e.g., the device keypad, IC cards, key-loading device, etc. Subsequent loading of the terminal master key or an initial DUKPT key may use techniques described in this document such as: 

Keys shall not be reloaded by any methodology in the event of a compromised device and must be withdrawn from use.
Testing Procedures:
12-7.a Examine documented procedures for the loading of TMKs and initial DUKPT keys to verify that they require asymmetric key-loading techniques or manual techniques for initial loading and allowed methods for replacement TMK or initial DUKPT key loading.
12-7.b Examine documented procedures to verify that keys are withdrawn from use if they were loaded to a device that has been compromised or gone missing. 

PIN Security Requirements:
13-1 Clear-text secret and private keys and key components must be transferred into an SCD only when it can be ensured that: 

Testing Procedures:
13-1 Observe key-loading environments, processes, and mechanisms (for example, terminals, PIN pads, key guns, etc.) used to transfer keys and key components. Perform the following: 

PIN Security Requirements:
13-3 The loading of plaintext secret or private key components or shares from an electronic medium—e.g., smart card, thumb drive, fob, or other device used for data transport—directly into a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the following: 

PIN Security Requirements:
13-4.1 The key-loading device must be a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected.
Note: A PCI-approved KLD meets this requirement for a SCD.
Testing Procedures:
13-4.1 Verify the key-loading device is a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected. 

PIN Security Requirements:
13-4.2 The key-loading device must be under the supervision of a person authorized by management or stored in a secure container such that no unauthorized person can have access to it.
Testing Procedures:
13-4.2 Verify the key-loading device is under the supervision of a person authorized by management or stored in a secure container such that no unauthorized person can have access to it. 

PIN Security Requirements:
13-4.3 The key-loading device must be designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key-recording device is not inserted between the SCDs.
Testing Procedures:
13-4.3.a Verify the key-loading device is designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD.
13-4.3.b Verify that both authorized personnel involved in key-loading activity inspect the key-loading device prior to use to ensure that a key-recording device has not been inserted between the SCDs. 

PIN Security Requirements:
13-4.4 The key-loading device must not retain any information that might disclose the key (e.g., allow replay of the key for injection into a non-SCD) that was installed in the device or a key that it has successfully transferred.
Testing Procedures:
13-4.4 Verify the key-loading device does not retain any information that might disclose the key or a key that it has successfully transferred. For example, attempt to output the same value more than one time from the device or cause the device to display check values for its contents both before and after injection and compare. 

PIN Security Requirements:
13-5 Any media (electronic or otherwise) containing secret or private key components or shares used for loading cryptographic keys must be maintained in a secure storage location and accessible only to authorized custodian(s). When removed from the secure storage location, media or devices containing key components or used for the injection of clear-text cryptographic keys must be in the physical possession of only the designated component holder(s), and only for the minimum practical time necessary to complete the key-loading process.
The media upon which a component resides must be physically safeguarded at all times when removed from secure storage. Key components that can be read (for example, those printed on paper or stored on magnetic cards, PROMs, or smartcards) must be managed so they are never used in a manner that would result in the component being displayed in clear text to anyone who is not a designated custodian for that component.
Testing Procedures:
13-5.a Interview personnel and observe media locations to verify that the media is maintained in a secure storage location accessible only to custodian(s) authorized to access the key components.
13-5.b Examine documented procedures for removing media or devices containing key components—or that are otherwise used for the injection of cryptographic keys—from the secure storage location. Verify procedures include the following: 

13-5.c Interview designated component holder(s) and examine key-management logs to verify that media or devices removed from secure storage are in the physical possession of only the designated component holder(s).
13-5.d Interview key-injection personnel and examine logs for the removal of media/devices from secure storage to verify they are removed only for the minimum practical time necessary to complete the key-loading process. 

PIN Security Requirements:
13-6 If the component is in human-readable form (e.g., printed within a PIN-mailer type document), it must be visible only to the designated component custodian and only for the duration of time required for this person to privately enter the key component into an SCD.
Testing Procedures:
13-6 Validate through interview and observation that printed key components are not opened until just prior to entry into the SCD. Plaintext secret and/or private keys and/or their components are visible only to key custodians for the duration of loading into an SCD. 

PIN Security Requirements:
13-7 Written or printed key-component documents must not be opened until immediately prior to use.
Testing Procedures:
13-7.a Examine documented procedures and confirm that printed/written key-component documents are not opened until immediately prior to use.
13-7.b Observe key-loading processes and verify that printed/written key components are not opened until immediately prior to use. 

PIN Security Requirements:
13-8 A person with access to any component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key.
E.g., in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such that any three key components or shares (i.e., m = 3) can be used to derive the key, no single individual can have access to more than two components/shares.
Testing Procedures:
13-8.a Examine documented procedures for the use of key components to verify that procedures ensure that any individual custodian only has access to their assigned components and never has access to sufficient key components to reconstruct a cryptographic key.
13-8.b Examine key-component access controls and access logs to verify that any single authorized custodian can and has only had access to their assigned component(s) and cannot access sufficient key components to reconstruct a cryptographic key 

PIN Security Requirements:
14-1 Any hardware and passwords/authentication codes used in the key-loading function must be controlled and maintained in a secure environment under dual control. Resources (e.g., passwords/authentication codes and associated hardware) must be managed such that no single individual has the capability to enable key loading of clear-text keys or their components. This is not to imply that individual access authentication mechanisms must be managed under dual control.
Note: Where key-loading is performed for POIs, the secure environment is defined in Annex B.
Testing Procedures:
14-1.a Examine documented procedures to verify they require the following: 

14-1.b Observe key-loading environments and controls to verify the following: 

PIN Security Requirements:
14-2 All cable attachments over which clear-text keying material traverses must be examined at the beginning of an entity's key-activity operations (system power on/authorization) to ensure they have not been tampered with or compromised.
Testing Procedures:
14-2.a Examine documented procedures to ensure they require that cable attachments are examined at the beginning of an entity's key-activity operations (system power on/authorization).
14-2.b Observe key-loading processes to verify that all cable attachments are properly examined at the beginning of an entity's key-activity operations (system power on/authorization). 

PIN Security Requirements:
14-3 Key-loading equipment usage must be monitored, and a log of all key-loading activities maintained for audit purposes shall contain, at a minimum, date, time, personnel involved, and number of devices keys are loaded to.
Testing Procedures:
14-3.a Observe key-loading activities to verify that key-loading equipment usage is monitored.
14-3.b Verify logs of all key-loading activities are maintained and contain all required information. 

PIN Security Requirements:
14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key-loading must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control. These tokens must be secured in a manner similar to key components, including tamper-evident, authenticable packaging and the use of access-control logs for when removed or placed into secure storage.
Testing Procedures:
14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key loading. Verify procedures require that physical tokens must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control.
14-4.b Inspect locations and controls for physical tokens to verify that tokens used to enable key loading are not in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys under single control.
14-4.c Examine storage locations for physical tokens to determine adequacy to ensure that only the authorized custodian(s) can access their specific tokens.
14-4.d Verify that access-control logs exist and are in use including notation of tamper-evident, authenticable bag numbers.
14-4.e Reconcile storage contents to access-control logs. 

PIN Security Requirements:
14-5 Default passwords/authentication codes used to enforce dual control must be changed, and documented procedures must exist to require that these password/PINs be changed when assigned personnel change.
Testing Procedures:
14-5.a Verify that documented procedures require default passwords/authentication codes used to enforce dual control are changed.
14-5.b Verify that documented procedures exist to require that these passwords/authentication codes be changed when assigned personnel change. 

PIN Security Requirements:
15-1 A cryptographic-based validation mechanism must be in place to ensure the authenticity and integrity of keys and/or their components (for example, testing key check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO 11568. Where check values are used, recorded, or displayed, key-component check values and key check values shall be generated by a cryptographic process such that all portions of the key or key component are involved in generating the check value. The check value shall be in accordance with the following note.
Note: Check values may be computed by two methods. TDEA may use either method. AES must only use the CMAC method. In the first method, check values are computed by encrypting an all binary zeros block using the key or component as the encryption key, using the leftmost n-bits of the result; where n is at most 24 bits (6 hexadecimal digits/3 bytes). In the second method the KCV is calculated by MACing an all binary zeros block using the CMAC algorithm as specified in ISO 9797-1 (see also NIST SP 800-38B). The check value will be the leftmost n-bits of the result, where n is at most 40 bits (10 hexadecimal digits). The block cipher used in the CMAC function is the same as the block cipher of the key itself. A TDEA key or a component of a TDEA key will be MACed using the TDEA block cipher, while a 128-bit AES key or component will be MACed using the AES-128 block cipher.
Testing Procedures:
15-1.a Examine documented procedures to verify a cryptographic-based validation mechanism is in place to ensure the authenticity and integrity of keys and/or components.
15-1.b Observe the key-loading processes to verify that the defined cryptographic-based validation mechanism used to ensure the authenticity and integrity of keys and components is being used and are verified by the applicable key custodians.
15-1.c Verify that the methods used for key validation are consistent with ISO 11568—for example, if check values are used, they are in accordance with this requirement. 

PIN Security Requirements:
16-1 Documented key-loading procedures must exist for all devices (e.g., HSMs and POIs), and all parties involved in cryptographic key loading must be aware of those procedures.
Testing Procedures:
16-1.a Verify documented procedures exist for all key-loading operations.
16-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for all key-loading operations.
16-1.c Observe key-loading process for keys loaded as components and verify that the documented procedures are demonstrably in use. This may be done as necessary on test equipment—e.g., for HSMs. 

PIN Security Requirements:
16-2 All key-loading events must be documented. Audit trails must be in place for all key-loading events.
Testing Procedures:
16-2 Examine log files and observe logging processes to verify that audit trails are in place for all key-loading events.  

PIN Security Requirements:
17-1 Where two organizations or logically separate systems share a key to encrypt PINs (including key-encipherment keys used to encrypt the PIN-encryption key) communicated between them, that key must be unique to those two organizations or logically separate systems and must not be given to any other organization or logically separate systems.
Testing Procedures:
17-1.a Examine the documented key matrix and operational procedures and interview personnel to determine whether any keys are shared between organizations.
17-1.b For all keys shared between two organizations (including key-encryption keys used to encrypt a PIN-encryption key) perform the following: 

PIN Security Requirements:
18-1 Synchronization errors must be monitored to help reduce the risk of an adversary’s substituting a key known only to them. Procedures must exist and be followed for investigating repeated synchronization errors for online processes such as online key exchanges or transmission or processing of PIN-based transactions.
Note: Multiple synchronization errors in PIN translation may be caused by the unauthorized replacement or substitution of one stored key for another, or the replacement or substitution of any portion of a TDEA key, whether encrypted or unencrypted.
Testing Procedures:
18-1.a Verify procedures have been implemented for monitoring and alerting to the presence of multiple cryptographic synchronization errors.
18-1.b Verify that implemented procedures include: 

PIN Security Requirements:
18-2 To prevent or detect usage of a compromised key, key-component packaging, or containers that show signs of tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
Testing Procedures:
18-2.a Verify that documented procedures are documented require that key-component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
18-2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it results in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist. 

PIN Security Requirements:
18-3 Encrypted symmetric keys must be managed in structures called key blocks. The key usage must be cryptographically bound to the key using accepted methods. 
The phased implementation dates are as follows: 

Acceptable methods of implementing the integrity requirements include, but are not limited to: 

18-3 Using the cryptographic-key summary to identify secret keys conveyed or stored, examine documented procedures and observe key operations to verify that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of acceptable methods or an equivalent. Where key blocks are not implemented, identify and examine project plans to implement in accordance with the prescribed timeline. 

PIN Security Requirements:
19-1 Encryption keys must be used only for the purpose they were intended⎯i.e., key-encryption keys must not to be used as PIN-encryption keys, PIN-encryption keys must not be used for account data, etc. Derivation Keys may be derived into multiple keys, each with its own purpose. For example, a DUKPT Initial Key may be used to derive both a PIN encryption key and a data encryption key. The derivation key would only be used for its own purpose, key derivation. This is necessary to limit the magnitude of exposure should any key(s) be compromised. Using keys only as they are intended also significantly strengthens the security of the underlying system.
Testing Procedures:
19-1.a Examine key-management documentation (e.g., the cryptographic key inventory) and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are defined for a specific purpose.
19-1.b Using a sample of device types, validate via examination of check values, terminal definition files, etc. that keys used for key encipherment or PIN encipherment are not used for any other purpose. 

PIN Security Requirements:
19-2 Private keys: 

Note: The restriction does not apply to certificate signing requests e.g., PKCS #10.
Testing Procedures:
19-2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are: 

PIN Security Requirements:
19-3 Public keys must only be used for a single purpose—a public key must only be used for either encryption or for verifying digital signatures, but not both (except for transaction-originating POI devices).
Testing Procedures:
19-3 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that public keys are only used: 

PIN Security Requirements:
19-4 Keys must never be shared or substituted between production and test/development systems: 

Note: For logically partitioned HSMs and computing platforms, if one or more logical partitions of a physical device are used for production and one or more other logical partitions are used for testing, including QA or similar, the entire configuration that is impacted⎯computing platform(s) and networking equipment⎯must be managed and controlled as production.
Testing Procedures:
19-4.a Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are never shared or substituted between production and development systems.
19-4.b Observe processes for generating and loading keys into in production systems to ensure that they are in no way associated with test or development keys.
19-4.c Observe processes for generating and loading keys into in test systems to ensure that they are in no way associated with production keys.
19-4.d Compare check, hash, cryptogram, or fingerprint values for production and test/development keys for higher-level keys (e.g., MFKs, KEKs shared with other network nodes and BDKs) to verify that development and test keys have different key values. 

PIN Security Requirements:
19-5 If a business rationale exists, a production platform (HSM and server/standalone computer) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements.
At all times the HSMs and servers/computers must be physically and logically secured in accordance with these requirements.
Note: This does not apply to HSMs that are never intended to be used for production.
Testing Procedures:
19-5 Interview personnel to determine whether production platforms are ever temporarily used for test purposes. If they are, verify that documented procedures require that: 

PIN Security Requirements:
20-1 POI devices must each implement unique secret and private keys for any function directly or indirectly related to PIN protection. These keys must be known only in that device and in hardware security modules (HSMs) at the minimum number of facilities consistent with effective system operations. Disclosure of the key in one such device must not provide any information that could be feasibly used to determine the key in any other such device.
This means not only the PIN-encryption key(s), but also keys that are used to protect other keys, firmware-authentication keys, payment-application authentication and display-prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device. POI private keys must not exist anywhere but the specific POI they belong to, except where generated external to the POI and prior to the injection into the POI.
Testing Procedures:
20-1.a Examine documented procedures for the loading and usage of all keys used in transaction-originating POI devices. Verify the procedures ensure that all private and secret keys used in transaction-originating POI devices are:
Known only to a single POI device, and
Known only to HSMs at the minimum number of facilities consistent with effective system operations.
20-1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POIs to verify that unique keys are generated and used for each POI device.
20-1.c Examine check values, hashes, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI vendor used) to determine that the associated private keys stored in the POI devices are unique per device—i.e., the public keys are unique. 

PIN Security Requirements:
20-2 If a transaction-originating terminal (for example POI device) interfaces with more than one acquiring organization, the transaction-originating terminal SCD must have a completely different and unique key or set of keys for each acquiring organization. These different keys, or sets of keys, must be totally independent and not variants of one another.
Testing Procedures:
20-2a Determine whether any transaction-originating terminals interface with multiple acquiring organizations. If so: 

20-2b Observe processes for generation and injection of keys into a single POI for more than one acquiring organization, to verify: 

PIN Security Requirements:
20-3 Keys that are generated by a derivation process and derived from the same Base (master) Derivation Key must use unique data for the derivation process as defined in ISO 11568 so that all such cryptographic devices receive unique initial secret keys. Base derivation keys must not ever be loaded onto POI devices—i.e., only the derived key is loaded to the POI device.
This requirement refers to the use of a single “base” key to derive initial keys for many different POIs, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for derivation of other keys once loaded, for example, as done with DUKPT.
Note: The same BDK with the same KSN installed in multiple injection systems or installed multiple times within the same injection system will not meet uniqueness requirements.
Testing Procedures:
20-3.a Examine documented procedures and observe processes for generating initial keys. Verify the following is implemented where initial keys are generated by a derivation process and derived from the same Base Derivation Key: 

20-3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device. 

PIN Security Requirements:
20-4 Entities processing or injecting DUKPT or other key-derivation methodologies must incorporate a segmentation strategy in their environments. Segmentation must use one or more of the following techniques: 

Testing Procedures:
20-4 Examine documented key-generation and injection procedures to verify that entities processing or injecting DUKPT or other key-derivation methodologies incorporate a segmentation strategy in their environments using one or more of the following techniques: 

PIN Security Requirements:
21-1 Secret or private keys must only exist in one or more of the following forms: 

PIN Security Requirements:
21-2.1 Knowledge of any one key component/share does not convey any knowledge of any part of the actual cryptographic key.
Testing Procedures:
21-2.1 Examine processes for creating key components/shares to verify that knowledge of any one key component/share does not convey any knowledge of any part of the actual cryptographic key. 

PIN Security Requirements:
21-2.2 Construction of the cryptographic key requires the use of at least two key components/shares.
Testing Procedures:
21-2.2 Observe processes for constructing cryptographic keys to verify that at least two key components/shares are required for each key construction. 

PIN Security Requirements:
21-2.3 Each key component/share has one or more specified authorized custodians.
Testing Procedures:
21-2.3.a Examine documented procedures for the use of key components/shares and interview key custodians and key-management supervisory personnel to verify that each key component/share is assigned to a specific individual, or set of individuals, who are designated as key custodians for that component/share.
21-2.3.b Observe key-component/share access controls and key-custodian authorizations/assignments to verify that all individuals with access to key components/shares are designated as key custodians for those components/shares. 

PIN Security Requirements:
21-2.4 Procedures exist to ensure that no custodian ever has access to sufficient key components or shares of a secret or private key to reconstruct a cryptographic key.
For example, in an m-of-n scheme (which must use a recognized secretsharing scheme such as Shamir), where only two of any three shares are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one share. If a custodian was previously assigned share A, which was then reassigned, the custodian must not then be assigned share B or C, as this would give them knowledge of two shares, which gives them ability to recreate the key.
In an m-of-n scheme where n=5 and where three shares are required to reconstruct the cryptographic key, a single custodian may be permitted to have access to two of the key shares (for example, share A and share B); and a second custodian (with, in this example, share C) would be required to reconstruct the final key, ensuring that dual control is maintained
Testing Procedures:
21-2.4.a Examine documented procedures for the use of key components/shares to verify that procedures ensure that any custodian never has access to sufficient key components or shares to reconstruct a secret or private cryptographic key.
21-2.4.b Examine key-component/share access controls and access logs to verify that authorized custodians cannot access sufficient key components or shares to reconstruct a secret or private cryptographic key. 

PIN Security Requirements:
21-3.1 Key components that exist in clear text outside of an SCD must be sealed in individual opaque, pre-numbered, tamper-evident, authenticable packaging that prevents the determination of the key component without noticeable damage to the packaging.
Note: Tamper-evident, authenticable packaging—opacity may be envelopes within tamper-evident packaging—used to secure key components must ensure that the key component cannot be determined. For components written on paper, opacity may be sufficient, but consideration must be given to any embossing or other possible methods to “read” the component without opening of the packaging. Similarly, if the component is stored on a magnetic card, or other media that can be read without direct physical contact, the packaging should be designed to prevent such access to the key component.
Testing Procedures:
21-3.1.a Examine key components and storage locations to verify that components are stored in opaque, pre-numbered, tamper-evident packaging that prevents the determination of the key component without noticeable damage to the packaging.
21-3.1.b Inspect any tamper-evident packaging used to secure key components—e.g., is the package sufficiently opaque to prevent reading of a component—and ensure that it prevents the determination of the key component without visible damage to the packaging.
21-3.1.c Ensure clear-text key components do not exist in non-secure containers such as databases or in software programs.
21-3.1.d Confirm that start-up instructions and other notes used by service technicians do not contain initialization-key values written in the clear (e.g., at the point in the checklist where the keys are entered). 

PIN Security Requirements:
21-3.2 Key components/shares for each specific custodian must be stored in a separate, secure container that is accessible only by the custodian and/or designated backup(s).
Note: Furniture-based locks or containers with a limited set of unique keys— for example, desk drawers—are not sufficient to meet this requirement. Components/shares for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers
Testing Procedures:
21-3.2 Inspect each key component/share storage container and verify the following: 

PIN Security Requirements:
21-3.3 If a key component/share is stored on a token, and an access code (e.g., a PIN or similar access-control mechanism) is used to access the token, only that token’s owner⎯or designated backup(s)⎯must have possession of both the token and its access code.
Testing Procedures:
21-3.3 Interview responsible personnel and observe implemented processes to verify that if a key is stored on a token, and an access code (PIN or similar mechanism) is used to access the token, only that token’s owner—or designated backup(s)—has possession of both the token and its access code. 

PIN Security Requirements:
22-1.1 Key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised.
Testing Procedures:
22-1.1 Interview responsible personnel and observe implemented processes to verify key components/shares are never reloaded when there is any suspicion that either the originally loaded key or the SCD has been compromised. 

PIN Security Requirements:
22-1.2 If unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification.
Testing Procedures:
22-1.2 Interview responsible personnel and observe implemented processes to verify that if unauthorized alteration is suspected, new keys are not installed until the SCD has been inspected and assurance reached that the equipment has not been subject to any form of unauthorized modification. 

PIN Security Requirements:
22-1.3 A secret or private cryptographic key must be replaced with a new key whenever the compromise of the original key is known. Suspected compromises must be assessed, and the analysis formally documented. If compromise is confirmed, the key must be replaced. In addition, all keys encrypted under or derived using that key must be replaced with a new key within the minimum feasible time. The replacement key must not be a variant or an irreversible transformation of the original key. Compromised keys must not be used to facilitate replacement with a new key(s).
Note: The compromise of a key must result in the replacement and destruction of that key and all variants and non-reversible transformations of that key, as well as all keys encrypted under or derived from that key.
Known or suspected substitution of a secret key must result in the replacement of that key and based on an analysis of how the key was substituted, any associated key-encipherment keys that may have been compromised.
Testing Procedures:
22-1.3 Interview responsible personnel and observe implemented processes to verify that if compromise of the cryptographic key is suspected, an assessment and analysis is performed. If compromise is confirmed, all the following are performed: 

PIN Security Requirements:
22-1.4 A documented escalation process and notification to organizations that currently share or have previously shared the key(s), including: 

22-1.4.a Interview responsible personnel and examine documented procedures to verify key personnel are identified and that the escalation process includes notification to organizations that currently share or have previously shared the key(s).
22-1.4.b Verify notifications include the following: 

PIN Security Requirements:
22-1.5 Identification of specific events that would indicate a compromise may have occurred. Such events must include but are not limited to: 

22-1.5 Interview responsible personnel and examine documented procedures to verify that specific events that may indicate a compromise are identified. This must include, as a minimum, the following events: 

PIN Security Requirements:
22-2 If attempts to load a secret key or key component into an KLD or POI fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI.
Testing Procedures:
22-2 Interview responsible personnel and observe implemented processes to verify that if attempts to load a secret key or key component into a KLD or POI fail, the same key or component is not loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased from or otherwise destroyed in the original KLD or POI. 

PIN Security Requirements:
23-1 Any key generated with a reversible process (such as a variant of a key) of another key must be protected in the same manner as the original key—that is, under the principles of dual control and split knowledge. Variants of the same key may be used for different purposes but must not be used at different levels of the key hierarchy. For example, reversible transformations must not generate key-encipherment keys from PIN keys.
Note: Exposure of keys that are created using reversible transforms of another (key-generation) key can result in the exposure of all keys that have been generated under that key-generation key. To limit this risk posed by reversible key calculation, such as key variants, the reversible transforms of a key must be secured in the same way as the original key-generation key.
Testing Procedures:
23-1.a Examine documented procedures and interview responsible personnel to determine whether keys are generated using reversible key-calculation methods.
23-1.b Observe processes to verify that any key generated using a reversible process of another key is protected under the principles of dual control and split knowledge. 

PIN Security Requirements:
23-2 An MFK used by host processing systems for encipherment of keys for local storage—and variants of the MFK—must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local storage shall not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration.
A logical configuration is defined as one where all the components form a system used to undertake a particular task and are managed and controlled under a single operational and security policy.
Testing Procedures:
23-2.a Interview responsible personnel to determine which host MFKs keys exist as variants.
Note: Some HSMs may automatically generate variants or control vectors for specific keys, but it is still up to the entity to specify exact usage.
23-2.b Examine vendor documentation to determine support for key variants.
23-2.c Via examination of the network schematic detailing transaction flows with the associated key usage and identification of the sources of the keys used, determine that variants of the MFK are not used external to the logical configuration that houses the MFK. 

PIN Security Requirements:
23-3 Reversible key transformations are not used across different levels of the key hierarchy. For example, reversible transformations must not generate working keys (e.g., PEKs) from key-encrypting keys. Such transformations are only used to generate different types of keyencrypting keys from an initial key-encrypting key or working keys with different purposes from another working key.
Note: Using transformations of keys across different levels of a key hierarchy—for example, generating a PEK from a key-encrypting key— increases the risk of exposure of each of those keys.
It is acceptable to use one “working” key to generate multiple reversible transforms to be used for different working keys, such as a PIN key, MAC key(s), and data key(s) (where a different reversible transform is used to generate each different working key). Similarly, it is acceptable to generate multiple key-encrypting keys from a single key-encrypting key. However, it is not acceptable to generate working keys from key-encrypting keys.
Testing Procedures:
23-3 Examine documented key-transformation procedures and observe implemented processes to verify that reversible key transformations are not used across different levels of the key hierarchy, as follows: 

PIN Security Requirements:
24-1 Instances of secret or private keys, and their key components, that are no longer used or that have been replaced by a new key must be destroyed.
Testing Procedures:
24-1.a Verify documented procedures are in place for destroying secret or private keys and their components that are no longer used or that have been replaced by a new key.
24-1.b Identify a sample of keys and key components that are no longer used or have been replaced. For each item in the sample, interview responsible personnel and examine key-history logs and key-destruction logs to verify that all keys have been destroyed.
24-1.c Examine storage locations for the sample of destroyed keys to verify they are no longer kept. 

PIN Security Requirements:
24-2.1 Keys on all other storage media types in all permissible forms— physically secured, enciphered (except for electronic DB backups of cryptograms), or components—must be destroyed following the procedures outlined in ISO–9564 or ISO–11568.
For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder.
Testing Procedures:
24-2.1.a Examine documented procedures for destroying keys and confirm that keys on all other storage media types in all permissible forms—physically secured, enciphered, or components—must be destroyed following the procedures outlined in ISO–9564 or ISO–11568.
24-2.1.b Observe key-destruction processes to verify that keys on all other storage media types in all permissible forms—physically secured, enciphered, or components—are destroyed following the procedures outlined in ISO–9564 or ISO–11568. 

PIN Security Requirements:
24-2.2 The key-destruction process must be observed by a third party other than the custodians of any component of that key. I.e., the third party must not be a key custodian for any part of the key being destroyed. The third-party witness must sign an affidavit of destruction, and this affidavit is retained for a minimum of two years.
Testing Procedures:
24-2.2.a Observe the key-destruction process and verify that it is witnessed by a third party other than a key custodian for any component of that key.
24-2.2.b Inspect key-destruction logs and verify that a third-party, non-keycustodian witness signs an affidavit as a witness to the key destruction process. 

PIN Security Requirements:
24-2.3 Key components for keys other than the HSM or KLD MFKs that have been successfully loaded and confirmed as operational must also be destroyed, unless the HSM does not store the encrypted values on a DB but only stores the subordinate keys internal to the HSM. BDKs used in KLDs may also be stored as components where necessary to reload the KLD.
Testing Procedures:
24-2.3.a Verify documented procedures exist for destroying key components of keys once the keys are successfully loaded and validated as operational.
24-2.3.b Observe key-conveyance/loading processes to verify that any key components are destroyed once the keys are successfully loaded and validated as operational. 

PIN Security Requirements:
25-1.1 Designate key custodian(s) for each component, such that the fewest number (e.g., a primary and a backup) of key custodians are assigned as necessary to enable effective key management. Key custodians must be employees or contracted personnel.
Testing Procedures:
25-1.1 Examine key-custodian assignments for each component to verify that: 

PIN Security Requirements:
25-1.2 Document this designation by having each custodian and backup custodian sign a key-custodian form.
Testing Procedures:
25-1.2.a Examine completed key-custodian forms to verify that key custodians sign the form,
25-1.2.b Examine completed key-custodian forms to verify that backup custodians sign the form 

PIN Security Requirements:
25-1.3 Each key-custodian form provides the following: 

25-1.3 Examine all key-custodian forms to verify that they include the following: 

PIN Security Requirements:
25-1.4 In order for key custodians to be free from undue influence in discharging their custodial duties, key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual except as noted below for organizations of insufficient size.
For example, for a key managed as three components, at least two individuals report to different individuals. In an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such as three of five key shares to form the key, key custodians sufficient to form the threshold necessary to form the key must not report to the same individual.
The components collectively held by an individual and his or her direct reports shall not constitute a quorum (or shall not provide any information about the value of the key that is not derivable from a single component). 
Custodians must not become a custodian for a component/share of a key where the custodian has previously been or is currently a custodian for another component/share of that key if that would collectively constitute a quorum to form the actual key. 
When the overall organization is of insufficient size such that the reporting structure cannot support this requirement, procedural controls can be implemented. 
Organizations that are of insufficient size that they cannot support the reporting-structure requirement must: 

25-1.4.a Examine key-custodian assignments and organization charts to confirm the following: 

25-1.4.b For organizations that are such a small, modest size that they cannot support the reporting-structure requirement, ensure that documented procedures exist and are followed to: 

PIN Security Requirements:
26-1 Logs must be kept whenever keys, key components, or related materials are removed from secure storage or loaded to an SCD. The logs must be securely stored, for example, in a secure container with the associated key components. These logs must be archived for a minimum of two years subsequent to key destruction. At a minimum, logs must include the following: 

26-1.a Examine log files and audit log settings to verify that logs are kept for any time that keys, key components, or related materials are: 

26-1.b Examine logs and verify they are: 

26-1.c Examine log files and audit log settings to verify that logs include the following: 

PIN Security Requirements:
27-1 If backup copies of secret and/or private keys exist, they must be maintained in accordance with the same requirements as are followed for the primary keys.
Testing Procedures:
27-1 Interview responsible personnel and examine documented procedures and backup records to determine whether any backup copies of keys or their components exist. Perform the following: 

PIN Security Requirements:
27-2 If backup copies are created, the following must be in place: 

27-2 Interview responsible personnel and observe backup processes to verify the following: 

PIN Security Requirements:
28-1 Written procedures must exist, and all affected parties must be aware of those procedures. All activities related to key administration must be documented. This includes all aspects of key administration, as well as: 

28-1.a Examine documented procedures for key-administration operations to verify they include: 

28-1.b Interview personnel responsible for key-administration operations to verify that the documented procedures are known and understood.
28-1.c Interview personnel to verify that security-awareness training is provided for the appropriate personnel.
28-1.d Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws). 

PIN Security Requirements:
29-1 Secure cryptographic devices—such as HSMs and POI devices (e.g., PEDs and ATMs)—must be placed into service only if there is assurance that the equipment has not been subject to unauthorized modification, substitution, or tampering and has or is not otherwise been subject to misuse prior to deployment.
Note: This applies to SCDS used for key injection or code signing, including display prompts.
Testing Procedures:
29-1.a Examine documented procedures to confirm that processes are defined to provide the following assurances prior to the loading of cryptographic keys: 

29-1.b Observe processes and interview personnel to verify that processes are followed to provide the following assurances prior to the loading of cryptographic keys: 

PIN Security Requirements:
29-1.1.1 Access to all POIs and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection. The minimum log contents include date and time, object name/identifier, purpose, name of individual(s) involved, signature or electronic capture (e.g., badge) of individual involved, and if applicable, tamper-evident package number(s) and serial number(s) of device(s) involved. Electronic logging⎯e.g., using bar codes⎯is acceptable for device tracking.
Testing Procedures:
29-1.1.1.a Examine access-control documentation and device configurations to verify that access to all POIs and key-injection/loading devices is defined and documented.
29-1.1.1.b For a sample of POIs and other SCDs, observe authorized personnel accessing devices and examine access logs to verify that access to all POIs and other SCDs is logged.
29-1.1.1.c Examine implemented access controls to verify that unauthorized individuals cannot access, modify, or substitute any POI or other SCD. 

PIN Security Requirements:
29-1.1.2 All personnel with access to POIs and other SCDs prior to deployment are documented in a formal list and authorized by management. A documented security policy must exist that requires the specification of personnel with authorized access to all secure cryptographic devices. This includes documentation of all personnel with access to POIs and other SCDs as authorized by management. The list of authorized personnel is reviewed at least annually.
Testing Procedures:
29-1.1.2.a Examine documented authorizations for personnel with access to devices to verify that prior to deployment: 

29-1.1.2.b For a sample of POIs and other SCDs, examine implemented access controls to verify that only personnel documented and authorized in an auditable manner have access to devices. 

PIN Security Requirements:
29-1.2 POIs and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords/authentication codes.
Testing Procedures:
29-1.2.a Examine vendor documentation or other information sources to identify default keys (such as keys that are pre-installed for testing purposes), passwords, or data.
29-1.2.b Observe implemented processes and interview personnel to verify that default keys or passwords are not used. 

PIN Security Requirements:
29-3 Implement physical protection of devices from the manufacturer’s facility up to the point of key-insertion and deployment, through one or more of the following: 

29-3.a Examine documented procedures to confirm that they require physical protection of devices from the manufacturer’s facility up to the point of key-insertion and deployment, through one or more of the defined methods.
29-3.b Interview responsible personnel to verify that one or more of the defined methods are in place to provide physical device protection for devices, from the manufacturer’s facility up to the point of key-insertion and deployment. 

PIN Security Requirements:
29-4.1 HSM serial numbers must be compared to the serial numbers documented by the sender (sent using a different communication channel from the device) to ensure device substitution has not occurred. A record of device serial-number verification must be maintained.
Note: Documents used for this process must be received via a different communication channel—i.e., the control document used must not have arrived with the equipment. An example of how serial numbers may be documented by the sender includes but is not limited to the manufacturer’s invoice or similar document.
Testing Procedures:
29-4.1.a Interview responsible personnel to verify that device serial numbers are compared to the serial number documented by the sender.
29-4.1.b For a sample of received devices, examine sender documentation sent via a different communication channel than the device’s shipment (for example, the manufacturer’s invoice or similar documentation) used to verify device serial numbers. Examine the record of serial-number validations to confirm the serial number for the received device was verified to match that documented by the sender. 

PIN Security Requirements:
29-4.2 The security policy enforced by the HSM must not allow unauthorized or unnecessary functions. HSM API functionality and commands that are not required to support specified functionality must be disabled before the equipment is commissioned.
For example, for HSMs used in transaction processing operations: 

PIN Security Requirements:
29-4.3 When HSMs are connected to online systems, controls are in place to prevent the use of an HSM to perform privileged or sensitive functions that are not available during routine HSM operations.
Testing Procedures:
Examples of sensitive functions include but are not limited to: loading of key components, outputting clear-text key components, and altering HSM configuration.
29-4.3 Examine HSM configurations and observe processes to verify that HSMs are not enabled in a sensitive state when connected to online systems. 

PIN Security Requirements:
29-4.4.1 Running self-tests to ensure the correct operation of the device
Testing Procedures:
29-4.4.1 Examine records of device inspections and test results to verify that self-tests are run on devices to ensure the correct operation of the device. 

PIN Security Requirements:
29-4.4.2 Installing (or re-installing) devices only after confirming that the device has not been tampered with or compromised
Testing Procedures:
29-4.4.2 Observe inspection processes and interview responsible personnel to verify that devices are installed, or reinstalled, only after confirming that the device has not been tampered with or compromised. 

PIN Security Requirements:
29-4.4.3 Physical and/or functional tests and visual inspection to confirm that physical and logical controls and anti-tamper mechanisms are not modified or removed
Testing Procedures:
29-4.4.3 Observe inspection processes and interview responsible personnel to confirm processes include physical and/or functional tests and visual inspection to verify that physical and logical controls and anti-tamper mechanisms are not modified or removed. 

PIN Security Requirements:
29-4.4.4 Maintaining records of the tests and inspections, and retaining records for at least one year
Testing Procedures:
29-4.4.4.a Examine records of inspections and interview responsible personnel to verify records of the tests and inspections are maintained.
29-4.4.4.b Examine records of inspections to verify records are retained for at least one year 

PIN Security Requirements:
29-5 Maintain HSMs in tamper-evident packaging or in secure storage until ready for installation.
Testing Procedures:
29-5.a Examine documented procedures to verify they require devices be maintained in tamper-evident packaging until ready for installation.
29-5.b Observe a sample of received devices to verify they are maintained in tamperevident packaging until ready for installation. 

PIN Security Requirements:
30-1 POI devices must be secured throughout the device lifecycle. The responsible entity must: 

30-1.a Obtain and examine documentation of inventory control and monitoring procedures. Determine that the procedures cover: 

30-1.b Interview applicable personnel to determine that procedures are known and followed. 

PIN Security Requirements:
30-2 Secure device-management processes must be implemented. The responsible entity must: 

30-2 Obtain and examine documentation of POI device-management processes. Determine that procedures cover: 

PIN Security Requirements:
31-1.1 HSMs require dual control (e.g., to invoke the system menu) to implement for all critical decommissioning processes.
Testing Procedures:
31-1.1.a Examine documented procedures for removing HSM from service to verify that dual control is implemented for all critical decommissioning processes.
31-1.1.b Interview personnel and observe demonstration (if HSM is available) of processes for removing HSMs from service to verify that dual control is implemented for all critical decommissioning processes. 

PIN Security Requirements:
31-1.2 Key are rendered irrecoverable (for example, zeroized) for SCDs. If data cannot be rendered irrecoverable, devices must be physically destroyed under dual control to prevent the disclosure of any sensitive data or keys.
Testing Procedures:
31-1.2 Interview personnel and observe demonstration of processes for removing SCDs from service to verify that all keying material is rendered irrecoverable (for example, zeroized), or that devices are physically destroyed under dual-control to prevent the disclosure of any sensitive data or keys. 

PIN Security Requirements:
31-1.3 SCDs being decommissioned are tested and inspected to ensure keys have been rendered irrecoverable.
Testing Procedures:
31-1.3 Interview personnel and observe processes for removing SCDs from service to verify that tests and inspections of devices are performed to confirm that keys have been rendered irrecoverable or the devices are physically destroyed. 

PIN Security Requirements:
31-1.4 Affected entities are notified before devices are returned.
Testing Procedures:
31-1.4 Interview responsible personnel and examine device-return records to verify that affected entities are notified before devices are returned. 

PIN Security Requirements:
31-1.5 Devices are tracked during the return process.
Testing Procedures:
31-1.5 Interview responsible personnel and examine device-return records to verify that devices are tracked during the return process. 

PIN Security Requirements:
31-1.6 Records of the tests and inspections are maintained for at least one year.
Testing Procedures:
31-1.6 Interview personnel and observe records to verify that records of the tests and inspections are maintained for at least one year. 

PIN Security Requirements:
32-1.1 Devices must not be authorized for use except under the dual control of at least two authorized people.
Note: Dual control consists of logical and/or physical characteristics. For example, dual control may be implemented for logical access via two individuals with two different passwords/authentication codes (at least five characters in length), or for physical access via a physical lock that requires two individuals, each with a different high-security key.
For devices that do not support two or more passwords/authentication codes, this may be achieved by splitting the single password used by the device into two halves, each half controlled by a separate authorized custodian. Each half must be a minimum of five characters.
Physical keys, authorization codes, passwords/authentication codes, or other enablers must be managed so that no one person can use both the enabler(s) and the device, which can create cryptograms of known keys or key components under a key-encipherment key used in production.
Testing Procedures:
32-1.1 Observe dual-control mechanisms and device-authorization processes to confirm that logical and/or physical characteristics are in place that prevent the device being authorized for use except under the dual control of at least two authorized people. 

PIN Security Requirements:
32-1.2 Passwords/authentication codes used for dual control must each be of at least five numeric and/or alphabetic characters.
Testing Procedures:
32-1.2 Observe password policies and configuration settings to confirm that passwords/authentication codes used for dual control must be at least five numeric and/or alphabetic characters. 

PIN Security Requirements:
32-1.3 Dual control must be implemented for the following: 

32-1.3 Examine dual-control mechanisms and observe authorized personnel performing the defined activities to confirm that dual control is implemented for the following: 

PIN Security Requirements:
32-1.4 Devices must not use default passwords/authentication codes.
Testing Procedures:
32-1.4.a Examine password policies and documented procedures to confirm default passwords/authentication codes must not be used for HSMs, KLDs, and other SCDs used to generate or load cryptographic keys.
32-1.4.b Observe device configurations and interview device administrators to verify that HSMs, KLDs, and other SCDs used to generate or load cryptographic keys do not use default passwords/authentication codes. 

PIN Security Requirements:
32-1.5 To detect any unauthorized use, devices are at all times within a secure room and either: 

32-1.5.a Examine documented procedures to confirm that they require devices are either: 

32-1.5.b Interview responsible personnel and observe devices and processes to confirm that devices are either: 

PIN Security Requirements:
33-1 Written procedures must exist, and all affected parties must be aware of those procedures. Records must be maintained of the tests and inspections performed on PIN-processing devices before they are placed into service, as well as devices being decommissioned.
Testing Procedure:
33-1.a Examine documented procedures/processes and interview responsible personnel to verify that all affected parties are aware of required processes and are provided suitable guidance on procedures for devices placed into service, initialized, deployed, used, and decommissioned.
33-1.b Verify that written records exist for the tests and inspections performed on PIN-processing devices before they are placed into service, as well as devices being decommissioned. 

PIN Security Requirements:
15-3 Mechanisms must exist to prevent a non-authorized KDH from performing key transport, key exchange, or key establishment with POIs. POIs and key-distribution hosts (KDHs) using public-key schemes must validate authentication credentials of other such devices involved in the communication immediately prior to any key transport, exchange, or establishment. Mutual authentication of the sending and receiving devices must be performed.
Note: Examples of this kind of validation include ensuring the SCD serial number is listed in a table of "permitted" devices, checking current certificate revocation lists or embedding valid authorized KDH certificates in devices, and disallowing communication with unauthorized KDHs, as delineated by techniques defined in the Technical FAQs for PCI PTS POI Security Requirements.
Testing Procedures:
15-3.a Examine documented procedures to confirm they define procedures for mutual authentication of the sending and receiving devices, as follows: 

15-3.b Interview applicable personnel to verify that mutual authentication of the sending and receiving devices is performed, as follows: 

PIN Security Requirements:
15-4 Key-establishment and distribution procedures must be designed such that:
Within an implementation design, there shall be no means available for “man-in-the-middle” attacks—e.g., through binding of the KDH certificate upon the initial communication.
System implementations must be designed and implemented to prevent replay attacks—e.g., through the use of random nonces and time stamps as noted in ANSI TR 34.
Testing Procedures:
15-4 Examine system and process documentation to verify that key-establishment and distribution procedures are designed such that: 

PIN Security Requirements:
15-5 Key pairs generated external to the device that uses the key pair must be securely transferred and loaded into the device and must provide for key protection in accordance with this document. That is, the secrecy of the private key and the integrity of the public key must be ensured. The process must ensure that once keys are injected, they are no longer available for injection into other POI devices—i.e., key pairs are unique per POI device.
Testing Procedures:
15-5 If key pairs are generated external to the device that uses the key pair, perform the following: 

PIN Security Requirements:
18-4 POIs shall only communicate with a Certification Authority (CA) for the purpose of certificate signing (or for key injection where the certificate-issuing authority generates the key pair on behalf of the POI); and with KDHs for key management, normal transaction processing, and certificate (entity) status checking.
Testing Procedures:
18-4.a Examine documented procedures to verify that: 

18-4.b Interview responsible personnel and observe POI configurations to verify that: 

PIN Security Requirements:
18-5 KDHs shall only communicate with POIs for the purpose of key management and normal transaction processing, and with CAs for the purpose of certificate signing and certificate (entity) status checking.
Testing Procedures:
18-5.a Examine documented procedures to verify that: 

18-5.b Interview responsible personnel and observe KDH configurations to verify that: 

PIN Security Requirements:
19-6 Key pairs must not be reused for certificate renewal or replacement— i.e., new key pairs must be generated. Each key pair must result in only one certificate.
19-6.a Examine documented procedures for requesting certificate issue, renewal, and replacement to verify procedures include generation of a unique key pair for each: 

19-6.b Interview responsible personnel and observe certificate issuing and replacement processes to verify that: 

PIN Security Requirements:
19-7 KDH private keys must not be shared between devices except for load balancing and disaster recovery.
Testing Procedures:
19-7 Examine documented processes to verify that KDH private keys are not permitted to be shared between devices, except for load balancing and disaster recovery. 

PIN Security Requirements:
19-8 POI private keys must not be shared between devices.
Testing Procedures:
19-8.a Examine documented processes to verify that POI private keys are not permitted to be shared between devices.
19-8.b Inspect public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI. 

PIN Security Requirements:
21-4 Private keys used to sign certificates, certificate status lists, messages, or for key protection must exist only in one or more of the following forms: 

Testing Procedures:
21-4.a Examine documented key-management procedures to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times.
21-4.b Observe key-management operations and interview key custodians and key-management supervisory personnel to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times. 

PIN Security Requirements:
10-4 All key-encryption keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed.
Testing Procedures:
10-4 Examine documented procedures to verify that all keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed. 

PIN Security Requirements:
15-5 Key pairs generated external to the device that uses the key pair must be securely transferred and loaded into the device and must provide for key protection in accordance with this document. That is, the secrecy of the private key and the integrity of the public key must be ensured. The process must ensure that once keys are injected, they are no longer available for injection into other POI devices—i.e., key pairs are unique per POI device.
Testing Procedures:
15-5 If key pairs are generated external to the device that uses the key pair, perform the following: 

PIN Security Requirements:
19-5 If a business rationale exists, a production platform (HSMs and servers/standalone computers) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the CA and RA server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements. At all times the HSMs and servers/computers must be physically and logically secured in accordance with these requirements.
Testing Procedures:
19-5 Interview personnel to determine whether production platforms are ever temporarily used for test purposes. If they are, verify that documented procedures require that: 

PIN Security Requirements:
19-6 Key pairs must not be reused for certificate renewal or replacement—i.e., new key pairs must be generated. Each key pair must result in only one certificate.
19-6.a Examine documented procedures for requesting certificate issue, renewal, and replacement to verify procedures include generation of a unique key pair for each: 

19-6.b Interview responsible personnel, examine records of past KDH-signing requests, and observe certificate issuing and replacement processes to verify that: 

PIN Security Requirements:
19-9.1 CA certificate signature keys, certificate (entity) status checking (for example, Certificate Revocation Lists) signature keys, or signature keys for updating valid/authorized host lists in encryption devices must not be used for any purpose other than subordinate entity certificate requests, certificate status checking, and self-signed root certificates.
Note: The keys used for certificate signing and certificate (entity) status checking (and if applicable, self-signed roots) may be for combined usage or may exist as separate keys dedicated to either certificate-signing or certificate (entity) status checking.
Testing Procedures:
19-9.1.a Examine certificate policy and documented procedures to verify that: 

Are not used for any purpose other than: 

19-9.1.b Interview responsible personnel and observe demonstration to verify that: 

Are not used for any purpose other than: 

PIN Security Requirements:
19-9.2 CAs that issue certificates to other CAs must not be used to issue certificates to POIs⎯i.e., a CA cannot sign certificates to both subordinate CAs and end-entity (POI) devices.
Testing Procedures:
19-9.2 If a CA issues certificates to other CAs, examine the CA certificate policy and documented procedures to verify that the CA does not also issue certificates to POI devices. 

PIN Security Requirements:
19-10 Public-key-based implementations must provide mechanisms for restricting and controlling the use of public and private keys. For example, this can be accomplished through the use of X.509 compliant certificate extensions.
Testing Procedures:
19-10 Examine documented procedures to verify that mechanisms are defined for restricting and controlling the use of public and private keys such that they can only be used for their intended purpose. 

PIN Security Requirements:
19-11 CA private keys must not be shared between devices except for load balancing and disaster recovery.
Testing Procedures:
19-11 Examine CA’s documented processes to verify that CA private keys are not permitted to be shared between devices, except for load balancing and disaster recovery. 

PIN Security Requirements:
19-12 Certificates used in conjunction with remote key-distribution functions must only be used for a single purpose. 

If CA separation is used to ensure certificate segmentation: 

If policy-based certificate segmentation is used to achieve unique purpose certificates: 

19-12.a Examine implementation schematics and other relevant documentation to identify PKI architecture and where certificates are used in the implementation.
19.12.b Identify mechanism(s) used to restrict certificates to a single-purpose use as either:
a) Separation of the Sub-CAs issuing the certificates, or
b) Policy-based certificate segmentation that depends upon a characteristic of the certificate.
19-12.c If CA separation is used to ensure certificate segmentation, confirm that the following are true:
a) The designation of each Sub-CA is documented.
b) Policies and procedures are in place to support and require appropriate use of each Sub-CA.
c) Any Sub-CA used to produce certificates used for remote key-delivery functions (i.e. encryption, POI authentication, or KDH authentication) is not used to produce certificates used for any other purpose.
d) Any Sub-CA used to produce certificates for POI firmware and POI application authentication is not used for any other purpose.
19-12.d If policy-based certificate segmentation is used to ensure certificate segmentation, confirm that all of the following are true:
a) The method of segmentation between certificates is clearly stated in the certificate practice statement (CPS) for the CA.
b) Certificates issued for all of the remote key-distribution functions (i.e. encryption, POI authentication, or KDH authentication) include a mechanism to identify designation for this purpose.
c) Policies and procedures are in place to support and require specific function designation for each certificate issued, and there is evidence that such procedures are followed.
d) The SCDs involved in the remote key-delivery functions ensure that the certificates used for these functions are designated for the purpose for which they are being used.
e) The SCDs involved in remote key delivery ensure that certificates with remote key-delivery designation are not used for some other purpose.
19-12.e Confirm that the mechanisms in place are effective in restricting the certificates to a single purpose use as noted below: 
a) Certificates associated with encryption for remote key-distribution functions are not used for any other purpose. 
b) Certificates associated with authentication of the KDH are not used for any other purpose. 
c) Certificates associated with authentication of the POI are not used for any other purpose. 
d) Certificates associated with authentication of POI firmware and POI applications are not used for any other purpose. 

PIN Security Requirements:
21-4 Private keys used to sign certificates, certificate status lists, messages, or for key protection must exist only in one or more of the following forms: 

Testing Procedures:
21-4.a Examine documented key-management procedures to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times.
21-4.b Observe key-management operations and interview key custodians and key-management supervisory personnel to verify that private keys used to sign certificates, certificate-status lists, messages, or for key protection must exist only in one or more of the approved forms at all times. 

PIN Security Requirements:
22-3 Root CAs must provide for segmentation of risk to address key compromise. An example of this would be the implementation of subordinate CAs.
Testing Procedures:
22-3 Through the examination of documented procedures, interviews and observation confirm that Root CAs provide for segmentation of risk to address key compromise. 

PIN Security Requirements:
22-4.1 The CA must cease issuance of certificates if a compromise is known or suspected and perform a damage assessment, including a documented analysis of how and why the event occurred.
Testing Procedures:
22-4.1.a Examine documented procedures to verify that the following are required in the event a compromise is known or suspected: 

22-4.1.b Interview responsible personnel and observe process to verify that in the event a compromise is known or suspected: 

PIN Security Requirements:
22-4.2 In the event of a confirmed compromise, the CA must determine whether to revoke and reissue all signed certificates with a newly generated signing key.
Testing Procedures:
22-4.2.a Examine documented procedures to verify that in the event of a confirmed compromise, procedures are defined for the CA to determine whether to revoke and reissue all signed certificates with a newly generated signing key.
22-4.2.b Interview responsible personnel to verify procedures are followed for the CA to determine whether to revoke and reissue all signed certificates with a newly generated signing key. 

PIN Security Requirements:
22-4.3 Mechanisms (for example, time stamping) must exist to prevent the usage of fraudulent certificates, once identified.
Testing Procedures:
22-4.3.a Examine documented procedures to verify that mechanisms are defined to prevent the usage of fraudulent certificates.
22-4.3.b Interview responsible personnel and observe implemented mechanisms to verify the prevention of the use of fraudulent certificates 

PIN Security Requirements:
22-4.4 The compromised CA must notify any superior or subordinate CAs of the compromise. The compromise damage analysis must include a determination of whether subordinate CAs and KDHs must have their certificates reissued and distributed to them or be notified to apply for new certificates.
Testing Procedures:
22-4.4.a Examine documented procedures to verify that the following procedures are required in the event of a compromise: 

22-4.4.b Interview responsible personnel to verify that the following procedures are performed in the event a compromise: 

PIN Security Requirements:
22-5 Minimum cryptographic strength for the CA system shall be: 

The key-pair lifecycle shall result in expiration of KDH keys every five years, unless another mechanism exists to prevent the use of a compromised KDH private key.
Testing Procedures:
22-5.a Interview appropriate personnel and examine documented procedures for the creation of these keys.
22-5.b Verify that the following minimum key sizes exist for RSA keys or the equivalent for the algorithm used as defined in Annex C: 

22-5.c Verify that KDH keys expire every five years unless another mechanism exists to prevent the use of a compromised KDH private key. 

PIN Security Requirements:
25-2.1 All user access must be restricted to actions authorized for that role.
Note: Examples of how access can be restricted include the use of CA software and operating-system and procedural controls.
Testing Procedures:
25-2.1.a Examine documented procedures to confirm that access to material that can be used to construct secret and private keys must be restricted to actions authorized for that role.
25-2.1.b Observe user role assignments and access-control mechanisms to verify that access to material that can be used to construct secret and private keys is restricted to actions authorized for that role. 

PIN Security Requirements:
25-3.1 CA systems that issue certificates to other CAs and KDHs must be operated offline using a dedicated closed network (not a network segment). 

25-3.1 Examine network diagrams and observe network and system configurations to verify: 

PIN Security Requirements:
25-3.2 For CAs operated online—e.g., POI-signing CAs: CA or Registration Authority (RA) software updates must not be done over the network (local console access must be used for CA or RA software updates).
Testing Procedures:
25-3.2 Examine software update processes to verify that local console access is used for all CA or RA software updates. 

PIN Security Requirements:
25-3.3 For CAs operated online—e.g., POI-signing CAs: Non-console access must use multi-factor authentication. This also applies to the use of remote console access.
Testing Procedures:
25-3.3 Examine remote-access mechanisms and system configurations to verify that all non-console access, including remote access, requires multi-factor authentication. 

PIN Security Requirements:
25-3.4 For CAs operated online—e.g., POI-signing CAs: Non-console user access to the CA or RA system environments shall be protected by authenticated encrypted sessions. No other remote access is permitted to the CA or RA platform(s) for system or application administration.
Note: Access for monitoring only (no create, update, delete capability) of online systems may occur without restriction.
Testing Procedures:
25-3.4.a Examine non-console access mechanisms and system configurations to verify that all non-console user access is protected by authenticated encrypted sessions.
25-3.4.b Observe an authorized CA personnel attempt non-console access to the host platform using valid CA credentials without using an authenticated encrypted session to verify that non-console access is not permitted. 

PIN Security Requirements:
25-3.5 CA certificate (for POI/KDH authentication and validity status checking) signing keys must only be enabled under at least dual control.
Note: Certificate requests may be vetted (approved) using single user logical access to the RA application.
Testing Procedures:
25-3.5.a Examine the certificate security policy and certification practice statement to verify that CA certificate-signing keys must only be enabled under at least dual control.
25-3.5.b Observe certificate-signing processes to verify that signing keys are enabled only under at least dual control. 

PIN Security Requirements:
25-4 The CA shall require a separation of duties for critical CA functions to prevent one person from maliciously using a CA system without detection, the practice referred to as “dual control.” At a minimum, there shall be multi-person control for operational procedures such that no one person can gain control over the CA signing key(s).
Testing Procedures:
25-4.a Examine documented procedures to verify they include following: 

25-4.b Observe CA operations and interview responsible personnel to verify: 

PIN Security Requirements:
25-5.1 All vendor-default IDs must be changed, removed, or disabled unless necessary for a documented and specific business reason. Vendor default IDs that are required as owners of objects or processes or for installation of patches and upgrades must only be enabled when necessary and otherwise must be disabled from login.
Testing Procedures:
25-5.1.a Examine documented procedures to verify that: 

25-5.1.b Examine system configurations and interview responsible personnel to verify that: 

PIN Security Requirements:
25-5.2 Vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step must be changed, removed, or disabled before installing a system on the network.
Testing Procedures:
25-5.2.a Examine documented procedures to verify that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the network.
25-5.2.b Examine system configurations and interview responsible personnel to verify that vendor defaults, including passwords and SNMP strings, that exist and are not addressed in the prior step are changed, removed, or disabled before installing a system on the network. 

PIN Security Requirements:
25-6.1 Audit logs must be archived for a minimum of two years.
Testing Procedures:
25-6.1 Examine audit trail files to verify that they are archived for a minimum of two years. 

PIN Security Requirements:
25-6.2 Records pertaining to certificate issuance and revocation must, at a minimum, be retained for the life of the associated certificate.
Testing Procedures:
25-6.2.a For a sample of certificate issuances, examine audit records to verify that the records are retained for at least the life of the associated certificate.
25-6.2.b For a sample of certificate revocations, examine audit records to verify that the records are retained for at least the life of the associated certificate 

PIN Security Requirements:
25-6.3 Logical events are divided into operating-system and CA application events. For both, the following must be recorded in the form of an audit record: 

25-6.3.a Examine audit trails to verify that logical events are divided into operating-system and CA application events.
25-6.3.b Examine a sample of operating-system logs to verify they contain the following information: 

25-6.3.c Examine a sample of application logs to verify they contain the following information: 

PIN Security Requirements:
25-7.1 Certificate-processing system components operated online must be protected by a firewall(s) from all unauthorized access, including casual browsing and deliberate attacks. Firewalls must minimally be configured to: 

Testing Procedures:
25-7.1.a Examine network and system configurations to verify that certificate-processing system components operated online are protected from unauthorized access by firewall(s).
25-7.1.b Examine firewall configurations for verify they are configured to: 

PIN Security Requirements:
25-7.2 Online certificate-processing systems must employ individually or in combination network and host-based intrusion detection systems (IDS) to detect inappropriate access. At a minimum, database servers and the application servers for RA and web, as well as the intervening segments, must be covered.
Testing Procedures:
25-7.2.a Observe network-based and/or host-based IDS configurations to verify that on-line certificate-processing systems are protected by IDS to detect inappropriate access.
25-7.2.b Verify that IDS coverage includes all database servers, RA application servers and web servers, as well as the intervening segments. 

PIN Security Requirements:
25-8.1 Initial, assigned passphrases are pre-expired (user must replace at first logon).
Testing Procedures:
25-8.1 Examine password procedures and observe security personnel to verify that first-time passwords for new users, and reset passwords for existing users, are set to a unique value for each user and are pre-expired. 

PIN Security Requirements:
25-8.2 Use of group, shared, or generic accounts and passwords, or other authentication methods is prohibited.
Testing Procedures:
25-8.2.a For a sample of system components, examine user ID lists to verify the following: 

25-8.2.b Examine authentication policies/procedures to verify that group and shared passwords or other authentication methods are explicitly prohibited.
25-8.2.c Interview system administrators to verify that group and shared passwords or other authentication methods are not distributed, even if requested. 

PIN Security Requirements:
25-8.3 If passwords are used, system-enforced expiration life must not exceed 90 days and a minimum life at least one day.
Testing Procedures:
25-8.3 For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days and have a minimum life of at least one day. 

PIN Security Requirements:
25-8.4 Passwords must have a minimum length of eight characters using a mix of alphabetic, numeric, and special characters or equivalent strength as defined in NIST SP 800-63B.
Testing Procedures:
25-8.4 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to be at least eight characters long and contain numeric, alphabetic, and special characters or equivalent strength as defined in NIST SP 800-63B. 

PIN Security Requirements:
25-8.5 Limit repeated access attempts by locking out the user ID after not more than five attempts.
Testing Procedures:
25-8.5 For a sample of system components, obtain and inspect system configuration settings to verify that authentication parameters are set to require that a user’s account be locked out after not more than five invalid logon attempts. 

PIN Security Requirements:
25-8.6 Authentication parameters must require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months.
Testing Procedures:
25-8.6 For a sample of system components, obtain and inspect system configuration settings to verify that authentication parameters are set to require a system-enforced passphrase history, preventing the reuse of any passphrase used in the last 12 months. 

PIN Security Requirements:
25-8.7 Passwords are not stored on any of the systems except in encrypted form or as part of a proprietary one-way transformation process, such as those used in UNIX systems.
Testing Procedures:
25-8.7 For a sample of system components, obtain and inspect system configuration settings to verify that passwords are not stored unless encrypted as part of a proprietary one-way hash. 

PIN Security Requirements:
25-8.8 The embedding of passwords in shell scripts, command files, communication scripts, etc. is strictly prohibited.
Testing Procedures:
25-8.8.a Examine policies and procedures and interview personnel to determine that the embedding of passwords in shell scripts, command files, communication scripts, etc. is strictly prohibited.
25-8.8.b Inspect a sample of shell scripts, command files, communication scripts, etc. to verify that passwords are not embedded in shell scripts, command files, or communication scripts. 

PIN Security Requirements:
25-8.9 Where log-on security tokens (for example, smart cards) are used, the security tokens must have an associated usage-authentication mechanism, such as a biometric or associated PIN/passphrase to enable their usage. The PIN/passphrase must be at least eight decimal digits in length, or equivalent.
Note: Log-on security tokens (for example, smart cards) and encryption devices are not subject to the pass-phrase management requirements for password expiry as stated above.
Testing Procedures:
25-8.9.a If log-on security tokens are used, observe devices in use to verify that the security tokens have an associated usage-authentication mechanism, such as a biometric or associated PIN/passphrase to enable their usage.
25-8.9.b Examine token-configuration settings to verify parameters are set to require that PINs/passwords be at least eight decimal digits in length, or equivalent. 

PIN Security Requirements:
25-9 Implement a method to synchronize all critical system clocks and times for all systems involved in key-management operations.
Testing Procedures:
25-9.a Examine documented procedures and system configuration standards to verify a method is defined to synchronize all critical system clocks and times for all systems involved in key-management operations.
25-9.b For a sample of critical systems, examine the time-related system parameters to verify that system clocks and times are synchronized for all systems involved in key-management operations.
25-9.c If a manual process is defined, verify that the documented procedures require that it occur at least quarterly.
25-9.d If a manual process is defined, examine system configurations and synchronization logs to verify that the process occurs at least quarterly. 

PIN Security Requirements:
28-2 CA operations must be dedicated to certificate issuance and management. All physical and logical CA system components must be separated from key-distribution systems.
Testing Procedures:
28-2.a Examine documented procedures to verify: 

28-2.b Observe CA system configurations and operations to verify they are dedicated to certificate issuance and management.
28-2.c Observe system and network configurations and physical access controls to verify that all physical and logical CA system components are separated from key-distribution systems. 

PIN Security Requirements:
28-3 Each CA operator must develop a certification practice statement (CPS). (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.) 

Note: This may take the form of a declaration by the CA operator of the details of its trustworthy system and the practices it employs in its operations and in support of the issuance of certificates. A CPS may take the form of either a specific, single document or a collection of specific documents.
The CPS must be consistent with the requirements described within this document. The CA shall operate in accordance with its CPS.
Testing Procedures:
28-3.a Examine documented certification practice statement (CPS) to verify that the CPS is consistent with the requirements described within this document.
28-3.b Examine documented operating procedures to verify they are defined in accordance with the CPS.
28-3.c Interview personnel and observe CA processes to verify that CA operations are in accordance with its CPS. 

PIN Security Requirements:
28-4 Each CA operator must develop a certificate policy. (See RFC 3647- Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework for an example of content.)
Testing Procedures:
28-4 Examine documented certificate policy to verify that the CA has one in place. 

PIN Security Requirements:
28-5.1 For CA and KDH certificate-signing requests, including certificate or key-validity status changes—for example, revocation, suspension, replacement—verification must include validation that: 

28-5.1.a Examine documented procedures to verify that certificate-signing requests, including certificate or key-validity status changes, require validation that: 

28-5.1.b Observe certificate-signing requests, including certificate or key-validity status changes, to verify they include validation that: 

PIN Security Requirements:
28-5.2 RAs must retain documentation and audit trails relating to the identification of entities for all certificates issued and certificates whose status had changed for the life of the associated certificates.
Testing Procedures:
28-5.2 Examine documentation and audit trails to verify that the identification of entities is retained for the life of the associated certificates: 

PIN Security Requirements:
32-2.1 The certificate-processing operations center must implement a three-tier physical security boundary, as follows: 

32-2.1.a Examine physical security policies to verify three tiers of physical security are defined as follows: 

32-2.1.b Observe the physical facility to verify three tiers of physical security are implemented as follows: 

PIN Security Requirements:
32-2.2.1 The facility entrance only allows authorized personnel to enter the facility.
Testing Procedures:

32-2.2.1.a Examine physical-security procedures and policies to verify they require that the facility entrance allows only authorized personnel to enter the facility.
32-2.2.1.b Observe the facility entrance and observe personnel entering the facility to verify that only authorized personnel are allowed to enter the facility. 

PIN Security Requirements:
32-2.2.2 The facility has a guarded entrance or a foyer with a receptionist. No entry is allowed for visitors if the entryway is not staffed—i.e., only authorized personnel who badge or otherwise authenticate themselves can enter when entryway is unstaffed.
Testing Procedures:
32-2.2.2.a Examine physical-security procedures and policies to verify they require that the facility have a guarded entrance or a foyer with a receptionist or the entryway prevents access to visitors.
32-2.2.2.b Observe the facility entrance to verify it has a guarded entrance or a foyer with a receptionist. 

PIN Security Requirements:
32-2.2.3 Visitors (guests) to the facility must be authorized and be registered in a logbook.
Testing Procedures:
32-2.2.3.a Examine physical-security procedures and policies to verify they require visitors to the facility to be authorized and be registered in a logbook.
32-2.2.3.b Observe the facility entrance and observe personnel entering the facility to verify that visitors are authorized and registered in a logbook. 

PIN Security Requirements:
32-2.3.1 Visitors must be authorized and escorted at all times within the Level 2 environment.
Testing Procedures:
32-2.3.1.a Examine documented policies and procedures to verify that authorized visitors must be escorted at all times within the Level 2 environment.
32-2.3.1.b Interview personnel and observe visitors entering the environment to verify that visitors are authorized and escorted at all times within the Level 2 environment. 

PIN Security Requirements:
32-2.3.2 Access logs must record all personnel entering the Level 2 environment.
Note: The logs may be electronic, manual, or both.
Testing Procedures:
32-2.3.2.a Examine documented policies and procedures to verify that access logs are required to record all personnel entering the Level 2 environment.
32-2.3.2.b Observe personnel entering the Level 2 barrier and examine corresponding access logs to verify that all entry through the Level 2 barrier is logged. 

PIN Security Requirements:
32-2.4 The Level 2 entrance must be monitored by a video-recording system.
Testing Procedures:
32-2.4.a Observe the Level 2 entrance to verify that a video-recording system is in place.
32-2.4.b Examine a sample of recorded footage to verify that the videorecording system captures all entry through the Level 2 entrance. 

PIN Security Requirements:
32-2.5.1 Doors to the Level 3 secure room must have locking mechanisms.
Testing Procedures:
32-2.5.1 Observe Level 3 environment entrances to verify that all doors to the Level 3 environment have locking mechanisms. 

PIN Security Requirements:
32-2.5.2 The Level 3 environment must be enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars. For example, the Level 3 environment may be implemented within a “caged” environment.
Testing Procedures:
32-2.5.2.a Examine physical security documentation for the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as have true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars
32-2.5.2.b Examine the physical boundaries of the Level 3 environment to verify that the environment is enclosed on all sides (including the ceiling and flooring areas) using techniques such as true floor-to-ceiling (slab-to-slab) walls, steel mesh, or bars and protection from entry from below floors and above ceilings. 

PIN Security Requirements:
32-2.6.1 All authorized personnel with access through the Level 3 barrier must:
Have successfully completed a background security check.
Be assigned resources (staff, dedicated personnel) of the CA operator with defined business needs and duties.
Note: This requirement applies to all personnel with pre-designated access to the Level 3 environment.
Testing Procedures:
32-2.6.1.a Examine documented policies and procedures to verify they require personnel authorized as having access through the Level 3 barrier to:
Have successfully completed a background security check.
Be assigned resources of the CA operator with defined business needs and duties.
32-2.6.1.b Interview responsible HR personnel to verify that background checks are conducted (within the constraints of local laws) on CA personnel prior such personnel being authorized for access through the Level 3 barrier.
32-2.6.1.c Interview a sample of personnel authorized for access through the Level 3 barrier to verify that they are assigned resources of the CA with defined business needs and duties. 

PIN Security Requirements:
32-2.6.2 Other personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.
Testing Procedures:
32-2.6.2.a Examine documented policies and procedures to verify that personnel requiring entry to this level must be accompanied by two (2) authorized and assigned resources at all times.
32-2.6.2.b Interview a sample of responsible personnel to verify that personnel requiring entry to this level are accompanied by two (2) authorized and assigned resources at all times. 

PIN Security Requirements:
32-2.7.1 The mechanism for enforcing dual-control and dual-occupancy must be automated.
Testing Procedures:
32-2.7.1.a Examine documented policies and procedures to verify that the defined enforcement mechanism is automated.
32-2.7.1.b Observe enforcement mechanism configuration to verify it is automated. 

PIN Security Requirements:
32-2.7.2 The system must enforce anti-pass-back.
Testing Procedures:
32-2.7.2.a Examine documented policies and procedures to verify that the system is required to enforce anti-pass-back.
32-2.7.2.b Observe mechanisms in use and authorized personnel within the environment to verify that anti-pass-back is enforced by the conduct of a test. 

PIN Security Requirements:
32-2.7.3 Dual occupancy requirements are managed using electronic (for example, badge and/or biometric) systems.
Testing Procedures:
32-2.7.3.a Examine documented policies and procedures to verify that dual occupancy requirements are defined to be managed using electronic (for example, badge and/or biometric) systems.
32-2.7.3.b Observe mechanisms in use and authorized personnel within the environment to verify that dual-occupancy requirements are managed using electronic systems. 

PIN Security Requirements:
32-2.7.4 Any time a single occupancy exceeds 30 seconds, the system must automatically generate an alarm and audit event that is followed up by security personnel.
Testing Procedures:
32-2.7.4.a Examine documented policies and procedures to verify that any time one person is alone in the room for more than 30 seconds, the system must automatically generate an alarm and an audit event that is followed up by security personnel.
32-2.7.4.b Observe mechanisms in use to verify that the system automatically generates an alarm event and an audit event when one person is alone in the room for more than 30 seconds.
32-2.7.4.c Examine a sample of audit events and interview security personnel to verify that the audit events are followed up by security personnel. 

PIN Security Requirements:
32-2.8.1 Invalid access attempts to the Level 3 room must create audit records, which must be followed up by security personnel
Testing Procedures:
32-2.8.1 Observe an invalid access attempt and examine correlating audit logs to verify that invalid access attempts to the Level 3 room create an audit log event. 

PIN Security Requirements:
32-2.9.1 A minimum of one or more cameras must provide continuous monitoring (for example, CCTV system) of the Level 3 environment, including the entry and exit. Note: Motion-activated systems that are separate from the intrusion-detection system may be used to activate recording activity.
Testing Procedures:
32-2.9.1.a Observe the Level 3 physical environment to verify that cameras are in place to monitor the Level 3 environment, including the entry and exit.
32-2.9.1.b Examine monitoring system configurations (e.g., CCTV systems) to verify that continuous monitoring is provided.
32-2.9.1.c If motion-activated systems are used for monitoring, observe system configurations for the motion-activated systems to verify they are separate from the intrusion-detection system. 

PIN Security Requirements:
32-2.9.2 The cameras must record to time-lapse VCRs or similar mechanisms, with a minimum of five frames equally recorded over every three seconds.
 Testing Procedures:
32-2.9.2 Examine monitoring system configurations to verify; 

PIN Security Requirements:
32-2.9.3 Continuous or motion-activated, appropriate lighting must be provided for the cameras.
Note: Visible spectrum lighting may not be necessary if the cameras do not require such lighting to capture images (for example, if infrared cameras are used).
Testing Procedures:
32-2.9.3.a Observe the Level 3 physical environment to verify that continuous or motion-activated lighting is provided for each camera monitoring the environment.
32-2.9.3.b Examine a sample of captured footage from different days and times to ensure that the lighting is adequate. 

PIN Security Requirements:
32-2.9.4 Surveillance cameras must be configured to prevent the monitoring of computer screens, keyboards, PIN pads, or other systems that may expose sensitive data. Cameras must not be able to be remotely adjusted to zoom in or otherwise observe the aforementioned.
Testing Procedures:
32-2.9.4.a Observe each camera locations in the Level 3 environment to verify they are not set to monitor computer screens, keyboards, PIN pads, or other systems that may expose sensitive data.
32-2.9.4.b Examine a sample of captured footage to verify it does not allow for the monitoring of computer screens, keyboards, PIN pads, or other systems that may expose sensitive data. 

PIN Security Requirements:
32-2.9.5 Personnel with access to the Level 3 environment must not have access to the media (for example, VCR tapes, digital-recording systems, etc.) containing the recorded surveillance data.
32-2.9.5.a Examine documented access policies and procedures to verify that personnel with access to the Level 3 environment are not permitted to have access to the media containing recorded surveillance data for that environment.
Testing Procedures:
32-2.9.5.b Examine Level 3 access lists as well as access controls to the media containing surveillance data, to verify that personnel with access to the Level 3 environment do not have access to the media containing recorded surveillance data. 

PIN Security Requirements:
32-2.9.6 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days. If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy (primary and backup) to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
Testing Procedures:
32-2.9.6.a Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived.
32-2.9.6.b If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.

PIN Security Requirements:
32-2.9.7 CCTV images must be backed up daily. The backup recording must be stored in a separate, secure location within the facility and must ensure segregation of duties between the users (personnel accessing the secure room) and administrators of the system. Alternatively, backups may be stored in other facilities via techniques such as disk mirroring, provided the storage is secure in accordance with these requirements.
Testing Procedures:
32-2.9.7 Examine backup techniques utilized to ensure that: 

PIN Security Requirements:
32-3.1 Any windows in the secure room must be locked and protected by alarmed sensors.
Testing Procedures:
32-3.1.a Observe all windows in the secure room to verify they are locked and protected by alarmed sensors.
32-3.1.b Examine configuration of window sensors to verify that the alarm mechanism is active.
32-3.1.c Test at least one window (if they can be opened) to verify that the alarms function appropriately. 

PIN Security Requirements:
32-3.2 Any windows or glass walls must be covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room.
Testing Procedures:
32-3.2 Observe all windows and glass walls in the secure room to verify they are covered, rendered opaque, or positioned to prevent unauthorized observation of the secure room. 

PIN Security Requirements:
32-3.3 The intrusion-detection system(s) must be connected to the alarm system and automatically activated every time all authorized personnel have performed an authenticated exit of the secure room. The system must be configured to activate within 30 seconds.
Testing Procedures:
32-3.3.a Examine security system configurations to verify: 

32-3.3.b Verify the IDS and alarms function correctly via: 

PIN Security Requirements:
32-3.4 Alarm activity must include unauthorized entry attempts or any actions that disable the intrusion-detection system.
Testing Procedures:
32-3.4 Examine security-system configurations to verify that an alarm event is generated for: 

PIN Security Requirements:
32-4.1 The access log must include the following details: 

32-4.1 Examine the access logbook to verify it contains the following information: 

PIN Security Requirements:
32-4.2 The logbook must be maintained within the Level 3 secure environment.
Testing Procedures:
32-4.2 Observe the location of the access logbook and verify that it is maintained within the Level 3 secure environment. 

PIN Security Requirements:
32-5 All access-control and monitoring systems (including intrusion-detection systems) are powered through an uninterruptible power source (UPS).
Testing Procedures:
32-5 Inspect uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems, including intrusion-detection systems, are powered through the UPS. 

PIN Security Requirements:
32-6.1 An individual must not sign off on an alarm event in which they were involved.
Testing Procedures:
32-6.1.a Examine documented procedures for responding to alarm events to verify that the procedure does not permit a person who was involved in an alarm event to sign-off on that alarm event.
32-6.1.b Determine who is authorized to sign off on alarm events.
32-6.1.c For a sample of documented alarm events, examine the record to verify that personnel authorized to sign off on alarm events were not also the cause of that event. 

PIN Security Requirements:
32-6.2 The use of any emergency entry or exit mechanism must cause an alarm event.
Testing Procedures:
32-6.2.a Examine security system configurations to verify that an alarm event is generated upon use of any emergency entry or exit mechanism.
32-6.2.b Conduct a test to verify the mechanisms work appropriately. 

PIN Security Requirements:
32-6.3 All alarms for physical intrusion necessitate an active response within 30 minutes by personnel assigned security duties.
Testing Procedures:
32-6.3.a Examine documented procedures to verify they require that all alarms for physical intrusion must be responded to within 30 minutes by personnel assigned security duties.
32-6.3.b Examine a sample of alarm events and interview personnel assigned with security-response duties to verify that alarms for physical intrusion are responded to within 30 minutes.
32-6.3.c Conduct a test to verify the appropriate response occurs. 

PIN Security Requirements:
32-7.1 If a manual synchronization process is used, synchronization must occur at least quarterly; events must be recorded, and variances documented; and documentation of the synchronization must be retained for at least a one-year period.
Testing Procedures:
32-7.1.a If a manual synchronization process is implemented, interview responsible personnel and examine records of synchronization to verify the mechanism is performed at least quarterly.
32-7.1.b Examine records of the synchronization process to verify that documentation is retained for at least one year. 

PIN Security Requirements:
1-2 Key-injection facilities must only inject keys using equipment that conforms to the requirements for SCDs.
Testing Procedures:
1-2. Examine documented procedures and system documentation to verify that key-injection platforms and systems used for managing cryptographic keys are required to conform to the requirements for SCDs. 

PIN Security Requirements:
1-3 Ensure that all hardware security modules (HSMs) are either: 

PIN Security Requirements:
1-4 The approval listing must match the deployed devices in the following characteristics: 

1-4.a For all PCI-approved HSMs used, examine HSM devices and examine the PCI SSC list of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM: 

1-4.b For all FIPS-approved HSMs used, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 or FIPS 140-3 Level 3 (or higher) approval listing for each HSM: 

PIN Security Requirements:
1-5 The KIF platform provider maintains documentation detailing the KIF architecture and key-management flows. The platform provider must: 

1-5.a Interview relevant personnel and examine documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
1-5.b Interview relevant personnel and examine documentation that describes and/or illustrates the architecture of the KIF to verify that all KIF components, key-management flows, and personnel interaction with key-management flows are identified and documented.
1-5.c Examine the key-management flows and interview personnel to verify: 

PIN Security Requirements:
5-1 Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Generation of cryptographic keys or key components must occur within an SCD. They must be generated by one of the following: 

Note: Random number generation is critical to the security and integrity of all cryptographic systems. All cryptographic key-generation relies upon good quality, randomly generated values.
Testing Procedures:
5-1.a Examine key-management policy documentation to verify that it requires that all devices used to generate cryptographic keys meet one of the following 

5-1.b Examine certification letters or technical documentation to verify that all devices used to generate cryptographic keys or key components meet one of the following 

5-1.c Examine procedures to be used for future generations and logs of past key generations to verify devices used for key generation are those as noted above, including validation of the firmware used. 

PIN Security Requirements:
6-1.1 Any clear-text output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the clear text of any key component/share. Each custodian’s access to clear-text output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.
6-1.1.a Examine documented procedures to verify the following: 

6-1.1.b Observe key-generation process demonstration and interview responsible personnel to verify: 

PIN Security Requirements:
6-1.2 There must be no point in the key-generation process where a single individual has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
Note: Key shares derived using a recognized secret-sharing algorithm or full-length key components are not considered key parts and do not provide any information regarding the actual cryptographic key.
Testing Procedures:
6-1.2.a Examine documented procedures for all key-generation methods and observe demonstrations of the key-generation process from end to end to verify there is no point in the process where a single person has the ability to determine, obtain, or ascertain any part of a clear-text key or all the components for a key.
6-1.2.b Examine key-generation logs to verify that: 

PIN Security Requirements:
6-1.3 Devices used for generation of clear-text key components that are output in the clear must either be powered off when not in use or require re-authentication whenever key generation is invoked.
Logically partitioned devices used concurrently for other processes— e.g., providing services simultaneously to host systems, such as for transaction processing—must have key-generation capabilities disabled when not in use and other activities are continuing.
Testing Procedures:
6-1.3 Examine documented procedures for all key-generation methods. Verify procedures require that: 

PIN Security Requirements:
6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (for example, unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.
Note: This does not apply to logically partitioned devices located in data centers that are concurrently used for other purposes, such as transaction processing.
Testing Procedures:
6-1.4.a Examine documented procedures for all key-generation methods to verify they include inspections of the key-generation equipment for evidence of tampering, prior to use⎯including verification that there is a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device).
6-1.4.b Observe key-generation set-up processes for all key types to verify that key-generation equipment is inspected prior to use, to ensure equipment does not show any signs of tampering⎯including verification that there is a validation step to ensure no unauthorized mechanism exists that might disclose a clear-text key or key component (e.g., a tapping device). 

PIN Security Requirements:
6-3.1 The room must have walls made of solid materials. The walls do not have to extend from true floor to true ceiling but do need to extend from floor to ceiling.
Testing Procedures:
6-3.1 Inspect the secure room designated for printing clear-text key components to verify that the walls are made of solid materials and extend from floor to ceiling. 

PIN Security Requirements:
6-3.2 Any windows into the secure room must be: 

6-3.2.a Observe all windows in the secure room to verify they are: 

6-3.2.b Examine configuration of window sensors to verify that the alarm mechanism is active. 

PIN Security Requirements:
6-3.3 An electronic access control system (for example, badge and/or biometrics) must be in place that: 

Testing Procedures:
6-3.3.a Observe authorized personnel entering the secure room to verify that a badge-control system is in place that enforces the following requirements: 

6-3.3.b Examine alarm mechanisms and interview alarm-response personnel to verify that the badge-control system supports generation of an alarm when one person remains alone in the secure room for more than 30 seconds. 

PIN Security Requirements:
6-3.4 CCTV cameras must record all activity, including recording events during dark periods through the use of infrared CCTV cameras or automatic activation of floodlights in case of any detected activity. This recording may be motion-activated, in which case the recording must continue for at least a minute after the last pixel of activity subsides.
Testing Procedures:
6-3.4 Inspect CCTV configuration and examine a sample of recordings to verify that CCTV monitoring is in place on a 24/7 basis, including the ability to record events during dark periods, and verify that, if motion-activated, recording continues for at least a minute after the last pixel of activity subsides. 

PIN Security Requirements:
6-3.5 Monitoring must be supported on a continuous (24/7) basis such that alarms can be resolved by authorized personnel.
Testing Procedures:
6-3.5 Inspect configuration of monitoring systems and interview monitoring personnel to verify that monitoring is supported on a continuous (24/7) basis and alarms can be resolved by authorized personnel. 

PIN Security Requirements:
6-3.6 The CCTV server and digital storage must be secured in a separate secure location that is not accessible to personnel who have access to the secure room.
Testing Procedures:
6-3.6.a Inspect location of the CCTV server and digital storage to verify they are located in a secure location that is separate from the secure room.
6-3.6.b Inspect access-control configurations for the CCTV server/storage secure location and the key-injection secure room to identify all personnel who have access to each area. Compare access lists to verify that personnel with access to the secure room do not have access to the CCTV server/storage secure location. 

PIN Security Requirements:
6-3.7 The CCTV cameras must be positioned to monitor: 

Testing Procedures:
6-3.7 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor: 

PIN Security Requirements:
6-3.8 CCTV cameras must be positioned so they do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials.
Testing Procedures:
6-3.8 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any combination locks, PIN pads, or keyboards used to enter passwords/authentication codes or other authentication credentials. 

PIN Security Requirements:
6-3.9 Images recorded from the CCTV system must be securely archived for a period of no less than 45 days. If digital-recording mechanisms are used, they must have sufficient storage capacity and redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
Testing Procedures:
6-3.9.a If digital-recording mechanisms are used, examine system configurations to verify that the systems have sufficient redundancy to prevent the loss of information necessary to reconstruct events for the most recent 45-day period.
6-3.9.b Examine storage of captured recordings to verify that at least the most recent 45 days of images are securely archived. 

PIN Security Requirements:
6-4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted—depending on media—immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
Examples of where such key residue may exist include (but are not limited to): 

6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures ensure the following: 

Examine logs of past destructions and deletions to verify that procedures are followed. 

6-4.b Observe the destruction process of each identified type of key residue and verify the following: 

PIN Security Requirements:
6-5 Asymmetric-key pairs must either be: 

6-5.a Examine documented procedures for asymmetric-key generation to confirm that procedures are defined to ensure that asymmetric-key pairs are either: 

6-5.b Observe key-generation processes to verify that asymmetric-key pairs are either: 

PIN Security Requirements:
6-6 Policy and procedures must exist to ensure that clear-text private or secret keys or their components/shares are not transmitted across insecure channels. Preclusions include but are not limited to: 

6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting clear-text private or secret keys or their components/shares across insecure channels, including but not limited to: 

6-6.b From observation of key-management processes verify that clear-text private or secret keys or their components are not transmitted across insecure channels, including but not limited to: 

PIN Security Requirements:
7-1 Written key-generation policies and procedures must exist, and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. All key-creation events performed by a key-injection facility must be documented. Procedures for creating all keys must be documented.
Testing Procedures:
7-1.a Examine documented key-generation procedures to confirm that they include all aspects of key-generation operations and address all keys in scope.
7-1.b Interview those responsible for the key-generation processes (including key custodians, supervisory staff, technical management, etc.) to verify that the documented procedures are known and understood by all affected parties.
7-1.c Observe key-generation ceremonies whether actual or for demonstration purposes and verify that the documented procedures are demonstrably in use. 

PIN Security Requirements:
7-2 Logs must exist for the generation of higher-level keys such as KEKs exchanged with other organizations and MFKs and BDKs. The minimum log contents include date and time, object name/identifier, purpose, name and signature of individual(s) involved, and tamperevident package number(s) and serial number(s) of device(s) involved.
Testing Procedures:
7-2.a Examine documented key-generation procedures to verify that all key-generation events for higher-level keys (e.g., KEKs shared with other organizations or otherwise manually loaded as components and MFKs and BDKs) must be logged.
7-2.b Observe demonstrations for all types of key-generation events to verify that all key-generation events are logged.
7-2.c Examine logs of key generation to verify that exchanges of higher-level keys with other organizations have been recorded and that all required elements were captured. 

PIN Security Requirements:
8-1 Keys must be transferred either encrypted, as two or more full-length clear-text components, key shares, or within an SCD. 
Clear-text key components/shares must be transferred in SCDs or using tamper-evident, authenticable packaging. 

Note: Components of encryption keys must be transferred using different communication channels, such as different courier services. It is not sufficient to send key components for a specific key on different days using the same communication channel.
Testing Procedures:
8-1.a Determine whether keys are transmitted encrypted, as clear-text components/shares, or within an SCD.
8-1.b If key components are transmitted in clear text using pre-numbered, tamperevident, authenticable packaging, perform the following: 

 8-1.c Where SCDs are used to convey components/shares, 

8-1.d Where an SCD is conveyed with pre-loaded secret and/or private keys, perform the following: 

PIN Security Requirements:
8-2 A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares sufficient to form the necessary threshold to derive the key.
Note: An m-of-n scheme is a component- or share-allocation scheme where m is the number of shares or components necessary to form the key, and n is the number of the total set of shares or components related to the key. Management of the shares or components must be sufficient to ensure that no one person can gain access to enough of the item to form the key alone.
E.g., in an m-of-n scheme (which must use a recognized secret-sharing scheme such as Shamir), such that any three key components or shares (i.e., m = 3) can be used to derive the key, no single individual can have access to more than two components/shares.
Testing Procedures:
8-2.a Examine documented procedures to verify they include controls to ensure that no single person can gain access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify procedures include: 

8-2.b Observe key-transfer processes and interview personnel to verify that controls are implemented to ensure that no single person can gain access to components or shares of this key or to any other medium containing other components or shares of this key that are sufficient to form the necessary threshold to derive the key. Verify the implemented controls ensure the following: 

8-2.c Examine records of past key transfers to verify that the method used did not allow for any personnel to have access to components or shares sufficient to form the key. 

PIN Security Requirements:
8-3 E-mail shall not be used for the conveyance of secret or private keys or their components/shares, even if encrypted, unless the key (or component/share) has already been encrypted in accordance with these requirements—i.e., in an SCD. This is due to the existence of these key values in memory just prior to encryption or subsequent to decryption. In addition, corporate e-mail systems allow the recovery by support staff of the clear text of any encrypted text or files conveyed through those systems.
Other similar mechanisms, such as SMS, fax, or telephone shall not be used to convey clear-text key values.
Testing Procedures:
8-3 Validate through interviews, observation, and log inspection that e-mail, SMS, fax, or telephone or similar communication is not used as means to convey secret or private keys or key components/shares. 

PIN Security Requirements:
8-4 Public keys must be conveyed in a manner that protects their integrity and authenticity. Examples of acceptable methods include: 

PIN Security Requirements:
9-1 During the process to convey it, any single clear-text secret or private key component/share must at all times be either: 

Note: No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key.
Testing Procedures:
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text key component must at all times be either: 

9-1.b Observe key-management processes, examine associated logs, and interview responsible personnel to verify processes are implemented to ensure that any single clear-text key component is at all times either: 

PIN Security Requirements:
9-2 Packaging or mailers (i.e., pre-numbered, tamper-evident packaging) containing clear-text key components are examined for evidence of tampering before being opened. Any sign of package tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, and the result is that one person could have knowledge of the key, it must result in the destruction and replacement of: 

9-2.a Verify documented procedures include requirements for all packaging or mailers containing clear-text key components to be examined for evidence of tampering before being opened.
9-2.b Interview responsible personnel and observe processes to verify that all packaging or mailers containing clear-text key components are examined for evidence of tampering before being opened.
9-2.c Verify documented procedures require that any sign of package tampering is identified, reported and if compromise is confirmed ultimately results in the destruction and replacement of both: 

9-2.d Interview responsible personnel and observe processes to verify that if a package shows signs of tampering indicating a component was potentially compromised, processes are implemented to identify the tampering, report/escalate it, and ,if compromise is confirmed, ultimately results in the destruction and replacement of both: 

9-2.e Examine records related to any escalated transmittal event. Verify that if compromise is confirmed it resulted in the destruction and replacement of both: 

PIN Security Requirements:
9-3 Only an authorized key custodian⎯and designated backup(s)⎯shall have physical access to a key component prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
Testing Procedures:
9-3.a Verify that a list(s) of key custodians⎯and designated backup(s)⎯authorized to have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
9-3.b Observe implemented access controls and processes to verify that only those authorized key custodians⎯and designated backup(s)⎯have physical access to key components prior to being secured in transmittal packaging and upon removal of a secured key component from transmittal packaging.
9-3.c Examine physical access logs (e.g., to security containers for key components) to verify that only the authorized individual(s) have access to each component. 

PIN Security Requirements:
9-4 Mechanisms must exist to ensure that only authorized custodians: 

9-4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented: 

9-4.b Observe implemented mechanisms and processes and examine logs to verify that only the authorized key custodians can perform the following: 

PIN Security Requirements:
9-5 Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components not in an SCD. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
Note: Numbered courier bags are not sufficient for this purpose
Testing Procedures:
9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following: 

PIN Security Requirements:
9-6 If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that: 

9-6.a If components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians, the component/shares for a specific custodian or custodian group can be shipped in the same TEA bag provided that: 

9-6.b Examine logs to verify that procedures are followed. 

PIN Security Requirements:
10-1 All key-encryption keys used to encrypt for transmittal or conveyance of other cryptographic keys must be at least as strong as the key being sent, as delineated in Annex C except as noted below for RSA keys used for key transport. 

PIN Security Requirements:
11-1 Written procedures must exist and be known to all affected parties.
Testing Procedures:
11-1.a Verify documented procedures exist for all key transmission and conveyance processing.
11-1.b Interview responsible personnel to verify that the documented procedures are known and understood by all affected parties for key transmission and conveyance processing.

PIN Security Requirements:
11-2 Methods used for the conveyance or receipt of keys must be documented.
Testing Procedures:
11-2 Verify documented procedures include all methods used for the conveyance or receipt of keys.