Document Diff - PCI Watch

Added p. 7

Q 14 June 2025: Devices may support Post-Quantum Cryptography (PQC), also known as Quantum Resistant, in addition to classic cryptography. Specifically, cryptographic algorithms that are currently thought - e.g., as published by NIST - to be secure against a cryptanalytic attack by a quantum computer. Is there an option for this to be noted as part of the PCI approval? Yes. Where the lab validates the support of PQC algorithms in the API and/or processing of the device and includes that notation in the test report submitted to PCI, then it will be listed as Additional Information for the device. The details of the PQC must be stated in the security policy. The specifics for all cryptography and associated critical security parameters (CSPs) must be included in the relevant tables in the Security Policy. Encapsulation and signature algorithms must be implemented and be available through functional calls.

This notation in Additional …

Modified p. 7 → 8

Q 14 September 2015: In the event of tamper, the device must become immediately inoperable and result in the automatic and immediate erasure of any secret information that may be stored in the device, such that it becomes infeasible to recover the secret information. Guidance notes provide that secret or private keys do not need to be zeroized if either or both of the following conditions exist:

• If any of these keys is not zeroized, other mechanisms must exist to …

Q 15 September 2015: In the event of tamper, the device must become immediately inoperable and result in the automatic and immediate erasure of any secret information that may be stored in the device, such that it becomes infeasible to recover the secret information. Guidance notes provide that secret or private keys do not need to be zeroized if either or both of the following conditions exist:

• If any of these keys is not zeroized, other mechanisms must exist to …

Modified p. 7 → 8

Q 15 September 2015: A device uses a key that is randomly generated internally in the secure processor to protect other keys. This key is stored in the clear and protected within a register in the same secure processor. The secure processor resides within a secure area of the device. This key is used to encrypt other keys, which are stored encrypted outside the secure processor•e.g., in flash memory that also resides within the secure area of the device. Upon …

Q 16 September 2015: A device uses a key that is randomly generated internally in the secure processor to protect other keys. This key is stored in the clear and protected within a register in the same secure processor. The secure processor resides within a secure area of the device. This key is used to encrypt other keys, which are stored encrypted outside the secure processor•e.g., in flash memory that also resides within the secure area of the device. Upon …

Modified p. 7 → 8

Q 16 September 2015: What standards and methods are used for measuring “electro-magnetic emissions”? A Vendors should take into account that EM emissions can be a risk to PIN data and should design to address this risk. There are many methods for shielding and minimizing EM emissions. The vendor must describe to the laboratory in writing how EM emissions are addressed by the device design. The laboratory will examine evidence provided by the vendor to determine if the evidence supports …

Q 17 September 2015: What standards and methods are used for measuring “electro-magnetic emissions”? A Vendors should take into account that EM emissions can be a risk to PIN data and should design to address this risk. There are many methods for shielding and minimizing EM emissions. The vendor must describe to the laboratory in writing how EM emissions are addressed by the device design. The laboratory will examine evidence provided by the vendor to determine if the evidence supports …

Modified p. 8 → 9

Q 18 May 2023: Error logs cannot be accessed without assuming an authenticated role supported by the cryptographic module. Does this apply in all circumstances? A In the case that the error log does not contain any sensitive module information, an operator can assume an authorized (any defined role) role that does not require authentication in order to gain access to the module’s error log. CSPs cannot be present in the error log. The access also must not allow the …

Q 19 May 2023: Error logs cannot be accessed without assuming an authenticated role supported by the cryptographic module. Does this apply in all circumstances? A In the case that the error log does not contain any sensitive module information, an operator can assume an authorized (any defined role) role that does not require authentication in order to gain access to the module’s error log. CSPs cannot be present in the error log. The access also must not allow the …

Modified p. 8 → 9

Q 19 September 2015: What parties may possess keys used for the cryptographic authentication of firmware updates? A The firmware is the responsibility of the device vendor, and as such the cryptographic keys that authenticate it within the device must be held solely by the vendor or their designated agent.

Q 20 September 2015: What parties may possess keys used for the cryptographic authentication of firmware updates? A The firmware is the responsibility of the device vendor, and as such the cryptographic keys that authenticate it within the device must be held solely by the vendor or their designated agent.

Modified p. 8 → 9

Q 20 September 2015: Firmware updates must be cryptographically authenticated, and if the authentication fails, the update is rejected and deleted. Are there any circumstances where firmware can be updated without authentication? A Some chipsets are not designed for firmware updates, but only to support firmware replacement. The deletion of the existing firmware and cryptographic keys during the replacement does not allow for the authentication of the new firmware to occur. In such cases it is acceptable to update the …

Q 21 September 2015: Firmware updates must be cryptographically authenticated, and if the authentication fails, the update is rejected and deleted. Are there any circumstances where firmware can be updated without authentication? A Some chipsets are not designed for firmware updates, but only to support firmware replacement. The deletion of the existing firmware and cryptographic keys during the replacement does not allow for the authentication of the new firmware to occur. In such cases it is acceptable to update the …

Modified p. 8 → 9

Q 21 September 2015: If a device supports firmware updates, the device must cryptographically authenticate the firmware, and if the firmware is not confirmed, the firmware update must be rejected and deleted. Can a device completely load new firmware before checking its authenticity and overwrite its primary copy of existing authenticated code if it retains a secure backup copy of the existing authenticated code? A Yes, provided the following is true:

• The new code is cryptographically authenticated prior to execution.

Q 22 September 2015: If a device supports firmware updates, the device must cryptographically authenticate the firmware, and if the firmware is not confirmed, the firmware update must be rejected and deleted. Can a device completely load new firmware before checking its authenticity and overwrite its primary copy of existing authenticated code if it retains a secure backup copy of the existing authenticated code? A Yes, provided the following is true:

• The new code is cryptographically authenticated prior to execution.

Modified p. 9 → 10

Q 22 September 2015: Is it acceptable to XOR key components during key loading to satisfy the authentication requirements of B6? A The XOR of key components alone is not enough to constitute authentication. Some type of authentication of the users that use the key loading function, or authentication of the key-loading command is required.

Q 23 September 2015: Is it acceptable to XOR key components during key loading to satisfy the authentication requirements of B6? A The XOR of key components alone is not enough to constitute authentication. Some type of authentication of the users that use the key loading function, or authentication of the key-loading command is required.

Modified p. 9 → 10

Q 23 September 2015: For devices that require the use of authentication data to access sensitive functions, and the authentication data are static, can the authentication data be sent with the device? A The authentication data can be sent with the device only when the authentication data is in tamper-evident packaging, such as the use of PIN mailers. Otherwise, separate communication channels must be used with pre-designated recipients.

Q 24 September 2015: For devices that require the use of authentication data to access sensitive functions, and the authentication data are static, can the authentication data be sent with the device? A The authentication data can be sent with the device only when the authentication data is in tamper-evident packaging, such as the use of PIN mailers. Otherwise, separate communication channels must be used with pre-designated recipients.

Modified p. 9 → 10

Q 24 September 2015: Plain-text secret or private keys and their components may be injected into a HSM using a key loader (which has to be some type of secure cryptographic device). Are there any restrictions on loading keys via this methodology? A Yes. The loading of plain-text secret or private keys and their components using a key-loader device is restricted to a controlled environment.

Q 25 September 2015: Plain-text secret or private keys and their components may be injected into a HSM using a key loader (which has to be some type of secure cryptographic device). Are there any restrictions on loading keys via this methodology? A Yes. The loading of plain-text secret or private keys and their components using a key-loader device is restricted to a controlled environment.

Modified p. 10 → 11

Q 26 June 2022: Is it acceptable to generate security related cryptographic keys solely from known or low-entropy data, such as passwords or serial numbers? A No. Any process used to generate cryptographic keys must ensure that there is sufficient entropy provided for the output key, and that the key-generation process includes consideration for dual control and split knowledge requirements. Sufficient entropy is considered to be an entropy that is at least equal to the bit strength of the output …

Q 27 June 2022: Is it acceptable to generate security related cryptographic keys solely from known or low-entropy data, such as passwords or serial numbers? A No. Any process used to generate cryptographic keys must ensure that there is sufficient entropy provided for the output key, and that the key-generation process includes consideration for dual control and split knowledge requirements. Sufficient entropy is considered to be an entropy that is at least equal to the bit strength of the output …

Modified p. 10 → 11

Q 27 Are HSMs allowed to have keys that are not unique per device? A Yes, but only for load balancing and disaster recovery purposes.

Q 28 Are HSMs allowed to have keys that are not unique per device? A Yes, but only for load balancing and disaster recovery purposes.

Modified p. 10 → 11

Q 28 September 2015: Is it acceptable for a device to have the ability to use Master Keys as both key-encryption keys for session key and as fixed keys•i.e., the Master Key could be used to encrypt PIN blocks and to decrypt session keys? A No. A key must be used for one purpose only as mandated in ANSI X9.24 and ISO 11568.

Q 29 September 2015: Is it acceptable for a device to have the ability to use Master Keys as both key-encryption keys for session key and as fixed keys•i.e., the Master Key could be used to encrypt PIN blocks and to decrypt session keys? A No. A key must be used for one purpose only as mandated in ANSI X9.24 and ISO 11568.

Modified p. 10 → 11

Q 29 September 2015: Is it acceptable to use the same authentication technique for loading both cryptographic keys and firmware? A The technique may be the same, but the secrets used for authentication must be different. Example: If RSA signatures are used, the RSA private key used to sign cryptographic keys for loading must be different from the private key used to sign firmware.

Q 30 September 2015: Is it acceptable to use the same authentication technique for loading both cryptographic keys and firmware? A The technique may be the same, but the secrets used for authentication must be different. Example: If RSA signatures are used, the RSA private key used to sign cryptographic keys for loading must be different from the private key used to sign firmware.

Modified p. 11 → 12

Q 31 September 2015: Is it acceptable to load double-length 128-bit TDES key components into a device in smaller bit-values⎯e.g., two 64-bit parts held by key custodian 1 and two 64-bit parts held by key custodian 2? A Yes, provided the 128-bit cryptographic TDES keys (and key components) are generated and managed as full double-length 128-bit TDES keys during their entire life cycle in accordance with ANSI X9.24 and ISO 11568. For example, it would be acceptable to generate a …

Q 32 September 2015: Is it acceptable to load double-length 128-bit TDES key components into a device in smaller bit-values⎯e.g., two 64-bit parts held by key custodian 1 and two 64-bit parts held by key custodian 2? A Yes, provided the 128-bit cryptographic TDES keys (and key components) are generated and managed as full double-length 128-bit TDES keys during their entire life cycle in accordance with ANSI X9.24 and ISO 11568. For example, it would be acceptable to generate a …

Modified p. 11 → 12

Q 32 September 2015: Under what conditions is it acceptable for a device to allow single component plain-text cryptographic keys to be loaded via a keypad? A None. A device must not accept entry of single component plain-text cryptographic keys via a keypad. Full-length key components and encrypted keys may be loaded via a keypad if the requirements for sensitive functions are met.

Q 33 September 2015: Under what conditions is it acceptable for a device to allow single component plain-text cryptographic keys to be loaded via a keypad? A None. A device must not accept entry of single component plain-text cryptographic keys via a keypad. Full-length key components and encrypted keys may be loaded via a keypad if the requirements for sensitive functions are met.

Modified p. 11 → 12

Q 33 November (update) 2022: ANSI X9.143 defines three keys. A key block protection key (KBPK), a key block encryption key (KBEK), and a key block MAC key (KBMK). The KBPK is used to calculate the KBEK and the KBMK. Can the KBPK be used for any other purpose? A No. In order to meet the requirement that a key is used only for a single purpose as defined in ANSI X9.24, the key block protection key is only used …

Q 34 November (update) 2022: ANSI X9.143 defines three keys. A key block protection key (KBPK), a key block encryption key (KBEK), and a key block MAC key (KBMK). The KBPK is used to calculate the KBEK and the KBMK. Can the KBPK be used for any other purpose? A No. In order to meet the requirement that a key is used only for a single purpose as defined in ANSI X9.24, the key block protection key is only used …

Modified p. 11 → 12

Q 34 November (update) 2022: The Guidance for DTR B10 states, “A device may include more than one compliant key-exchange and storage scheme. This does not imply that the device must enforce ANSI X9.143 or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.” If the use of ANSI X9.143 as the key-exchange mechanism is optional, must there be an explicit device configuration change to enable/disable ANSI X9.143 as the "active" key-exchange …

Q 35 November (update) 2022: The Guidance for DTR B10 states, “A device may include more than one compliant key-exchange and storage scheme. This does not imply that the device must enforce ANSI X9.143 or an equivalent scheme, but it must be capable of implementing such a scheme as a configuration option.” If the use of ANSI X9.143 as the key-exchange mechanism is optional, must there be an explicit device configuration change to enable/disable ANSI X9.143 as the "active" key-exchange …

Modified p. 12 → 13

Q 36 May (update) 2018: Can secret keys or their components be used for other purposes, such as passwords/authentication codes, to enable the use of sensitive services? A No. The use of secret keys or their components for other purposes violates the requirement that keys be used for their sole intended purpose⎯e.g., key encipherment or PIN encipherment, etc.

Q 37 May (update) 2018: Can secret keys or their components be used for other purposes, such as passwords/authentication codes, to enable the use of sensitive services? A No. The use of secret keys or their components for other purposes violates the requirement that keys be used for their sole intended purpose⎯e.g., key encipherment or PIN encipherment, etc.

Modified p. 12 → 13

Q 37 September 2015: The PCI PIN Security Requirements stipulate that any cryptographic device used in connection with the acquisition of PIN data that is removed from service must have all keys stored within the device destroyed that have been used (or potentially could be) for any cryptographic purpose. If necessary to comply with the above, the device must be physically destroyed so that it cannot be placed into service again or allow the disclosure of any secret data or …

Q 38 September 2015: The PCI PIN Security Requirements stipulate that any cryptographic device used in connection with the acquisition of PIN data that is removed from service must have all keys stored within the device destroyed that have been used (or potentially could be) for any cryptographic purpose. If necessary to comply with the above, the device must be physically destroyed so that it cannot be placed into service again or allow the disclosure of any secret data or …

Modified p. 13 → 14

Q 38 November (update) 2022: Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available as described. What characteristics enforced in ANSI X9.143 and ISO 20038 must be considered in determining equivalence? A “Equivalency” must be demonstrated in the context of security …

Q 39 November (update) 2022: Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available as described. What characteristics enforced in ANSI X9.143 and ISO 20038 must be considered in determining equivalence? A “Equivalency” must be demonstrated in the context of security …

Modified p. 14 → 15

Q 39 November (update) 2022: HSMs are required to support key blocks using the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology and/or the ISO 20038 methodology. ANSI X9.143 and ISO 20038 are methods to package keys (the key blocks) for conveyance or storage, but they use symmetric mechanisms for that and for key conveyance require a symmetric key- exchange key that is pre-shared for use as the key block …

Q 40 November (update) 2022: HSMs are required to support key blocks using the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology and/or the ISO 20038 methodology. ANSI X9.143 and ISO 20038 are methods to package keys (the key blocks) for conveyance or storage, but they use symmetric mechanisms for that and for key conveyance require a symmetric key- exchange key that is pre-shared for use as the key block …

Modified p. 14 → 15

Q 40 November (update) 2022: Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available for peer review. What constitutes publicly available? A “Publicly available" means posted in a forum or otherwise published such that it is available for peer review for …

Q 41 November (update) 2022: Devices must support the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys must support either the ANSI X9.143 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and said review is publicly available for peer review. What constitutes publicly available? A “Publicly available" means posted in a forum or otherwise published such that it is available for peer review for …

Modified p. 14 → 15

Q 41 December 2022: For Key Blocks, is the same MAC key allowed to be used across different MAC algorithms, or is a key unique to each algorithm implemented required? A A key unique to each implemented MAC algorithm must be used as specified in ANSI X9.143.

Q 42 December 2022: For Key Blocks, is the same MAC key allowed to be used across different MAC algorithms, or is a key unique to each algorithm implemented required? A A key unique to each implemented MAC algorithm must be used as specified in ANSI X9.143.

Modified p. 14 → 15

Q 42 March (update) 2024: Can an HSM support other key distribution using asymmetric techniques ASC X9 TR 34? A If the HSM supports key distribution using asymmetric techniques, it must support TR-34; or ECDH to allow derivation of a shared secret key followed by symmetric encryption of, at least, the symmetric key with ECDSA signature over the encrypted key and attributes. Other key distribution using asymmetric techniques can also exist on the device.

Q 43 March (update) 2024: Can an HSM support other key distribution using asymmetric techniques ASC X9 TR 34? A If the HSM supports key distribution using asymmetric techniques, it must support TR-34; or ECDH to allow derivation of a shared secret key followed by symmetric encryption of, at least, the symmetric key with ECDSA signature over the encrypted key and attributes. Other key distribution using asymmetric techniques can also exist on the device.

Removed p. 15

Q 46 September 2015: Can a device use a key-encrypting key to encrypt or decrypt key-tag information along with a key? A Yes. Associated key-tag information such as the algorithm, key expiration, usage, or key MAC may be encrypted or decrypted along with the key using a key-encrypting key. The key and its tag are bound together using a chaining mode of encipherment as defined in IS0 10116.

Modified p. 15 → 16

Q 43 December (update) 2023: HSMs support Elliptic Curve Cryptography for various functions, including personalization, key conveyance and transaction processing. Are there any specific implementations required? A In support of ECC used in the EMV Contact and Contactless Specifications, HSMs used in personalization should support the Elliptic Curve Schnorr Digital Signature Algorithm (EC- SDSA). This will become mandatory in the next update of the HSM Security Requirements.

Q 44 December (update) 2023: HSMs support Elliptic Curve Cryptography for various functions, including personalization, key conveyance and transaction processing. Are there any specific implementations required? A In support of ECC used in the EMV Contact and Contactless Specifications, HSMs used in personalization should support the Elliptic Curve Schnorr Digital Signature Algorithm (EC- SDSA). This will become mandatory in the next update of the HSM Security Requirements.

Modified p. 15 → 16

Q 44 March 2024: Preventing the determination of the key length for variable length symmetric keys is required for proprietary key blocks. Does this apply to ISO 20038 or ANSI X9.143 key blocks? A ISO 20038 and X9.143 specify that TDEA and AES keys should use key length obfuscation to hide the true key length. Where padding is used:

Q 45 March 2024: Preventing the determination of the key length for variable length symmetric keys is required for proprietary key blocks. Does this apply to ISO 20038 or ANSI X9.143 key blocks? A ISO 20038 and X9.143 specify that TDEA and AES keys should use key length obfuscation to hide the true key length. Where padding is used:

Modified p. 15 → 16

Q 45 September 2015: Is it acceptable for a PIN-encryption key to be used as a key-encrypting key, or for a key-encrypting key to be used as a PIN-encrypting key? A No. A key must be used for one purpose only as mandated by ANSI X9.24 and ISO 11568-3.

Q 46 September 2015: Is it acceptable for a PIN-encryption key to be used as a key-encrypting key, or for a key-encrypting key to be used as a PIN-encrypting key? A No. A key must be used for one purpose only as mandated by ANSI X9.24 and ISO 11568-3.

Modified p. 15 → 17

Q 47 May 2022: If a PIN block translating HSM does not enforce a unique key per transaction encryption for the resulting PIN block, what restrictions apply to prevent the misuse of card issuance-related functions? A The following restrictions apply:

• Standard PIN block formats⎯i.e., ISO format 0, 1, 2, 3 and 4⎯shall not be translated into non-standard PIN block formats and translations between these PIN block formats shall be restricted as specified in the table in DTR B14.

Q 48 May 2022: If a PIN block translating HSM does not enforce a unique key per transaction encryption for the resulting PIN block, what restrictions apply to prevent the misuse of card issuance-related functions? A The following restrictions apply:

• Standard PIN block formats⎯i.e., ISO format 0, 1, 2, 3 and 4⎯shall not be translated into non-standard PIN block formats and translations between these PIN block formats shall be restricted as specified in the table in DTR B14.

Modified p. 15 → 17

 For card issuance, where i) the translation is between PIN blocks using real PANs, ii) the introduction of a new PAN is required to support account number changes, and iii) it is not performed in interchange processing systems; or

 For card issuance, where i) the translation is between PIN blocks using real PANs, ii) the introduction of a new PAN is required to support account number changes, and iii) it is not performed in interchange processing systems; or  For translation between a tokenized PAN and a “real” or funding PAN (FPAN), where cryptographic controls are implemented and validated to ensure that the PAN Token is a valid token for the FPAN⎯e.g., a MAC over both the PAN …

Modified p. 16 → 17

Q 48 December 2022: ISO 9564 stipulates restrictions on translations between PIN block formats, that are applicable when the HSM does not enforce unique-key-per-transaction encryption for the resulting PIN block. For example, translations from PIN block formats 0, 3 or 4 to PIN block format 1 is not allowed unless that stipulation is met. How must this unique-key-per-transaction encryption be enforced by the HSM? A The HSM must enforce the UKPT exception by integrating the UKPT derivation of the PIN …

Q 49 December 2022: ISO 9564 stipulates restrictions on translations between PIN block formats, that are applicable when the HSM does not enforce unique-key-per-transaction encryption for the resulting PIN block. For example, translations from PIN block formats 0, 3 or 4 to PIN block format 1 is not allowed unless that stipulation is met. How must this unique-key-per-transaction encryption be enforced by the HSM? A The HSM must enforce the UKPT exception by integrating the UKPT derivation of the PIN …

Modified p. 16 → 18

Q 49 September 2015: The operating system of the device must contain only necessary components and must be configured securely and run with least privilege. What is considered an “operating system” for PCI purposes? A In the scope of PCI PTS, any underlying software providing services for code running in the device is considered part of the operating system. Examples of such services include: system initialization and boot, hardware abstraction layers, memory management, multitasking, synchronization primitives, file systems, device drivers, …

Q 50 September 2015: The operating system of the device must contain only necessary components and must be configured securely and run with least privilege. What is considered an “operating system” for PCI purposes? A In the scope of PCI PTS, any underlying software providing services for code running in the device is considered part of the operating system. Examples of such services include: system initialization and boot, hardware abstraction layers, memory management, multitasking, synchronization primitives, file systems, device drivers, …

Modified p. 16 → 18

Q 50 February 2020: Can an HSM operating in PCI-mode support known weak cryptographic algorithms/key sizes not otherwise allowable when used for EMV card personalization? Yes. When used for EMV card personalization an HSM when operating in PCI mode may support:

Q 51 February 2020: Can an HSM operating in PCI-mode support known weak cryptographic algorithms/key sizes not otherwise allowable when used for EMV card personalization? Yes. When used for EMV card personalization an HSM when operating in PCI mode may support:

Removed p. 17

Q 51 ISO 9564 and requirement C1 require that the HSM’s security policy enforce the prohibition of the translation of PIN block formats from ISO format 0 to IS0 format 1. Are there any circumstances where it is permitted that HSMs allow the translation of PIN blocks from ISO format 0 to ISO format 1? A Yes, if a unique session key is used for every ISO format 1 PIN block, and the key uniqueness is guaranteed by the functionality of the HSM and is not reliant upon APIs exercised by the host application.

Modified p. 17 → 19

Q 52 September (update) 2015: Are HSMs allowed to support non-ISO PIN block formats and non-ISO algorithms? A Yes, however, the HSM must provide functionality to enforce a policy that meets B14:

• ISO formats 0, 1, 2, 3 and 4 cannot be translated into any non-ISO format.

Q 53 September (update) 2015: Are HSMs allowed to support non-ISO PIN block formats and non-ISO algorithms? A Yes, however, the HSM must provide functionality to enforce a policy that meets B14:

• ISO formats 0, 1, 2, 3 and 4 cannot be translated into any non-ISO format.

Modified p. 17 → 19

Q 53 May (update) 2018: Is the device allowed to share PCI relevant keys and passwords/authentication codes between PCI approved mode of operation and non-PCI approved mode of operation? A No. The device must either enforce separation of all PCI relevant keys and passwords/authentication codes between the two modes or the device must zeroize all PCI relevant keys and passwords/authentication codes when switching between modes except as follows. If the device includes an internally generated hardware key, for example inside …

Q 54 May (update) 2018: Is the device allowed to share PCI relevant keys and passwords/authentication codes between PCI approved mode of operation and non-PCI approved mode of operation? A No. The device must either enforce separation of all PCI relevant keys and passwords/authentication codes between the two modes or the device must zeroize all PCI relevant keys and passwords/authentication codes when switching between modes except as follows. If the device includes an internally generated hardware key, for example inside …

Modified p. 18 → 20

Q 55 May 2018: The PCI PTS Lab Requirements prohibit a PTS lab from creating any vendor documentation. Are there any scenarios where a PTS lab may assist a vendor in creating documentation? A In some cases. A PTS vendor may revise a Security Policy for grammar, formatting, or spelling edits for a device under evaluation which requires those edits to be submitted to PCI to place on the portal. In this case, the PTS lab performing the evaluation may …

Q 56 May 2018: The PCI PTS Lab Requirements prohibit a PTS lab from creating any vendor documentation. Are there any scenarios where a PTS lab may assist a vendor in creating documentation? A In some cases. A PTS vendor may revise a Security Policy for grammar, formatting, or spelling edits for a device under evaluation which requires those edits to be submitted to PCI to place on the portal. In this case, the PTS lab performing the evaluation may …

Modified p. 18 → 20

Q 56 August 2022: Vendors can have various options for both hardware and firmware that may be either security- or non-security-relevant. For non-security-relevant options, vendors are allowed to designate in their hardware/firmware identifiers a lower case “x” in the relevant position. Security-relevant options must have specific numbers and/or letters assigned and listed as part of the approval. The Program Guide specifies that options, both security- and non-security-relevant must be clearly defined and documented as to the options available and their …

Q 57 August 2022: Vendors can have various options for both hardware and firmware that may be either security- or non-security-relevant. For non-security-relevant options, vendors are allowed to designate in their hardware/firmware identifiers a lower case “x” in the relevant position. Security-relevant options must have specific numbers and/or letters assigned and listed as part of the approval. The Program Guide specifies that options, both security- and non-security-relevant must be clearly defined and documented as to the options available and their …

Modified p. 19 → 20

Q 57 April 2023: HSM virtualization systems that are not implemented within a physical system that is tamper responsive must exist in their entirety in an environment that meets at least the security requirements of a controlled environment as outlined in ISO 13491-2. How is that handled where the vendor implements their own solution versus selling the solution to other entities to implement? A Where the vendor implements their own solution as part of an HSM as a Service, the …

Q 58 April 2023: HSM virtualization systems that are not implemented within a physical system that is tamper responsive must exist in their entirety in an environment that meets at least the security requirements of a controlled environment as outlined in ISO 13491-2. How is that handled where the vendor implements their own solution versus selling the solution to other entities to implement? A Where the vendor implements their own solution as part of an HSM as a Service, the …

Modified p. 19 → 21

Q 58 September 2015: Many devices are designed so that third parties can create and load applications. Vendors often support this by providing third parties the tools needed to create and load applications. How can a vendor ensure that the application will not need to be controlled by the vendor? A If applications are not considered firmware, they do not need to be controlled by the vendor. The device design must prevent applications from impacting functions and features governed by …

Q 59 September 2015: Many devices are designed so that third parties can create and load applications. Vendors often support this by providing third parties the tools needed to create and load applications. How can a vendor ensure that the application will not need to be controlled by the vendor? A If applications are not considered firmware, they do not need to be controlled by the vendor. The device design must prevent applications from impacting functions and features governed by …

Document Comparison

Content Changes