Document Comparison
PCI-P2PE-v3_1-Standard.pdf
→
PCI-P2PE-Standard-v3.2.pdf
61% similar
255 → 260
Pages
97620 → 93625
Words
842
Content Changes
Content Changes
842 content changes. 206 administrative changes (dates, page numbers) hidden.
Added
p. 2
June 2025 3.2 Updated based on stakeholder feedback.
For complete information, see the Point-to-Point Encryption Standard
• Summary of Significant Changes from v3.1 to v3.2.
For complete information, see the Point-to-Point Encryption Standard
• Summary of Significant Changes from v3.1 to v3.2.
Added
p. 7
1A Account data must be accepted by, processed, and encrypted in PCI-approved PTS POI devices with SRED 1B Logically secure PTS POI devices 1C Managing whitelists and Non-payment software 1D Implement secure application-management processes 1E Component providers ONLY: report status to solution providers Application Security The secure development of payment applications designed to have access to cleartext account data intended solely for installation on PCI- approved PTS POI devices.
4A Use approved decryption devices 4B Secure the decryption environment 4C Monitor the decryption environment and respond to incidents 4D Implement secure, hybrid decryption processes 4E Component providers ONLY: report status to solution providers
An SCD used for the acceptance and encryption of account data at the point of sale is required to be a PCI-approved PTS POI device, which is a device evaluated and approved via the PCI PTS program and includes SRED (secure reading and exchange of data) as part of …
4A Use approved decryption devices 4B Secure the decryption environment 4C Monitor the decryption environment and respond to incidents 4D Implement secure, hybrid decryption processes 4E Component providers ONLY: report status to solution providers
An SCD used for the acceptance and encryption of account data at the point of sale is required to be a PCI-approved PTS POI device, which is a device evaluated and approved via the PCI PTS program and includes SRED (secure reading and exchange of data) as part of …
Added
p. 11
P2PE Solutions and Use of Third Parties and/or P2PE Component Providers A given P2PE Solution may be entirely performed and managed by a single P2PE Solution Provider or by a merchant acting as its own solution provider (Merchant-Managed Solution, or MMS); or certain services may be outsourced to third parties who perform these functions on behalf of the solution provider. All third parties that perform P2PE functions on behalf of a P2PE Solution Provider, or a P2PE Component Provider, must be validated per applicable P2PE requirements, and such entities have the option of becoming P2PE Component Providers.
A “P2PE Component Provider” is an entity that provides a service assessed to a defined set of P2PE requirements and has the potential to result in a P2PE Component Provider listing on the PCI SSC website. P2PE Component Providers’ services are performed on behalf of other P2PE solution providers for use in P2PE Solutions. …
A “P2PE Component Provider” is an entity that provides a service assessed to a defined set of P2PE requirements and has the potential to result in a P2PE Component Provider listing on the PCI SSC website. P2PE Component Providers’ services are performed on behalf of other P2PE solution providers for use in P2PE Solutions. …
Added
p. 14
§ PTS POI devices (for account-data encryption) are approved per the PCI PIN Transaction Security (PTS) Point of Interaction (POI) Standard and Program § HSMs used in the decryption environment for account-data decryption, as well as HSMs used for cryptographic-key operations, are approved per the PCI PTS HSM Standard and Program, or, via NIST FIPS 140-2 or 140-3 (Level 3 or 4) § The P2PE decryption environment is required to be PCI DSS compliant
Note: This standard does not supersede the PCI Data Security Standard, PCI PIN Security Requirements, or any other PCI Standards, nor do these requirements constitute a recommendation from the PCI SSC or obligate merchants, service providers, or financial institutions to purchase or deploy such solutions. As with all other PCI standards, any mandates, regulations, or rules regarding these requirements are provided by the participating payment brands.
Note: This standard does not supersede the PCI Data Security Standard, PCI PIN Security Requirements, or any other PCI Standards, nor do these requirements constitute a recommendation from the PCI SSC or obligate merchants, service providers, or financial institutions to purchase or deploy such solutions. As with all other PCI standards, any mandates, regulations, or rules regarding these requirements are provided by the participating payment brands.
Added
p. 15
Any sampling of PTS POI devices and their applications, cryptographic keys, and key components must follow these principles:
§ With respect to the PTS POI device HW/FW combinations, at least one unique combination of PTS POI device HW and FW supported by the P2PE Product must be validated and functionally tested (as determined by the P2PE requirements and associated testing procedures) from each PTS approval that is being associated with the P2PE Product assessment. § Where the FW is not monolithic, i.e., it is split into separate FW functionality (e.g., OS, SRED, OP), every FW required for the device to function as intended must be validated and functionally tested (as determined by the P2PE requirements and associated testing procedures).
Note: In the PCI PTS POI Program, firmware can also be denoted as an ‘Application’ (not to be confused with a P2PE Application or Non- payment Software) and listed as such on the …
§ With respect to the PTS POI device HW/FW combinations, at least one unique combination of PTS POI device HW and FW supported by the P2PE Product must be validated and functionally tested (as determined by the P2PE requirements and associated testing procedures) from each PTS approval that is being associated with the P2PE Product assessment. § Where the FW is not monolithic, i.e., it is split into separate FW functionality (e.g., OS, SRED, OP), every FW required for the device to function as intended must be validated and functionally tested (as determined by the P2PE requirements and associated testing procedures).
Note: In the PCI PTS POI Program, firmware can also be denoted as an ‘Application’ (not to be confused with a P2PE Application or Non- payment Software) and listed as such on the …
Added
p. 16
Technical FAQs The PCI P2PE Technical FAQs is a separate document from this PCI P2PE Standard that provides answers to questions regarding the PCI P2PE Standard and Program.
Technical FAQs are normative and are an integral and mandatory part of the PCI P2PE Standard and Program. P2PE Technical FAQs must be fully considered during a PCI P2PE security assessment.
The PCI P2PE Technical FAQs document can be found in the PCI Council’s Document Library for P2PE at https://www.pcisecuritystandards.org/document_library
Technical FAQs are normative and are an integral and mandatory part of the PCI P2PE Standard and Program. P2PE Technical FAQs must be fully considered during a PCI P2PE security assessment.
The PCI P2PE Technical FAQs document can be found in the PCI Council’s Document Library for P2PE at https://www.pcisecuritystandards.org/document_library
Added
p. 17
• Security Objectives: The top-level requirements that identify the high-level security objectives.
• Security Requirements: Specific security controls or activities that must be satisfied to support the overarching security objectives.
• Testing Procedures: The expected testing activities to validate the security requirements have been satisfied.
Testing Procedure Methods Entities are expected to produce evidence that the security requirements defined in this document have been satisfied. The Testing Procedures typically include the following activities:
• Examine: The tester critically evaluates evidence. Common examples include, but are not limited to, reviewing policies, procedures, software design and architecture documents (electronic or physical), source code, configurations, log files, and security-testing results.
• Interview: The tester converses with relevant individual personnel. The purpose of interviews includes determining how an activity is performed, whether an activity is performed as defined, and whether personnel have particular knowledge or understanding of applicable policies, processes, responsibilities, and concepts.
• Observe: The tester watches a particular …
• Security Requirements: Specific security controls or activities that must be satisfied to support the overarching security objectives.
• Testing Procedures: The expected testing activities to validate the security requirements have been satisfied.
Testing Procedure Methods Entities are expected to produce evidence that the security requirements defined in this document have been satisfied. The Testing Procedures typically include the following activities:
• Examine: The tester critically evaluates evidence. Common examples include, but are not limited to, reviewing policies, procedures, software design and architecture documents (electronic or physical), source code, configurations, log files, and security-testing results.
• Interview: The tester converses with relevant individual personnel. The purpose of interviews includes determining how an activity is performed, whether an activity is performed as defined, and whether personnel have particular knowledge or understanding of applicable policies, processes, responsibilities, and concepts.
• Observe: The tester watches a particular …
Added
p. 20
PCI SSC PCI P2PE Program Guide
PCI P2PE Technical FAQs
PCI P2PE PIM Template
PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements
PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements
PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Security Requirements
PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Derived Test Requirements
PCI P2PE Technical FAQs
PCI P2PE PIM Template
PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements
PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements
PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Security Requirements
PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Derived Test Requirements
Added
p. 21
1A Account data must be accepted by, processed, and encrypted in PCI-approved PTS POI devices with SRED 1B Logically secure PTS POI devices 1C Managing whitelists and Non-payment software 1D Implement secure application-management processes.
Domain 1 requirements also include the confirmation that all P2PE Applications, P2PE Non-payment software, and whitelists are properly reviewed and installed on the device.
Note: Within this domain, the term “solution provider” refers to whichever entity is undergoing the P2PE assessment. This may be a P2PE Solution Provider, a P2PE Component Provider, or a merchant as a solution provider (MMS). Refer to “P2PE Solutions and use of Third Parties and/or P2PE Component Providers” for more information about validating this Domain.
Note: For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 4, and 5 of this document refers to the merchant’s encryption environments and represents requirements the merchant as a solution provider is responsible for meeting, for …
Domain 1 requirements also include the confirmation that all P2PE Applications, P2PE Non-payment software, and whitelists are properly reviewed and installed on the device.
Note: Within this domain, the term “solution provider” refers to whichever entity is undergoing the P2PE assessment. This may be a P2PE Solution Provider, a P2PE Component Provider, or a merchant as a solution provider (MMS). Refer to “P2PE Solutions and use of Third Parties and/or P2PE Component Providers” for more information about validating this Domain.
Note: For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 4, and 5 of this document refers to the merchant’s encryption environments and represents requirements the merchant as a solution provider is responsible for meeting, for …
Added
p. 35
• Updated list of PTS POI devices, P2PE Applications, and/or P2PE Non- payment Software 1E-1.2.b Examine reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:
Additional software is often added to PTS POI devices after the PTS evaluation and approval. It is vital to the security of these devices and their use in a P2PE solution that any such software is assessed to confirm its secure operation and protection of account data. This domain accounts for the assessment of all P2PE Applications (software with access to cleartext account data) that are intended for use within the PTS POI devices as part of a P2PE Solution.
• Application (Applic) version number(s)
Note: Refer to the PCI P2PE Technical FAQs - Domain 2, Q4 regarding PTS POI device expiry. Individual PTS POI hardware and firmware must also be assessed and approved to the PTS POI SRED requirements.
2A-1.1 For …
Additional software is often added to PTS POI devices after the PTS evaluation and approval. It is vital to the security of these devices and their use in a P2PE solution that any such software is assessed to confirm its secure operation and protection of account data. This domain accounts for the assessment of all P2PE Applications (software with access to cleartext account data) that are intended for use within the PTS POI devices as part of a P2PE Solution.
• Application (Applic) version number(s)
Note: Refer to the PCI P2PE Technical FAQs - Domain 2, Q4 regarding PTS POI device expiry. Individual PTS POI hardware and firmware must also be assessed and approved to the PTS POI SRED requirements.
2A-1.1 For …
Added
p. 48
2B-1.3.2 Examine documentation to verify documented approval by appropriate authorized parties is present for each change 2B-1.3.3 Functionality testing to verify that the change does not adversely impact the security of the device.
Added
p. 53
- Have no impact on functionality of the application or its dependencies
- Have no impact on functionality of the application or its dependencies
- Have impact to any security functionality or P2PE requirement
- Have impact to any security functionality or P2PE requirement
2B-1.8.d Select a sample of recent payment application changes and examine the change-control documentation that specifies the type of application change to verify that the version assigned to the change matches the type of change according to the documented methodology.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.10 The vendor’s published versioning methodology must be communicated to customers and integrators/ resellers via the PIM.
• Confirmation that all secure development processes were followed
- Link Layer protocols
2B-3.1 Examine/observe the application developer’s system development documentation to verify the application developer’s process includes full documentation and integration testing of the application and intended platforms, including the following:
2B-4.1 The application must …
- Have no impact on functionality of the application or its dependencies
- Have impact to any security functionality or P2PE requirement
- Have impact to any security functionality or P2PE requirement
2B-1.8.d Select a sample of recent payment application changes and examine the change-control documentation that specifies the type of application change to verify that the version assigned to the change matches the type of change according to the documented methodology.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.10 The vendor’s published versioning methodology must be communicated to customers and integrators/ resellers via the PIM.
• Confirmation that all secure development processes were followed
- Link Layer protocols
2B-3.1 Examine/observe the application developer’s system development documentation to verify the application developer’s process includes full documentation and integration testing of the application and intended platforms, including the following:
2B-4.1 The application must …
Added
p. 64
• Any changes to the application (e.g., device changes/upgrades, and major and minor software changes)
• Any changes to the Implementation Guide requirements in this document 2C-3.1.2.a Examine documented procedures to verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements 2C-3.1.2.b Examine documented procedures to verify the Implementation Guide is updated as needed to keep the documentation current with:
Domain 2 Requirement Required Content for the Implementation Guide 2A-3.2 § A list of all logical interfaces for the application, and the function/purpose of each. § The logical interfaces intended for sharing of cleartext account data (e.g., those used to pass cleartext data back to the approved firmware of the PTS POI device) § The logical interfaces not intended for sharing of cleartext account data (e.g., those for communication with other applications) 2A-3.3 Guidance that use of any other methods for …
• Any changes to the Implementation Guide requirements in this document 2C-3.1.2.a Examine documented procedures to verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements 2C-3.1.2.b Examine documented procedures to verify the Implementation Guide is updated as needed to keep the documentation current with:
Domain 2 Requirement Required Content for the Implementation Guide 2A-3.2 § A list of all logical interfaces for the application, and the function/purpose of each. § The logical interfaces intended for sharing of cleartext account data (e.g., those used to pass cleartext data back to the approved firmware of the PTS POI device) § The logical interfaces not intended for sharing of cleartext account data (e.g., those for communication with other applications) 2A-3.3 Guidance that use of any other methods for …
Added
p. 70
3A-1.2 Examine documentation and interview personnel (as needed) to verify (for each intended solution implementation, if they differ, e.g., across different merchant environments):
3A-1.2.1 Cleartext account data must not be disclosed to any component or device outside of the PCI-approved PTS POI devices within the merchant environment until it is securely decrypted in the decryption environment.
3A-1.2.a Examine documentation (for each intended solution implementation, if they differ, e.g., across different merchant environments) to verify that cleartext account data is not disclosed to any component or device outside of the PCI- approved PTS POI devices within the merchant environment(s) until it is securely decrypted in the decryption environment(s).
• To which region/country it applies 3A-1.3.b [Removed]
• Changes in overall solution architecture 3A-2.2.a Interview responsible personnel and examine documentation to verify the solution provider has a formal process for ensuring P2PE controls are maintained when changes to the P2PE solution occur, including procedures for addressing …
3A-1.2.1 Cleartext account data must not be disclosed to any component or device outside of the PCI-approved PTS POI devices within the merchant environment until it is securely decrypted in the decryption environment.
3A-1.2.a Examine documentation (for each intended solution implementation, if they differ, e.g., across different merchant environments) to verify that cleartext account data is not disclosed to any component or device outside of the PCI- approved PTS POI devices within the merchant environment(s) until it is securely decrypted in the decryption environment(s).
• To which region/country it applies 3A-1.3.b [Removed]
• Changes in overall solution architecture 3A-2.2.a Interview responsible personnel and examine documentation to verify the solution provider has a formal process for ensuring P2PE controls are maintained when changes to the P2PE solution occur, including procedures for addressing …
Added
p. 78
Note: It is imperative that the PIM accurately contains all required information. This is critical for the PTS POI devices and instructions on how to access the PTS POI device HW/FW/Application version information such that it can be verified in the merchant environment against the Validated P2PE Solution details. The PIM must accurately reflect the information required for the merchant, which may warrant separate PIMs for differing merchant environments if the PTS POI devices, instructions, and/or required information differ between merchants.
Requirement 3D: Management of P2PE Applications Domain 3 Requirements Testing Procedures 3D-1 All software with access to cleartext account data (P2PE Applications) is validated to P2PE Domain 2 and is only deployed on/to eligible PCI- approved PTS POI devices with SRED. Note: Refer to the P2PE Technical FAQs and P2PE Program Guide for information regarding PTS POI devices.
3D-1.1 All software on PTS POI devices with access to cleartext account data …
Requirement 3D: Management of P2PE Applications Domain 3 Requirements Testing Procedures 3D-1 All software with access to cleartext account data (P2PE Applications) is validated to P2PE Domain 2 and is only deployed on/to eligible PCI- approved PTS POI devices with SRED. Note: Refer to the P2PE Technical FAQs and P2PE Program Guide for information regarding PTS POI devices.
3D-1.1 All software on PTS POI devices with access to cleartext account data …
Added
p. 87
• Capable of detecting tampering or modification
• Conducted by authorized personnel
• Conducted at least quarterly 4B-1.5.a Examine documented procedures, interview personnel, and observe inspections (as needed) to verify:
• Inspections performed are capable of detecting tampering or modification of HSMs used for decryption operations and related processes
• Inspections are performed by authorized personnel
Note: Refer to the PCI P2PE Technical FAQs - Domain 2, Q3 regarding the allowable number of digits.
4B-1.7.a Examine documented processes and interview personnel to confirm that cleartext account data is never sent back to the encryption environment.
4B-1.8.a Examine documented processes and interview personnel to confirm that any truncated PANs sent back to the encryption environment adhere to the allowable number of digits.
- Description and justification for the functionality
- Who approved the new installation or updated functionality prior to release
4B-1.9.1 [Accounted for via 4B-1.9]
• Changes to cryptographic-related functions
• Disconnect/reconnect of devices 4C-1.2.a Examine documented procedures to verify mechanisms are …
• Conducted by authorized personnel
• Conducted at least quarterly 4B-1.5.a Examine documented procedures, interview personnel, and observe inspections (as needed) to verify:
• Inspections performed are capable of detecting tampering or modification of HSMs used for decryption operations and related processes
• Inspections are performed by authorized personnel
Note: Refer to the PCI P2PE Technical FAQs - Domain 2, Q3 regarding the allowable number of digits.
4B-1.7.a Examine documented processes and interview personnel to confirm that cleartext account data is never sent back to the encryption environment.
4B-1.8.a Examine documented processes and interview personnel to confirm that any truncated PANs sent back to the encryption environment adhere to the allowable number of digits.
- Description and justification for the functionality
- Who approved the new installation or updated functionality prior to release
4B-1.9.1 [Accounted for via 4B-1.9]
• Changes to cryptographic-related functions
• Disconnect/reconnect of devices 4C-1.2.a Examine documented procedures to verify mechanisms are …
Added
p. 96
4D-1.1.c Examine the solution provider documentation that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems, to verify that it accurately represents the decryption environment.
• Utilize a secure connection between them
• Utilize a secure connection between them
• Reside within the same CDE as defined in PCI DSS
• Reside within the same CDE as defined in PCI DSS
• Be dedicated to decryption operations and transaction processing in support of a P2PE Solution 4D-1.3.a Examine documentation / network diagrams to verify the Host System(s) and HSM(s), at a minimum,
• Are dedicated to decryption operations and transaction processing in support of a P2PE Solution 4D-1.3.b Examine and/or observe network and system configurations to verify 4D- 1.3.a.
• Utilize a secure connection between them
• Utilize a secure connection between them
• Reside within the same CDE as defined in PCI DSS
• Reside within the same CDE as defined in PCI DSS
• Be dedicated to decryption operations and transaction processing in support of a P2PE Solution 4D-1.3.a Examine documentation / network diagrams to verify the Host System(s) and HSM(s), at a minimum,
• Are dedicated to decryption operations and transaction processing in support of a P2PE Solution 4D-1.3.b Examine and/or observe network and system configurations to verify 4D- 1.3.a.
Added
p. 100
4D-1.13 The cleartext data-decryption keys must only be accessible to authorized personnel with a defined job- related need to access the keys.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.14.2 Storage must only be made to a dedicated hard drive (on its own bus) within the host.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.14.2 Storage must only be made to a dedicated hard drive (on its own bus) within the host.
Added
p. 105
4D-3.1.b Examine the configuration settings of system components to verify that all traffic transmitted over the secure channel uses strong cryptography.
4D-3.5 Examine, Interview, Observe, and/or test as needed to verify that non-console access to the Host System is only permitted from a PCI DSS compliant environment, including 4D-3.5.1 through 4D-3.5.2 4D-3.5.1 The authorized system (e.g., workstation) from which non-console access originates must meet all applicable PCI DSS requirements. For example, system hardening, patching, anti-virus protection, a local firewall etc.
- Logs of access to the room from a badge access system
- Access to the room from a badge access system
- Access to the room from a badge access system
4D-4.6.a Examine CCTV configuration and review a sample of recordings to verify that CCTV monitoring is in place on a 24-hour basis, and covers, as a minimum, the following areas:
• All entrances and exits
4D-3.5 Examine, Interview, Observe, and/or test as needed to verify that non-console access to the Host System is only permitted from a PCI DSS compliant environment, including 4D-3.5.1 through 4D-3.5.2 4D-3.5.1 The authorized system (e.g., workstation) from which non-console access originates must meet all applicable PCI DSS requirements. For example, system hardening, patching, anti-virus protection, a local firewall etc.
- Logs of access to the room from a badge access system
- Access to the room from a badge access system
- Access to the room from a badge access system
4D-4.6.a Examine CCTV configuration and review a sample of recordings to verify that CCTV monitoring is in place on a 24-hour basis, and covers, as a minimum, the following areas:
• All entrances and exits
Added
p. 112
• Date/status of last PCI DSS assessment (continued on next page) 4E-1.1.a Examine component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel to confirm that the following processes are documented and implemented:
Added
p. 120
Note: If the solution provider has applied a vendor security patch resulting in an updated HSM firmware version, and the PCI SSC or NIST acceptance of that updated firmware version has not yet been completed (resulting in a mismatch between the HSM firmware version in use and the listed, validated one), the solution provider must obtain documentation from the vendor regarding the update that includes confirmation the update has been submitted for evaluation per the process specified by either PCI SSC or NIST (as applicable to the HSM).
1-4.a For all PCI-approved HSMs used, examine HSM devices and 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:
• The FIPS 140 Approval Number 1-4.c If the solution provider has applied a vendor security patch that resulted in an updated HSM firmware version, and the PCI …
1-4.a For all PCI-approved HSMs used, examine HSM devices and 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:
• The FIPS 140 Approval Number 1-4.c If the solution provider has applied a vendor security patch that resulted in an updated HSM firmware version, and the PCI …
Added
p. 126
6-2.b Observe the generation process and examine documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any cleartext secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD except where Requirement 5 and Requirement 13 are met.
Added
p. 127
6-3.b Interview personnel and observe processes to verify the requirement is satisfied.
The following sub-requirements are applicable to the printing of key components:
The following sub-requirements are applicable to the printing of key components:
Added
p. 136
• Examine documentation (e.g., record of past key transfers), interview, personnel and observe as needed to verify that the process used to transport cleartext key components using pre-numbered, tamper-evident, authenticable packaging, is sufficient to ensure:
Added
p. 143
9-3.a Examine the 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.
Added
p. 144
• Observe the method used to transport cleartext key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.
Added
p. 149
(continued on next page) 12-1.a Examine documented procedures, interview personnel, and observe processes as needed to verify the requirement is satisfied for all applicable keys.
Added
p. 162
13-9 [Requirement removed]
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 or sign applications 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.
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 Examine/observe locations and controls for physical tokens to verify that tokens used to enable key loading are not in the control …
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 or sign applications 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.
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 Examine/observe locations and controls for physical tokens to verify that tokens used to enable key loading are not in the control …
Added
p. 174
19-1 Encryption keys must only be used for the purpose they were intended¾i.e., key-encryption keys must not be used as data-encryption keys, data-encryption keys must not be used for key encryption, etc.
Added
p. 192
- Notify the affected parties to apply for new certificates.
- Notifies the affected parties to apply for new certificates.
- Notifies the affected parties to apply for new certificates.
Added
p. 212
• Determination that the requestor is valid, which may include but not limited to verifying that the:
• organization exists by using at least one third-party identity-proofing service or database, or,
• organization exists by using at least one third-party identity-proofing service or database, or,
Added
p. 219
Note: Dual-control mechanisms can include any manner of physical and/or logical means that satisfies the objective.
Added
p. 247
5H-1.5.4 The encryption key must have a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices.
5H-1.5.4.a Examine documented key-management policies and procedures to verify that the encryption mechanism uses an encryption key that has a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices.
5H-1.5.4.b Observe key-management processes to verify that the encryption mechanism uses an encryption key that has a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices.
Note: Adding, changing, or removing PTS POI devices and/or HSM types, or critical key-management methods may require a Delta Change. Please refer to the PCI P2PE Program Guide for details about obligations when adding, changing, or removing elements of a Listed P2PE Product.
5I-1.1.a Examine the component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel to confirm that the following …
5H-1.5.4.a Examine documented key-management policies and procedures to verify that the encryption mechanism uses an encryption key that has a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices.
5H-1.5.4.b Observe key-management processes to verify that the encryption mechanism uses an encryption key that has a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices.
Note: Adding, changing, or removing PTS POI devices and/or HSM types, or critical key-management methods may require a Delta Change. Please refer to the PCI P2PE Program Guide for details about obligations when adding, changing, or removing elements of a Listed P2PE Product.
5I-1.1.a Examine the component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel to confirm that the following …
Modified
p. 6
The requirements contained within this standard are intended for P2PE solution providers and other entities that provide P2PE components or P2PE applications for use in P2PE solutions, as well as P2PE assessors evaluating these entities. Additionally, merchants benefit from using P2PE solutions due to increased protection of account data and subsequent reduction in the presence of clear-text account data within their environments.
The requirements contained within this standard are intended for P2PE Solution Providers and other entities that provide P2PE Components or P2PE Applications for use in P2PE Solutions, as well as P2PE Assessors evaluating these entities. Additionally, merchants benefit from using P2PE Solutions due to increased protection of account data and subsequent reduction in the presence of cleartext account data within their environments.
Modified
p. 6
Types of Solution Providers P2PE Solution Provider A P2PE solution provider is an entity with a third-party relationship with respect to its merchant customers (e.g., a processor, acquirer, or payment gateway) that has overall responsibility for the design and implementation of a specific P2PE solution and manages P2PE solutions for its merchant customers. The solution provider has overall responsibility for ensuring that all P2PE requirements are met, including any P2PE requirements performed by third-party organizations on behalf of the solution …
Types of Solution Providers P2PE Solution Provider A P2PE Solution Provider is an entity with a third-party relationship with respect to its merchant customers (e.g., a processor, acquirer, or payment gateway) that has overall responsibility for the design and implementation of a specific P2PE Solution and manages P2PE Solutions for its merchant customers. The P2PE Solution Provider has overall responsibility for ensuring that all P2PE requirements are met, including any P2PE requirements performed by third-party organizations on behalf of the …
Modified
p. 6
Merchant as a Solution Provider/Merchant-managed Solution The terms “merchant as a solution provider” and “merchant-managed solution” apply to merchants who choose to manage their own P2PE solutions on behalf of their own merchant encryption environments rather than outsourcing the solution to a third-party P2PE solution provider. Appendix A defines the separation needed between encryption environments where the encrypting POI devices are physically located and the merchant’s account-data decryption environment (and other merchant cardholder data environments) for a merchant-managed solution. Appendix …
Merchant as a Solution Provider / Merchant-managed Solution The terms “merchant as a solution provider” and “merchant-managed solution” (MMS) apply to merchants who choose to manage their own P2PE solutions on behalf of their own merchant encryption environments rather than outsourcing the solution to a third-party P2PE solution provider. Appendix A defines the separation needed between encryption environments where the encrypting PTS POI devices are physically located and the merchant’s account-data decryption environment (and other merchant cardholder data environments) for …
Modified
p. 6
For merchant-managed solutions, where the term “merchant” is used in Domains 1, 3, 4, and 5 of this document, those requirements refer to the merchant’s encryption environments and represent requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Note: For merchant-managed solutions, where the term “merchant” is used in Domains 1, 3, 4, and 5 of this document, those requirements refer to the merchant’s encryption environments and represent requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Removed
p. 7
1A Account data must be encrypted in equipment that is resistant to physical and logical compromise.
1B Logically secure POI devices.
1C Use P2PE applications that protect PAN and SAD.
1E Component providers ONLY: report status to solution providers.
Application Security The secure development of payment applications designed to have access to clear-text account data intended solely for installation on PCI- approved POI devices.
2A Protect PAN and SAD.
2B Develop and maintain secure applications.
2C Implement secure application-management processes.
3A P2PE solution management.
3B Third-party management.
3C Creation and maintenance of P2PE Instruction Manual for merchants.
4A Use approved decryption devices.
4B Secure the decryption environment.
4C Monitor the decryption environment and respond to incidents.
4D Implement secure, hybrid decryption processes.
4E Component providers ONLY: report status to solution providers.
1B Logically secure POI devices.
1C Use P2PE applications that protect PAN and SAD.
1E Component providers ONLY: report status to solution providers.
Application Security The secure development of payment applications designed to have access to clear-text account data intended solely for installation on PCI- approved POI devices.
2A Protect PAN and SAD.
2B Develop and maintain secure applications.
2C Implement secure application-management processes.
3A P2PE solution management.
3B Third-party management.
3C Creation and maintenance of P2PE Instruction Manual for merchants.
4A Use approved decryption devices.
4B Secure the decryption environment.
4C Monitor the decryption environment and respond to incidents.
4D Implement secure, hybrid decryption processes.
4E Component providers ONLY: report status to solution providers.
Modified
p. 7
This table provides an overview of each domain and its associated high-level requirements. Each requirement identified here has corresponding sub-requirements and validation procedures, which are presented in detail beginning at Domain 1: Encryption Device and Application Management.
This table provides an overview of each domain and its associated high-level requirements. Each requirement identified here has corresponding sub-requirements and testing procedures, which are presented in detail beginning at Domain 1: Encryption Device Management.
Modified
p. 7
Domain Overview P2PE Validation Requirements Encryption Device and Application Management The secure management of the PCI- approved POI devices and the resident software.
Domain Overview P2PE Validation Requirements Encryption Device Management The secure management of the PCI- approved PTS POI devices with SRED used for account data acceptance, encryption, and subsequent transmission to the secure decryption environment.
Modified
p. 7
P2PE Solution Management Overall management of the P2PE solution by the solution provider, including third-party relationships, incident response, and the P2PE Instruction Manual (PIM).
2A Protect account data 2B Develop and maintain secure applications 2C Implement secure application-management processes P2PE Solution Management Overall management of the P2PE solution by the solution provider, including third-party relationships, incident response, and the P2PE Instruction Manual (PIM).
Modified
p. 7
Decryption Environment The secure management of the environment that receives encrypted account data and decrypts it.
3A P2PE solution management 3B Third-party management 3C Creation and maintenance of P2PE Instruction Manual for merchants 3D Management of P2PE Applications Decryption Environment The secure management of the environment that receives encrypted account data and decrypts it.
Modified
p. 9
Definition of Secure Cryptographic Devices (SCDs) to be used in P2PE Solutions Secure cryptographic devices (SCDs) are used for the encryption and decryption of account data, signing P2PE Applications, non-payment software, and whitelists, as well as for the storage and management of cryptographic keys. SCDs include but are not limited to key-loading devices (KLDs), point-of-interaction (POI) encryption devices, and hardware security modules (HSMs). An SCD used for the acceptance and encryption of account data at the point of sale is …
Definition of Secure Cryptographic Devices (SCDs) to be used in P2PE Solutions Secure cryptographic devices (SCDs) are used for the encryption and decryption of account data, signing P2PE Applications, Non-payment Software, and whitelists, as well as for the storage and management of cryptographic keys. SCDs include but are not limited to key-loading devices (KLDs), point-of-interaction (POI) encryption devices, and hardware security modules (HSMs).
Modified
p. 9
Note: For P2PE Solutions using hybrid decryption, SCDs are used for encryption of account data as well as for storage and management of cryptographic keys; however, they are not required for decryption of account data.
Modified
p. 9
P2PE Solutions: Hardware Decryption or Hybrid Decryption For PCI P2PE solutions, the encryption environment at the point of merchant acceptance consists exclusively of hardware encryption performed within PCI-approved POI devices.
P2PE Solutions: Hardware Decryption or Hybrid Decryption For P2PE Solutions, the merchant encryption environment at the point of payment acceptance consists exclusively of hardware-based encryption performed within PCI-approved PTS POI devices with SRED.
Modified
p. 9
P2PE decryption environments require HSMs for all management of cryptographic keys, and that HSMs be used for decryption of account data (hardware decryption); or optionally account-data decryption can occur outside an HSM in non-SCD “Host Systems” (hybrid decryption) meeting additional hybrid decryption requirements specified in Domains 4 and 5, in Sections 4D and 5H, respectively.
Modified
p. 9
Note: Hybrid decryption is NOT an option for merchant-managed solutions (MMS).
Modified
p. 10
SCD Type and Usage Domain PCI-Approved POI Device for Account-Data Encryption FIPS 140-2 or 140-3 Level 3 or 4 or PCI Approved HSM for Account-Data Decryption SCD for Cryptographic Key Injection, Key Operations, or Software/Whitelist Signing Encryption Device and Application Management Applicable N/A N/A Application Security N/A N/A N/A P2PE Solution Management N/A N/A N/A Decryption Environment1 N/A Applicable N/A P2PE Cryptographic Key Operations and Device Management1 Applicable Applicable Applicable 1 For hybrid decryption environments, note that while account-data decryption …
SCD Type and Usage Domain PCI-Approved PTS POI Device for Account-Data Encryption FIPS 140-2 or 140-3 Level 3 or 4, or PCI Approved HSM for Account-Data Decryption SCD for Cryptographic Key Injection, Key Operations, or Software/Whitelist Signing Encryption Device and Application Management Applicable N/A N/A Application Security Applicable N/A N/A P2PE Solution Management N/A N/A N/A Decryption Environment1 N/A Applicable N/A P2PE Cryptographic Key Operations and Device Management1 Applicable Applicable Applicable 1 For hybrid decryption environments, note that while account-data …
Removed
p. 11
A “P2PE component provider” is an entity that provides a service assessed to a specific set of P2PE requirements and results in a P2PE component provider listing on the PCI SSC website. P2PE component providers’ services are performed on behalf of other P2PE solution providers for use in P2PE solutions.
There are two options for third-party entities performing functions on behalf of solution providers to validate compliance:
1. Undergo a P2PE assessment of relevant P2PE requirements on their own and submit the applicable P2PE Report on Validation (P-ROV) to
PCI SSC for review and acceptance. Upon acceptance, the P2PE component is listed on PCI SSC’s list of Validated P2PE Components.
2. Have their services reviewed during the course of each of their solution-provider or component-provider customers’ P2PE assessments.
Accordingly, a solution can be reviewed via one of the following scenarios:
1. The solution provider can perform all domains in their entirety.
− A merchant as a solution …
There are two options for third-party entities performing functions on behalf of solution providers to validate compliance:
1. Undergo a P2PE assessment of relevant P2PE requirements on their own and submit the applicable P2PE Report on Validation (P-ROV) to
PCI SSC for review and acceptance. Upon acceptance, the P2PE component is listed on PCI SSC’s list of Validated P2PE Components.
2. Have their services reviewed during the course of each of their solution-provider or component-provider customers’ P2PE assessments.
Accordingly, a solution can be reviewed via one of the following scenarios:
1. The solution provider can perform all domains in their entirety.
− A merchant as a solution …
Modified
p. 11
P2PE Solution Providers (or merchants as solution providers) must manage the overall P2PE Solution and any third parties used to perform P2PE functions on their behalf, whether those third parties are separately listed by PCI SSC as P2PE Component Providers or are assessed as part of the solution provider’s P2PE assessment. Refer to the PCI P2PE Program Guide for additional information regarding the use of third parties and P2PE Component Providers.
Removed
p. 12
“P2PE non-payment software” is any software or other files with no access to clear-text account data that is intended to be loaded onto a PCI- approved POI device and used as part of a P2PE solution.
P2PE non-payment software is assessed only per designated P2PE Domain 1 Requirements at 1C-2 during the assessment of the P2PE solution(s) in which the application will be used. Note that this software is not subject to P2PE Domain 2 Requirements.
P2PE non-payment software is assessed only per designated P2PE Domain 1 Requirements at 1C-2 during the assessment of the P2PE solution(s) in which the application will be used. Note that this software is not subject to P2PE Domain 2 Requirements.
Modified
p. 12
“P2PE Non-payment Software” is any software or other files with no access to cleartext account data that is intended to be loaded onto a PCI- approved PTS POI device and used as part of a P2PE Solution. P2PE Non-payment Software is assessed only per designated P2PE Domain 1 Requirements. Note that this software is not subject to P2PE Domain 2 Requirements.
Modified
p. 12
Note: P2PE applications and P2PE non-payment software do not meet the PTS definition of “firmware” and are not reviewed as part of the PTS POI assessment. Therefore, both P2PE Applications and P2PE non-payment software must be assessed as part of this Standard. Additionally, software meeting the PTS definition of “firmware” is not reassessed during a P2PE assessment (PTS firmware is not considered a P2PE payment application, nor is it P2PE non-payment software).
Note: P2PE Applications and P2PE Non-payment Software do not meet the PCI PTS definition of “firmware” and are not reviewed as part of the PTS POI assessment. Therefore, both P2PE Applications and P2PE Non-payment Software must be assessed as part of this Standard. Additionally, software meeting the PTS definition of “firmware” is not reassessed during a P2PE assessment (PTS firmware is not considered a P2PE Application, nor is it P2PE Non-payment Software).
Modified
p. 12
Refer to the P2PE Program Guide for specific requirements relative to assessing and listing P2PE applications.
Refer to the PCI P2PE Program Guide for specific requirements relative to validating and listing P2PE applications.
Removed
p. 13
The solution provider’s overall management of the P2PE solution including any third-party relationships, communications between various P2PE entities, and/or use of P2PE component providers The merchant-focused P2PE Instruction Manual (PIM) that the solution provider prepares for and distributes to merchants (for their encryption environments), including completion of the PCI-provided PIM Template Domain 4
• Security requirements for the decryption environment Management of all system components located within or connected to the decryption environment, including those used for decryption of account data, and Maintenance of PCI DSS compliance for the decryption environment Domain 5
• Security requirements for P2PE key-management operations Secure key management
•including all HSMs, key-loading devices, etc.
• Security requirements for the decryption environment Management of all system components located within or connected to the decryption environment, including those used for decryption of account data, and Maintenance of PCI DSS compliance for the decryption environment Domain 5
• Security requirements for P2PE key-management operations Secure key management
•including all HSMs, key-loading devices, etc.
Modified
p. 13
Here is a high-level summary of the five P2PE domains:
Here is a high-level summary of the P2PE domains:
Modified
p. 13
Domain 1
• Security requirements for the encryption environment All PCI-approved POI devices included in the P2PEsolution (for the merchant to use for payment acceptance) Integration of all software onto POI devices − P2PE payment applications (subject to a Domain 2 assessment) − P2PE non-payment software (those with no access to clear-text account data•e.g., a loyalty or advertising application) Domain 2
• Security requirements for P2PE applications For software with access to clear-text account data intended for use on PTS-approved POI …
• Security requirements for the encryption environment All PCI-approved POI devices included in the P2PE
• Security requirements for P2PE applications For software with access to clear-text account data intended for use on PTS-approved POI …
Domain 1
• Security requirements for the account data encryption devices and their management within the merchant environment § All PCI-approved PTS POI devices included in the P2PE Solution (for the merchant to use for payment acceptance) § Integration of all software/files onto PTS POI devices
• Security requirements for the account data encryption devices and their management within the merchant environment § All PCI-approved PTS POI devices included in the P2PE Solution (for the merchant to use for payment acceptance) § Integration of all software/files onto PTS POI devices
Modified
p. 13
Note: This domain cannot be outsourced to a third party or a P2PE component provider and MUST be performed by the P2PE solution provider (or merchant as a solution provider).
Note: This domain cannot be outsourced to a third party or to a P2PE Component Provider and MUST be satisfied by the P2PE Solution Provider (or merchant as a solution provider for MMS).
Modified
p. 13 → 14
•used by the solution provider or third party for cryptographic-key operations performed in support of account-data encryption POI devices and decryption HSMs
•used by the solution provider or third party for cryptographic-key operations performed in support of account-data encryption PTS POI devices and decryption HSMs Relationship between the PCI P2PE Standard and other PCI Standards The relationship with other PCI standards is as follows:
Removed
p. 14
POI devices (for account-data encryption) are approved per PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements HSMs in the decryption environment used for account-data decryption and related cryptographic-key operations are approved per PCI PTS HSM or FIPS 140-2 or 140-3 Level 3 (or 4) Cryptographic-key operations for both encryption and decryption environments using key-management practices from the PTS PIN Security Standard The decryption environment is PCI DSS compliant Please note that this standard for point-to-point encryption solutions does not supersede the PCI Data Security Standard, PCI PIN Security Requirements, or any other PCI Standards, nor do these requirements constitute a recommendation from the Council or obligate merchants, service providers, or financial institutions to purchase or deploy such solutions. As with all other PCI standards, any mandates, regulations, or rules regarding these requirements are provided by the participating payment brands.
Any sampling of POI devices and their applications, cryptographic keys, …
Any sampling of POI devices and their applications, cryptographic keys, …
Modified
p. 14
Sampling of system components for assessment purposes does not reduce the scope of the solution-provider environment or the applicability of P2PE requirements. Whether or not sampling is to be used, P2PE requirements apply to the entire solution-provider environment. If sampling is used, each sample must be assessed against all applicable P2PE requirements. Sampling of the P2PE requirements themselves is not permitted.
Sampling of system components for assessment purposes does not reduce the scope of the applicability of P2PE requirements. Whether or not sampling is to be used, P2PE requirements apply to the entire P2PE Product under assessment as indicated in the P2PE Applicability of
Modified
p. 15
Multiple Acquirers The P2PE standard outlines the technology and processes needed to ensure the security of a solution that protects account data from the point of interaction to the point of initial decryption. In some instances, multiple acquirers or multiple solution providers may manage one or more P2PE solutions on the same merchant POI device. P2PE does not preclude these scenarios, as the business processes governing this shared environment are outside the responsibility of the PCI SSC. Vendors and merchants …
Multiple Acquirers The P2PE Standard outlines the technology and processes needed to ensure the security of a solution that protects account data from the point of interaction to the point of initial decryption. In some instances, multiple acquirers or multiple solution providers may manage one or more P2PE solutions on the same merchant PTS POI device. P2PE does not preclude these scenarios, as the business processes governing this shared environment are outside the responsibility of the PCI SSC. Vendors and …
Modified
p. 15 → 16
P2PE Program Guide Please refer to the P2PE Program Guide for information about the P2PE program, including the following topics:
P2PE Program Guide Refer to the PCI P2PE Program Guide for information about the PCI P2PE program, including, but not limited to, the following topics:
Modified
p. 15 → 16
P2PE Component Provider types P2PE Report on Validation submission and acceptance processes Annual renewal process for solutions included on the list of Validated P2PE Solutions Vendor Release Agreements for vendors and providers of P2PE solutions, applications, and solution components The P2PE Delta Change process.
§ Applicability matrix denoting the applicability of P2PE security requirements for each P2PE Product § P2PE Component Provider types § P2PE Report on Validation submission and acceptance processes § Annual renewal process for validated P2PE products § Vendor Release Agreements for vendors and providers of P2PE Solutions, P2PE Applications, and P2PE Components § The Administrative and Delta Change processes § Notification responsibilities in the event a listed P2PE solution is determined to be at fault in a compromise
Modified
p. 15 → 16
Note: The PCI SSC does not approve or list merchant-managed solutions (MMS) on its website. Refer to the Program Guide for more information on MMS.
Note: The PCI SSC does not approve or list merchant-managed solutions (MMS) on its website. Refer to the P2PE Program Guide for more information on MMS.
Removed
p. 16
Diagram 1: Example P2PE Implementation at a Glance Key Management and Remote/Local Cryptographic Key Loading Hardware Security Module (FIPS 140-2 or PCI HSM Approved) P2PE Key Management and Cryptography Account Data Application 1 Account Data Application 2 Non-account Data Application 3 P2PE Key Management and Cryptography Plain-text account data Encrypted (or truncated) Communications w/o account data Transaction account data flow (encrypted or truncated data only) Assessed to PCI PTS POI (SRED) Assessed to P2PE Domain 1 Assessed to P2PE Domain 2
PCI DSS validation as required by the merchant's acquirer or payment brand Customer presentment of payment card POS software and other Merchant systems (Encrypted and/or truncated payment card data may pass through these systems, or be transmitted directly to solution provider from the POI.) Communications Interface (Including Open Protocols, remote and key management) Assessed to P2PE Domain 3 Assessed to P2PE Appendix A (Merchant-managed Solutions only) Assessed to P2PE Domain …
PCI DSS validation as required by the merchant's acquirer or payment brand Customer presentment of payment card POS software and other Merchant systems (Encrypted and/or truncated payment card data may pass through these systems, or be transmitted directly to solution provider from the POI.) Communications Interface (Including Open Protocols, remote and key management) Assessed to P2PE Domain 3 Assessed to P2PE Appendix A (Merchant-managed Solutions only) Assessed to P2PE Domain …
Modified
p. 16 → 18
Note: This diagram is for illustrative purposes and shows only one type of scenario that may occur.
Note: This diagram is for illustrative purposes.
Removed
p. 18
• Key Management, Part 2: Mechanisms Using Symmetric Key Management Techniques
•3: Information Technology
• Key Management, Part 3: Mechanisms Using Asymmetric Techniques (RSA and Diffie-Hellman) ISO 13491: Banking
• Secure Cryptographic Devices (Retail) ISO TR 14742: Financial services - Recommendations on cryptographic algorithms and their use ISO 16609: Banking
• Requirements for message authentication using symmetric techniques ISO 18031: Information technology -- Security techniques -- Random bit generation ISO/IEC 18033-3: Information Technology
• Encryption algorithms
• Part 3: Block Ciphers ISO TR 19038: Guidelines on Triple DEA Modes of Operation ISO 20038: Banking and related financial services -- Key wrap using AES NIST NIST Special Publication 800-22: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications NIST Special Publication 800-57: Recommendation for Key Management NIST Special Publication 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management NIST Special Publication 800-131: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key …
•3: Information Technology
• Key Management, Part 3: Mechanisms Using Asymmetric Techniques (RSA and Diffie-Hellman) ISO 13491: Banking
• Secure Cryptographic Devices (Retail) ISO TR 14742: Financial services - Recommendations on cryptographic algorithms and their use ISO 16609: Banking
• Requirements for message authentication using symmetric techniques ISO 18031: Information technology -- Security techniques -- Random bit generation ISO/IEC 18033-3: Information Technology
• Encryption algorithms
• Part 3: Block Ciphers ISO TR 19038: Guidelines on Triple DEA Modes of Operation ISO 20038: Banking and related financial services -- Key wrap using AES NIST NIST Special Publication 800-22: A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications NIST Special Publication 800-57: Recommendation for Key Management NIST Special Publication 800-63B: Digital Identity Guidelines - Authentication and Lifecycle Management NIST Special Publication 800-131: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key …
Removed
p. 20
1B Logically secure POI devices.
1C Use P2PE applications that protect PAN and SAD.
1C Use P2PE applications that protect PAN and SAD.
Removed
p. 20
It is not the intent of Domain 1 that solution providers (or component providers) actively manage POI devices onsite at merchant locations.
Note: Domain 1 includes the only requirements applicable to P2PE non- payment software (software on PCI-approved POI devices without access to account data). For software that never has access to account data, only Requirements at 1C-2 are applicable•this will validate that this software is not accessing account data, and is not bypassing or overriding any security features provided by the other approved components of the device. However, requirements in Domain 5 apply to the SCD used for signing non-payment software as well as the associated cryptographic keys and key management.
For more information, refer to the section entitled “P2PE Solutions and Use of P2PE Applications and/or P2PE Non-payment Software.” Within this domain, the term “solution provider” refers to whichever entity is undergoing the P2PE assessment. This may be a solution …
Note: Domain 1 includes the only requirements applicable to P2PE non- payment software (software on PCI-approved POI devices without access to account data). For software that never has access to account data, only Requirements at 1C-2 are applicable•this will validate that this software is not accessing account data, and is not bypassing or overriding any security features provided by the other approved components of the device. However, requirements in Domain 5 apply to the SCD used for signing non-payment software as well as the associated cryptographic keys and key management.
For more information, refer to the section entitled “P2PE Solutions and Use of P2PE Applications and/or P2PE Non-payment Software.” Within this domain, the term “solution provider” refers to whichever entity is undergoing the P2PE assessment. This may be a solution …
Modified
p. 20 → 21
1E Component providers ONLY: report status to solution providers Target audience: P2PE solution providers or those who, on behalf of P2PE solution providers, manage the POI devices and their applications used in the P2PE solution.
1E Component providers ONLY: report status to solution providers Target audience: P2PE Solution Providers or those who, on behalf of P2PE Solution Providers (a Component Provider or a Third Party), manage the PTS POI devices used in the P2PE Solution.
Modified
p. 20 → 21
Domain 1 requirements encompass the use of secure point-of- interaction (POI) devices and P2PE applications and/or P2PE non-payment software. The POI device must be a PCI-approved POI device with SRED. Domain 1 requirements also include the confirmation that all P2PE applications and P2PE non-payment software are properly reviewed, installed, and configured on the device.
Domain 1 requirements encompass the use of secure PTS POI devices and their management. The POI device must be a PCI-approved PTS POI device with SRED.
Removed
p. 21
See “P2PE Solutions and use of Third Parties and/or P2PE Component Providers” for more information about validating this Domain as a solution provider, a component provider, or a merchant as a solution provider.
1A-1.1 For each POI device type used in the solution, examine the POI device and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
1A-1.1.1.b For all POI device types used in the solution, review POI device configurations to verify that all POI device types used in the solution have SRED capabilities enabled and active (that is, the POI devices are operating in “encrypting mode”) prior to devices being deployed to merchant encryption environments.
1A-1.1 For each POI device type used in the solution, examine the POI device and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
1A-1.1.1.b For all POI device types used in the solution, review POI device configurations to verify that all POI device types used in the solution have SRED capabilities enabled and active (that is, the POI devices are operating in “encrypting mode”) prior to devices being deployed to merchant encryption environments.
Modified
p. 21 → 22
Requirement 1A: Account data must be encrypted in equipment that is resistant to physical and logical compromise Domain 1 Requirements Testing Procedures 1A-1 PCI-approved POI devices with SRED are used for transaction acceptance.
Requirement 1A: Account data must be accepted by, processed, and encrypted in PCI-approved PTS POI devices with Domain 1 Requirements Testing Procedures 1A-1 PCI-approved PTS POI devices with SRED are used for payment acceptance in the merchant environment.
Modified
p. 21 → 22
1A-1.1 Account-data encryption operations must be performed using a POI device approved per the PCI PTS program with SRED (secure reading and exchange of data). The PTS approval listing must match the deployed devices in the following characteristics:
1A-1.1 Account-data encryption operations must be performed using a PTS POI device (including the individual hardware and firmware) approved per the PCI PTS program with SRED (secure reading and exchange of data). The PTS approval listing must match the deployed PTS POI devices in the following characteristics:
Modified
p. 21 → 22
• Firmware version number(s)
• Firmware (FW) version number(s)
Modified
p. 21 → 22
• Firmware version number(s)
• Firmware (FW) version number(s)
Modified
p. 21 → 22
Note: The PCI PTS POI approval listing must not be expired.
Note: The PCI PTS POI approval listing must not be expired. The PCI PTS POI firmware must not be expired. Individual PTS POI hardware and firmware must also be assessed and approved to the PTS POI SRED requirements.
Modified
p. 21 → 22
1A-1.1.1 The PTS POI device’s SRED capabilities must be enabled and active prior to being placed into service.
Modified
p. 21 → 22
1A-1.1.1.a Examine documented procedures and interview personnel to verify that procedures are defined to ensure that SRED capabilities are enabled and active on all POI devices prior to devices being deployed to merchant encryption environments.
1A-1.1.1.a Examine documented procedures to verify that SRED capabilities are enabled and active on all PTS POI devices prior to the devices being placed into service for payment acceptance in merchant encryption environments.
Removed
p. 22
1A-1.2.a For all POI device types used in the P2PE solution, identify and document all account-data capture interfaces.
1A-1.2.1 All account-data capture mechanisms on the POI device must be SRED-validated, or must be disabled or otherwise prevented from being used for P2PE transactions such that they cannot be enabled by the merchant.
1A-1.2.1.a Examine POI device configuration and deployment procedures to verify they include either:
• Disabling all capture mechanisms that are not SRED validated, or
• Implementing configurations that prevent all non-SRED validated capture mechanisms from being used for P2PE transactions 1A-1.2.1.b Verify that the documented procedures include ensuring that all non- SRED-validated capture mechanisms are disabled or otherwise prevented from being used for P2PE transactions prior to devices being deployed to merchant encryption environments.
1A-1.2.1.c For all POI device types, verify:
• All non-validated capture mechanisms are either disabled or configured to prevent their use for P2PE transactions prior to devices being deployed to …
1A-1.2.1 All account-data capture mechanisms on the POI device must be SRED-validated, or must be disabled or otherwise prevented from being used for P2PE transactions such that they cannot be enabled by the merchant.
1A-1.2.1.a Examine POI device configuration and deployment procedures to verify they include either:
• Disabling all capture mechanisms that are not SRED validated, or
• Implementing configurations that prevent all non-SRED validated capture mechanisms from being used for P2PE transactions 1A-1.2.1.b Verify that the documented procedures include ensuring that all non- SRED-validated capture mechanisms are disabled or otherwise prevented from being used for P2PE transactions prior to devices being deployed to merchant encryption environments.
1A-1.2.1.c For all POI device types, verify:
• All non-validated capture mechanisms are either disabled or configured to prevent their use for P2PE transactions prior to devices being deployed to …
Modified
p. 22
1A-1.2.a Examine documented procedures to verify that PTS POI devices must be configured to use only SRED-validated account-data capture mechanisms of the approved hardware/firmware.
Removed
p. 23
1A-2 Applications on POI devices with access to clear-text account data are assessed per Domain 2 before being deployed into a P2PE solution.
Note: Applications included in a P2PE solution but not already listed on the list of Validated P2PE Applications must undergo an assessment per Domain 2 (in addition to meeting applicable application requirements in Domain 1).
1A-2.1 All applications on POI devices with access to clear-text account data must be assessed according to Domain 2.
The assessment must match the application in the following characteristics:
• Version number 1A-2.1.a For applications on the PCI SSC list of Validated P2PE Applications, review the list and compare to applications used in the solution to verify that the applications match the P2PE application listing in the following characteristics:
• Version number 1A-2.1.b For applications not on the PCI SSC list of Validated P2PE Applications, review the application P-ROV(s) and verify that the applications used in the …
Note: Applications included in a P2PE solution but not already listed on the list of Validated P2PE Applications must undergo an assessment per Domain 2 (in addition to meeting applicable application requirements in Domain 1).
1A-2.1 All applications on POI devices with access to clear-text account data must be assessed according to Domain 2.
The assessment must match the application in the following characteristics:
• Version number 1A-2.1.a For applications on the PCI SSC list of Validated P2PE Applications, review the list and compare to applications used in the solution to verify that the applications match the P2PE application listing in the following characteristics:
• Version number 1A-2.1.b For applications not on the PCI SSC list of Validated P2PE Applications, review the application P-ROV(s) and verify that the applications used in the …
Removed
p. 24
1B-1.1.b For a sample of all POI device types intended for use in a solution, logon to the device using an authorized test merchant account. Verify that merchant account level logical access meets the following:
Modified
p. 24
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-1 Solution provider ensures that logical access to POI devices deployed at merchant encryption environment(s) is restricted to authorized personnel.
Requirement 1B: Secure logical access to PTS POI devices Domain 1 Requirements Testing Procedures 1B-1 Solution provider ensures that logical access to PTS POI devices deployed at merchant encryption environment(s) is restricted to authorized personnel.
Modified
p. 24
1B-1.1 Solution provider must ensure merchant logical access to POI devices, if needed, is restricted as follows:
1B-1.1 Solution provider must ensure merchant logical access (by any means/method) to PTS POI devices, if needed, is restricted as follows:
Modified
p. 24
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear-text PAN and/or SAD.
• Cannot view or access device configuration settings that could impact the security controls of the device or allow access to cryptographic keys or cleartext account data.
Modified
p. 24
• Cannot enable disabled device interfaces or disabled data-capture mechanisms.
• Cannot [re]enable device interfaces or data-capture mechanisms that are required to be disabled.
Modified
p. 24
• Does not use any POI vendor default device passwords.
• Does not use the PTS POI vendor’s default passwords.
Modified
p. 24
1B-1.1.a Examine documented POI device configuration procedures and documented account privilege assignment rules to verify that merchant logical access to POI devices is restricted as follows:
• Cannot access PTS POI devices remotely 1B-1.1.a Examine documented PTS POI device configuration procedures and documented account privilege assignment rules to verify that merchant logical access (by any means/method) to PTS POI devices is restricted as follows:
Modified
p. 24
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear- text PAN and/or SAD.
• Cannot view or access device configuration settings that could impact the security controls of the device or allow access to cryptographic keys or cleartext account data.
Modified
p. 24
• Does not use the POI vendor’s default passwords.
• Does not use the PTS POI vendor’s default passwords.
Modified
p. 24
• Cannot enable disabled device interfaces or disabled data-capture mechanisms.
• Cannot [re]enable device interfaces or data- capture mechanisms that are required to be disabled.
Modified
p. 24 → 25
• Cannot enable disabled device interfaces or disabled data-capture mechanisms
• Cannot [re]enable device interfaces or data-capture mechanisms that are required to be disabled.
Modified
p. 24 → 25
• Does not use the POI vendor’s default passwords.
• Does not use the PTS POI vendor’s default passwords.
Modified
p. 24 → 25
• Cannot view or access device configuration settings that could impact the security controls of the device, or allow access to cryptographic keys or clear- text PAN and/or SAD
• Cannot view or access device configuration settings that could impact the security controls of the device or allow access to cryptographic keys or cleartext account data.
Removed
p. 25
• The solution provider must document which payment application(s) facilitates printing of PANs for merchants.
• The P2PE application that facilitates this is confirmed per 1A-2.1 as assessed to Domain 2 and on PCI SSC’s list of Validated P2PE Applications.
Note: Domain 2 (at 2A-3.1.2) and Domain 3 (at 3A- 1.3) also include requirements that must be met for any P2PE application and P2PE solution provider, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
1B-1.1.1.a Review solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation specifies the payment application(s) that facilitate printing of PANs for merchants.
1B-1.1.1.b Review applications confirmed at 1A-2.1 to verify the application(s) that facilitates printing of full PANs on merchant receipts is on PCI SSC’s list of Validated P2PE Applications.
1B-1.2 All solution-provider personnel …
• The P2PE application that facilitates this is confirmed per 1A-2.1 as assessed to Domain 2 and on PCI SSC’s list of Validated P2PE Applications.
Note: Domain 2 (at 2A-3.1.2) and Domain 3 (at 3A- 1.3) also include requirements that must be met for any P2PE application and P2PE solution provider, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
1B-1.1.1.a Review solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation specifies the payment application(s) that facilitate printing of PANs for merchants.
1B-1.1.1.b Review applications confirmed at 1A-2.1 to verify the application(s) that facilitates printing of full PANs on merchant receipts is on PCI SSC’s list of Validated P2PE Applications.
1B-1.2 All solution-provider personnel …
Modified
p. 25 → 26
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-1.1.1 Where there is a legal or regulatory obligation in a region for merchants to print full PAN on merchant receipts, it is allowable for the merchant to have access to full PAN for this purpose but ONLY if the following are met:
Requirement 1B: Secure logical access to PTS POI devices Domain 1 Requirements Testing Procedures
Removed
p. 26
1B-1.2.1.b For a sample of all POI devices and personnel, observe configured accounts and permissions, and interview responsible personnel to verify that the level of logical access granted is according to least privilege and need to know.
1B-2.1.c Interview personnel and observe actual remote connection attempts to verify that either multi-factor or cryptographic authentication is used for all remote access to POI devices.
1B-2.3 POI devices must be configured such that merchants do not have remote access to the merchant POI devices.
1B-2.3.a Examine documented POI-configuration procedures and interview personnel to verify that devices must be configured to ensure merchants do not have remote access to the POI devices.
1B-2.3.b For all device types used in the solution, observe a sample of device configurations to verify that merchants do not have remote access to the POI devices.
1B-2.1.c Interview personnel and observe actual remote connection attempts to verify that either multi-factor or cryptographic authentication is used for all remote access to POI devices.
1B-2.3 POI devices must be configured such that merchants do not have remote access to the merchant POI devices.
1B-2.3.a Examine documented POI-configuration procedures and interview personnel to verify that devices must be configured to ensure merchants do not have remote access to the POI devices.
1B-2.3.b For all device types used in the solution, observe a sample of device configurations to verify that merchants do not have remote access to the POI devices.
Modified
p. 26 → 25
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-1.2.1 Solution provider personnel with logical access to POI devices deployed in merchant encryption environments must be granted based on least privilege and need to know.
Requirement 1B: Secure logical access to PTS POI devices Domain 1 Requirements Testing Procedures 1B-1.1.b Interview personnel and observe processes to verify that merchant logical access meets the following:
Modified
p. 26 → 25
1B-2 Solution provider secures any remote access to POI devices deployed at merchant encryption environments.
1B-1.2.1 [Combined into 1B-1.2] 1B-2 Solution provider secures any remote access to PTS POI devices deployed at merchant encryption environments.
Modified
p. 26 → 25
1B-2.1 Solution provider’s authorized personnel must use multi-factor or cryptographic authentication for all remote access to merchant POI devices.
1B-2.1 Solution provider’s authorized personnel must use multi-factor or cryptographic authentication for all remote access to merchant PTS POI devices.
Modified
p. 26 → 25
1B-2.1.a Examine documented procedures to verify that either multi-factor or cryptographic authentication must be used for all remote access to POI devices.
[continued on next page] 1B-2.1.a Examine documented procedures to verify that either multi-factor or cryptographic authentication must be used for all remote access to PTS POI devices.
Modified
p. 26 → 25
1B-2.1.b Observe remote-access mechanisms and controls to verify that either multi- factor or cryptographic authentication is configured for all remote access to POI devices.
1B-2.1.b Interview personnel and observe remote-access mechanisms and controls to verify that either multi-factor or cryptographic authentication is used for all remote access to PTS POI devices.
Modified
p. 26
1B-2.4 Examine documentation to verify secure identification and authentication procedures are defined for remote access to PTS POI devices deployed at merchant encryption environments.
Modified
p. 26
Note: Authorized solution provider personnel must use multi-factor or cryptographic authentication for all remote access to a terminal management system (TMS) or similar system used to either directly access or to manage merchant POI devices.
Note: Authorized solution provider personnel must use multi-factor or cryptographic authentication for all remote access to a terminal management system (TMS), or similar system used to either directly access or to manage merchant PTS POI devices.
Modified
p. 26
1B-2.2 POI devices must be configured to ensure that remote access is only permitted from the solution provider’s authorized systems (which might include a terminal management system (TMS) or similar system).
1B-2.1.c [Removed] 1B-2.2 PTS POI devices must be configured to ensure that remote access is only permitted from the solution provider’s authorized systems (which might include a terminal management system (TMS) or similar system).
Modified
p. 26
1B-2.2.a Examine documented device-configuration procedures and interview personnel to verify that devices must be configured to permit remote access only from the solution provider’s authorized systems.
1B-2.2.a Examine documented PTS POI device-configuration procedures to verify that PTS POI devices must be configured to permit remote access only from the solution provider’s authorized systems.
Modified
p. 26
1B-2.2.b For all devices used in the solution, observe a sample of device configurations to verify that remote access is permitted only from the solution provider’s authorized systems.
1B-2.2.b Interview personnel and observe the remote access process to verify that remote access is permitted only from the solution provider’s authorized systems.
Removed
p. 27
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-2.4 Solution provider must implement secure identification and authentication procedures for remote access to POI devices deployed at merchant encryption environments.
1B-2.4 Examine documentation to verify secure identification and authentication procedures are defined for remote access to POI devices deployed at merchant encryption environments.
1B-2.4 Examine documentation to verify secure identification and authentication procedures are defined for remote access to POI devices deployed at merchant encryption environments.
Modified
p. 27 → 26
1B-2.5.1 Tracing all logical access to POI devices by solution-provider personnel to an individual user.
1B-2.5.1 Tracing all logical access to PTS POI devices by solution-provider personnel to an individual user.
Modified
p. 27 → 26
1B-2.5.1.a Examine POI device configurations and authentication mechanisms to verify that all logical access to POI devices by solution-provider personnel can be traced to an individual user.
1B-2.5.1.a Examine documentation to verify that all logical access to PTS POI devices by solution-provider personnel can be traced to an individual user.
Modified
p. 27
1B-2.5.1.b Observe a sample of authorized logical accesses and examine access records/logs to verify that all logical access is traced to an individual user.
Requirement 1B: Secure logical access to PTS POI devices Domain 1 Requirements Testing Procedures 1B-2.5.1.b Observe a sample of authorized logical accesses and examine access records/logs to verify that all logical access is traced to an individual user.
Modified
p. 27
1B-2.5.2 Maintaining audit logs of all logical access to POI devices by solution-provider personnel and retaining access logs for at least one year.
1B-2.5.2 Maintaining audit logs of all logical access to PTS POI devices by solution-provider personnel and retaining access logs for at least one year.
Modified
p. 27
1B-2.5.2 Examine documentation to verify that access records/logs of all logical access to POI devices by solution-provider personnel are required to be retained for at least one year.
1B-2.5.2 Examine documentation to verify that access records/logs of all logical access to PTS POI devices by solution-provider personnel are required to be retained for at least one year.
Removed
p. 28
1B-3.1 Secure update processes must be implemented for all firmware and software updates, including:
• Integrity check of update
• Verification of the origin of the update 1B-3.1.a Examine documented procedures to verify secure update processes are defined for all firmware and software updates, and include:
• Integrity checks of update
• Verification of the origin of the update 1B-3.1.b Observe a sample of firmware and software updates, and interview personnel to verify:
• The integrity of the update is checked
• Integrity check of update
• Verification of the origin of the update 1B-3.1.a Examine documented procedures to verify secure update processes are defined for all firmware and software updates, and include:
• Integrity checks of update
• Verification of the origin of the update 1B-3.1.b Observe a sample of firmware and software updates, and interview personnel to verify:
• The integrity of the update is checked
Modified
p. 28 → 27
1B-3 The solution provider implements procedures to protect PTS POI devices and applications from known vulnerabilities and securely update devices.
Modified
p. 28 → 27
1B-3.1 [Requirement removed] 1B-3.2 An up-to-date inventory of PTS POI device system builds must be maintained and confirmed at least annually and upon any changes to the build.
Modified
p. 28 → 27
Note: A POI system build includes at least the following information:
Note: A PTS POI system build includes at least the following information:
Modified
p. 28 → 27
• Hardware version number
• Hardware version number(s)
Modified
p. 28 → 27
• P2PE Payment Applications
• PTS Application version number(s)
Modified
p. 28 → 27
• Procedures for maintaining an up-to-date inventory of POI device system builds
• Procedures for maintaining an up-to-date inventory of PTS POI device system builds
Modified
p. 28 → 27
• Procedures for confirming all builds at least annually and upon any changes to the build 1B-3.2.b Review documented inventory of devices, and examine the inventory of system builds to verify:
• Procedures for confirming all builds at least annually and upon any changes to the build 1B-3.2.b Examine documented inventory of PTS POI devices and their system builds to verify:
Modified
p. 28 → 27
• The inventory includes all POI device system builds.
• The inventory includes all PTS POI device system builds.
Modified
p. 28 → 27
• The inventory of POI device system builds is up to date.
• The inventory of PTS POI device system builds is up to date.
Removed
p. 29
1B-3.4.c Observe authorized personnel attempt to run the update process with arbitrary code to verify that the system will not allow the update to occur.
Modified
p. 29 → 28
Requirement 1B: Secure logical access to POI devices Domain 1 Requirements Testing Procedures 1B-3.3 Critical software security updates must be deployed to POI devices in the field within 30 days of receipt from device vendors or application vendors.
Requirement 1B: Secure logical access to PTS POI devices Domain 1 Requirements Testing Procedures 1B-3.3 Critical software security updates must be deployed to PTS POI devices in the merchant environment within 30 days of receipt from PTS POI device vendors and application/software vendors.
Modified
p. 29 → 28
These security patches can be deployed via “push” from the solution provider or vendor, or via “pull” from the PTS POI device or merchant. In all cases, the solution provider is ultimately responsible to ensure security patches are installed in a timely manner.
Modified
p. 29 → 28
Aligns with 2C-1.2 1B-3.3.a Examine documented procedures to verify they include defined procedures for deploying critical software security updates to POI devices in the field within 30 days of receipt from device or application vendors.
Aligns with 2C-1.2 1B-3.3.a Examine documented procedures to verify they include defined procedures for deploying critical software security updates to PTS POI devices in the merchant environment within 30 days of receipt from PTS POI device vendors and application/software vendors.
Modified
p. 29 → 28
1B-3.3.b Examine security update deployment records and device logs, and interview responsible solution provider personnel and to verify that critical security updates are deployed to devices and applications in the field within 30 days of receipt from device and application vendors.
1B-3.3.b Examine security update deployment records and device logs, and interview responsible solution provider personnel to verify that critical security updates are deployed to PTS POI devices in the merchant environment within 30 days of receipt from PTS POI device vendors and application/software vendors.
Modified
p. 29 → 28
1B-3.4 The integrity of patch and update code must be maintained during delivery and deployment, as defined by the vendor•e.g., in the POI device vendor's security guidance or in the P2PE application’s Implementation Guide.
1B-3.4 The integrity of software updates must be maintained during delivery and deployment, as defined by the relevant vendor•e.g., in the PTS POI device vendor's security guidance or in the P2PE Application’s Implementation Guide.
Modified
p. 29 → 28
1B-3.4.a Examine documented procedures for device updates to verify they follow guidance from the device or application vendor to maintain the integrity of all patch and update code during delivery and deployment.
1B-3.4.a Examine documented procedures for PTS POI device software updates to verify they follow guidance from the PTS POI device or application/software vendor to maintain the integrity of all patch and update code during delivery and deployment.
Modified
p. 29 → 28
1B-3.4.b Observe processes for delivering updates and interview responsible personnel to verify that the integrity of patch and update code is maintained during delivery and deployment, and according to guidance from the device or application vendor.
1B-3.4.b Observe processes for delivering updates and interview responsible personnel to verify that the integrity of software is maintained during delivery and deployment, and according to guidance from the PTS POI device or application/software vendor. This must include attempts to load/run invalid software to verify the update is rejected.
Removed
p. 30
• Changes to the applications within the device
• Changes to the firmware within the device
• Changes to the firmware within the device
Modified
p. 30 → 29
1B-4.1 Any account data used for debugging or troubleshooting purposes must be securely deleted. These data sources must be collected in limited amounts and collected only when necessary to resolve a problem, encrypted while stored, and deleted immediately after use.
Modified
p. 30 → 29
1B-4.1.a Examine the solution provider’s procedures for troubleshooting customer problems and verify the procedures include:
1B-4.1.a Examine documented procedures for troubleshooting customer problems and verify the procedures include the following for account data:
Modified
p. 30 → 29
• PAN and/or SAD is never output to merchant environments
• Never output to merchant environments
Modified
p. 30 → 29
• Collection of PAN and/or SAD only when needed to solve a specific problem
• Collection only when needed to solve a specific problem
Modified
p. 30 → 29
• Storage of such data in a specific, known location with limited access
• Storage in a specific, known location with limited access
Modified
p. 30 → 29
• Encryption of PAN and/or SAD while stored
• Encryption while stored
Modified
p. 30 → 29
• Secure deletion of such data immediately after use 1B-4.1.b For a sample of recent troubleshooting requests, observe data collection and storage locations, and interview responsible personnel to verify the procedures identified at 1B-4.1.a were followed.
• Secure deletion immediately after use 1B-4.1.b For a sample of recent troubleshooting requests, observe data collection and storage locations, and interview responsible personnel to verify the procedures identified at 1B-4.1.a were followed.
Modified
p. 30 → 29
1B-5 The P2PE solution provides auditable logs of any changes to critical functions of the POI device(s).
1B-5 The P2PE solution provider maintains auditable logs of any changes to critical functions of the PTS POI device(s).
Modified
p. 30 → 29
1B-5.1 Any changes to critical functions of POI devices must be logged•either on the device or within the remote-management systems of the P2PE solution provider.
1B-5.1 Any changes to critical functions of PTS POI devices must be logged•either on the PTS POI device or within the remote-management systems of the P2PE solution provider.
Modified
p. 30 → 29
1B-5.1.a Examine device and/or system configurations to verify that any changes to the critical functions of the POI devices are logged, including:
1B-5.1.a Examine documented procedures to verify that any changes to the critical functions of the PTS POI devices are logged, including:
Modified
p. 30 → 29
• Changes to the applications within the device
• Changes to the applications/software within the device
Modified
p. 30 → 29
• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) 1B-5.1.b Observe authorized personnel perform authorized changes on POI devices, as follows, and examine log files to verify that all such activities result in a correlating log file:
• Changes to any security-sensitive configuration options within the device (including whitelists and debug modes) 1B-5.1.b Observe authorized personnel perform authorized changes on PTS POI devices and examine the log files to verify all activities in 1B-5.1.a.
Modified
p. 30 → 29
1B-5.1.1.a Examine documented procedures and sample logs to ensure access to logs is limited to need-to-know personnel and the integrity of logs is maintained and verified.
Removed
p. 31
Requirement 1C: Use applications that protect PAN and SAD Domain 1 Requirements Testing Procedures 1C-1 Applications are implemented securely, including when using shared resources and when updating applications and application functionality.
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
• Cryptographic authentication by the POI device’s firmware
• Approval of functionality by authorized personnel prior to implementation
• Approval of functionality by authorized personnel prior to implementation
− Description and justification for the functionality − The identity of the authorized person who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Aligns with 2A-3.4 1C-1.1 Review documented policies and procedures and interview personnel to verify that processes for implementing any …
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
• Cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
• Cryptographic authentication by the POI device’s firmware
• Approval of functionality by authorized personnel prior to implementation
• Approval of functionality by authorized personnel prior to implementation
− Description and justification for the functionality − The identity of the authorized person who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data Aligns with 2A-3.4 1C-1.1 Review documented policies and procedures and interview personnel to verify that processes for implementing any …
Modified
p. 31 → 30
1C-1.1 Processes for any whitelisting functionality must include:
1C-1.1 Processes for managing whitelisting functionality must exist and include, at a minimum:
Modified
p. 31 → 30
a) Implementing whitelisting functionality in accordance with the (as applicable):
Modified
p. 31 → 30
c) Review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data
Modified
p. 31 → 30
d) Documentation for all new installations and updates to whitelist functionality that includes the following (at a minimum):
Modified
p. 31 → 30
- The identity of the authorized person who approved the new installation or updated functionality prior to release.
Modified
p. 31
c) Documentation for all new installations and updates to Non-payment software that includes the following (at a minimum):
Modified
p. 31 → 32
- PTS POI device vendor's security guidance - P2PE Application’s Implementation Guide
Removed
p. 32
Requirement 1C: Use applications that protect PAN and SAD Domain 1 Requirements Testing Procedures 1C-1.1.1 Any whitelisting functionality must only allow the output of clear-text account data for non-PCI payment brand account/card data.
1C-1.1.1.a Observe application and device configurations and interview personnel to verify that whitelisting functionality only allows for the output of non-PCI payment brand accounts/cards, by following guidance in either the device vendor's security guidance or the application’s Implementation Guide.
1C-1.1.1.b For all device types with whitelisting functionality, perform test transactions to verify the output of clear-text account data is only enabled for non- PCI payment brand account/card data.
1C-1.1.2 Any new installations of, or updates, to whitelisting functionality must be:
• Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
• Cryptographically authenticated by the POI device’s firmware in accordance with the device vendor's security guidance or the application’s Implementation Guide.
1C-1.1.2 Observe the …
1C-1.1.1.a Observe application and device configurations and interview personnel to verify that whitelisting functionality only allows for the output of non-PCI payment brand accounts/cards, by following guidance in either the device vendor's security guidance or the application’s Implementation Guide.
1C-1.1.1.b For all device types with whitelisting functionality, perform test transactions to verify the output of clear-text account data is only enabled for non- PCI payment brand account/card data.
1C-1.1.2 Any new installations of, or updates, to whitelisting functionality must be:
• Cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
• Cryptographically authenticated by the POI device’s firmware in accordance with the device vendor's security guidance or the application’s Implementation Guide.
1C-1.1.2 Observe the …
Modified
p. 32 → 30
- Description and justification for the functionality
Modified
p. 32 → 31
- The identity of the authorized person who approved the new installation or updated functionality prior to release.
Modified
p. 32
c) Documented to include the identity of the authorized person(s) who approved the installation.
Removed
p. 33
• Is cryptographically authenticated by the POI device’s firmware.
• Requires an SCD with dual control for the application-signing process.
• Review of the non-payment software vendor’s documentation to determine all logical interfaces used by the non-payment software do not allow for the storing, processing, or transmitting of clear-text account data
• Documenting how the solution provider confirmed that the non-payment software has no logical interfaces that allow for storing, processing, or transmitting clear-text account data
• Authentication of the non-payment software by the POI device’s firmware
• Requiring an SCD with dual control to sign the non-payment software
• Following this process both for new installations and for updates 1C-2.1.1 The non-payment software does not have any logical interfaces
•e.g., application programming interfaces (APIs)
•that allow for storing, processing, or transmitting clear-text account data.
1C-2.1.1 For each POI device type and each non-payment software intended for that POI device type that does not have a business need to …
• Requires an SCD with dual control for the application-signing process.
• Review of the non-payment software vendor’s documentation to determine all logical interfaces used by the non-payment software do not allow for the storing, processing, or transmitting of clear-text account data
• Documenting how the solution provider confirmed that the non-payment software has no logical interfaces that allow for storing, processing, or transmitting clear-text account data
• Authentication of the non-payment software by the POI device’s firmware
• Requiring an SCD with dual control to sign the non-payment software
• Following this process both for new installations and for updates 1C-2.1.1 The non-payment software does not have any logical interfaces
•e.g., application programming interfaces (APIs)
•that allow for storing, processing, or transmitting clear-text account data.
1C-2.1.1 For each POI device type and each non-payment software intended for that POI device type that does not have a business need to …
Modified
p. 33 → 31
Requirement 1C: Use applications that protect PAN and SAD Domain 1 Requirements Testing Procedures 1C-2 All applications/software without a business need do not have access to clear-text account data.
Requirement 1C: Managing whitelists and Non-payment software Domain 1 Requirements Testing Procedures 1C-2 All software without a business need does not have access to cleartext account data.
Modified
p. 33 → 31
Note: Requirements at 1C-2 are the only requirements applicable to applications/software (non-payment software) on PCI-approved POI devices with no access to clear-text account data (e.g., a loyalty or advertising application). However, requirements in Domain 5 apply to the SCD used for signing non-payment software as well as the associated cryptographic keys and key management.
Note: Requirements at 1C-2 are the only requirements applicable to software (Non-payment software) on PCI-approved POI devices with no access to clear-text account data (e.g., a loyalty or advertising application).
Modified
p. 33 → 31
1C-2.1 Processes must be documented and implemented to ensure that, prior to new installations or updates, any non-payment software:
1C-2.1 Processes must be documented and implemented to ensure that, prior to new installations and updates, all Non-payment software:
Modified
p. 33 → 31
a) Is confirmed to not have any logical interfaces (e.g., application programming interfaces [APIs]) that allow for receiving, storing, processing, or transmitting of cleartext account data.
Modified
p. 33 → 31
1C-2.1 Review the solution provider’s documented processes and interview responsible personnel to confirm the processes include:
1C-2.1 Examine documented processes and interview responsible personnel (as needed) to confirm the stated processes are documented and established.
Removed
p. 34
• Following vendor guidance in the application’s Implementation Guide
• Functionality testing of all changes on the intended device(s)
Note: Modifications (e.g., adding an application or a POI device) to a PCI-listed P2PE Solution (or Component) requires an assessment per PCI’s “Delta Change” process. See the P2PE Program Guide for more information.
• Guidance in the Implementation Guide is followed.
• Functionality testing of all changes on the intended devices is performed.
1D-1.1.b Review records of changes to applications and, and confirm the following:
• All Implementation Guide requirements were followed.
• Approval of the change by appropriate parties is documented.
• The documentation includes reason and impact of the change.
• The documentation describes functionality testing that was performed.
• Documentation includes back-out procedures for application installations/updates.
• Functionality testing of all changes on the intended device(s)
Note: Modifications (e.g., adding an application or a POI device) to a PCI-listed P2PE Solution (or Component) requires an assessment per PCI’s “Delta Change” process. See the P2PE Program Guide for more information.
• Guidance in the Implementation Guide is followed.
• Functionality testing of all changes on the intended devices is performed.
1D-1.1.b Review records of changes to applications and, and confirm the following:
• All Implementation Guide requirements were followed.
• Approval of the change by appropriate parties is documented.
• The documentation includes reason and impact of the change.
• The documentation describes functionality testing that was performed.
• Documentation includes back-out procedures for application installations/updates.
Modified
p. 34 → 32
Requirement 1D: Implement secure application-management processes Domain 1 Requirements Testing Procedures 1D-1 Integrity of applications is maintained during installation and updates.
Requirement 1D: Implement secure application-management processes Domain 1 Requirements Testing Procedures 1D-1 Installation, updates, and changes to P2PE Applications is managed securely.
Modified
p. 34 → 32
1D-1.2 Processes must be documented and implemented to manage all changes to applications, including:
Modified
p. 34 → 32
1D-1.2.a Examine documented processes for implementing changes to applications, and interview solution-provider personnel, and confirm the following processes are in place:
Removed
p. 35
Aligns with 2C-2.1 1D-1.2 Review the solution provider’s documentation and confirm their documented processes include using the guidance in the application’s Implementation Guide for any application installations and updates.
1D-1.2.1 All applications must be cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
1D-1.2.1 Confirm the following through interviews with responsible solution provider personnel and by observing an installation/update:
• Cryptographic signing processes for applications are followed as specified in the Implementation Guide.
• Cryptographic signing (or similar) is performed prior to installation only by authorized personnel using dual control.
• All new installations and updates to applications are signed prior to installation on the device.
• Cryptographic signing for new installations and updates to applications is done under dual control.
1D-1.3 Processes must be in place to implement application developer guidance on key and certificate usage from the application’s Implementation Guide.
Aligns with 2B-3.1.1 1D-1.3.a Review the solution …
1D-1.2.1 All applications must be cryptographically signed (or similar) prior to installation on the POI device only by authorized personnel using dual control.
1D-1.2.1 Confirm the following through interviews with responsible solution provider personnel and by observing an installation/update:
• Cryptographic signing processes for applications are followed as specified in the Implementation Guide.
• Cryptographic signing (or similar) is performed prior to installation only by authorized personnel using dual control.
• All new installations and updates to applications are signed prior to installation on the device.
• Cryptographic signing for new installations and updates to applications is done under dual control.
1D-1.3 Processes must be in place to implement application developer guidance on key and certificate usage from the application’s Implementation Guide.
Aligns with 2B-3.1.1 1D-1.3.a Review the solution …
Modified
p. 35 → 33
Requirement 1D: Implement secure application-management processes Domain 1 Requirements Testing Procedures 1D-1.2 All new installations and updates to applications must be authenticated as follows:
Requirement 1D: Implement secure application-management processes Domain 1 Requirements Testing Procedures 1D-1.3 [Requirement removed] 1D-2 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.
Modified
p. 35 → 33
• The solution provider retains a current copy of the Implementation Guide.
• The solution provider retains a current copy of the Implementation Guide. The solution provider distributes the Implementation Guide to any outsourced integrators/resellers the solution provider uses for the P2PE solution upon obtaining updates from the application vendor.
Modified
p. 36 → 34
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the component provider’s encryption management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include encryption management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
Note: This section is ONLY applicable for P2PE component providers undergoing an assessment of this domain for subsequent PCI listing of the validated component provider’s encryption management services. This section is not applicable to, and does not need to be completed by, P2PE solution providers (or merchants as solution providers) that include encryption management functions in their P2PE solution assessment (whether those functions are performed by the solution provider or are outsourced to non-PCI listed third parties).
Modified
p. 36 → 34
• Number of POI devices deployed and any change in numbers since last report
• Number of PTS POI devices deployed and any change in numbers since last report
Modified
p. 36 → 34
• Number of POI devices deployed and any change in numbers since last report
• Number of PTS POI devices deployed and any change in numbers since last report
Modified
p. 36 → 34
• Date when list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated 1E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component- provider personnel, and to confirm that the following processes are documented and implemented (per merchant location):
• Date when list of personnel with logical remote access to deployed merchant PTS POI devices was last reviewed/updated 1E-1.1.a Examine component provider’s documented procedures for providing required reporting to applicable solution providers and interview responsible component-provider personnel to confirm that the following processes are documented and implemented (per merchant location):
Modified
p. 36 → 34
• Date list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated 1E-1.1.b Observe reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
• Date list of personnel with logical remote access to deployed merchant PTS POI devices was last reviewed/updated 1E-1.1.b Examine reports provided to applicable solution providers annually and upon significant changes to the solution, and confirm they include at least the following:
Modified
p. 36 → 34
• Date when list of personnel with logical remote access to deployed merchant POI devices was last reviewed/updated
• Date when list of personnel with logical remote access to deployed merchant PTS POI devices was last reviewed/updated
Removed
p. 37
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software 1E-1.2.b Observe reports provided to applicable solution providers, and confirm at least the following are reported upon occurrence:
Modified
p. 37 → 35
• Adding, changing, and/or removing P2PE applications on POI devices (i.e., software with access to clear-text account data), including description of change
• Adding, changing, and/or removing P2PE Applications on PTS POI devices, including description of change
Modified
p. 37 → 35
• Adding, changing, and/or removing P2PE non- payment software on POI devices (i.e., software without access to clear-text account data), including description of change
• Adding, changing, and/or removing P2PE Non- payment Software on PTS POI devices, including description of change
Modified
p. 37 → 35
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software
• Updated list of PTS POI devices, P2PE Applications, and/or P2PE Non-payment Software
Modified
p. 37 → 35
Note: Adding, changing, or removing POI device types, P2PE applications, and/or P2PE non-payment software may require adherence to PCI SSC’s process for making changes. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
Note: Adding, changing, or removing PTS POI device types, P2PE Applications, and/or P2PE Non-payment Software may require adherence to PCI SSC’s process for making changes. Please refer to the PCI P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE Solution.
Modified
p. 37 → 35
1E-1.2.a Review component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include notifying the solution provider upon occurrence of the following:
1E-1.2.a Examine component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include notifying the solution provider upon occurrence of the following:
Modified
p. 37 → 35
• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change
• Adding, changing, and/or removing P2PE Applications on PTS POI devices, (including description of change
Modified
p. 37 → 35
• Adding, changing, and/or removing P2PE non-payment software on POI devices (without access to clear-text account data), including description of change
• Adding, changing, and/or removing P2PE Non-payment Software on PTS POI devices, including description of change
Modified
p. 37 → 35
• Adding, changing, and/or removing P2PE applications on POI devices (with access to clear-text account data), including description of change
• Adding, changing, and/or removing P2PE Applications on PTS POI devices including description of change
Modified
p. 37 → 35
• Adding, changing, and/or removing P2PE non-payment software (without access to clear-text account data), including description of change
• Adding, changing, and/or removing P2PE Non-payment Software, including description of change
Modified
p. 37 → 35
• Updated list of POI devices, P2PE applications, and/or P2PE non-payment software
• Updated list of PTS POI devices, P2PE Applications, and/or P2PE Non- payment Software
Removed
p. 38
2A Protect PAN and SAD.
2B Develop and maintain secure applications.
2C Implement secure application-management processes.
Although point-of-interaction (POI) devices are often considered as “hardware” devices, software is often added to POI devices after the PIN Transaction Security (PTS) evaluation and approval. (Such a device is referred to as a “PCI-approved POI device” after the PTS evaluation and approval is complete.) It is vital to the security of these devices
•and the systems that rely on the operation of these devices
•that any such software is assessed to confirm its secure operation. To this end, P2PE requirements specify both the confirmation that a PCI-approved POI device is in use and that P2PE applications and P2PE non-payment software are installed and configured on the device properly (Domain 1), as well as the independent assessment of all P2PE applications (with access to clear-text account data) that are resident within the POI device (Domain 2).
2B Develop and maintain secure applications.
2C Implement secure application-management processes.
Although point-of-interaction (POI) devices are often considered as “hardware” devices, software is often added to POI devices after the PIN Transaction Security (PTS) evaluation and approval. (Such a device is referred to as a “PCI-approved POI device” after the PTS evaluation and approval is complete.) It is vital to the security of these devices
•and the systems that rely on the operation of these devices
•that any such software is assessed to confirm its secure operation. To this end, P2PE requirements specify both the confirmation that a PCI-approved POI device is in use and that P2PE applications and P2PE non-payment software are installed and configured on the device properly (Domain 1), as well as the independent assessment of all P2PE applications (with access to clear-text account data) that are resident within the POI device (Domain 2).
Modified
p. 38 → 36
Target audience: Application vendors designing applications (that have access to clear-text account data) for use within PCI-approved POI devices as part of a P2PE solution.
2A Protect account data 2B Develop and maintain secure applications 2C Implement secure application-management processes Target audience: Application vendors designing applications (that have access to cleartext account data) for use within PCI-approved PTS POI devices (with SRED) as part of a P2PE Solution.
Modified
p. 38 → 36
The PTS evaluation of a PCI-approved POI device includes all firmware in the device. While it may be possible for a POI device to implement all the necessary functionality for use in a P2PE solution solely within its existing PTS- approved firmware, generally the POI device will contain additional software. When used in a P2PE solution, all software (excluding the PCI-approved POI firmware) implemented on the POI device that has the potential to access clear-text account data (P2PE applications) must …
The PTS evaluation of a PCI-approved PTS POI device includes all firmware in the device. While it may be possible for a PTS POI device to implement all the necessary functionality for use in a P2PE solution solely within its existing PTS-approved firmware, generally the PTS POI device will contain additional software. When used in a P2PE solution, all software (excluding the PCI-approved PTS POI firmware) implemented on the PTS POI device that has the potential to access cleartext account …
Modified
p. 38 → 36
The P2PE Standard does not require P2PE Applications used in a P2PE solution to be validated to any other PCI Standard.
Note: The P2PE Standard does not require P2PE Applications used in a P2PE Solution to be validated to any other PCI Standard.
Modified
p. 38 → 36
See “P2PE Solutions and use of Third Parties and/or P2PE Component Providers” for more information about P2PE applications and software, and about validating P2PE applications per this domain.
See “P2PE Solutions and use of Third Parties and/or P2PE Component Providers” for more information about P2PE Applications and software, and about validating P2PE Applications per this domain.
Removed
p. 40
• SRED listed as a function provided 2A-1.1 For each POI device type used by the application, examine the POI device configurations and review the PCI SSC list of Approved PTS Devices to verify that all of the following POI device characteristics match the PTS listing:
2A-1.2 For each type of POI device being assessed as part of the application assessment, verify that the application only uses SRED-validated account data capture mechanisms.
2A-2.1.a Interview software personnel and examine the application’s design documentation to verify it documents all flows and justifies all uses of PAN and/or SAD input into, processed by, and output from the application.
2A-1.2 For each type of POI device being assessed as part of the application assessment, verify that the application only uses SRED-validated account data capture mechanisms.
2A-2.1.a Interview software personnel and examine the application’s design documentation to verify it documents all flows and justifies all uses of PAN and/or SAD input into, processed by, and output from the application.
Modified
p. 40 → 38
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-1 The application executes on a PCI-approved POI device with SRED enabled and active.
Requirement 2A: Protect Account Data Domain 2 Requirements Testing Procedures 2A-1 The application executes on a PCI-approved PTS POI device with SRED enabled and active.
Modified
p. 40 → 38
2A-1.1 The application must be intended for use on a POI device approved per the PCI PTS program, with SRED (secure reading and exchange of data). The PTS approval listing must match the following characteristics:
2A-1.1 The application must be intended for use on a PTS POI device approved per the PCI PTS program, with SRED (secure reading and exchange of data). The PTS approval listing must match the following characteristics:
Modified
p. 40 → 38
• Firmware version number
• Firmware (FW) version number(s)
Modified
p. 40 → 38
• Firmware version number
• Firmware (FW) version number(s)
Modified
p. 40 → 38
2A-1.2 The application must only use the SRED-validated account-data capture mechanisms of the underlying PTS POI device for accepting and processing P2PE-related transactions.
Modified
p. 40 → 39
2A-2 The application does not store PAN and/or SAD for any longer than business processes require.
Requirement 2A: Protect Account Data Domain 2 Requirements Testing Procedures 2A-2 The application does not store account data for any longer than business processes require.
Modified
p. 40 → 39
2A-2.1 The application vendor must maintain current documentation for all flows and provide a business justification for all uses of PAN and/or SAD input into, processed by, and output from the application.
2A-2.1 The application vendor must maintain current documentation for all data flows of account data (encrypted and cleartext) and provide a business justification for all uses of account data input into, processed by, and output from the application.
Modified
p. 40 → 39
2A-2.1.b Perform a source-code review and verify that PAN and/or SAD are only utilized according to the documentation.
2A-2.1.b Examine the application source code and verify that account data is only utilized by the application according to the documentation.
Removed
p. 41
• How it uses PAN and/or SAD for its application processing
Modified
p. 41 → 39
2A-2.2 The application must not store account data (even if encrypted) as follows:
Modified
p. 41 → 39
• How it ensures the application does not store SAD after authorization is complete 2A-2.2.b Perform a source-code review to verify that the application is designed such that:
• How it ensures the application does not store SAD after authorization is complete 2A-2.2.b Examine source code to verify that the application is designed such that:
Modified
p. 42 → 40
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-2.3 The application must not retain PAN and/or SAD in working memory any longer than strictly necessary.
Requirement 2A: Protect Account Data Domain 2 Requirements Testing Procedures 2A-2.3 The application must not retain account data in working memory any longer than strictly necessary.
Modified
p. 42 → 40
2A-2.3.a Examine the application’s design documentation and verify it contains a detailed description of the function of the application, including how it ensures the application does not retain PAN and/or SAD in working memory any longer than strictly necessary.
2A-2.3.a Examine the application’s design documentation and verify it contains a detailed description of how the application is designed to not retain account data in working memory any longer than strictly necessary.
Modified
p. 42 → 40
2A-2.3.b Perform a source-code review and verify that PAN and/or SAD is cleared from all working memory locations after use, including local variables (before exiting the function).
2A-2.3.b Examine the application source code and verify that account data is cleared from all working memory locations after use.
Modified
p. 42 → 40
2A-2.3.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application clears all working memory locations utilized for the temporal retention of PAN and/or SAD during processing.
2A-2.3.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application clears all working memory locations utilized for the temporal retention of account data during processing.
Modified
p. 42 → 40
2A-2.4 The application must securely delete any PAN and/or SAD that was stored during application processing.
2A-2.4 The application must securely delete account data that was stored during application processing using industry-accepted methods for secure deletion of data.
Modified
p. 42 → 40
2A-2.4.a Examine the application’s design documentation and verify it describes the process used by the application to securely delete any PAN and/or SAD that was stored during application processing.
2A-2.4.a Examine the application’s design documentation and verify it describes the process used by the application to securely delete account data that was stored during application processing industry-accepted methods for secure deletion of data.
Modified
p. 42 → 40
2A-2.4.b Perform a source-code review and verify that the process provided by the application vendor renders all stored PAN and/or SAD irrecoverable once application processing is completed, in accordance with industry-accepted standards for secure deletion of data.
2A-2.4.b Examine the application source code and verify that all stored account data is irrecoverable once application processing is completed, in accordance with industry-accepted methods for secure deletion of data.
Modified
p. 42 → 40
2A-2.4.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the process provided by the application renders all PAN and/or SAD data irrecoverable, in accordance with industry-accepted standards for secure deletion of data, once the business process of the application …
2A-2.4.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the application renders all account data irrecoverable, in accordance with industry-accepted standards for secure deletion of data, once the business process of the application is completed.
Removed
p. 43
2A-3.1.1.a If the application outputs any truncated PANs, examine the application’s design documentation and verify it contains a description of the application’s function, including that any truncation of PANs adheres to the allowable number of digits as specified in PCI DSS and/or related FAQs.
Modified
p. 43 → 41
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3 The application does not transmit clear-text PAN and/or SAD outside of the POI device, and only uses communication methods included in the scope of the PCI-approved POI device evaluation.
Requirement 2A: Protect Account Data Domain 2 Requirements Testing Procedures 2A-3 The application does not transmit cleartext account data outside of the PTS POI device or to any other co-resident software other than to the PTS POI device firmware and only uses communication methods included in the scope of the PCI-approved PTS POI device evaluation.
Modified
p. 43 → 41
• Output cleartext account data outside of the PTS POI device
Modified
p. 43 → 41
Note: Output of clear-text data that is verified as being unrelated to any of the PCI payment brands is acceptable. The security of this process is assessed at Requirement 2A-3.4.
Note: Output or sharing of cleartext data that is verified as being unrelated to any of the PCI payment brands is acceptable. The security of this process is assessed at Requirement 2A-3.4.
Modified
p. 43 → 41
2A-3.1.a Examine the application’s design documentation and verify it contains a description of the application’s function, including that the application does not output clear-text account data outside of the POI device.
2A-3.1.a Examine the application’s design documentation and verify the application is designed such that it does not:
Modified
p. 43 → 41
2A-3.1.b Perform a source-code review and verify the application never outputs clear-text account data outside of the POI device.
2A-3.1.b Examine the application source code and verify the application satisfies this requirement.
Modified
p. 43 → 41
2A-3.1.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application does not output clear-text account data outside of the POI device.
2A-3.1.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), test all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application satisfies this requirement.
Modified
p. 43 → 41
2A-3.1.1 The output of any truncated PANs must adhere to the allowable number of digits as specified in PCI DSS and/or related FAQs.
2A-3.1.1 If the application outputs truncated PANs, the truncation must adhere to the allowable number of digits.
Modified
p. 43 → 41
Note: This requirement does not supersede stricter requirements in place for displays of PAN•e.g., legal or payment card brand requirements for point-of-sale (POS) receipts.
Note: This requirement does not supersede stricter requirements in place for displays of PAN•e.g., legal or payment card brand requirements for point-of-sale (POS) receipts 2A-3.1.1.a Examine the application’s design documentation and verify that any truncation of PANs adheres to the allowable number of digits.
Modified
p. 43 → 41
2A-3.1.1.b If the application outputs any truncated PANs, perform a source-code review and verify that any truncation of PANs adheres to the allowable number of digits as specified in PCI DSS and/or related FAQs that specify allowable digits.
2A-3.1.1.b Examine the application source code and verify that truncation of PANs adheres to the allowable number of digits.
Modified
p. 43 → 42
2A-3.1.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the application design/functionality satisfies the requirement.
Removed
p. 44
Note: Domain 1 (at 1B.1.1.1) and Domain 3 (at 3A-1.3) also include requirements that must be met for any POI device and for a P2PE solution provider, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
2A-3.1.2.a If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, examine the application’s design documentation and verify it contains a description of the application’s function, including that the printing of full PANs on merchant receipts is a legal/regulatory obligation.
2A-3.1.2.b If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, perform a source-code review and verify the following:
2A-3.1.2.c If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, install and configure the application according to the application vendor’s documentation, including the …
2A-3.1.2.a If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, examine the application’s design documentation and verify it contains a description of the application’s function, including that the printing of full PANs on merchant receipts is a legal/regulatory obligation.
2A-3.1.2.b If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, perform a source-code review and verify the following:
2A-3.1.2.c If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, install and configure the application according to the application vendor’s documentation, including the …
Modified
p. 44 → 42
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3.1.2 If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, this is ONLY allowable if the application includes the following:
Requirement 2A: Protect Account Data Domain 2 Requirements Testing Procedures 2A-3.1.2 If the application facilitates merchant printing of full PANs on receipts due to a legal or regulatory obligation, this is ONLY allowable if the application includes the following:
Modified
p. 44 → 42
• The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and is not attached via cabling or other networking mechanisms.
• The application only transmits cleartext PAN internally within the PTS POI device to an integrated printer that is part of the PTS POI device that is not attached via cabling or other networking mechanisms.
Modified
p. 44 → 42
• The P2PE application securely deletes the clear-text PAN after completion of printing.
• The P2PE Application securely deletes the cleartext PAN after completion of printing using industry-accepted methods for secure deletion of data.
Modified
p. 44 → 42
• The P2PE application securely deletes the clear-text PAN after completion of printing.
• The P2PE Application securely deletes the cleartext PAN after completion of printing using industry-accepted methods for secure deletion of data.
Modified
p. 44 → 42
• The application only transmits clear-text PAN internally within the POI device to an integrated printer that is part of the PCI-approved POI device and does not include any functionality that sends clear-text PANs to any devices attached via cabling or other networking mechanisms.
• The application only transmits cleartext PAN internally within the PTS POI device to an integrated printer that is part of the PTS POI device that is not attached via cabling or other networking mechanisms.
Removed
p. 45
Note: The application may be the only POI-resident application at the time of assessment, but other assessed applications may be added to a P2PE solution at a later date; or the application may be added to a solution that includes pre-approved applications. The assessor must test this requirement with this point in mind.
2A-3.2.b Perform a source-code review and verify that the application cannot directly facilitate sharing of clear-text account data with other applications via its logical interfaces.
2A-3.2.b Perform a source-code review and verify that the application cannot directly facilitate sharing of clear-text account data with other applications via its logical interfaces.
Modified
p. 45 → 43
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other applications (including non-payment software).
Requirement 2A: Protect Account Data Domain 2 Requirements Testing Procedures 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of (or allowing access to) cleartext account data directly with other applications/software (including other P2PE Applications and Non-payment Software).
Modified
p. 45 → 43
Note: The application is allowed to share clear-text account data directly with the POI device’s SRED-approved firmware.
Note: The application is allowed to share cleartext account data directly with the PTS POI device’s SRED-approved firmware.
Modified
p. 45 → 43
• The logical interfaces intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device).
• The logical interfaces intended for sharing of cleartext account data (e.g., those used to pass cleartext data back to the approved firmware of the PTS POI device).
Modified
p. 45 → 43
• The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications).
• The logical interfaces not intended for sharing of cleartext account data (e.g., those for communication with other applications/software).
Modified
p. 45 → 43
Examine the logical interfaces used to communicate with other applications and confirm that the application cannot share clear-text account data with other applications via these logical interfaces.
Examine the logical interfaces used to communicate with other applications and confirm that the application cannot share cleartext account data with other applications/software via these logical interfaces.
Modified
p. 45 → 43
2A-3.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the application cannot directly facilitate sharing of clear-text account data with other applications via its logical interfaces.
2A-3.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that the application satisfies this requirement.
Removed
p. 46
2A-3.3.c Perform a source-code review and verify that, when configured appropriately, the application only utilizes the external communication methods included in the POI device vendor’s security guidance and does not implement its own external communication methods (e.g., does not implement its own IP stack).
Modified
p. 46 → 44
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3.3 The application must only use external communication methods included in the PCI-approved POI device evaluation.
Requirement 2A: Protect Account Data Domain 2 Requirements Testing Procedures 2A-3.3 The application must only use external communication interfaces included in the PTS POI device evaluation.
Modified
p. 46 → 44
For example, the POI device may provide an IP stack approved per the PTS Open Protocols module, or the device may provide serial ports or modems approved by the PTS evaluation to communicate transaction data encrypted by its PCI PTS SRED functions.
Note: For example, the PTS POI device may provide an IP stack approved per the PTS Open Protocols module, or the device may provide serial ports or modems approved by the PTS evaluation to communicate transaction data encrypted by its PCI PTS SRED functions.
Modified
p. 46 → 44
Note: Using any external communication methods not included in the PCI-approved POI device evaluation will invalidate the PTS approval and such use is prohibited in P2PE solutions.
Note: Using any external communication methods not included in the PCI-approved PTS POI device evaluation will invalidate the PTS approval and such use is prohibited in P2PE Solutions. Individual PTS POI device HW/FW may denote a certain interface is excluded for use. This exclusion must be adhered to.
Modified
p. 46 → 44
Security of applications where the POI device implements Open Protocols is covered at Requirement 2B-2.1.
Security of applications where the PTS POI device implements Open Protocols is covered at Requirement 2B- 2.1.
Modified
p. 46 → 44
2A-3.3.a Examine the POI device vendor’s security guidance to determine which external communication methods are approved via the PCI-approved POI device evaluation.
2A-3.3.a Examine the PTS POI device vendor’s security guidance to determine which external communication methods are approved via the PTS POI device evaluation.
Modified
p. 46 → 44
2A-3.3.d Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that:
2A-3.3.d Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), test the PTS POI device interface. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify that:
Removed
p. 47
Requirement 2A: Protect PAN and SAD Domain 2 Requirements Testing Procedures 2A-3.4 Any whitelisting functionality implemented by the application must include guidance in the application’s Implementation Guide that includes the following:
• How to perform cryptographic authentication by the POI device’s firmware
• How to configure the application functionality to ensure the output of clear- text account data is prohibited, except for non-PCI payment brand account/card data
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
• How to establish cryptographically authentication by the POI device’s firmware
• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data
• That such functionality must be approved by authorized personnel prior to implementation
− Description and justification for the functionality − Who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior …
• How to perform cryptographic authentication by the POI device’s firmware
• How to configure the application functionality to ensure the output of clear- text account data is prohibited, except for non-PCI payment brand account/card data
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
• How to establish cryptographically authentication by the POI device’s firmware
• That review of whitelist functionality must be performed to confirm it only outputs non-PCI payment brand account/card data
• That such functionality must be approved by authorized personnel prior to implementation
− Description and justification for the functionality − Who approved the new installation or updated functionality prior to release − Confirmation that it was reviewed prior …
Modified
p. 47 → 45
• How to configure the whitelisting functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data
• How to configure the whitelisting functionality to ensure the output of cleartext account data is prohibited, except for non-PCI payment brand account/card data
Modified
p. 47 → 45
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control
• How to perform cryptographic signing (or similar) prior to installation on the PTS POI device by authorized personnel using dual control
Modified
p. 47 → 45
- Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 2A-3.4 Examine the application’s Implementation Guide required at 2C-3 of this document and verify it contains details to describe whitelisting functionality and that it provides instructions as denoted in the requirement.
Modified
p. 47 → 45
- Who approved the new installation or updated functionality prior to release
Removed
p. 48
2B-1.1.d Verify each of the items at 2B-1.1.1 through 2B-1.1.3 by performing the following:
• Examine software development processes and interview software developers.
• Examine testing documentation and samples of test data, observe testing processes, and interview software-testing personnel.
• Examine the final application product.
• Examine software development processes and interview software developers.
• Examine testing documentation and samples of test data, observe testing processes, and interview software-testing personnel.
• Examine the final application product.
Modified
p. 48 → 46
2B-1.1 Applications must be developed based on industry best practices and in accordance with the POI device vendor's security guidance, and information security is incorporated throughout the software development life cycle. These processes must include the following:
2B-1.1 Applications must be developed based on industry best practices and in accordance with the PTS POI device vendor's security guidance, and information security is incorporated throughout the software development life cycle. These processes must include the following:
Modified
p. 48 → 46
2B-1.1.b Examine the POI device vendor’s security guidance, and verify that any specified software development processes are:
2B-1.1.b Examine the PTS POI device vendor’s security guidance, and verify that any specified software development processes are:
Modified
p. 48 → 46
• Implemented per the POI device vendor's security guidance 2B-1.1.c Examine the application’s Implementation Guide required at 2C-3 of this document and verify it provides information from the POI device vendor’s security guidance applicable to the solution provider (e.g., application configuration settings which are necessary for the application to function with the device).
• Implemented per the PTS POI device vendor's security guidance 2B-1.1.c Examine the application’s Implementation Guide required at 2C-3 of this document and verify it provides information from the PTS POI device vendor’s security guidance applicable to the solution provider (e.g., application configuration settings which are necessary for the application to function with the device).
Modified
p. 48 → 46
2B-1.1.1 Live PANs must not be used for testing or development.
2B-1.1.d [Removed] 2B-1.1.1 Live PANs must not be used for testing or development.
Modified
p. 49 → 46
2B-1.1.2 Development, test, and/or custom application data/accounts, user IDs, and passwords must be removed before applications are released for production or released to customers.
Modified
p. 49 → 46
2B-1.1.2 Examine the software-development procedures and interview responsible personnel to verify that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers.
2B-1.1.2 Examine the software-development procedures to verify that development, test, and/or custom application data/accounts, user IDs, and passwords are removed before an application is released for production or released to customers.
Modified
p. 49 → 47
2B-1.2 Application code and any non-code configuration mechanisms must be reviewed prior to every release or update.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.2 Application code and any non-code configuration mechanisms must be reviewed prior to every release or update.
Removed
p. 50
2B-1.3.2 Verify that documented approval by appropriate authorized parties is present for each change.
2B-1.3.3.a For each sampled change, verify that functionality testing was performed to verify that the change does not adversely impact the security of the device.
2B-1.3.3.a For each sampled change, verify that functionality testing was performed to verify that the change does not adversely impact the security of the device.
Modified
p. 50 → 48
2B-1.3.1 Documentation of impact. 2B-1.3.1 Verify that documentation of customer impact is included in the change- control documentation for each change.
2B-1.3.1 Documentation of impact. 2B-1.3.1 Examine documentation to verify that the customer impact is included in the change-control documentation for each change.
Modified
p. 50 → 48
2B-1.3.3.a For each sampled change, examine evidence to verify that functionality testing was performed to verify that the change does not adversely impact the security of the device.
Modified
p. 50 → 48
2B-1.3.3.b Verify that all changes (including patches) are tested per secure coding guidance before being released.
2B-1.3.3.b Examine evidence to verify that all changes (including patches) are tested per secure coding guidance before being released.
Modified
p. 50 → 48
2B-1.3.4 Verify that back-out, rollback, or application de-installation procedures are prepared for each change.
2B-1.3.4 Examine evidence to verify that back-out, rollback, or application de- installation procedures are prepared for each change.
Modified
p. 51 → 49
2B-1.4.1.a Obtain and review software development processes for applications. Verify the process includes prevention of common coding vulnerabilities relevant to the programming languages and platforms in use.
2B-1.4.1.a Examine software development processes for applications. Verify the process includes prevention of common coding vulnerabilities relevant to the programming languages and platforms in use.
Modified
p. 51 → 49
2B-1.4.1.b Verify that applications are not vulnerable to common coding vulnerabilities by performing manual or automated penetration testing that specifically attempts to exploit vulnerabilities relevant to the application (an example of such a vulnerability would include buffer overflows).
2B-1.4.1.b Test to verify that application is not vulnerable to common coding vulnerabilities by performing manual or automated penetration testing that specifically attempts to exploit vulnerabilities relevant to the application (an example of such a vulnerability would include buffer overflows).
Modified
p. 53 → 51
2B-1.5.a Verify documented software development processes require training in secure development practices for application developers, as applicable for the developer’s job function and technology used.
2B-1.5.a Examine documented software development processes to verify they require training in secure development practices for application developers, as applicable for the developer’s job function and technology used.
Modified
p. 54 → 52
Note: Wildcards may only be substituted for elements of the version number that represent non-security impacting changes. Refer to 2B-6.3 for additional requirements on the use of wildcards.
• Definition of elements that indicate use of wildcards Note: Wildcards may only be substituted for elements of the version number that represent non-security impacting changes. Refer to 2B-6.3 for additional requirements on the use of wildcards.
Modified
p. 54 → 53
2B-1.8 The versioning methodology must indicate the type and impact of all application changes in accordance with the P2PE Program Guide, including:
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.8 The versioning methodology must indicate the type and impact of all application changes in accordance with the P2PE Program Guide, including:
Modified
p. 54 → 53
- Have impact on application functionality but no impact on security or P2PE requirements
Modified
p. 54 → 53
- Have impact on application functionality but no impact on security or P2PE requirements
Modified
p. 54 → 53
• How each type of change ties to a specific version number (continued on next page) 2B-1.8.a Examine the software vendor’s documented versioning methodology to verify the version methodology includes:
• How each type of change ties to a specific version number 2B-1.8.a Examine the software vendor’s documented versioning methodology to verify the version methodology includes:
Modified
p. 54 → 53
2B-1.8.b Verify that the versioning methodology is in accordance with the P2PE Program Guide requirements.
2B-1.8.b Examine documentation to verify that the versioning methodology is in accordance with the P2PE Program Guide requirements.
Removed
p. 55
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.8 (continued) 2B-1.8.d Select a sample of recent payment application changes and review the change-control documentation that specifies the type of application change to verify that the version assigned to the change matches the type of change according to the documented methodology.
Modified
p. 55 → 54
2B-1.9 The versioning methodology must specifically identify whether wildcards are used and, if so, how they are used. The following must be included:
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-1.9 The versioning methodology must specifically identify whether wildcards are used and, if so, how they are used. The following must be included:
Modified
p. 55 → 54
2B-1.9.a Examine the software vendor’s documented versioning methodology to verify that it includes specific identification of how wildcards are used, including:
Modified
p. 55 → 54
2B-1.9.b Verify that any use of wildcards is in accordance with the P2PE Program Guide requirements•e.g., elements that appear after a wildcard element cannot be used for a security impacting change.
2B-1.9.b Examine documentation to verify that any use of wildcards is in accordance with the P2PE Program Guide requirements•e.g., elements that appear after a wildcard element cannot be used for a security impacting change.
Modified
p. 56 → 54
2B-1.9.d Select a sample of recent payment application changes and examine the change-control documentation that specifies the type of application change. Verify that:
Modified
p. 56 → 54
• Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change 2B-1.10 The vendor’s published versioning methodology must be communicated to customers and integrators/ resellers.
• Elements of the version number used to represent non-security-impacting changes (including a wildcard element) are not used to represent a security impacting change
Modified
p. 56 → 55
2B-1.10Examine the application’s Implementation Guide required at 2C-3 of this document to verify it includes a description of the vendor’s published versioning methodology for customers and integrators/resellers, and includes the following:
Modified
p. 57 → 55
2B-1.13 Software vendor must implement a process to document and authorize the final release of the application and any application updates. Documentation must include:
Modified
p. 57 → 55
2B-1.13.b For a sample of recent releases of application and application updates, review approval documentation to verify it includes:
2B-1.13.b For a sample of recent releases of application and application updates, examine approval documentation to verify it includes:
Modified
p. 57 → 56
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2 The application is implemented securely, including the secure use of any resources shared between different applications.
Modified
p. 57 → 56
2B-2.1 Where the application relies on the Open Protocol functionality of the POI device firmware, the application must be developed in accordance with the POI device vendor's security guidance.
2B-2.1 Where the application relies on the Open Protocol functionality of the PTS POI device firmware, the application must be developed in accordance with the PTS POI device vendor's security guidance.
Modified
p. 57 → 56
Note: POI device vendor security guidance is intended for application developers, system integrators, and end-users of the platform to meet the PCI PTS POI Open Protocol requirements as part of a PCI-approved POI device evaluation.
Note: POI device vendor security guidance is intended for application developers, system integrators, and end-users of the platform to meet the PCI PTS POI Open Protocol requirements as part of a PCI-approved PTS POI device evaluation.
Modified
p. 57 → 56
2B-2.1.b Review the application’s Implementation Guide required at 2C-3 of this document and confirm that it includes the following in accordance with the POI device vendor's security guidance:
2B-2.1.b Examine the application’s Implementation Guide required at 2C-3 to verify that it includes the following in accordance with the PTS POI device vendor's security guidance:
Modified
p. 58 → 57
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2.1.1 The application must not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device vendor’s security guidance. This includes the use of:
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2.1.1 The application must not circumvent, bypass, or add additional services or protocols to the Open Protocols of the PTS POI device firmware as approved and documented in the PTS POI device vendor’s security guidance. This includes the use of:
Modified
p. 58 → 57
Adding or enabling additional services or protocols, or failing to follow the issued POI device vendor’s security guidance, will invalidate the approval status of that device for that implementation.
Adding or enabling additional services or protocols or failing to follow the issued PTS POI device vendor’s security guidance, will invalidate the approval status of that device for that implementation.
Modified
p. 58 → 57
2B-2.1.1 Perform a source-code review and verify that the application:
2B-2.1.1 Examine the application source-code and verify that the application:
Modified
p. 58 → 57
• Was developed according to the POI device vendor’s security guidance with respect to the documented Open Protocols
• Was developed according to the PTS POI device vendor’s security guidance with respect to the documented Open Protocols
Modified
p. 58 → 57
• Does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the POI device firmware as approved and documented in the POI device's vendor security guidance. This includes the use of:
• Does not circumvent, bypass, or add additional services or protocols to the Open Protocols of the PTS POI device firmware as approved and documented in the POI device's vendor security guidance. This includes the use of:
Modified
p. 58 → 57
- IP services 2B-2.2 The application-development process must include secure integration with any resources shared with or between applications.
Modified
p. 58 → 57
(continued on next page) 2B-2.2.a Review the POI device vendor's security guidance and the application’s Implementation Guide.
(continued on next page) 2B-2.2.a Examine the PTS POI device vendor's security guidance and the application’s Implementation Guide.
Modified
p. 58 → 57
Confirm that the application’s Implementation Guide required at 2C-3 of this document is in accordance with any applicable information in the POI device vendor's security guidance, and includes the following:
Confirm that the application’s Implementation Guide required at 2C-3 of this document is in accordance with any applicable information in the PTS POI device vendor's security guidance, and includes the following:
Modified
p. 59 → 58
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2.2 (continued) 2B-2.2.b Perform a source-code review and verify that any connection to, or use of, shared resources is done securely and in accordance with the POI device vendor’s security guidance.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-2.2 (continued) 2B-2.2.b Examine the application source-code and verify that any connection to, or use of, shared resources is done securely and in accordance with the POI device vendor’s security guidance.
Modified
p. 59 → 58
2B-2.3 Perform a source-code review and verify that applications do not bypass or render ineffective any application segregation that is enforced by the POI device, in accordance with the POI device vendor’s security guidance.
2B-2.3 Examine the application source-code and verify that applications do not bypass or render ineffective any application segregation that is enforced by the POI device, in accordance with the POI device vendor’s security guidance.
Modified
p. 59 → 58
2B-2.4 Perform a source-code review and verify that applications do not bypass or render ineffective any OS hardening which is implemented by the POI device, in accordance with the device vendor’s security guidance.
2B-2.4 Examine the application source-code and verify that applications do not bypass or render ineffective any OS hardening which is implemented by the POI device, in accordance with the device vendor’s security guidance.
Modified
p. 59 → 58
2B-2.5 Perform a source-code review and verify that applications do not bypass or render ineffective any encryption or account-data security methods implemented by the POI device, in accordance with the device vendor’s security guidance.
2B-2.5 Examine the application source-code and verify that applications do not bypass or render ineffective any encryption or account-data security methods implemented by the POI device, in accordance with the device vendor’s security guidance.
Modified
p. 59 → 58
2B-2.6 If the application provides configuration/update functionality at the terminal, perform a functional test of the application loaded on each applicable POI device type and verify that the application does not bypass or render ineffective any applicable controls contained within this standard.
2B-2.6 Test the application loaded on each applicable PTS POI device type and verify that the application does not bypass or render ineffective any applicable controls contained within this standard.
Removed
p. 60
2B-3.1 Through observation and review of the application developer’s system development documentation, confirm the application developer’s process includes full documentation and integration testing of the application and intended platforms, including the following:
Modified
p. 60 → 59
Examples of guidance include which cryptographic certificates to load, how to load account-data keys (through the firmware of the device), when to roll keys, etc.
Note: Examples of guidance include which cryptographic certificates to load, how to load account-data keys (through the firmware of the device), when to roll keys, etc.
Modified
p. 60 → 59
2B-3.1.1 Review the application’s Implementation Guide required at 2C-3 of this document, and confirm it includes security guidance for solution providers, describing how cryptographic keys and/or certificates have to be used and managed.
2B-3.1.1 Examine the application’s Implementation Guide required at 2C-3 of this document, and confirm it includes security guidance for solution providers, describing how cryptographic keys and/or certificates have to be used and managed.
Removed
p. 61
2B-4.1 The application must not directly encrypt clear-text account data. The application must not implement any account-data encryption functions that bypass or are intended to be used instead of the approved SRED encryption functions of the POI device’s firmware.
Modified
p. 61 → 60
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-4 Applications do not implement any account-data encryption functions in lieu of SRED encryption. All such functions are performed by the approved SRED firmware of the POI device.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-4 Applications do not implement any account-data encryption functions in lieu of SRED encryption. All such functions are performed by the approved SRED firmware of the PTS POI device.
Modified
p. 61 → 60
Note: The application may provide additional encryption on the SRED-encrypted account data; however it cannot bypass or replace the SRED encryption of the clear-text account data.
• Implement any account-data encryption functions that bypass or are intended to be used instead of the approved SRED encryption functions of the PTS POI device’s SRED firmware and associated cryptographic keys exclusively for account data encryption. Note: The application may provide additional encryption on the SRED-encrypted account data; however, it cannot bypass or replace the SRED encryption of the cleartext account data.
Modified
p. 61 → 60
• Confirmation that the application does not perform encryption of clear-text account-data, nor does it replace the POI device’s SRED encryption
• Confirmation that the application does not perform encryption of cleartext account-data, nor does it replace the POI device’s SRED encryption
Modified
p. 61 → 60
• A description of the purpose and encryption method for any encryption provided by the application in addition to SRED encryption 2B-4.1.b Perform a source-code review to verify that any application functionality facilitating the encryption of account data utilizes the approved cryptographic algorithm(s) and associated key-management functions of the POI device’s SRED firmware and is not implemented within the application itself.
• A description of the purpose and encryption method for any encryption provided by the application in addition to SRED encryption 2B-4.1.b Examine the application source code to verify that the application functionality facilitating the encryption of account data utilizes the approved cryptographic algorithm(s) and associated key-management functions of the PTS POI device’s SRED firmware and is not implemented within the application itself.
Modified
p. 61 → 60
2B-4.1.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application does not perform encryption of account-data nor does it replace the SRED encryption performed by the underlying POI device’s firmware.
2B-4.1.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application satisfies the requirement.
Modified
p. 62 → 61
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-4.2 The application must not be able to decrypt SRED- encrypted account data⎯i.e., the application must not be able to recover the original clear-text account data from the encrypted account data.
Requirement 2B: Develop and maintain secure applications Domain 2 Requirements Testing Procedures 2B-4.2 The application must not be able to decrypt SRED- encrypted account data¾i.e., the application must not be able to recover the original cleartext account data from the encrypted account data.
Modified
p. 62 → 61
• Confirmation that the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
• Confirmation that the application is not capable of decrypting any cleartext account data encrypted by the SRED functions of the underlying POI firmware.
Modified
p. 62 → 61
2B-4.2.b Perform a source-code review to verify that the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
2B-4.2.b Examine the application source code to verify that the application is not capable of decrypting cleartext account data encrypted by the SRED functions of the underlying PTS POI firmware.
Modified
p. 62 → 61
2B-4.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application is not capable of decrypting any clear-text account data encrypted by the SRED functions of the underlying POI firmware.
2B-4.2.c Install and configure the application according to the application vendor’s documentation, including the application’s Implementation Guide. Using an appropriate “test platform” (if necessary), perform test transactions that utilize all functions of the application that handle account data. Use forensic tools and/or methods (commercial tools, scripts, etc.) to verify the application is not capable of decrypting any cleartext account data encrypted by the SRED functions of the underlying POI firmware.
Modified
p. 63 → 62
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-1 New vulnerabilities are discovered and applications are tested for those vulnerabilities on an ongoing basis.
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-1 New vulnerabilities are discovered, and applications are tested for those vulnerabilities on an ongoing basis.
Modified
p. 63 → 62
2C-1.1.a Obtain and examine processes to identify new vulnerabilities and test applications for vulnerabilities that may affect the application. Verify the processes include the following:
2C-1.1.a Examine processes to identify new vulnerabilities and test applications for vulnerabilities that may affect the application. Verify the processes include the following:
Modified
p. 63 → 62
2C-1.2.a Obtain and examine processes to develop and deploy application security upgrades. Verify that processes include the timely development and deployment of critical security updates to customers.
2C-1.2.a Examine processes to develop and deploy application security upgrades. Verify that processes include the timely development and deployment of critical security updates to customers.
Modified
p. 64 → 63
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-2 Applications are installed and updates are implemented on the PCI-approved POI devices only via trusted and cryptographically authenticated processes using an approved security mechanism evaluated for the PCI-approved POI devices.
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-2 Applications are installed, and updates are implemented on the PTS POI devices only via trusted and cryptographically authenticated processes using an approved security mechanism evaluated for the PTS POI devices.
Modified
p. 64 → 63
• A statement that application installations and updates cannot occur except by using the approved security mechanisms of the POI device’s firmware 2C-2.1.1.b Perform a source-code review to verify that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware.
• A statement that application installations and updates cannot occur except by using the approved security mechanisms of the POI device’s firmware 2C-2.1.1.b Examine the application source-code to verify that the application only allows installations and updates using the approved security mechanisms of the POI device’s firmware.
Modified
p. 64 → 63
2C-2.1.1.d After the application is installed and configured in accordance with the Implementation Guide, attempt to perform an installation and an update using non-approved security mechanisms, and verify that the POI device will not allow the installation or update to occur.
2C-2.1.1.d After the application is installed and configured in accordance with the Implementation Guide, test in order to perform an installation and an update using non-approved security mechanisms and verify that the PTS POI device will not allow the installation or update to occur.
Modified
p. 64
2C-2.1.2 The application developer includes guidance for whoever signs the application, including requirements for using an SCD with dual control for the application-signing process.
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-2.1.2 The application developer includes guidance for whoever signs the application, including requirements for using an SCD or an HMD with dual control for the application-signing process.
Modified
p. 64
• Instructions how to use an SCD with dual control for the application-signing process
• Instructions how to use an SCD or HMD with dual control for the application-signing process
Modified
p. 64
• A statement that all applications must be signed via the instructions provided in the Implementation Guide
• A statement that all applications must be signed via the instructions provided in the Implementation Guide 2C-3 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.
Removed
p. 65
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-3 Maintain instructional documentation and training programs for the application’s installation, maintenance/upgrades, and use.
2C-3.1 Examine the Implementation Guide and related processes, and verify the guide is disseminated to all relevant application installers and users (including customers, resellers, and integrators).
• Any changes to the Implementation Guide requirements in this document 2C-3.1.2.a Verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements.
2C-3.1.2.b Verify the Implementation Guide is updated as needed to keep the documentation current with:
• Any changes to the application (e.g., device changes/upgrades and major and minor software changes)
2C-3.1 Examine the Implementation Guide and related processes, and verify the guide is disseminated to all relevant application installers and users (including customers, resellers, and integrators).
• Any changes to the Implementation Guide requirements in this document 2C-3.1.2.a Verify the Implementation Guide is reviewed at least annually and upon changes to the application or the P2PE Domain 2 requirements.
2C-3.1.2.b Verify the Implementation Guide is updated as needed to keep the documentation current with:
• Any changes to the application (e.g., device changes/upgrades and major and minor software changes)
Modified
p. 65 → 64
2C-3.1 The process to develop, maintain, and disseminate an Implementation Guide for the application’s installation, maintenance, upgrades and general use includes the following:
2C-3.1 The process to develop, maintain, and disseminate an Implementation Guide for the application’s installation, maintenance, upgrades, and general use must include the following:
Modified
p. 65 → 64
2C-3.1.1 Addresses all requirements in P2PE Domain 2 wherever the Implementation Guide is referenced.
2C-3.1 [Removed] 2C-3.1.1 Addresses all requirements in P2PE Domain 2 wherever the Implementation Guide is referenced.
Modified
p. 65 → 64
2C-3.1.1 Verify the Implementation Guide covers all related requirements in P2PE Domain 2.
2C-3.1.1 Examine the Implementation Guide to verify it covers all related requirements in P2PE Domain 2.
Modified
p. 65 → 64
• Any changes to the Implementation Guide requirements in this document 2C-3.1.3 Distribution to all new and existing application installers (e.g., solution providers, integrator/resellers, etc.), and re-distribution to all existing application installers every time the guide is updated.
• Any changes to the Implementation Guide requirements in this document 2C-3.1.3 Distribution to all new application installers (e.g., solution providers, integrator/resellers, etc.), and re-distribution to all existing application installers every time the guide is updated.
Modified
p. 65 → 64
2C-3.1.3 Verify the Implementation Guide is distributed to new application installers, and re-distributed to all application installers every time the guide is updated.
2C-3.1.3 Examine documented procedures to verify the Implementation Guide is distributed to new application installers and re-distributed to all application installers every time the guide is updated.
Modified
p. 65
2C-3.2 Develop and implement training and communication programs to ensure application installers (e.g., solution providers or integrators/resellers) know how to implement the application according to the Implementation Guide.
Requirement 2C: Implement secure application-management processes Domain 2 Requirements Testing Procedures 2C-3.2 Develop and implement training and communication programs to ensure application installers (e.g., solution providers or integrators/resellers) know how to implement the application according to the Implementation Guide.
Modified
p. 65
2C-3.2.1 Examine the training materials for resellers and integrators and verify the materials are reviewed on an annual basis and when new application versions are released, and updated as needed.
2C-3.2.1 Examine the training materials for resellers and integrators and verify the materials are reviewed on an annual basis and when new application versions are released and updated as needed.
Removed
p. 66
Domain 2 Requirement Required Content for the Implementation Guide 2A-3.2 The application must not facilitate, via its own logical interface(s), sharing of clear-text account data directly with other applications (including non-payment software).
The logical interfaces intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device) The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications) 2A-3.3 The application only uses external communication methods included in the PCI-approved POI device evaluation and has not implemented its own external communication stack.
The logical interfaces intended for sharing of clear-text account data (e.g., those used to pass clear-text data back to the approved firmware of the POI device) The logical interfaces not intended for sharing of clear-text account data (e.g., those for communication with other applications) 2A-3.3 The application only uses external communication methods included in the PCI-approved POI device evaluation and has not implemented its own external communication stack.
Removed
p. 67
• How to perform cryptographic authentication by the POI device’s firmware
• How to configure the application functionality to ensure the output of clear- text account data is prohibited, except for non-PCI payment brand account/card data
• How to establish cryptographically authentication by the POI device’s firmware
• That such functionality must be approved by authorized personnel prior to implementation
• How to configure the application functionality to ensure the output of clear- text account data is prohibited, except for non-PCI payment brand account/card data
• How to establish cryptographically authentication by the POI device’s firmware
• That such functionality must be approved by authorized personnel prior to implementation
Removed
p. 67
• That review of whitelist functionality to confirm it only outputs non-PCI payment brand account/card data.
• That documentation for all new installations or updates to whitelist functionality that includes the following:
• Description and justification for the functionality
• Who approved the new installation or updated functionality prior to release
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
Information from the POI device vendor’s security guidance applicable to the solution provider (e.g., application configuration settings which are necessary for the application to function with the device).
2B-1.3 All changes to the application must follow change-control procedures.
• That documentation for all new installations or updates to whitelist functionality that includes the following:
• Description and justification for the functionality
• Who approved the new installation or updated functionality prior to release
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
Information from the POI device vendor’s security guidance applicable to the solution provider (e.g., application configuration settings which are necessary for the application to function with the device).
2B-1.3 All changes to the application must follow change-control procedures.
Modified
p. 67 → 66
• How to configure the whitelisting functionality to ensure the output of clear-text account data is prohibited, except for non-PCI payment brand account/card data.
• How to configure the application functionality to ensure the output of cleartext account data is prohibited, except for non-PCI payment brand account/card data
Modified
p. 67 → 66
• How to perform cryptographic signing (or similar) prior to installation on the POI device by authorized personnel using dual control.
• How to perform cryptographic signing (or similar) prior to installation on the PTS POI device by authorized personnel using dual control.
Modified
p. 67 → 66
2A-3.4 If applicable, details to describe the whitelisting functionality implemented by the application as follows:
Modified
p. 67 → 66
• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 2B-1.1 Applications must be developed based on industry best practices and in accordance with the POI device vendor’s security guidance, and information security is incorporated throughout the software development life cycle.
• Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 2B-1.1 Information from the PTS POI device vendor’s security guidance applicable to the application (e.g., application configuration settings which are necessary for the application to function with the device).
Modified
p. 67 → 66
• Documentation detailing the impact of all changes included in the relevant application release
2B-1.3
• Documentation detailing the impact of all changes included in the relevant application release
• Documentation detailing the impact of all changes included in the relevant application release
Removed
p. 68
2B-4.1 The application must not directly encrypt clear-text account data. The application must not implement any account-data encryption functions that bypass or are intended to be used instead of the approved SRED encryption functions of the POI device’s firmware.
2B-2.2 The application development process must include secure integration with any shared resources.
2B-2.2 The application development process must include secure integration with any shared resources.
Modified
p. 68 → 67
• Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change 2B-2.1 Where the application relies on the Open Protocol functionality of the POI device firmware, the application must be developed in accordance with the POI device vendor’s security guidance.
• Details of any wildcard elements that are used, including confirmation that they will never be used to represent a security-impacting change 2B-2.1 • Any instructions on how to securely configure any configurable options, as applicable to the application’s specific business processing.
Modified
p. 68 → 67
• Any guidance that the POI device vendor intended for integrators/ resellers, solution providers, and/or end-users.
• Any guidance that the PTS POI device vendor intended for integrators/ resellers, solution providers, and/or end- users.
Modified
p. 68 → 67
Includes the following, in accordance with the POI device vendor’s security guidance:
2B-2.2 Includes the following, in accordance with the PTS POI device vendor’s security guidance:
Modified
p. 68 → 67
• Instructions for how the application should be configured to ensure secure integration with shared resources 2B-3.1.1 The application developer must provide security guidance describing how cryptographic keys and/or certificates have to be used.
• Instructions for how the application should be configured to ensure secure integration with shared resources 2B-3.1.1 Security guidance for solution providers, describing how cryptographic keys and/or certificates have to be used and managed.
Modified
p. 68 → 67
The description of the application’s function that includes the following:
2B-4.1 The description of the application’s function that includes the following:
Modified
p. 68 → 67
• Confirmation that the application does not perform its own encryption of clear-text account data, nor does it replace the POI device’s SRED encryption.
• Confirmation that the application does not perform its own encryption of cleartext account data, nor does it replace the PTS POI device’s SRED encryption.
Modified
p. 69 → 67
• A description of how the application uses the approved security protocol of the POI device’s firmware for any application installations and updates
2C-2.1.1
• A description of how the application uses the approved security protocol of the PTS POI device’s firmware for any application installations and updates
• A description of how the application uses the approved security protocol of the PTS POI device’s firmware for any application installations and updates
Modified
p. 69 → 67
• A statement that application installations and updates cannot occur except by using the approved security protocol of the POI device’s firmware The application developer includes guidance for whoever signs the application, including requirements for using an SCD with dual control for the application-signing process.
• A statement that application installations and updates cannot occur except by using the approved security protocol of the POI device’s firmware
Modified
p. 69 → 68
• A statement that all applications must be signed via the instructions provided in the Implementation Guide.
• A statement that all applications must be signed via the instructions provided in the Implementation Guide
Modified
p. 70 → 69
3A P2PE solution management 3B Third-party management 3C Creation and maintenance of P2PE Instruction Manual for merchants Target Audience: The solution provider (or merchant as a solution provider for merchant-managed solutions), who maintains ultimate responsibility of the P2PE solution.
3A P2PE Solution management 3B Third-party management 3C Creation and maintenance of P2PE Instruction Manual for merchants 3D Management of P2PE Applications Target Audience: The P2PE Solution Provider (or merchant as a solution provider for merchant-managed solutions), who maintains ultimate responsibility of the P2PE Solution.
Modified
p. 70 → 69
The effective management and integration of the essential elements comprising the P2PE solution ultimately results in the absence of clear-text account data within the merchant’s encryption environment•e.g., merchant stores, shops, retail premises, etc. Domain 3 is critical to the P2PE solution due to the fact that P2PE solutions consist of numerous devices/products (POI devices, Applications, HSMs) operating in various environments (encryption, decryption, and key-injection), and all of these devices, products, and environments must be successfully integrated together and managed.
The effective management and integration of the essential elements comprising the P2PE Solution ultimately results in the absence of cleartext account data within the merchant’s encryption environment•e.g., merchant stores, shops, retail premises, etc. Domain 3 is critical to the P2PE Solution due to the fact that P2PE Solutions consist of numerous devices/products (PTS POI devices, P2PE Applications, HSMs, management of Component Providers, etc.) operating in various environments (e.g., encryption, decryption, and key-injection), and all of these devices, products, and environments …
Removed
p. 71
3A-1.2 Examine the data-flow diagram and interview personnel to verify the diagram:
Modified
p. 71 → 70
3A-1.1.a Interview relevant personnel and review documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the overall P2PE solution.
3A-1.1.a Interview relevant personnel and examine documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the overall P2PE solution.
Modified
p. 71 → 70
3A-1.1.b Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the overall P2PE solution to verify that the document is current.
3A-1.1.b Interview relevant personnel and examine documentation that describes and/or illustrates the architecture of the overall P2PE solution to verify that the document is current.
Modified
p. 71 → 70
3A-1.1.c Interview relevant personnel and review documentation that describes and/or illustrates the architecture of the overall P2PE solution to verify that the document:
3A-1.1.c Interview relevant personnel and examine documentation that describes and/or illustrates the architecture of the overall P2PE solution to verify that the document:
Modified
p. 71 → 70
3A-1.2 Current documentation (including a data-flow diagram) must include details of the account-data flow from the POI device (the point the card data is captured and encrypted) through to the point the encrypted card data is decrypted and the clear-text data exits the decryption environment.
3A-1.2 Current documentation (including a data-flow diagram) must include details of the account-data flow from the PTS POI devices (the point the card data is captured and encrypted) through to the point the encrypted card data is decrypted and the cleartext data exits the decryption environment.
Modified
p. 71 → 70
• Shows all account-data flows across systems and networks from the point the card data is captured through to the point the card data exits the decryption environment.
• All account-data flows across systems and networks from the point the card data is captured by the PTS POI devices through to the point the card data exits the decryption environment.
Modified
p. 71 → 70
• Is kept current and updated as needed upon changes to the environment.
• All documentation is kept current and updated as needed upon changes to the environment and/or solution.
Removed
p. 72
• To which region/country it applies 3A-1.3.b Perform independent review of, or conduct interviews with responsible solution provider personnel, to verify that the exception to facilitate merchants’ access to full PANs is based on a legal/regulatory obligation and not solely for convenience.
Modified
p. 72 → 71
Requirement 3A: P2PE solution management Domain 3 Requirements Testing Procedures 3A-1.3 Where there is a legal or regulatory obligation in a region for merchants to print full PAN on merchant receipts, it is allowable for the merchant to have access to full PAN for this purpose but the solution provider must document specifics about the legal or regulatory obligation including at least the following:
Requirement 3A: P2PE solution management Domain 3 Requirements Testing Procedures 3A-1.3 If there is a legal or regulatory obligation in a region for merchants to print full PAN on merchant receipts, it is allowable for the merchant to have access to full PAN for this purpose, but the solution provider must document specifics about the legal or regulatory obligation including at least the following:
Modified
p. 72 → 71
Note: Domain 2 (at 2A-3.1.2) also includes requirements that must be met for any PTS POI device and any P2PE Application, respectively, that facilitates merchant printing of full PAN where there is a legal or regulatory obligation to do so.
Modified
p. 72 → 71
3A-1.3.a Review solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation includes at least the following details about the legal/regulatory obligation:
3A-1.3.a Examine solution provider’s documentation about the legal/regulatory obligation that requires merchants to have access to full PANs for receipt printing purposes to verify that the documentation includes at least the following details about the legal/regulatory obligation:
Removed
p. 73
• Changes in overall solution architecture 3A-2.2.a Interview responsible personnel and review documentation to verify the solution provider has a formal process for ensuring P2PE controls are maintained when changes to the P2PE solution occur, including procedures for addressing the following:
Modified
p. 73 → 72
3A-2.1 Where P2PE component providers are used, a methodology must be implemented to manage and monitor status reporting from P2PE component providers, including:
3A-2.1 If P2PE component providers are used, a methodology must be implemented to manage and monitor status reporting from P2PE component providers, including:
Modified
p. 73 → 72
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider 3A-2.1 Where component providers are used, interview responsible personnel, review documentation, and observe processes to verify the solution provider has implemented a methodology for managing and monitoring status reporting from P2PE component providers, including processes for:
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider 3A-2.1 Interview responsible personnel, examine documentation, and observe processes to verify the solution provider has implemented a methodology for managing and monitoring status reporting from P2PE component providers, including processes for:
Modified
p. 73 → 72
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider 3A-2.2 Processes must be implemented to ensure P2PE controls are maintained when changes to the P2PE solution occur including, but not limited to:
• Following up with the component provider to resolve any questions or changes in expected performance of the component provider 3A-2.2 Processes must be implemented to ensure P2PE controls are maintained when changes to the P2PE solution occur, including but not limited to:
Modified
p. 73 → 72
• Changes in overall solution architecture 3A-2.2.b For a sample of changes, verify changes were documented and the solution updated accordingly.
• Changes in overall solution architecture 3A-2.2.b For a sample of changes, examine the changes to verify they were documented and the solution updated accordingly.
Modified
p. 74 → 73
• Encryption/decryption failures 3A-3.2 Upon detection of any suspicious activity defined at 3A-3.1, the POI device must be immediately removed, shut down, or taken offline until the integrity of the device is verified and the P2PE encryption mechanism is restored.
• Encryption/decryption failures 3A-3.2 Upon detection of any suspicious activity defined at 3A-3.1, the PTS POI device must be immediately removed, shut down, or taken offline until the integrity of the device is verified and the P2PE encryption mechanism is restored.
Modified
p. 74 → 73
3A-3.2 Review documented procedures and interview responsible personnel to verify that upon detection of any suspicious activity defined at 3A-3.1, POI devices are immediately removed, shut down, or taken offline.
3A-3.2 Examine documented procedures and interview responsible personnel to verify that upon detection of any suspicious activity defined at 3A-3.1, PTS POI devices are immediately removed, shut down, or taken offline.
Modified
p. 74 → 73
3A-3.2.1 The POI device must not be re-enabled until it is confirmed that the issue has been resolved and P2PE encryption functionality is restored and re-enabled.
3A-3.2.1 The PTS POI device must not be re-enabled until it is confirmed that the issue has been resolved and P2PE encryption functionality is restored and re-enabled.
Modified
p. 74 → 73
3A-3.2.1 Examine documented procedures and interview personnel to verify the POI devices must not be re-enabled until it is confirmed that either the issue has been resolved and P2PE encryption functionality is restored and re- enabled.
3A-3.2.1 Examine documented procedures and interview personnel to verify the PTS POI devices must not be re-enabled until it is confirmed that the issue has been resolved and P2PE encryption functionality is restored and re-enabled.
Modified
p. 76 → 75
• Updating the solution and/or controls to prevent cause from recurring 3A-3.5.a Interview responsible personnel and review documentation to verify the solution provider has a formal process for any P2PE control failures, including procedures for addressing the following:
• Updating the solution and/or controls to prevent cause from recurring 3A-3.5.a Interview responsible personnel and examine documentation to verify the solution provider has a formal process for any P2PE control failures, including procedures for addressing the following:
Modified
p. 76 → 75
• Implementing controls to prevent cause from recurring 3A-3.5.b For a sample of P2PE control failures, interview personnel and review supporting document to verify that:
• Implementing controls to prevent cause from recurring 3A-3.5.b For a sample of P2PE control failures, interview personnel and examine supporting document to verify that:
Modified
p. 77 → 76
3B-1.1 Solution provider must have formal agreements in place with all third parties that perform P2PE functions on behalf of the solution provider, including:
3B-1.1 If the Solution Provider uses third parties that perform P2PE functions on behalf of the Solution Provider, formal agreements must be in place that include:
Modified
p. 77 → 76
• Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain 3B-1.1.b If the solution provider utilizes any third parties, examine the business agreements and verify the elements delineated in 3B-1.1.a are present and adequately accounted for.
• Agreement to provide reports to solution provider as required in the “Component providers ONLY: report status to solution providers” section of the applicable P2PE Domain 3B-1.1.b If the solution provider utilizes any third parties, interview personnel and observe processes to verify the elements delineated in 3B-1.1.a are present and adequately accounted for.
Removed
p. 78
• Evidence of adherence to PCI’s process for P2PE Delta Changes 3B-1.2 Verify formal agreements established for all third parties managing SCDs on behalf of the solution provider require:
• Evidence of adherence to PCI’s process for P2PE Delta Changes
• Evidence of adherence to PCI’s process for P2PE Delta Changes
Modified
p. 78 → 77
Requirement 3B: Third-party management Domain 3 Requirements Testing Procedures 3B-1.2 For all third parties that have been contracted by the solution provider to manage any of the SCD types used in the P2PE solution, the solution provider must establish formal agreements with the third parties to ensure those third parties provide the Solution Provider with the following:
Requirement 3B: Third-party management Domain 3 Requirements Testing Procedures 3B-1.2 If the Solution Provider uses third parties to manage any of the SCD types used in the P2PE solution, the solution provider must establish formal agreements with the third parties to ensure those third parties provide the Solution Provider with the following:
Modified
p. 78 → 77
• Updated list of any dependencies included in the Delta Change (e.g., POI devices, P2PE applications, and/or HSMs) used in the solution
• Updated list of any dependencies included in the Delta Change (e.g., PTS POI devices, P2PE Applications, and/or HSMs) used in the solution 3B-1.2 Examine documentation for all third parties managing SCDs on behalf of the solution provider and verify the following is required:
Modified
p. 78 → 77
• Updated list of any dependencies included in the Delta Change (e.g., POI devices, P2PE applications, and/or HSMs) used in the solution
• Updated list of any dependencies included in the Delta Change (e.g., PTS POI devices, P2PE Applications, and/or HSMs) used in the solution
Removed
p. 79
3C-1.1.g Configure each POI device type, settings, etc. in accordance with all instructions in the PIM and confirm the following:
• The PIM provides accurate instructions.
• The PIM instructions facilitate a securely installed P2PE solution.
• The PIM provides accurate instructions.
• The PIM instructions facilitate a securely installed P2PE solution.
Modified
p. 79 → 78
3C-1.1.d Examine the PIM to verify that all devices specified in the PIM are PCI- approved POI devices that were assessed as part of this P2PE solution assessment.
3C-1.1.d Examine the PIM to verify that all devices specified in the PIM are eligible PCI-approved PTS POI devices that were assessed as part of this P2PE solution assessment.
Modified
p. 79 → 78
• All P2PE applications specified in the PIM are assessed for this solution (per Domain 1).
• All P2PE Applications specified in the PIM are assessed for this solution.
Modified
p. 79 → 78
• All P2PE applications specified in the PIM are either PCI-listed P2PE applications or assessed to Domain 2 as part of this P2PE solution assessment.
• All P2PE Applications specified in the PIM are either PCI-listed P2PE Applications or assessed to Domain 2 as part of this P2PE solution assessment (Solution-specific P2PE Applications).
Modified
p. 79 → 78
3C-1.1.f Examine the PIM to verify that all P2PE non-payment software specified in the PIM were assessed as part of this P2PE solution assessment (per Requirement 1C-2).
3C-1.1.f Examine the PIM to verify that all P2PE Non-payment software specified in the PIM has been assessed as part of this P2PE solution assessment (per Requirement 1C-2).
Modified
p. 80 → 79
Requirement 3C: Creation and maintenance of the P2PE Instruction Manual for merchants Domain 3 Requirements Testing Procedures 3C-1.2 Review P2PE Instruction Manual (PIM) at least annually and upon changes to the solution or the P2PE requirements. Update PIM as needed to keep the documentation current with:
Requirement 3C: Creation and maintenance of the P2PE Instruction Manual for merchants Domain 3 Requirements Testing Procedures 3C-1.2 Review P2PE Instruction Manual (PIM) at least annually and upon changes to the solution or the P2PE requirements. Update the PIM as needed to keep the documentation current with:
Modified
p. 80 → 79
• Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and
• Any changes to the P2PE solution (including additions or removals of PTS POI device types, P2PE Applications, and/or P2PE Non-payment software), and
Modified
p. 80 → 79
3C-1.2.a Examine documented procedures to verify they include:
• Applicable merchant instructions 3C-1.2.a Examine documented procedures to verify they include:
Modified
p. 80 → 79
Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and Any changes to the P2PE requirements.
Any changes to the P2PE solution (including additions or removals of PTS POI device types, P2PE Applications, and/or P2PE Non-payment software), and Any changes to the P2PE requirements.
Modified
p. 80 → 79
3C-1.2.b Observe processes for reviewing and updating the PIM, and interview responsible personnel to verify:
Applicable merchant instructions 3C-1.2.b Observe processes for reviewing and updating the PIM, and interview responsible personnel to verify:
Modified
p. 80 → 79
Any changes to the P2PE solution (including additions or removals of POI device types, P2PE applications, and/or P2PE non-payment software), and Any changes to the P2PE requirements.
Any changes to the P2PE solution (including additions or removals of POI device types, P2PE Applications, and/or P2PE Non-payment software), and Any changes to the P2PE requirements.
Modified
p. 80 → 79
3C-1.2.1 Communicate PIM updates to affected merchants, and provide merchants with an updated PIM as needed.
3C-1.2.1 Communicate PIM updates to affected merchants and provide merchants with an updated PIM as needed.
Removed
p. 81
Within a P2PE solution, the decryption environment is where incoming encrypted account data is decrypted back to its original clear-text. This environment therefore consists of the secure cryptographic devices (and a Host System for hybrid environments) and cryptographic keys involved in the account-data decryption process. Requirements in Domain 4 entail securing all decryption systems and associated cryptographic keys, along with implementing monitoring and response procedures.
Modified
p. 81 → 82
4E Component providers ONLY: report status to solution providers Target Audience: P2PE solution providers, or those who, on behalf of P2PE solution providers, manage the P2PE decryption environment.
4E Component providers ONLY: report status to solution providers Target Audience: P2PE Solution Providers, or those who, on behalf of P2PE Solution Providers, manage the P2PE decryption environment.
Modified
p. 81 → 82
Hybrid decryption environments require HSMs for cryptographic key-management functions but allow for non-SCD Host Systems to be used for account-data decryption. Unlike a P2PE solution with a hardware decryption environment (in which cryptographic key management and account-data decryption are performed entirely within a hardware security module, or HSM), a hybrid decryption environment (which requires HSMs for cryptographic key-management functions) allows for the decryption of account data outside of an HSM in non-SCDs on a Host System. These environments must meet …
Hybrid decryption environments require HSMs for cryptographic key-management functions but allow for non-SCD Host Systems to be used for account-data decryption. Unlike a P2PE solution with a hardware decryption environment (in which cryptographic key management and account-data decryption are performed entirely within a hardware security module, or HSM), a hybrid decryption environment (which requires HSMs for cryptographic key-management functions) allows for the decryption of account data
Modified
p. 81 → 82
Note: References to “devices” within this section are always to be interpreted as referencing decryption devices, such as HSMs, unless specifically noted. For hybrid decryption environments, references to “decryption devices and systems” within this section are always to be interpreted as referencing HSMs and the Host System, unless specifically noted. This section is not intended to include requirements to be assessed against encrypting devices, such as POI devices.
Note: References to “devices” within this section are always to be interpreted as referencing decryption devices, such as HSMs, unless specifically noted. For hybrid decryption environments, references to “decryption devices and systems” within this section are always to be interpreted as referencing HSMs and the Host System, unless specifically noted. This section is not intended to include requirements to be assessed against encrypting devices, such as PTS POI devices.
Modified
p. 81 → 82
Note: For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 4, and 5 of this document refers to merchant personnel in the encryption environments, and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Note: For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 4, and 5 of this document refers to merchant personnel in the encryption environments and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Removed
p. 82
• FIPS 140-2 or 140-3 Level 3 (overall) or higher certified, or
Note: HSM approval listings must be current⎯HSMs must have a non-expired PCI PTS HSM approval or a non-expired FIPS 140-2 or 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).
4A-1.1.a For all HSMs used in the decryption environment, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs used in the solution are either:
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or 140-3 Level 3 (overall), or higher. Refer to http://csrc.nist.gov.
4A-1.1.1 The approval listing must match the deployed devices in the following characteristics:
• Model name and number
• Device firmware version number
• Device firmware version number
• For PCI-approved HSMs, any applications, including application version number, resident within the device …
Note: HSM approval listings must be current⎯HSMs must have a non-expired PCI PTS HSM approval or a non-expired FIPS 140-2 or 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).
4A-1.1.a For all HSMs used in the decryption environment, examine approval documentation (e.g., FIPS certification or PTS approval) and review the list of approved devices to verify that all HSMs used in the solution are either:
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or 140-3 Level 3 (overall), or higher. Refer to http://csrc.nist.gov.
4A-1.1.1 The approval listing must match the deployed devices in the following characteristics:
• Model name and number
• Device firmware version number
• Device firmware version number
• For PCI-approved HSMs, any applications, including application version number, resident within the device …
Modified
p. 82 → 83
A Host System is defined as a combination of software and hardware components used to of decrypt account data. May also be used for transaction processing using non-SCD host systems.
A Host System is defined as a combination of software and hardware components used to decrypt account data. May also be used for transaction processing using non-SCD host systems.
Modified
p. 82 → 83
Requirement 4A: Use approved decryption devices Domain 4 Requirements Testing Procedures 4A-1 Use approved decryption devices 4A-1.1 All hardware security modules (HSMs) must be either:
Requirement 4A: Use approved decryption devices Domain 4 Requirements Testing Procedures 4A-1 Use approved decryption devices 4A-1.1 All account-data decryption operations must be performed only by the FIPS-approved and/or PTS-approved HSMs identified in requirement 1-3.
Modified
p. 82 → 83
4A-1.1 Examine documented procedures and interview personnel to verify that all account-data decryption operations are performed only by the FIPS-approved and/or PTS-approved HSMs identified in 1-3.
Removed
p. 83
Note: If the solution provider has applied a vendor security patch resulting in an updated HSM firmware version, and the PCI SSC or NIST validation of that updated firmware version has not yet been completed (resulting in a mismatch between the HSM firmware version in use and the listed, validated one), the solution provider must obtain documentation from the vendor regarding the update that includes confirmation the update has been submitted for evaluation per the process specified by either PCI SSC or NIST (as applicable to the HSM).
4A-1.1.1.b For all FIPS-approved HSMs used in the solution, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS 140-2 or 140-3 Level 3 (or higher) approval listing for each HSM:
• Firmware version number 4A-1.1.1.c If the solution provider has applied a vendor security patch that resulted in …
4A-1.1.1.b For all FIPS-approved HSMs used in the solution, examine HSM devices and review the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS 140-2 or 140-3 Level 3 (or higher) approval listing for each HSM:
• Firmware version number 4A-1.1.1.c If the solution provider has applied a vendor security patch that resulted in …
Modified
p. 83 → 84
Requirement 4A: Use approved decryption devices Domain 4 Requirements Testing Procedures 4A-1.1.1 (continued)
Requirement 4A: Use approved decryption devices Domain 4 Requirements Testing Procedures 4A-1.1.2 If FIPS-approved HSMs are used for account-data decryption and related processes, the HSM must use the FIPS-approved cryptographic primitives, data-protection mechanisms, and key-management processes for account- data decryption and related processes.
Modified
p. 83 → 84
4A-1.1.2.a Examine FIPS approval documentation (security policy) and HSM operational procedures to verify that the FIPS approval covers the cryptographic primitives, data-protection mechanisms, and key-management used for account- data decryption and related processes.
4A-1.1.2.a Examine FIPS approval documentation and HSM operational procedures to verify that the FIPS approval covers the cryptographic primitives, data-protection mechanisms, and key-management used for account-data decryption and related processes.
Modified
p. 83 → 84
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements
• A statement that nothing has been changed on, or added to, the HSM that impacts the security of the HSM, cryptographic key-management processes, or P2PE requirements 4A-1.1.3 If PCI PTS-approved HSMs are used for account- data decryption and related processes, the HSM must be configured to operate in accordance with the security policy that was included in the PTS HSM approval, for all P2PE operations (including algorithms, data protection, key management, etc.).
Removed
p. 84
Requirement 4A: Use approved decryption devices Domain 4 Requirements Testing Procedures 4A-1.1.3 If PCI PTS-approved HSMs are used, the HSM must be configured to operate in accordance with the security policy that was included in the PTS HSM approval, for all P2PE operations (including algorithms, data protection, key management, etc.).
Modified
p. 84
4A-1.1.3 Examine HSM configurations for all P2PE solution functions to verify that HSMs are configured to operate according to the security policy that was included as part of the PTS approval. In addition, review the PCI approval listing(s) for any implementation-specific notes and if present, verify they are accounted for.
4A-1.1.3 Examine HSM configurations for all account-data decryption and related processes to verify that HSMs are configured to operate according to the security policy that was included as part of the PTS approval. In addition, examine the PCI approval listing(s) for any implementation-specific notes and if present, verify they are accounted for.
Modified
p. 85
4B-1.1 Current documentation must be maintained that describes or illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
4B-1.1 Current documentation must be maintained that describes or illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from PTS POI devices, all systems within the decryption environment, and any outbound connections.
Modified
p. 85
4B-1.1.a Review documentation to verify that a procedure exists to maintain a document that describes/illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
4B-1.1.a Examine documentation to verify that a procedure exists to maintain a document that describes/illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
Modified
p. 85
4B-1.1.b Interview responsible personnel and review solution-provider documentation to verify that it describes/illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from POI devices, all systems within the decryption environment, and any outbound connections.
4B-1.1.b Interview responsible personnel and examine documentation to verify that it describes/illustrates the configuration of the decryption environment, including the flow of data and interconnectivity between incoming transaction data from PTS POI devices, all systems within the decryption environment, and any outbound connections.
Modified
p. 85
• Management of user interface
• Management of the user interface
Modified
p. 86
For example, require authentication for use of the HSMs APIs and secure all authentication credentials from unauthorized access. Where an HSM is unable to authenticate use of the API, limit the exposure of the HSM to a trusted host via a dedicated physical link that authorizes access on behalf of the HSM over the trusted channel (e.g., high-speed serial or dedicated Ethernet).
Note: For example, require authentication for use of the HSMs APIs and secure all authentication credentials from unauthorized access. Where an HSM is unable to authenticate use of the API, limit the exposure of the HSM to a trusted host via a dedicated physical link that authorizes access on behalf of the HSM over the trusted channel (e.g., high-speed serial or dedicated Ethernet).
Modified
p. 86
4B-1.4 POI devices must be authenticated by the decryption environment and upon request by the solution provider.
4B-1.4 PTS POI devices used in the merchant environment for account data acceptance and encryption must be authenticated by the decryption environment and upon request by the solution provider.
Modified
p. 86
Note: The intent is to ensure the decryption environment can authenticate each unique POI device within a P2PE solution with which it is communicating.
Note: The intent is to ensure the decryption environment can authenticate each unique PTS POI device within a P2PE solution with which it is communicating.
Modified
p. 86
This authentication may occur via use of cryptographic keys or certificates, uniquely associated with each POI device and decryption system.
This authentication may occur via use of cryptographic keys or certificates, uniquely associated with each PTS POI device and decryption system.
Modified
p. 86
4B-1.4.a Examine documented policies and procedures to verify they require POI devices be authenticated upon connection to the decryption environment and upon request by the solution provider.
4B-1.4.a Examine documented policies and procedures to verify they require PTS POI devices be authenticated upon connection to the decryption environment and upon request by the solution provider.
Modified
p. 86
4B-1.4.b Verify documented procedures are defined for the following:
4B-1.4.b Examine documented procedures are defined for the following:
Modified
p. 86
• Procedures and/or mechanisms for authenticating POI devices by the decryption environment
• Procedures and/or mechanisms for authenticating PTS POI devices by the decryption environment
Modified
p. 86
• Procedures and/or mechanisms for authenticating POI devices upon request by the solution provider 4B-1.4.c Interview responsible personnel and observe a sample of device authentications to verify the following:
• Procedures and/or mechanisms for authenticating PTS POI devices upon request by the solution provider 4B-1.4.c Interview responsible personnel and observe a sample of device authentications to verify the following:
Modified
p. 86
• POI devices are authenticated by the decryption environment.
• PTS POI devices are authenticated by the decryption environment.
Modified
p. 86
• POI devices are authenticated upon request by the solution provider.
• PTS POI devices are authenticated upon request by the solution provider.
Removed
p. 87
• Physically connected devices 4B-1.5.a Examine documented procedure to verify that inspection of devices is required at least quarterly to detect signs of tampering or modification, and that inspection procedures include:
• Physically connected devices 4B-1.5.b Interview personnel performing inspections and observe inspection processes to verify that inspections include:
• Physically connected devices 4B-1.5.c Interview personnel performing inspections and review supporting documentation to verify that inspections are performed at least quarterly.
• Physically connected devices 4B-1.5.b Interview personnel performing inspections and observe inspection processes to verify that inspections include:
• Physically connected devices 4B-1.5.c Interview personnel performing inspections and review supporting documentation to verify that inspections are performed at least quarterly.
Modified
p. 87
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.5 Inspections of decryption devices by authorized personnel must be performed at least quarterly to detect tampering or modification of devices. Inspections to include:
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.5 Processes for inspections of HSMs used for decryption operations and related processes must be:
Modified
p. 87
4B-1.6 Decryption environment must be secured according to PCI DSS.
• Inspections are performed at least quarterly 4B-1.5.b [Removed] 4B-1.5.c [Removed] 4B-1.6 Decryption environment must be secured according to PCI DSS.
Modified
p. 87
Note: The QSA (P2PE) should NOT challenge or re- evaluate the PCI DSS environment (or its compliance) where a completed and current ROC exists.
Note: The P2PE Assessor should NOT challenge or re- evaluate the PCI DSS environment (or its compliance) where a completed and current ROC exists.
Modified
p. 87
4B-1.6.a Review the “Description of Scope of Work and Approach Taken” section of the solution provider’s current PCI DSS Report on Compliance (ROC) to verify the PCI DSS assessment scope fully covers the P2PE decryption environment.
4B-1.6.a Examine the current PCI DSS Report on Compliance (ROC) to verify the PCI DSS assessment scope fully covers the P2PE decryption environment.
Modified
p. 87
4B-1.6.b Review PCI DSS ROC and/or Attestation of Compliance (AOC) to verify that all applicable PCI DSS requirements are “in place” for the P2PE decryption environment.
4B-1.6.b Examine the PCI DSS ROC and/or AOC to verify that all applicable PCI DSS requirements are “in place” for the P2PE decryption environment.
Modified
p. 87
4B-1.6.c Review PCI DSS ROC and/or Attestation of Compliance (AOC) to verify that the PCI DSS assessment of the P2PE decryption environment was:
4B-1.6.c Examine the PCI DSS ROC and/or AOC to verify that the PCI DSS assessment of the P2PE decryption environment was:
Modified
p. 88
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.7 Processes are implemented to ensure that clear- text account data is never sent back to the encryption environment.
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.7 Processes must be implemented to ensure that cleartext account data is never sent back to the encryption environment.
Modified
p. 88
Note: Output of clear-text data that is verified as being unrelated to any of the PCI payment brands is acceptable. The security of this process when it occurs from the decryption environment is assessed at Requirement 4B-1.9 4B-1.7.a Review documented processes and interview personnel to confirm that clear-text account data is never sent back to the encryption environment.
Note: Output of cleartext data that is verified as being unrelated to any of the PCI payment brands is acceptable. The security of this process when it occurs from the decryption environment is assessed at Requirement 4B-1.9.
Modified
p. 88
4B-1.7.b Observe process flows and data flows to verify that there is no process, application, or other mechanism that sends clear-text account data back into the encryption environment.
4B-1.7.b Observe process flows and data flows to verify that there is no process, application, or other mechanism that sends cleartext account data back into the encryption environment.
Modified
p. 88
4B-1.8 Any truncated PANs sent back to the encryption environment must adhere to the allowable number of digits as specified in PCI DSS and/or related FAQs that specify allowable digits.
4B-1.8 If the decryption environment allows for truncated PANs to be sent back to the encryption environment, they must adhere to the allowable number of digits.
Modified
p. 88
4B-1.8.b Observe process flows and data flows to verify that there is no process, application, or other mechanism that sends more digits of truncated PANs back to the encryption environment than is permitted.
Removed
p. 89
4B-1.9.1.a Observe application and system configurations and interview personnel to verify that whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows the output of clear- text account data for non-PCI payment brand account/card data.
Modified
p. 89
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.9 Any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must ensure that the ONLY allowed output of clear-text account data is for non-PCI payment brand account/card data, and includes the following:
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.9 If whitelisting functionality is implemented in the decryption environment that transmits data to the encryption environment, it must be ensured that the ONLY allowed output of cleartext account data is for non- PCI payment brand account/card data, and includes the following:
Modified
p. 89
- Description and justification for the functionality - Who approved the new installation or updated functionality prior to release - Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 4B-1.9.a Examine documented policies and procedures to verify that that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment ensures that the ONLY allowed output of cleartext account data is for non-PCI payment brand account/card data, and includes …
Modified
p. 89
- Confirmation that it was reviewed prior to release to only output non-PCI payment brand account/card data 4B-1.9.b Observe application and system configurations and interview personnel to verify that whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows the output of cleartext account data for non-PCI payment brand account/card data.
Modified
p. 89
4B-1.9.c Perform test transactions to verify that any whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment only allows output cleartext account for non-PCI payment brand account/card data.
Modified
p. 90
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.9.2 Any new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must be:
Requirement 4B: Secure the decryption environment Domain 4 Requirements Testing Procedures 4B-1.9.2 If whitelisting is supported, new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must be:
Modified
p. 90
• Cryptographically authenticated by the HSM 4B-1.9.3 Any new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must follow change-control procedures that include:
• Cryptographically authenticated by the HSM 4B-1.9.3 If whitelisting is supported, new installations of, or updates to, whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment must follow change-control procedures that include:
Modified
p. 90
4B-1.9.3 Review records of both new and updated whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment, and confirm the following:
4B-1.9.3 Examine records of both new and updated whitelisting functionality implemented in the decryption environment that transmits data to the encryption environment, and confirm the following:
Removed
p. 91
• Unauthorized use of the HSM API 4C-1.2.a Examine documented procedures to verify mechanisms are defined to detect and respond to potential security incidents, including:
Modified
p. 91
Note: Critical functions include but are not limited to application and firmware updates, key-injection, as well as changes to security-sensitive configurations.
Note: Critical functions include but are not limited to application and firmware updates, cryptographic-related functions, as well as changes to security-sensitive configurations/settings.
Modified
p. 91
4C-1.1 Examine system configurations and correlating log files to verify that any changes to the critical functions of decryption devices are logged, including:
4C-1.1 Examine system configurations and correlating log files to verify that any changes to the critical functions of decryption devices are logged, including (but limited to):
Modified
p. 91
• Changes to any security-sensitive configurations 4C-1.2 Mechanisms must be implemented to detect and respond to suspicious activity, including but not limited to:
• Changes to any security-sensitive configurations/settings 4C-1.2 Mechanisms must be implemented to detect and respond to suspicious activity, including but not limited to:
Modified
p. 92
• Unauthorized use of the HSM API 4C-1.3 Mechanisms must be implemented to detect encryption failures, including at least the following:
Modified
p. 92
Note: Although Domain 4 is concerned with the decryption environment, not the encryption environment, all traffic received into the decryption environment must be actively monitored to confirm that the POI devices in the merchant’s encryption environment is not outputting clear-text account data through some error or misconfiguration.
Note: Although Domain 4 is concerned with the decryption environment, not the encryption environment, all traffic received into the decryption environment must be actively monitored to confirm that the POI devices in the merchant’s encryption environment is not outputting cleartext account data through some error or misconfiguration.
Modified
p. 92
• Procedures are defined to detect encryption failures, and include 4C-1.3.1 through 4C-1.3.4 below.
• Procedures are defined to detect encryption failures and include 4C-1.3.1 through 4C-1.3.3 below.
Modified
p. 92
• Procedures include immediate notification upon detection of a cryptographic failure, for each 4C-1.3.1 through 4C-1.3.4 below.
• Procedures include immediate notification upon detection of a cryptographic failure, for each 4C-1.3.1 through 4C-1.3.3 below.
Modified
p. 92
4C-1.3.1 Checking for incoming clear-text account data.
4C-1.3.1 Checking for incoming cleartext account data.
Modified
p. 92
4C-1.3.1.a Observe implemented processes to verify controls are in place to check for incoming clear-text account data.
4C-1.3.1.a Observe implemented processes to verify controls are in place to check for incoming cleartext account data.
Modified
p. 92
4C-1.3.1.b Observe implemented controls and notification mechanisms to verify mechanisms detect and provide immediate notification upon detection of incoming clear-text account data.
4C-1.3.1.b Observe implemented controls and notification mechanisms to verify mechanisms detect and provide immediate notification upon detection of incoming cleartext account data.
Modified
p. 92
4C-1.3.1.c Interview personnel to verify that designated personnel are immediately notified upon detection of incoming clear-text account data.
4C-1.3.1.c Interview personnel to verify that designated personnel are immediately notified upon detection of incoming cleartext account data.
Modified
p. 92
4C-1.3.2.a Observe implemented processes to verify controls are in place to detect and review any cryptographic errors reported by the HSM.
Modified
p. 92 → 93
4C-1.3.2.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification of cryptographic errors reported by the HSM.
Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 4C-1.3.2 (continued) 4C-1.3.2.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification of cryptographic errors reported by the HSM.
Modified
p. 92 → 93
For example, transaction data received without an expected authentication data block (such as a MAC or signature, or a malformed message).
Note: For example, transaction data received without an expected authentication data block (such as a MAC or signature, or a malformed message).
Removed
p. 93
4C-1.3.4.a Observe implemented processes to verify controls are in place to review data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections.
4C-1.3.4.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
4C-1.3.4.c Interview personnel to verify that designated personnel are immediately notified upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
4C-1.3.4.b Observe implemented controls and notification mechanisms to verify that mechanisms detect and provide immediate notification upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
4C-1.3.4.c Interview personnel to verify that designated personnel are immediately notified upon detection of POI devices that are causing an unusually high rate of transaction authorization rejections.
Modified
p. 93 → 94
Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 4C-1.3.4 Reviewing data sent by any POI devices that are causing an unusually high rate of transaction authorization rejections.
Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 4C-1.4 All suspicious activity must be identified and a record maintained for one year, at a minimum, to include at least the following:
Modified
p. 93 → 94
• Details of whether any account data was transmitted from the POI device during any identified time that encryption was malfunctioning or disabled 4C-1.4.a Examine documented procedures to verify they include procedures for identifying the source and maintaining a record, of all suspicious activity, to include at least the following:
• Details of whether any account data was transmitted from the POI device during any identified time that encryption was malfunctioning or disabled 4C-1.4.a Examine documented procedures to verify they include procedures for identifying the source and maintaining a record of all suspicious activity, to include at least the following:
Modified
p. 93 → 94
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled
• Details of whether any account data was transmitted from the POI device during the time that encryption was malfunctioning or disabled 4C-1.5 Implement mechanisms to provide immediate notification of suspicious activity to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers).
Removed
p. 94
Requirement 4C: Monitor the decryption environment and respond to incidents Domain 4 Requirements Testing Procedures 4C-1.5 Implement mechanisms to provide immediate notification of suspicious activity to applicable parties, including merchants, processors, acquirers, and any P2PE solution providers (if decryption services are being performed on behalf of other P2PE solution providers).
Key Management and Remote/Local Cryptographic Key Loading Hardware Security Module (FIPS 140-2 or PCI HSM Approved) P2PE Key Management and Cryptography Account Data Application 1 Account Data Application 2 Non-account Data Application 3 P2PE Key Management and Cryptography Plain-text account data Encrypted (or truncated) Communications w/o account data Transaction account data flow (encrypted or truncated data only) Assessed to PCI PTS POI (SRED) Assessed to P2PE Domain 1 Assessed to P2PE Domain 2
PCI DSS validation as required by the merchant's acquirer or payment brand Customer presentment of payment card POS software and other Merchant systems (Encrypted and/or truncated payment card data …
Key Management and Remote/Local Cryptographic Key Loading Hardware Security Module (FIPS 140-2 or PCI HSM Approved) P2PE Key Management and Cryptography Account Data Application 1 Account Data Application 2 Non-account Data Application 3 P2PE Key Management and Cryptography Plain-text account data Encrypted (or truncated) Communications w/o account data Transaction account data flow (encrypted or truncated data only) Assessed to PCI PTS POI (SRED) Assessed to P2PE Domain 1 Assessed to P2PE Domain 2
PCI DSS validation as required by the merchant's acquirer or payment brand Customer presentment of payment card POS software and other Merchant systems (Encrypted and/or truncated payment card data …
Modified
p. 95
Note: This diagram is for illustrative purposes only.
Note: This diagram is for illustrative purposes only. Requirements 4D-x are ONLY for hybrid decryption environments.
Removed
p. 96
4D-1.1.c Review the solution provider documentation that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems, to verify that it accurately represents the decryption environment.
Modified
p. 96
4D-1.1.a Interview responsible personnel and review documentation to verify that a procedure exists to maintain a document that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems within the decryption environment.
4D-1.1.a Interview responsible personnel and examine documentation to verify that a procedure exists to maintain a document that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems within the decryption environment.
Modified
p. 96
4D-1.1.b Interview responsible personnel and review solution provider documentation that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems within that environment, to verify that the document is current.
4D-1.1.b Interview responsible personnel and examine solution provider documentation that describes/illustrates the configuration of the Host System, including the flow of data and interconnectivity between all systems within that environment, to verify that the document is current.
Modified
p. 96
4D-1.2 The Host System must be isolated, or dedicated, to processing payment transactions with only necessary services, protocols, daemons etc. enabled:
4D-1.2 The Host System must be isolated, or dedicated, to processing payment transactions with only necessary services, protocols, daemons, etc. enabled:
Modified
p. 96
• The necessary services, protocols, daemons etc. must be documented and justified, including description of the enabled security features for these services etc.
• The necessary services, protocols, daemons, etc. must be documented and justified, including description of the enabled security features for these services etc.
Modified
p. 96
4D-1.2.a Inspect network and system configuration settings to verify the host processing system is isolated, or dedicated, to processing payment transactions, with only necessary services, protocols, daemons etc. enabled.
4D-1.2.a Examine network and system configuration settings to verify the host processing system is isolated, or dedicated, to processing payment transactions, with only necessary services, protocols, daemons, etc. enabled.
Modified
p. 96
4D-1.2.b Review the documented record of services, protocols, daemons etc. that are required by the Host System and verify that each service includes justification and a description of the enabled security feature.
4D-1.2.b Examine the documented record of services, protocols, daemons etc. that are required by the Host System and verify that each service includes justification and a description of the enabled security feature.
Removed
p. 97
4D-1.3.a Examine network diagrams to verify the Host System(s) and HSM(s) are located on a network that is segmented from other networks that are not required for decryption operations or transaction processing.
4D-1.3.b Inspect network and system configurations to verify the Host System(s) and HSM(s) are located on a network that is segmented from other networks not required for decryption operations or transaction processing.
4D-1.3.b Inspect network and system configurations to verify the Host System(s) and HSM(s) are located on a network that is segmented from other networks not required for decryption operations or transaction processing.
Modified
p. 97
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.3 The Host System and HSMmust reside on a network that is dedicated to decryption operations and transaction processing and must be segmented from any other network, or system, that is not performing or supporting decryption operations or transaction processing.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.3 The Host System and HSM
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.3 The Host System and HSM must, at a minimum:
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.3 The Host System and HSM must, at a minimum:
Modified
p. 97
4D-1.4.c Inspect Host System and compare with system configuration standards to verify that all software installed on the Host System has a defined business justification.
4D-1.4.c Examine Host System and compare with system configuration standards to verify that all software installed on the Host System has a defined business justification.
Modified
p. 97
4D-1.5.a Examine documented policies and procedures to verify that a process is defined to prevent and/or detect and alert, any unauthorized changes to applications/software.
4D-1.5.a Examine documented policies and procedures to verify that a process is defined to prevent and/or detect and alert of any unauthorized changes to applications/software.
Modified
p. 97
4D-1.5.b Interview personnel and observe system configurations to verify that controls are implemented to prevent and/or detect and alert personnel, upon any unauthorized changes to applications/software.
4D-1.5.b Interview personnel and observe system configurations to verify that controls are implemented to prevent and/or detect and alert personnel upon any unauthorized changes to applications/software.
Modified
p. 98
• Testing integrity of any security functions critical to the secure operation of the Host System 4D-1.6.a Inspect Host System configuration settings, and examine vendor/solution provider documentation to verify that the Host System performs a self-test when it is powered up to ensure its integrity before use. Verify the self-test includes the following:
• Testing integrity of any security functions critical to the secure operation of the Host System 4D-1.6.a Examine Host System configuration settings, and vendor/solution provider documentation to verify that the Host System performs a self-test when it is powered up to ensure its integrity before use. Verify the self-test includes the following:
Modified
p. 98
4D-1.7.a Inspect Host System configuration settings and examine vendor/solution provider documentation to verify that the Host System performs a self-test when a security-impacting function or operation is modified.
4D-1.7.a Examine Host System configuration settings and vendor/solution provider documentation to verify that the Host System performs a self-test when a security- impacting function or operation is modified.
Modified
p. 98
Note: An “error state” identifies the Host System has encountered an issue that requires a response action. To prevent potential damage or compromise, the system must cease cryptographic operations until the issue is resolved and the host is returned to a normal processing state.
Note: An “error state” identifies the Host System has encountered an issue that requires a response action. To prevent potential damage or compromise, the system must cease cryptographic operations until the issue is resolved, and the host is returned to a normal processing state.
Modified
p. 98
4D-1.8.a Inspect Host System configuration settings and examine vendor/solution provider documentation to verify that the host enters an error state and generates an alert in the event of the following:
4D-1.8.a Examine Host System configuration settings and documentation to verify that the host enters an error state and generates an alert in the event of the following:
Modified
p. 99
4D-1.9.a Review documented procedures to verify alerts generated from the Host System must be documented and result in notification to authorized personnel and initiate a response procedure.
4D-1.9.a Examine documented procedures to verify alerts generated from the Host System are documented and result in notification to authorized personnel and initiate a response procedure.
Modified
p. 99
• During diagnostics of cryptographic operations 4D-1.10.b Inspect Host System configuration settings and interview personnel to verify that controls and/or procedures are in place to ensure that the Host System does not perform any cryptographic operations:
• During diagnostics of cryptographic operations 4D-1.10.b Examine Host System configuration settings and interview personnel to verify that controls and/or procedures are in place to ensure that the Host System does not perform any cryptographic operations:
Modified
p. 99
4D-1.11.a Inspect configuration documentation to verify that access controls are defined to ensure all source code and executable code for cryptographic software and firmware is protected from unauthorized disclosure and unauthorized modification.
4D-1.11.a Examine configuration documentation to verify that access controls are defined to ensure all source code and executable code for cryptographic software and firmware is protected from unauthorized disclosure and unauthorized modification.
Modified
p. 99
4D-1.12 The clear-text data-decryption keys must not be accessible to any processes or functions not directly required for decryption operations.
4D-1.12 The cleartext data-decryption keys must not be accessible to any processes or functions not directly required for decryption operations.
Modified
p. 99
4D-1.12.a Review solution provider documentation, including data-flow diagrams, to verify that clear-text decryption keys are not accessible to any processes or functions not directly required for decryption operations.
4D-1.12.a Examine documentation, including data-flow diagrams, to verify that cleartext decryption keys are not accessible to any processes or functions not directly required for decryption operations.
Modified
p. 99 → 100
4D-1.12.b Inspect Host System configurations and access controls and to verify that clear-text decryption keys are not accessible to any processes or functions not directly required for decryption operations.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.12 (continued) 4D-1.12.b Examine Host System configurations and access controls and to verify that cleartext decryption keys are not accessible to any processes or functions not directly required for decryption operations.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.12 (continued) 4D-1.12.b Examine Host System configurations and access controls and to verify that cleartext decryption keys are not accessible to any processes or functions not directly required for decryption operations.
Removed
p. 100
4D-1.14.2 Storage can only be made to a dedicated hard drive (on its own bus) within the host.
Modified
p. 100
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.13 The clear-text data-decryption keys must only be accessible to authorized personnel with a defined job- related need to access the keys
4D-1.13.a Examine documented key-management policies and procedures to verify cleartext data-decryption keys must only be accessible to authorized personnel with a defined job-related need to access the keys.
Modified
p. 100
4D-1.13.b Inspect Host System configuration settings and verify that clear-text data- decryption keys are only accessible to authorized personnel with a defined job-related need to access the keys.
4D-1.13.b Examine Host System configuration settings and verify that cleartext data- decryption keys are only accessible to authorized personnel with a defined job-related need to access the keys.
Modified
p. 100
4D-1.14 The Host System must not write clear-text cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:
4D-1.14 The Host System must not write cleartext cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:
Modified
p. 100
4D-1.14.a Examine documented configuration procedures to verify that the Host System must not write clear-text cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:
4D-1.14.a Examine documented configuration procedures to verify that the Host System must not write cleartext cryptographic keys to persistent storage (e.g., hard drives, removable storage, flash drives etc.) except for the following:
Modified
p. 100
• Core dumps of memory required for trouble-shooting 4D-1.14.b Examine Host System configuration settings and interview personnel to verify that clear-text cryptographic keys are not written to persistent storage except in the following circumstances:
• Core dumps of memory required for troubleshooting 4D-1.14.b Examine Host System configuration settings and interview personnel to verify that cleartext cryptographic keys are not written to persistent storage except in the following circumstances:
Modified
p. 100
• Core dumps of memory required for trouble-shooting 4D-1.14.c Verify documented procedures include Requirements 4D-1.14.1 through 4D- 1.14.5 below.
• Core dumps of memory required for troubleshooting 4D-1.14.c Examine documented procedures to verify they include Requirements 4D- 1.14.1 through 4D-1.14.5 below.
Modified
p. 100
4D-1.14.1.a Review Host System configuration standards to verify that storage locations of any swap/page files and core dumps are defined.
4D-1.14.1.a Examine Host System configuration standards to verify that storage locations of any swap/page files and core dumps are defined.
Modified
p. 100 → 101
4D-1.14.3.a Examine backup configuration settings for the Host System and storage locations to verify that swap/page files and core dumps are not backed up.
Modified
p. 101
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-1.14.3 (continued)
4D-1.14.3.b Examine the configurations of storage locations to verify that swap/page files and core dumps cannot be copied off the storage locations.
Modified
p. 101
4D-1.14.4 Access to, and the use of, any tools used for trouble-shooting or forensics must be controlled and authorized by management.
4D-1.14.4 Access to, and the use of, any tools used for troubleshooting or forensics must be controlled and authorized by management.
Modified
p. 101
4D-1.14.4.a Examine documented procedures to verify that controls are defined to ensure that the access to, and use of, any tools used for trouble-shooting or forensics, are controlled and authorized by management.
4D-1.14.4.a Examine documented procedures to verify that controls are defined to ensure that the access to, and use of, any tools used for troubleshooting or forensics, are controlled and authorized by management.
Modified
p. 101
4D-1.14.4.b Observe the process for accessing the tools used for trouble-shooting or forensics, and verify that they are controlled and authorized by management in accordance with the documented procedure.
4D-1.14.4.b Observe the process for accessing the tools used for troubleshooting or forensics and verify that they are controlled and authorized by management in accordance with the documented procedure.
Modified
p. 101
4D-1.14.4.c Observe the process for using the tools used for trouble-shooting or forensics, and verify that they are controlled and authorized by management in accordance with the documented procedure.
4D-1.14.4.c Observe the process for using the tools used for troubleshooting or forensics and verify that they are controlled and authorized by management in accordance with the documented procedure.
Modified
p. 101
4D-1.14.5.a Review documented procedures to verify that it defines a process for securely deleting swap/page files and core dumps at the required times:
4D-1.14.5.a Examine documented procedures to verify that it defines a process for securely deleting swap/page files and core dumps at the required times:
Modified
p. 101
4D-1.14.5.b Verify, through the use of forensic tools and/or methods, that the secure procedure removes swap/page files and core dumps, in accordance with industry- accepted standards for secure deletion of data.
4D-1.14.5.b Test, through the use of forensic tools and/or methods, that the secure procedure removes swap/page files and core dumps, in accordance with industry- accepted standards for secure deletion of data.
Modified
p. 102
4D-2.1.b Inspect Host System configuration settings to verify that user password parameters are set to require users to change passwords at least every 30 days.
4D-2.1.b Examine Host System configuration settings to verify that user password parameters are set to require users to change passwords at least every 30 days.
Modified
p. 102
4D-2.2.b Inspect Host System (s) configuration settings to verify that user passwords:
4D-2.2.b Examine Host System (s) configuration settings to verify that user passwords:
Modified
p. 102
4D-2.3 Where log-on security tokens (e.g., smart cards) are used to access the Host System, the security tokens must have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage. The PIN or password/passphrase must be at least ten alphanumeric characters in length, or equivalent.
4D-2.3 If log-on security tokens (e.g., smart cards) are used to access the Host System, the security tokens must have an associated usage-authentication mechanism, such as a biometric or associated PIN or password/passphrase to enable their usage. The PIN or password/passphrase must be at least ten alphanumeric characters in length, or equivalent.
Modified
p. 102
4D-2.4.b Inspect Host 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.
4D-2.4.b Examine Host 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.
Modified
p. 103
• auditing of host functions 4D-2.5.b Inspect the Host System configuration settings to verify that role-based access control is enforced and the following roles, at a minimum, are defined:
• auditing of host functions 4D-2.5.b Examine the Host System configuration settings to verify that role-based access control is enforced and the following roles, at a minimum, are defined:
Modified
p. 103 → 104
4D-2.6.1.b Interview audit personnel to verify that a Host System user is not permitted to audit their own activity on the Host System.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2.6.1 (continued) 4D-2.6.1.b Interview audit personnel to verify that a Host System user is not permitted to audit their own activity on the Host System.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-2.6.1 (continued) 4D-2.6.1.b Interview audit personnel to verify that a Host System user is not permitted to audit their own activity on the Host System.
Modified
p. 104
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures
4D-2.6.2 A Host System administrator must use their operator-level account when performing non- administrative functions.
Modified
p. 104
4D-2.6.2.a Review documented policies and procedures to verify a Host System administrator is not permitted to use their administrative-level account when performing non-administrative functions.
4D-2.6.2.a Examine documented policies and procedures to verify a Host System administrator is not permitted to use their administrative-level account when performing non-administrative functions.
Modified
p. 104
4D-2.7.c Inspect the Host System configuration settings and, for a sample of user accounts, verify that any changes to their access privileges have been formally documented in the audit log.
4D-2.7.c Examine the Host System configuration settings and, for a sample of user accounts, verify that any changes to their access privileges have been formally documented in the audit log.
Modified
p. 105
4D-2.9.a Review Host System documentation to verify that tamper detection mechanisms are defined for the Host System, including the generation of an alert upon opening of the Host System case, covers and/or doors.
4D-2.9.a Examine Host System documentation to verify that tamper detection mechanisms are defined for the Host System, including the generation of an alert upon opening of the Host System case, covers and/or doors.
Modified
p. 105
4D-2.9.c Review records of alerts and interview personnel to verify an alert is generated upon opening of the Host System, covers and/or doors.
4D-2.9.c Examine records of alerts and interview personnel to verify an alert is generated upon opening of the Host System, covers and/or doors.
Modified
p. 105
4D-3.1 All non-console access to the Host System must use strong cryptography and security protocols 4D-3.1.a For a sample of systems that are authorized to connect to the Host System via a non-console connection, inspect configuration settings to verify that access to the Host System is provided through the use of strong cryptography and security protocols 4D-3.1.b Inspect the configuration settings of system components to verify that all traffic transmitted over the secure channel uses strong cryptography.
4D-3.1 All non-console access to the Host System must use strong cryptography and security protocols 4D-3.1.a For a sample of systems that are authorized to connect to the Host System via a non-console connection, examine configuration settings to verify that access to the Host System is provided through the use of strong cryptography and security protocols.
Modified
p. 105
4D-3.2 Non-console access to the Host System must not provide access to any other service, or channel, outside of that used to connect to the Host, e.g., “split tunneling.” 4D-3.2.a Inspect the configuration settings of the secure channel, to verify that split tunneling is prohibited.
4D-3.2 Non-console access to the Host System must not provide access to any other service, or channel, outside of that used to connect to the Host, e.g., “split tunneling.” 4D-3.2.a Examine the configuration settings of the secure channel, to verify that split tunneling is prohibited.
Modified
p. 105
4D-3.3.a Inspect the configuration settings of the Host System and/or the device permitted to connect to the Host System, to verify that multi-factor authentication is required for non-console access to the Host System.
4D-3.3.a Inspect the configuration settings of the Host System and/or the device permitted to connect to the Host System to verify that multi-factor authentication is required for non-console access to the Host System.
Removed
p. 106
4D-3.5 Verify that non-console access to the Host System is only permitted from a PCI DSS compliant environment, including 4D-3.5.1 through 4D-3.5.2 Review solution provider documentation, including data-flow diagrams, and perform the following:
Modified
p. 106
4D-3.4.a Examine documented policies and procedures to verify that a process is defined to authorize systems for non-console access, and not permit access until such times that authorization has been granted.
4D-3.4.a Examine documented policies and procedures to verify that a process is defined to authorize systems for non-console access and not permit access until such times that authorization has been granted.
Modified
p. 106
4D-3.5.1 Review solution provider documentation, including PCI DSS ROC and/or Attestation of Compliance (AOC), data-flow diagrams, policies and, system configuration standards, to verify that the system authorized for non-console access meets all applicable PCI DSS requirements.
4D-3.5.1 Examine documentation, including PCI DSS ROC and/or Attestation of Compliance (AOC), data-flow diagrams, policies, and system configuration standards, to verify that the system authorized for non-console access meets all applicable PCI DSS requirements.
Modified
p. 106
• Meet all applicable PCI DSS requirements 4D-3.5.2 Review solution provider documentation, including PCI DSS ROC and/or Attestation of Compliance (AOC), data-flow diagrams, policies and, system configuration standards, to verify that the network/system that facilitates non-console access to the Host System must:
• Meet all applicable PCI DSS requirements 4D-3.5.2 Examine documentation, including PCI DSS ROC and/or Attestation of Compliance (AOC), data-flow diagrams, policies, and system configuration standards, to verify that the network/system that facilitates non-console access to the Host System must:
Modified
p. 106
4D-3.7.a Review documented policies and procedures to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
4D-3.7.a Examine documented policies and procedures to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
Modified
p. 106
4D-3.7.b Inspect the system configuration settings to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
4D-3.7.b Examine the system configuration settings to verify that the system parameters are set to terminate non-console sessions after 15 minutes of inactivity.
Modified
p. 107
- Logs of access to the room from a manual sign-in sheet (continued on next page) 4D-4.3.a Examine documented policies and procedures to verify all physical access to the secure room must be monitored and logs must be maintained. Policies and procedures must require the following:
Modified
p. 107
- Access to the room from a manual sign-in sheet
Removed
p. 108
(continued on next page) 4D-4.6.a Inspect CCTV configuration and review a sample of recordings to verify that CCTV monitoring is in place on a 24-hour basis, and covers, as a minimum, the following areas:
Modified
p. 108
- Access to the room from a manual sign-in sheet 4D-4.3.c Interview personnel responsible for reviewing logs used to record physical access to the secure room to verify the following:
Modified
p. 108
4D-4.4.a Inspect physical access controls to verify that dual access is enforced.
4D-4.4.a Examine physical access controls to verify that dual access is enforced.
Modified
p. 108 → 109
4D-4.6 The secure room must be monitored via CCTV on a 24-hour basis. This must include, as a minimum, the following areas:
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.6 The secure room must be monitored via CCTV on a 24-hour basis. This must include, as a minimum, the following areas:
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.6 The secure room must be monitored via CCTV on a 24-hour basis. This must include, as a minimum, the following areas:
Modified
p. 108 → 109
• All entrances and exists
• All entrances and exits
Removed
p. 109
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.6 (continued)
• All entrances and exists
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.6 (continued)
• All entrances and exists
Modified
p. 109
4D-4.6.b If CCTV is motion-activated, observe system configurations for the motion- activated systems to verify they are separate from the intrusion-detection system.
• Access to the Host System and HSM(s) 4D-4.6.b If CCTV is motion-activated, observe system configurations for the motion- activated systems to verify they are separate from the intrusion-detection system.
Modified
p. 109
4D-4.7 Surveillance cameras must not be configured to allow the monitoring of computer screens, keyboards, PIN pads, or other systems which may expose sensitive data.
4D-4.7 Surveillance cameras must not be configured to allow the monitoring of computer screens, keyboards, PIN pads, or other systems that may expose sensitive data.
Modified
p. 109
4D-4.7 Observe CCTV camera positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any computer screens, PIN pads, keyboards, or other systems which may expose sensitive data.
4D-4.7 Observe CCTV camera positioning and examine a sample of recordings to verify that CCTV cameras do not monitor any computer screens, PIN pads, keyboards, or other systems that may expose sensitive data.
Modified
p. 109
4D-4.9.b Examine access lists for the secure room as well as access controls to the media containing surveillance data, to verify that personnel with access to the secure room do not have access to the media containing recorded surveillance data 4D-4.10 Continuous or motion-activated, appropriate lighting must be provided for the cameras.
4D-4.9.b Examine access lists for the secure room as well as access controls to the media containing surveillance data, to verify that personnel with access to the secure room do not have access to the media containing recorded surveillance data.
Modified
p. 110
4D-4.14 Inspect uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems are powered through the UPS.
4D-4.14 Examine uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems are powered through the UPS.
Removed
p. 111
• A door that is contact monitored and fitted with automatic closing or locking devices.
• An airlock entrance system.
• An airlock entrance system.
Modified
p. 111
- A door that is contact monitored and fitted with automatic closing or locking devices.
Modified
p. 111
- An airlock entrance system.
Modified
p. 111 → 112
4D-4.21 An audible alarm must sound if the entrance to the secure room remains open for more than 30 seconds.
Requirement 4D: Implement secure hybrid decryption process
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.21 An audible alarm must sound if the entrance to the secure room remains open for more than 30 seconds.
• Applicable for hybrid decryption environments only Domain 4 Requirements Testing Procedures 4D-4.21 An audible alarm must sound if the entrance to the secure room remains open for more than 30 seconds.
Removed
p. 112
• Details of any suspicious activity that occurred, per 4C-1.2 4E-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component- provider personnel, and to confirm that the following processes are documented and implemented:
Modified
p. 112
4E-1.1 Track status of the decryption-management service and provide reports to solution provider annually and upon significant changes, including at least the following:
4E-1.1 Component Providers must track the status of the decryption-management service and provide reports to solution providers annually and upon significant changes, including at least the following:
Modified
p. 112 → 113
• Details of any suspicious activity that occurred, per 4C-1.2
• Details of any suspicious activity that occurred, per 4C-1.2 4E-1.2 Component Providers must manage and monitor changes to decryption-management services and notify solution providers upon occurrence of any of the following:
Removed
p. 113
Requirement 4E: Component providers ONLY: report status to solution providers Domain 4 Requirements Testing Procedures 4E-1.2 Manage and monitor changes to decryption- management services and notify the solution provider upon occurrence of any of the following:
Modified
p. 113
• Addition and/or removal of HSM types.
• Addition and/or removal of HSM types
Modified
p. 113
4E-1.2.a Review component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include notifying the solution provider upon occurrence of the following:
4E-1.2.a Examine component provider’s documented procedures and interview responsible component-provider personnel, and confirm that processes include notifying the solution provider upon occurrence of the following:
Modified
p. 113
• Additions and/or removal of HSM types.
• Additions and/or removal of HSM types
Modified
p. 114
Target Audience: P2PE solution providers or those who, on behalf of P2PE solution providers, manage cryptographic key operations for POI devices, HSMs, and SCDs.
Target Audience: P2PE solution providers or those who, on behalf of P2PE solution providers, manage cryptographic key operations for PTS POI devices, HSMs, and SCDs.
Modified
p. 115
When used in connection with vendor-operated PKIs used for remote key loading using asymmetric techniques. This applies specifically to the distribution of acquirer keys to transaction-originating devices (POIs) for use in connection with account-data encryption, whether the actual distribution of acquirer keys occurs from the transaction-processing host or is distributed directly by the vendor. This includes:
§ When used in connection with vendor-operated PKIs used for remote key loading using asymmetric techniques. This applies specifically to the distribution of acquirer keys to PTS POI devices for use of account-data encryption, whether the actual distribution of acquirer keys occurs from the transaction-processing host or is distributed directly by the vendor. This includes:
Modified
p. 115
- Root and Subordinate Certification Authority keys and keys used in connection with associated Registration Authority activities - Device-specific key pairs used for that purpose - Keys associated with protection of the aforementioned keys during storing, loading, and usage - The generation of the aforementioned keys § When used in connection with KIF activities for loading and/or distribution of acquirer keys to PTS POI devices for use of account-data encryption.
Modified
p. 115
When used for the protection of account data when conveyed between non-integrated PCI-listed POI devices•e.g., an SCR and a PIN pad.
§ When used for the protection of account data when conveyed between non-integrated PCI-listed PTS POI devices•e.g., an SCR and a PIN pad.
Modified
p. 116
Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key- distribution using asymmetric techniques for the distribution of keys to POI devices for use in connection with account-data encryption. If the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control andkey-loading device(s)
•even if these systems involve the use of certificates, the remote key-establishment and distribution applications requirements will not apply. “Remotely” means whenever the …
•such as properly implemented dual control and
•even if these systems involve the use of certificates, the remote key-establishment and distribution applications requirements will not apply. “Remotely” means whenever the …
Characteristics of the actual key-distribution methodology implemented. These requirements apply to all entities implementing remote key- distribution using asymmetric techniques for the distribution of keys to PTS POI devices for use of account-data encryption. If the key loading is not performed remotely and authentication is provided by another method
•such as properly implemented dual control and key- loading device(s)
•even if these systems involve the use of certificates, the remote key-establishment and distribution applications requirements will not apply. “Remotely” means whenever the …
•such as properly implemented dual control and key- loading device(s)
•even if these systems involve the use of certificates, the remote key-establishment and distribution applications requirements will not apply. “Remotely” means whenever the …
Modified
p. 116
• The distribution of symmetric keys using asymmetric techniques from a key-distribution host (KDH) to many key-receiving devices (KRDs⎯i.e., POI devices); or
• The distribution of symmetric keys using asymmetric techniques from a key-distribution host (KDH) to many key-receiving devices (KRDs¾i.e., PTS POI devices); or
Modified
p. 117
Key-Injection Facilities The term key-injection facility (KIF) describes those entities that perform key injection of POI devices used for account-data encryption and key injection of HSMs used for decryption. Key injection may be performed by the solution provider or by a third party such as a POI terminal manufacturer or vendor. Domain 5 contains requirements that apply to key-injection facilities, or other entities that are performing KIF-related services for others, such as key generation or key loading.
Key-Injection Facilities The term key-injection facility (KIF) describes those entities that perform key injection of PTS POI devices used for account-data encryption and key injection of HSMs used for decryption. Key injection may be performed by the solution provider or by a third party such as a PTS POI terminal manufacturer or vendor. Domain 5 contains requirements that apply to key-injection facilities, or other entities that are performing KIF-related services for others, such as key generation or key loading.
Modified
p. 117
Key-injection systems that allow clear-text secret and/or private keys and/or their components to appear in unprotected memory (e.g., within a computer and outside of the secure boundary of a secure cryptographic device) are inherently less secure. Any such systems are subject to additional controls as delineated in the criteria in this domain.
Key-injection systems that allow cleartext secret and/or private keys and/or their components to appear in unprotected memory (e.g., within a computer and outside of the secure boundary of a secure cryptographic device) are inherently less secure. Any such systems are subject to additional controls as delineated in the criteria in this domain.
Modified
p. 118
Within this domain, the term “Solution Provider” refers to whichever entity is undergoing the P2PE assessment. This may be the solution provider, a component provider, or the merchant as a solution provider.
Note: Within this domain, the term “Solution Provider” refers to whichever entity is undergoing the P2PE assessment. This may be the solution provider, a component provider, or the merchant as a solution provider.
Modified
p. 118
For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 4, and 5 of this document refers to merchant personnel in the encryption environments, and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
For merchant-managed solutions, the term “merchant” as used within Domains 1, 3, 4, and 5 of this document refers to merchant personnel in the encryption environments and represents requirements the merchant as a solution provider is responsible for meeting for, or on behalf of, those merchant encryption environments.
Modified
p. 118
Note: An essential part of maintaining the security of POI devices and HSMs and the cryptographic keys used on those devices is for the solution provider to know where those devices and keys are•e.g., during key creation and loading onto devices, while being used at a merchant, when devices are undergoing repair, etc. Therefore, it is the responsibility of the entity managing devices and cryptographic keys to keep track of POI devices and HSMs from the point where the device …
Note: An essential part of maintaining the security of PTS POI devices and HSMs and the cryptographic keys used on those devices is for the solution provider to know where those devices and keys are•e.g., during key creation and loading onto devices, while being used at a merchant, when devices are undergoing repair, etc. Therefore, it is the responsibility of the entity managing devices and cryptographic keys to keep track of POI devices and HSMs from the point where the …
Modified
p. 119
• FIPS 140-2 or FIPS 140-3 Level 3 or higher certified, or
• FIPS 140-2 or FIPS 140-3 Level 3 (overall) or higher certified, or
Modified
p. 119
• PCI PTS HSM approved Note 1: HSM approval listings must be current¾HSMs must have a non-expired PCI PTS HSM approval or a non-expired FIPS 140-2 or FIPS 140-3 certificate (i.e., the FIPS 140 HSM certificates must not be listed as historical or revoked).
Modified
p. 119
Note 2: 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.
Modified
p. 119
Note 3: Key-injection platforms and systems must include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs. This includes SCDs used in key-injection facilities (e.g., modified PEDs). A PED used for key injection must be validated and approved to the KLD approval class.
Modified
p. 119
1-3 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 For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and the list of approved devices to verify that all HSMs are either:
Modified
p. 119
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or FIPS 140-3 Level 3, or higher. Refer http://csrc.nist.gov.
• Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or FIPS 140-3 Level 3 (overall), or higher. Refer to http://csrc.nist.gov.
Modified
p. 119
• Listed on the PCI SSC website, with a valid SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Refer to https://www.pcisecuritystandards.org.
• Listed on the PCI SSC website, with a valid PCI SSC reference number, as Approved PCI PTS Devices under the approval class “HSM.” Refer to https://www.pcisecuritystandards.org.
Modified
p. 120
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment 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:
• For PCI-approved HSMs, any applications, including application version number, resident within the device which were included in the PTS assessment
Modified
p. 120
• The PCI PTS HSM number
• The PCI PTS approval number
Modified
p. 121
• Maintain current documentation that describes or illustrates the architecture of the KIF, including all KIF functionality.
• Maintain current documentation that describes and/or illustrates the architecture of the KIF, including all KIF functionality.
Modified
p. 121
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.a Interview personnel and examine documentation to verify that procedures exist for maintaining documentation that describes and/or illustrates the architecture of the KIF.
Modified
p. 121
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.b Interview 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.
Modified
p. 121
• Documentation shows all key-management flows across functions and networks from the point the key is generated through to the point the key is injected into the POI.
• Documentation shows all key-management flows across functions and networks from the point the key is generated through to the point the key is injected into the PTS POI device.
Modified
p. 121
• Documentation is kept current and updated as needed upon changes to the KIF architecture
• Documentation is kept current and updated as needed upon changes to the KIF architecture.
Modified
p. 122
• An approved key-generation function of a PCI- approved HSM or POI device
• An approved key-generation function of a PCI- approved HSM or PTS POI device
Modified
p. 122
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.
Note: Random number generation is critical to the security and integrity of all cryptographic systems. All 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:
Modified
p. 122
• An approved key-generation function of a PCI-approved HSM or POI device
• An approved key-generation function of a PCI-approved HSM or PTS POI device
Modified
p. 122
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.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:
Modified
p. 122
• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22 5-1.c Examine procedures to be used for future generations and logs of past key generation to verify devices used for key-generation are those as noted above, including validation of firmware used.
• An SCD that has an approved random number generator that has been certified by an independent qualified laboratory according to NIST SP 800-22
Removed
p. 123
6-1 Perform the following:
Modified
p. 123 → 124
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 Any cleartext output of the key-generation process must be managed under dual control. Only the assigned custodian can have direct access to the cleartext of any key component/share. Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.
Modified
p. 123 → 124
• Any key-generation process with clear-text output is performed under dual control
• Any key-generation process with cleartext output is performed under dual control
Modified
p. 123 → 124
• Any output of a clear-text component or share is overseen by only the assigned key custodian(s) for that component/share
• Any output of a cleartext component or share is overseen by only the assigned key custodian(s) for that component/share
Modified
p. 123 → 124
• 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.
• Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian, and not the entire key.
Modified
p. 123 → 124
• Any key-generation process with clear-text output is performed under dual control.
• Any key-generation process with cleartext output is performed under dual control.
Modified
p. 123 → 124
• Any output of clear-text component or share is overseen by only the assigned key custodian(s) for the component/share.
• Any output of cleartext component or share is overseen by only the assigned key custodian(s) for the component/share.
Modified
p. 123 → 124
• 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.
• Each custodian’s access to cleartext output is limited to the individual component(s)/share(s) assigned to that custodian and not the entire key.
Modified
p. 123 → 124
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.
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 cleartext key or all the components for a key.
Modified
p. 123 → 124
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.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 cleartext key or all the components for a key.
Modified
p. 124 → 125
• Key-generation devices that generate clear-text key components are powered off when not in use or require re-authentication whenever key generation is invoked; or
• Key-generation devices that generate cleartext key components are powered off when not in use or require re-authentication whenever key generation is invoked; or,
Modified
p. 124 → 125
6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (e.g., 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.
6-1.4 Key-generation equipment used for generation of cleartext key components must not show any signs of tampering (e.g., unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a cleartext 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.
Modified
p. 124 → 125
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.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 cleartext key or key component (e.g., a tapping device).
Modified
p. 124 → 125
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).
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 cleartext key or key component (e.g., a tapping device).
Modified
p. 124 → 125
6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during key-generation processes where clear-text keying material is in use. It must not be feasible to observe any clear-text keying material either directly or via camera monitoring.
6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during key-generation processes where cleartext keying material is in use. It must not be feasible to observe any cleartext keying material either directly or via camera monitoring.
Removed
p. 125
For example, it is not permitted for the cryptographic key to be passed through the memory of a computer unless it has been specifically tasked for the sole purpose of key generation/loading. Computers that have been specifically purposed and used solely for key generation/loading are permitted for use if all other requirements can be met, including those of Requirement 5 and the controls defined in Requirement 13.
Note: See Requirement 5 and Requirement 13 6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
6-2.b Observe the generation process and examine documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary …
Note: See Requirement 5 and Requirement 13 6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
6-2.b Observe the generation process and examine documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary …
Modified
p. 125 → 126
Note: This requirement excludes from its scope computers used only for administration of SCDs, or key-generation devices that do not have the ability to access cleartext cryptographic keys or components.
Modified
p. 125 → 126
Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected directly from a secure port on the key-generating SCD to the target (e.g., a POI device) meet this requirement. Where the components pass through memory of the PC, Requirement 13 must be met.
Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected 6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any cleartext secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
Modified
p. 125 → 127
6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, verify that either:
6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, examine, observe, and interview as needed to verify that:
Modified
p. 125 → 127
• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device), or
• Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device) 6-3 Printed key components must be protected against compromise. Key components must be printed in a way that prevents observation by any party other than the 6-3.a Examine documented procedures for printed key components and verify the requirement is satisfied.
Removed
p. 126
• Only approved key custodians can observe the key component.
• Only approved key custodians can observe the key component.
• Tampering can be visually detected.
• Tampering can be visually detected.
6-3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed in tamper- evident and authenticable packaging immediately after printing such that:
6-3.b Observe blind mailers, tamper-evident and authenticable packaging, or other sealed containers used for key components to verify that components cannot be read from within and that tampering can be visually detected.
6-3.c Observe processes for printing key components to verify that:
• Key components are printed within blind mailers or sealed in tamper-evident and authenticable packaging (that is able to be authenticated) immediately after printing, such that no one but the authorized custodian ever has physical access to the output;
• Printers are not networked; and
• Printers used for this …
• Only approved key custodians can observe the key component.
• Tampering can be visually detected.
• Tampering can be visually detected.
6-3.a Examine documented procedures for printed key components and verify that they require printed key components to be printed within blind mailers or sealed in tamper- evident and authenticable packaging immediately after printing such that:
6-3.b Observe blind mailers, tamper-evident and authenticable packaging, or other sealed containers used for key components to verify that components cannot be read from within and that tampering can be visually detected.
6-3.c Observe processes for printing key components to verify that:
• Key components are printed within blind mailers or sealed in tamper-evident and authenticable packaging (that is able to be authenticated) immediately after printing, such that no one but the authorized custodian ever has physical access to the output;
• Printers are not networked; and
• Printers used for this …
Modified
p. 126 → 128
Note: Printed key components includes manual (handwritten) capture.
Note: This requirement includes manual (handwritten) capture.
Modified
p. 126 → 128
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.
6-3.1 Observe the secure room designated for printing cleartext key components to verify that the walls are made of solid materials and extend from floor to ceiling.
Modified
p. 127 → 129
• Enforces dual-access requirements for entry into the secure room, and anti-pass-back requirements.
• Enforces dual-access (i.e., the presence of at least two individuals) requirements for entry into the secure room, and anti-pass-back requirements.
Modified
p. 127 → 129
6-3.4 Inspect CCTV configuration and examine a sample of recordings to verify that CCTV monitoring includes 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.
6-3.4 Examine the CCTV configuration and a sample of recordings to verify that CCTV monitoring includes 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.
Modified
p. 127 → 129
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.
6-3.5 Examine 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.
Modified
p. 127 → 129
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.a Observe the location of the CCTV server and digital storage to verify they are located in a secure location that is separate from the secure room.
Modified
p. 127 → 129
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.
6-3.6.b Examine 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.
Modified
p. 127 → 130
6-3.7 Inspect CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:
6-3.7 Observe CCTV positioning and examine a sample of recordings to verify that CCTV cameras are positioned to monitor:
Removed
p. 128
6-4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted
Modified
p. 128 → 130
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.
6-3.8 Observe 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.
Modified
p. 128 → 131
Examples of where such key residue may exist include (but are not limited to):
• Printing material, including ribbons and paper waste
• Printing material, including ribbons and paper waste
Note: Examples of where such key residue may exist include (but are not limited to):
• Printing material, including ribbons and paper waste
• Printing material, including ribbons and paper waste
Modified
p. 128 → 131
• Any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation.
• Any residue that may contain cleartext keys or components is destroyed or securely deleted immediately after generation.
Modified
p. 128 → 131
• Any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation.
• Any residue that may contain cleartext keys or components is destroyed or securely deleted immediately after generation.
Modified
p. 130 → 133
• Faxing, e-mailing, or otherwise electronically conveying clear-text private or secret keys or components
• Faxing, e-mailing, or otherwise electronically conveying cleartext private or secret keys or components
Modified
p. 130 → 133
• Conveying clear-text private key shares or secret key components/shares without containing them within tamper-evident and authenticable packaging
• Conveying cleartext private key shares or secret key components/shares without containing them within tamper-evident and authenticable packaging
Modified
p. 130 → 133
• Conveying clear-text private key shares or secret key components/shares without containing them within tamper-evident and authenticable packaging
• Conveying cleartext private key shares or secret key components/shares without containing them within tamper-evident and authenticable packaging
Modified
p. 130 → 133
• Writing key or component values in procedure manuals 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:
• Writing key or component values in procedure manuals 6-6.a Examine documented policy and procedures to verify that they include language that prohibits transmitting cleartext private or secret keys or their components/shares across insecure channels, including but not limited to:
Modified
p. 130 → 133
• Faxing, e-mailing, or otherwise electronically conveying clear-text keys or components
• Faxing, e-mailing, or otherwise electronically conveying cleartext keys or components
Modified
p. 130 → 133
• Faxing, e-mailing, or otherwise electronically conveying clear-text keys or components
• Faxing, e-mailing, or otherwise electronically conveying cleartext keys or components
Modified
p. 130 → 133
• Writing key or component values in procedure manual 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:
• Writing key or component values in procedure manual 6-6.b Observe key-management processes to verify that cleartext private or secret keys or their components are not transmitted across insecure channels, including but not limited to:
Modified
p. 130 → 133
• Conveying clear-text private or secret key components without containing them within tamper-evident, authenticable packaging
• Conveying cleartext private or secret key components without containing them within tamper-evident, authenticable packaging
Modified
p. 132 → 135
Keys conveyed from a key-injection facility (including facilities that are device manufacturers) must be conveyed in compliance with these requirements. Such keys can include, but are not limited to:
• HSM master keys (e.g., MFKs) Keys conveyed from a key-injection facility (including facilities that are device manufacturers) must be conveyed in compliance with these requirements. Such keys can include, but are not limited to:
Removed
p. 133
• Confirm through observation, interview, and inspection of the records of past key transfers that the process used to transport clear-text key components using pre- numbered, tamper-evident, authenticable packaging, is sufficient to ensure:
Modified
p. 133 → 136
Cleartext key components/shares must be conveyed in SCDs or using tamper-evident, authenticable packaging.
Modified
p. 133 → 136
• Where key components are transmitted in clear-text using pre-numbered, tamper-evident, authenticable mailers:
• If key components are transmitted in cleartext using pre-numbered, tamper-evident, authenticable mailers:
Modified
p. 133 → 136
(continued on next page) 8-1.a Determine whether keys are transmitted encrypted, as clear-text components/shares, or within an SCD.
(continued on next page) 8-1.a Examine documentation and interview personnel (as needed) to determine whether keys are transmitted encrypted, as cleartext components/shares, and/or within an SCD. Carry out the additional testing procedures as applicable.
Modified
p. 133 → 136
8-1.b If key components are transmitted in clear-text using pre-numbered, tamper-evident, authenticable packaging, perform the following:
8-1.b If key components are transmitted in cleartext using pre-numbered, tamper-evident, authenticable packaging, perform the following:
Modified
p. 134 → 137
• Where SCDs are used for conveying components/shares, the mechanisms or data (e.g., PIN) to obtain the key component/share from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
• If SCDs are used for conveying components/shares, the mechanisms or data (e.g., PIN) to obtain the key component/share from the SCD must be conveyed using a separate communication from the SCD channel, or it must be conveyed in the same manner as a paper component. SCDs must be inspected for signs of tampering.
Modified
p. 134 → 137
• Where an SCD (i.e., HSM or KLD) is conveyed with pre-loaded secret and/or private keys, the SCD must require dual control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
• If an SCD (i.e., HSM or KLD) is conveyed with pre- loaded secret and/or private keys, the SCD must require dual control mechanisms to become operational. Those mechanisms must not be conveyed using the same communication channel as the SCD. SCDs must be inspected for signs of tampering.
Modified
p. 134 → 137
8-1.c Where SCDs are used to convey components/shares:
8-1.c If SCDs are used to convey components/shares:
Modified
p. 134 → 137
8-1.d Where an SCD is conveyed with pre-loaded secret and/or private keys, perform the following:
8-1.d If an SCD is conveyed with pre-loaded secret and/or private keys, perform the following:
Modified
p. 136 → 139
Other similar mechanisms, such as SMS, fax, or telephone must not be used to convey clear-text key values.
Other similar mechanisms, such as SMS, fax, or telephone must not be used to convey cleartext key values.
Modified
p. 136 → 139
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.
8-3 Interview personnel and examine logs to verify that e-mail, SMS, fax, telephone, or similar communication is not used as means to convey secret or private keys or key components/shares.
Modified
p. 137 → 140
8-4.b Validate that procedures dictate that self-signed certificates must not be used as the sole method of authentication.
8-4.b Examine documentation, interview personnel, and observe processes as needed to verify that self-signed certificates are not used as the sole method of authentication.
Removed
p. 138
9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single clear-text secret or private key component/share must at all times be either:
Modified
p. 138 → 141
Key components/shares conveyed to and from a key-injection facility (or applicable entity providing key-management services) must be conveyed in compliance with these requirements. Such key components/shares include but are not limited to those for key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf), or …
Key components/shares conveyed to and from a key-injection facility (or applicable entity providing key-management services) must be conveyed in compliance with these requirements. Such key components/shares include but are not limited to those for key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf), or …
Modified
p. 138 → 141
9-1 During the process to convey it, any single clear-text secret or private key component/share must at all times be either:
9-1 During the process to convey it, any single cleartext secret or private key component/share must at all times be either:
Modified
p. 138 → 141
• Sealed in a security container or courier mailer (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it and unauthorized access would be detected, or
• Sealed in a security container or courier mailer (including pre-numbered, tamper-evident, authenticable packaging) in such a way that it can be 9-1.a Examine documented procedures for transmission, conveyance, or movement of keys between any two locations to verify that any single cleartext secret or private key component/share must at all times be either:
Modified
p. 138 → 142
9-1.b Observe key-management processes, examine associated logs, and interview responsible personnel to verify processes implemented ensure that any single clear-text secret or private key component/share is at all times either:
9-1.b Observe key-management processes, examine associated logs, and interview responsible personnel to verify processes implemented ensure that any single cleartext secret or private key component/share is at all times either:
Modified
p. 138 → 142
• Sealed in a security container or courier mailer (including pre-numbered tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or contained within a physically secure SCD.
• Sealed in a security container or courier mailer (including pre-numbered tamper- evident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it or contained within a physically secure SCD.
Removed
p. 139
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.
Modified
p. 139 → 142
• Any keys encrypted under this (combined) key 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.
• Any keys encrypted under this (combined) key 9-2.a Examine documented procedures to verify they include requirements for all packaging or mailers containing cleartext key components to be examined for evidence of tampering before being opened.
Modified
p. 139 → 142
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.b Interview responsible personnel and observe processes to verify that all packaging or mailers containing cleartext key components are examined for evidence of tampering before being opened.
Modified
p. 139 → 142
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.c Examine 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:
Modified
p. 139 → 143
• Any keys encrypted under this (combined) key 9-3 Only an authorized key custodian⎯and designated backup(s)⎯must 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.
• Any keys encrypted under this (combined) key 9-3 Only an authorized key custodian¾and designated backup(s)¾must 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.
Modified
p. 139 → 143
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.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.
Removed
p. 140
• Observe the method used to transport clear-text key components using tamper-evident mailers, and interview responsible personnel to verify that details of the serial number of the package are transmitted separately from the package itself.
Modified
p. 140 → 143
9-4.a Verify that a list(s) of key custodians authorized to perform the following activities is defined and documented:
9-4.a Examine the list(s) of key custodians authorized to perform the following activities is defined and documented:
Modified
p. 140 → 144
9-5 Pre-numbered, tamper-evident, authenticable bags must 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.
9-5 Pre-numbered, tamper-evident, authenticable bags must be used for the conveyance of cleartext key components not in an SCD. Out-of-band mechanisms must be used to verify receipt of the appropriate bag numbers.
Modified
p. 140 → 144
9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of clear-text key components and perform the following:
9-5 Verify that pre-numbered, tamper-evident, authenticable bags are used for the conveyance of cleartext key components and perform the following:
Removed
p. 141
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:
Modified
p. 141 → 144
• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or PIN mailers) to prevent confusion and/or inadvertent observation when the package is opened.
• The components inside the tamper-evident and authenticable package are in separate opaque and identifiable packaging (e.g., individually sealed within labeled, opaque envelopes or PIN mailers) to prevent 9-6.a Examine documents, interview personnel, and observe processes as needed to verify that:
Modified
p. 141 → 144
• Records reflect the receipt of the shipped bag and association with subsequent individual bags 9-6.b Examine logs to verify that procedures are followed.
• Records reflect the receipt of the shipped bag and association with subsequent individual bags
Modified
p. 142 → 146
10-1.b Using the network schematic and the summary listing of cryptographic keys and through interview of personnel, identify keys that protect other keys for transmission. Consider keys manually transferred (e.g., cryptograms sent to an ESO) as well as those that are system-generated and transferred (e.g., KEK or TMK encrypting working keys).
10-1.b Examine documented procedures and interview personnel as needed to verify the requirement is satisfied for all applicable keys. Consider keys manually transferred (e.g., cryptograms sent to an ESO) as well as those that are system-generated and transferred (e.g., KEK or TMK encrypting working keys).
Modified
p. 143 → 147
TDEA keys are not be used to encrypt keys greater in strength than 112 bits.
TDEA keys are not used to encrypt keys greater in strength than 112 bits.
Modified
p. 144 → 148
11-1.a Verify documented procedures exist for all key transmission and conveyance processing.
11-1.a Observe documented procedures exist for all key transmission and conveyance processing.
Modified
p. 144 → 148
11-2 Verify documented procedures include all methods used for the conveyance or receipt of keys.
11-2 Observe documented procedures include all methods used for the conveyance or receipt of keys.
Removed
p. 145
(continued on next page) 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.
Modified
p. 145 → 149
Key-injection facilities (or applicable entities providing key-management services) must load keys using dual control and for clear-text secret and private keys, split knowledge. Such keys include, but are not limited to:
Key-injection facilities (or applicable entities providing key-management services) must load keys using dual control and for cleartext secret and private keys, split knowledge. Such keys include, but are not limited to:
Modified
p. 145 → 149
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.c Observe the key-loading processes for all key types (e.g., MFKs, AWKs, TMKs, DEKs, etc.). Verify the number and length of the key components against information provided through verbal discussion and written documentation.
Modified
p. 146 → 150
12-1.e Ensure key-loading devices can only be accessed and used under dual control.
12-1.e Observe key-loading devices can only be accessed and used under dual control.
Modified
p. 147 → 151
• Separate key-loading devices for each component/share (continued on next page) 12-3.a Identify instances where a key-loading device is used to load clear-text keys. Examine documented procedures for loading of clear-text cryptographic keys to verify:
• Separate key-loading devices for each component/share (continued on next page) 12-3.a Examine documented procedures for loading of cleartext cryptographic keys to verify:
Modified
p. 147 → 151
12-3.b For each type of production SCD loaded using a key-loading device, observe for the process (e.g., a demonstration) of loading clear-text cryptographic keys and interview personnel. Verify that:
12-3.b For each type of production SCD loaded using a key-loading device, observe for the process (e.g., a demonstration) of loading cleartext cryptographic keys and interview personnel. Verify that:
Removed
p. 148
Note: 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.
Modified
p. 148 → 152
Note 2: Passwords/authentication codes to the same object may be assigned to a custodian group team¾e.g., custodian team for component A.
Modified
p. 148 → 152
Note 3: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. A PED that has been modified to perform these functions must be validated and approved to the KLD approval class., 12-3.c Examine documented records of key-loading to verify the presence of two authorized persons during each type of …
Modified
p. 148 → 152
12-3.d Ensure that any default dual-control mechanisms (e.g., default passwords/authentication codes
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
12-3.d Observe that any default dual-control mechanisms (e.g., default passwords/authentication codes
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
•usually printed in the vendor's manual
•in a key-loading device) have been disabled or changed.
Modified
p. 148 → 152
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⎯e.g., via XOR‘ing of full-length components.
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¾e.g., via XOR‘ing of full-length components.
Modified
p. 148 → 152
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.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.
Modified
p. 148 → 152
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.
12-4.b 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.
Modified
p. 149 → 153
12-6 Thorough 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.
12-6 Examine documented procedures, interview personnel, and observe processes as needed to confirm that any devices that are loaded with the same key components use the same mathematical process to derive the final key.
Modified
p. 150 → 154
12-8.b If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, verify that the applicable requirements detailed in this Domain are met, including:
12-8.b If key-establishment protocols using public-key cryptography are used to remotely distribute secret keys, examine documented procedures, interview personnel, and observe processes as needed to verify that the applicable requirements detailed in this Domain are met, including:
Modified
p. 152 → 156
Some key-injection platforms use personal-computer (PC)-based software applications, whereby clear-text secret and/or private keys and/or their components exist in memory outside the secure boundary of an SCD for loading keys. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. These weaknesses include:
Some key-injection platforms use personal-computer (PC)-based software applications, whereby cleartext secret and/or private keys and/or their components exist in memory outside the secure boundary of an SCD for loading keys. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. These weaknesses include:
Modified
p. 152 → 156
• Clear-text keys and components can reside in software during the key-loading process.
• Cleartext keys and components can reside in software during the key-loading process.
Modified
p. 153 → 157
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of clear-text key components.
• Any cameras present in the environment must be positioned to ensure they cannot monitor the entering of cleartext key components.
Modified
p. 153 → 157
• The sending and receiving SCDs must be inspected prior to key loading to ensure that they have not been subject to any prior tampering or unauthorized modification that could lead to the disclosure of clear-text keying material.
• The sending and receiving SCDs must be inspected prior to key loading to ensure that they have not been subject to any prior tampering or unauthorized modification that could lead to the disclosure of cleartext keying material.
Modified
p. 153 → 157
• Ensure cameras are positioned to ensure they cannot monitor the entering of clear- text key components.
• Observe cameras are positioned to ensure they cannot monitor the entering of cleartext key components.
Modified
p. 153 → 157
The SCD is inspected to ensure it has not been subject to any prior tampering or unauthorized modification, which could lead to the disclosure of clear-text keying material.
The SCD is inspected to ensure it has not been subject to any prior tampering or unauthorized modification, which could lead to the disclosure of cleartext keying material.
Modified
p. 154 → 158
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. If a PED that has been modified to perform these functions has not been validated and approved to the KLD approval class, the PED must be managed in accordance with Requirement 13-9.
Note: The addition of applications that replace or disable the PCI-evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings. A PED that has been modified to perform these functions must be validated and approved to the KLD approval class.
Modified
p. 154 → 158
13-2.a Examine documentation to verify that only SCDs are used in the loading of clear- text secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, computer keyboards or keyboards attached to an HSM must never be used for the loading of clear-text secret or private keys or their components.
13-2.a Examine documentation to verify that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure key-loading facility, as delineated in this requirement. For example, computer keyboards or keyboards attached to an HSM must never be used for the loading of cleartext secret or private keys or their components.
Modified
p. 154 → 158
13-2.b Observe a demonstration of key loading to verify that only SCDs are used in the loading of clear-text secret or private keys or their components outside of a secure key- loading facility.
13-2.b Observe a demonstration of key loading to verify that only SCDs are used in the loading of cleartext secret or private keys or their components outside of a secure key- loading facility.
Modified
p. 155 → 159
13-4 For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device:
13-4 Secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device must meet the following requirements (13-4.1 through 13-4.8):
Modified
p. 155 → 159
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.
13-4.1 Examine documented procedures, interview personnel, and observe processes as needed to 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.
Modified
p. 156 → 160
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.
13-4.2 Examine documented procedures, interview personnel, and observe processes as needed to 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.
Modified
p. 156 → 160
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.a Examine documented procedures, interview personnel, and observe processes as needed to 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.
Modified
p. 156 → 160
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.
13-4.3.b Examine documented procedures, interview personnel, and observe processes as needed to 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.
Modified
p. 156 → 160
13-4.4 Verify the key-loading device does not retain any information that might disclose the key that was installed in the device 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.
13-4.4 Examine documented procedures, interview personnel, and observe processes as needed to verify the key-loading device does not retain any information that might disclose the key that was installed in the device 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.
Modified
p. 157 → 161
Key components that can be read (e.g., 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.
Key components that can be read (e.g., 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 cleartext to anyone who is not a designated custodian for that component.
Modified
p. 157 → 161
13-6 Validate through interview and observation that if components are in human-readable form, they are visible only to designated component custodians and only for the duration of time required for this person to privately enter the key component into an SCD.
13-6 If components are in human-readable form, examine documented procedures, interview personnel, and observe processes as needed to verify that they are visible only to designated component custodians and only for the duration of time required for this person to privately enter the key component into an SCD.
Removed
p. 158
13-9 Key-injection facilities that use PC-based key- loading software platforms or similar devices (e.g., modified PEDs) that allow clear-text secret and/or private keys and/or their components to exist in memory outside the secure boundary of an SCD must minimally implement the following additional controls:
Note: Effective 1 January 2021, entities engaged in key loading on behalf of others must not be allowed to use PC based key-loading methodologies where clear-text secret and/or private keying material appears in the clear in memory outside the secure boundary of an SCD.
Effective 1 January 2023, entities only performing key loading for devices for which they are the processor must no longer have this option.
13-9 Interview appropriate personnel and examine documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key-loading platform. Examine any logs of key loading.
Note: Effective 1 January 2021, entities engaged in key loading on behalf of others must not be allowed to use PC based key-loading methodologies where clear-text secret and/or private keying material appears in the clear in memory outside the secure boundary of an SCD.
Effective 1 January 2023, entities only performing key loading for devices for which they are the processor must no longer have this option.
13-9 Interview appropriate personnel and examine documentation to determine the procedures for key loading to POIs, key-loading devices, and HSMs that are part of the key-loading platform. Examine any logs of key loading.
Modified
p. 158 → 162
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.
Note: 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.
Removed
p. 159
• Standalone (i.e., without modems, not connected to a LAN or WAN, not capable of wireless connections, etc.);
• Dedicated to only the key-loading function (e.g., there must not be any other application software installed); and
• Located in a physically secure room meeting the criteria of Requirement 32-9 that is dedicated to key-loading activities.
13-9.1 For facilities using PC-based key-loading software platforms or similar devices, verify through interviews and observation that the platform is:
• Dedicated to only key loading
• Located in a physically secure room meeting the criteria of Requirement 32-9 that is dedicated to key loading activities 13-9.2 All hardware used in key loading (including the PC) must be managed under dual control. Key-injection must not occur unless there are minimally two individuals in the key-injection room at all times during the process. If a situation arises that would cause only one person to be in the room, all individuals must …
• Dedicated to only the key-loading function (e.g., there must not be any other application software installed); and
• Located in a physically secure room meeting the criteria of Requirement 32-9 that is dedicated to key-loading activities.
13-9.1 For facilities using PC-based key-loading software platforms or similar devices, verify through interviews and observation that the platform is:
• Dedicated to only key loading
• Located in a physically secure room meeting the criteria of Requirement 32-9 that is dedicated to key loading activities 13-9.2 All hardware used in key loading (including the PC) must be managed under dual control. Key-injection must not occur unless there are minimally two individuals in the key-injection room at all times during the process. If a situation arises that would cause only one person to be in the room, all individuals must …
Removed
p. 160
• Logs of access to the room from a badge-access system;
• Logs of access to the room from a manual sign- in sheet;
• User sign-on logs on the PC at the operating- system level;
• User sign-on logs on the PC at the application level;
• Logs of the device IDs and serial numbers that are loaded, along with the date and time and the individuals performing the key-injection;
• Video surveillance logs with a minimum retention period of 45 days.
13-9.3.a Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
• Retained for a minimum of three years.
• Regularly reviewed by an authorized person who does not have access to the room or to the PC.
• The reviews are documented.
13-9.3.b Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
• Logs include a minimum of:
− Access to the room from a …
• Logs of access to the room from a manual sign- in sheet;
• User sign-on logs on the PC at the operating- system level;
• User sign-on logs on the PC at the application level;
• Logs of the device IDs and serial numbers that are loaded, along with the date and time and the individuals performing the key-injection;
• Video surveillance logs with a minimum retention period of 45 days.
13-9.3.a Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
• Retained for a minimum of three years.
• Regularly reviewed by an authorized person who does not have access to the room or to the PC.
• The reviews are documented.
13-9.3.b Verify through interviews and observation that logs of key-loading activities are maintained and meet the following:
• Logs include a minimum of:
− Access to the room from a …
Removed
p. 161
13-9.4.2 The key-loading device is started from a powered-off position every time key- loading activities occur.
13-9.4.3 The software application must load keys without recording any clear-text values on portable media or other unsecured devices.
13-9.4.3 The software application loads keys without recording any clear-text values on portable media or other unsecured devices.
13-9.4.4 Clear-text keys must not be stored except within an SCD.
13-9.4.4 Clear-text keys are not stored except within an SCD.
13-9.4.5 The personnel responsible for the systems administration of the PC (e.g., a Windows administrator who configures the PC’s user IDs and file settings, etc.) must not have authorized access into the room
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or passwords/authentication codes to operate the key-injection application.
13-9.4.5 Personnel responsible for the systems administration of the PC do not have authorized access into the room
•i.e., they are escorted by authorized key-injection personnel
•and do not have …
13-9.4.3 The software application must load keys without recording any clear-text values on portable media or other unsecured devices.
13-9.4.3 The software application loads keys without recording any clear-text values on portable media or other unsecured devices.
13-9.4.4 Clear-text keys must not be stored except within an SCD.
13-9.4.4 Clear-text keys are not stored except within an SCD.
13-9.4.5 The personnel responsible for the systems administration of the PC (e.g., a Windows administrator who configures the PC’s user IDs and file settings, etc.) must not have authorized access into the room
•they must be escorted by authorized key-injection personnel
•and they must not have user IDs or passwords/authentication codes to operate the key-injection application.
13-9.4.5 Personnel responsible for the systems administration of the PC do not have authorized access into the room
•i.e., they are escorted by authorized key-injection personnel
•and do not have …
Removed
p. 162
13-9.4.8 All openings on the PC that are not used for key-injection are covered with security seals that are tamper-evident and serialized. The seals are recorded in a log, and the log is maintained along with the other key-loading logs in a dual-control safe. Verification of the seals must be performed prior to key-loading activities.
13-9.4.9 If the PC application reads or stores clear- text key components (e.g., BDKs or TMKs) from portable electronic media (e.g., smart cards), the media must be secured as components under dual control when not in use. The key components must be manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge.
Note: For DUKPT implementations, the BDK must be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key-injection facilities with PC …
13-9.4.9 If the PC application reads or stores clear- text key components (e.g., BDKs or TMKs) from portable electronic media (e.g., smart cards), the media must be secured as components under dual control when not in use. The key components must be manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge.
Note: For DUKPT implementations, the BDK must be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key-injection facilities with PC …
Modified
p. 163
Requirement 14: All hardware and access/authentication mechanisms (e.g., passwords/authentication codes) used for key loading or the signing of authenticated applications (e.g., for “whitelists”) must be managed under dual control.
Requirement 14: All hardware and access/authentication mechanisms (e.g., passwords/authentication codes) used for key loading must be managed under dual control.
Modified
p. 163
14-1 Any hardware and passwords/authentication codes used in the key-loading function or for the signing of authenticated applications 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.
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 cleartext keys or their components. This is not to imply that individual access authentication mechanisms must be managed under dual control.
Modified
p. 163
Note: Where key-loading is performed for POI devices, the secure environment as defined in Requirement 32-9 must additionally be met.
Note: Where key-loading is performed for PTS POI devices, the secure environment as defined in Requirement 32-9 must additionally be met.
Modified
p. 163
• Any hardware used in the key-loading function or for the signing of authenticated applications must be controlled and maintained in a secure environment under dual control.
• Any hardware used in the key-loading function must be controlled and maintained in a secure environment under dual control.
Modified
p. 163
• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function or for the signing of authenticated applications must be controlled and managed such that no single individual has the capability to enable key loading of clear-text keys or their components.
• Any resources (e.g., passwords/authentication codes and associated hardware) used in the key-loading function must be controlled and managed such that no single individual has the capability to enable key loading of cleartext keys or their components.
Modified
p. 163
• All hardware used in the key-loading function or for the signing of authenticated applications is controlled and maintained in a secure environment under dual control.
• All hardware used in the key-loading function is controlled and maintained in a secure environment under dual control.
Modified
p. 163
• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions and for the signing of authenticated applications are controlled and managed such that no single individual has the capability to enable key loading.
• All resources (e.g., passwords/authentication codes and associated hardware) used for key-loading functions are controlled and managed such that no single individual has the capability to enable key loading.
Modified
p. 163
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) or application-signing operations to ensure they have not been tampered with or compromised.
14-2 All cable attachments over which cleartext 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.
Modified
p. 163
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) or application-signing operations.
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).
Modified
p. 163
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) or application-signing operations.
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).
Removed
p. 164
14-4 Any physical tokens (e.g., brass keys or chip cards) used to enable key loading or the signing of authenticated applications must not be in the control or possession of any one individual who could use those tokens to load secret or private cryptographic keys or sign applications 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.
14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key loading or the signing of authenticated applications. 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 or sign applications under single control.
14-4.b Inspect locations and controls for physical tokens to …
14-4.a Examine documented procedures for the use of physical tokens (e.g., brass keys or chip cards) to enable key loading or the signing of authenticated applications. 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 or sign applications under single control.
14-4.b Inspect locations and controls for physical tokens to …
Modified
p. 164
14-3.a Observe key-loading and application-signing activities to verify that key-loading equipment usage is monitored.
14-3.a Observe key-loading activities to verify that key-loading equipment usage is monitored.
Modified
p. 164
14-3.b Verify logs of all key-loading and application-signing activities are maintained and contain all required information.
14-3.b Examine logs of all key-loading activities and verify that they are maintained and contain all required information.
Modified
p. 164
14-4.d Verify that access-control logs exist and are in use including notation of tamper- evident, authenticable bag numbers.
14-4.d Examine access-control logs and verify they are in use including notation of tamper- evident, authenticable bag numbers.
Modified
p. 164
14-4.e Reconcile storage contents to access-control logs.
14-4.e Examine documented procedures, interview personnel, and observe processes as needed to reconcile storage contents to access-control logs.
Modified
p. 164
14-5.a Verify that documented procedures require default passwords/authentication codes used to enforce dual-control mechanisms are changed.
14-5.a Examine documented procedures to verify they require default passwords/authentication codes used to enforce dual-control mechanisms are changed.
Modified
p. 164
14-5.b Verify that documented procedures exist to require that these passwords/authentication codes be changed when assigned personnel change.
14-5.b Examine documented procedures to verify they require that the passwords/authentication codes be changed when assigned personnel change.
Modified
p. 165
Requirement 15: The loading of keys or key components must incorporate a validation mechanism such that the authenticity of the keys is ensured and it can be ascertained that they have not been tampered with, substituted, or compromised.
Requirement 15: The loading of keys or key components must incorporate a validation mechanism such that the authenticity of the keys is ensured, and it can be ascertained that they have not been tampered with, substituted, or compromised.
Modified
p. 165
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 …
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 …
Modified
p. 165
15-1.c Verify that the methods used for key validation are consistent with ISO 11568•e.g., when check values are used, they are in accordance with this requirement.
15-1.c Examine the methods used for key validation to verify they are consistent with ISO 11568•e.g., when check values are used, they are in accordance with this requirement.
Modified
p. 167
• Verify the process ensures that key pairs are unique per POI device.
• Observe the process to verify it ensures that key pairs are unique per PTS POI device.
Modified
p. 167 → 168
16-1.a Verify documented procedures exist for all key-loading operations.
16-1.a Examine documented procedures and verify they exist for all key-loading operations.
Modified
p. 168 → 169
• Generate or otherwise obtain key-check values for any key-encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host database. Cryptograms may be used for …
• Observe and/or test to Generate or otherwise obtain key-check values for any key- encipherment keys (KEKs) to verify key uniqueness between the two organizations. A random sample may be used where more than 10 zone connections are in use. This is not intended to be based on values retained on paper or otherwise sent as part of the original conveyance of the keying material, but rather on values generated from stored zone production keys from the production host database. …
Modified
p. 168 → 169
• Compare key-check values against those for known or default keys to verify that known or default key values are not used.
• Observe key-check values against those for known or default keys to verify that known or default key values are not used.
Modified
p. 169 → 170
18-1.a Verify procedures have been implemented for monitoring and alerting to the presence of multiple cryptographic synchronization errors.
18-1.a Examine documented procedures to verify they have been implemented for monitoring and alerting to the presence of multiple cryptographic synchronization errors.
Modified
p. 169 → 170
18-1.b Verify that implemented procedures include:
18-1.b Examine and/or observe the implemented procedures include:
Modified
p. 169 → 170
18-2.a Verify that documented procedures 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 discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
18-2.a Examine the documented procedures to verify they 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 discarding and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
Modified
p. 170 → 171
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 January 2023.
• Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 January 2023 (past).
Modified
p. 170 → 171
• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 January 2025.
• Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 January 2025 (past).
Modified
p. 170 → 171
• A MAC computed over the concatenation of the clear- text attributes and the enciphered portion of the key block, which includes the key itself⎯e.g., TR-31;
• A MAC computed over the concatenation of the cleartext attributes and the enciphered portion of the key block, which includes the key itself.
Modified
p. 171 → 172
• POI devices only communicate with CAs for the purpose of certificate signing, or for key injection where the certificate-issuing authority generates the key pair on behalf of the device;
• PTS POI devices only communicate with CAs for the purpose of certificate signing, or for key injection where the certificate-issuing authority generates the key pair on behalf of the device;
Modified
p. 171 → 172
18-4.b Interview responsible personnel and observe POI configurations to verify that:
18-4.b Interview responsible personnel and observe PTS POI configurations to verify that:
Modified
p. 171 → 172
• POI devices only communicate with CAs for the purpose of certificate signing, or for key-injection where the certificate issuing authority generates the key pair on behalf of the device;
• PTS POI devices only communicate with CAs for the purpose of certificate signing, or for key-injection where the certificate issuing authority generates the key pair on behalf of the device;
Modified
p. 171 → 172
• POI devices only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking.
• PTS POI devices only communicate with KDHs or key management, normal transaction processing, and certificate (entity) status checking.
Modified
p. 171 → 172
18-5 KDHs must only communicate with POI devices for the purpose of key management and normal transaction processing, and with CAs for the purpose of certificate signing and certificate (entity) status checking.
18-5 KDHs must only communicate with PTS POI devices for the purpose of key management and normal transaction processing, and with CAs for the purpose of certificate signing and certificate (entity) status checking.
Modified
p. 171 → 172
• KDHs only communicate with POI devices for the purpose of key management and normal transaction processing;
• KDHs only communicate with PTS POI devices for the purpose of key management and normal transaction processing;
Modified
p. 173 → 174
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.
Modified
p. 173 → 174
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.
19-1.b Using a sample of device types, examine/observe check values, terminal definition files, etc. to verify that keys used for key encipherment are not used for any other purpose.
Modified
p. 175 → 176
19-4.d Compare check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.
19-4.d Examine/observe check, hash, cryptogram, or fingerprint values for production and test/development keys with higher-level keys (MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values.
Modified
p. 176 → 177
19-8 POI device private keys must not be shared between POI devices.
19-8 PTS POI device private keys must not be shared between PTS POI devices.
Modified
p. 176 → 177
19-8.b Inspect public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI device.
19-8.b Examine public key certificates on the host processing system to confirm that a unique certificate exists for each connected POI device.
Modified
p. 178 → 179
19-12.c If CA separation is used to ensure certificate segmentation, confirm that the following are true:
19-12.c If CA separation is used to ensure certificate segmentation, examine/observe as needed to verify that the following are true:
Modified
p. 179 → 180
19-12.d If policy-based certificate segmentation is used to ensure certificate segmentation, confirm that all of the following are true:
19-12.d If policy-based certificate segmentation is used to ensure certificate segmentation, examine/observe as needed to confirm that all of the following are true:
Modified
p. 179 → 180
19-12.e Confirm that the mechanisms in place are effective in restricting the certificates to a single purpose use as noted below:
19-12.e Examine/observe as needed to confirm that the mechanisms in place are effective in restricting the certificates to a single purpose use as noted below:
Removed
p. 180
20-2 If a POI device directly interfaces with more than one entity for decryption of account data (e.g., different acquiring organizations), the POI device must have a completely different and unique key or set of keys for each acquirer. These different keys, or sets of keys, must be totally independent and not variants of one another.
20-2.a Examine documented procedures for generating all types of keys and verify procedures exist to ensure that unique keys or sets of keys are used for each acquiring organization and totally independent and are not variants of one another.
20-2.b Interview personnel and observe key-generation processes to verify that unique keys or sets of keys will be generated for each acquiring organization when required.
20-2.c Intentionally left blank
20-2.a Examine documented procedures for generating all types of keys and verify procedures exist to ensure that unique keys or sets of keys are used for each acquiring organization and totally independent and are not variants of one another.
20-2.b Interview personnel and observe key-generation processes to verify that unique keys or sets of keys will be generated for each acquiring organization when required.
20-2.c Intentionally left blank
Modified
p. 180 → 181
20-1 POI devices must each implement unique secret and private keys for any function directly or indirectly related to account-data 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.
20-1 PTS POI devices must each implement unique secret and private keys for any function directly or indirectly related to account-data 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.
Modified
p. 180 → 181
This means not only the account-data-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.
Note: This means not only the account-data-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.
Modified
p. 181 → 182
This requirement refers to the use of a single “base” key to derive initial keys for many different POI devices, 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 the derivation of other keys once loaded•e.g., as done with DUKPT.
This requirement refers to the use of a single “base” key to derive initial keys for many different PTS POI devices, 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 the derivation of other keys once loaded•e.g., as done with DUKPT.
Modified
p. 181 → 182
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating POI device.
• Key derivation is performed prior to a key being loaded/sent to the recipient transaction-originating PTS POI device.
Modified
p. 181 → 182
20-3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device.
20-3.b Examine/observe to verify that derivation keys used to generate keys for multiple devices are never loaded into a PTS POI device.
Modified
p. 182 → 183
• Keys must be uniquely identifiable in all hosts and POI Devices⎯e.g., EPPs/PEDs. Keys must be identifiable via cryptographically verifiable means⎯e.g., through the use of digital signatures or key check values.
• Keys must be uniquely identifiable in all hosts and PTS POI Devices. Keys must be identifiable via cryptographically verifiable means¾e.g., through the use of digital signatures or key check values
Modified
p. 182 → 183
• Key pairs must be unique per POI device⎯e.g., EPPs and PEDs 20-6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including:
• Key pairs must be unique per PTS POI device 20-6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including:
Modified
p. 182 → 183
20-6.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, verify that:
20-6.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, examine/observe to verify that:
Modified
p. 182 → 183
• Key pairs used by POI devices are unique per device.
• Key pairs used by PTS POI devices are unique per device.
Modified
p. 183 → 184
Some key-injection platforms use personal-computer (PC)-based software applications or similar devices whereby clear-text secret and/or private keys and/or their components exist in memory outside the secure boundary of an SCD for loading keys. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. The exploitation of some of the weaknesses could be possible without collusion. Therefore, key-injection facilities that use PC-based key-loading software platforms whereby clear-text secret and/or private keys and/or their components …
Some key-injection platforms use personal-computer (PC)-based software applications or similar devices whereby cleartext secret and/or private keys and/or their components exist in memory outside the secure boundary of an SCD for loading keys. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. The exploitation of some of the weaknesses could be possible without collusion. Therefore, key-injection facilities that use PC-based key-loading software platforms whereby cleartext secret and/or private keys and/or their components …
Modified
p. 183 → 184
Note: Key-injection facilities may have clear-text keying material outside of an SCD when used within a secure room in accordance with Requirement 32.
Note: Key-injection facilities may have cleartext keying material outside of an SCD when used within a secure room in accordance with Requirement 32.
Modified
p. 183 → 184
Note for hybrid decryption solutions: Clear-text data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data.
Note for hybrid decryption solutions: Cleartext data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of decrypting account data.
Removed
p. 185
21-3.1.b Inspect any tamper-evident packaging used to secure key components
Modified
p. 185 → 187
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.
21-3.1 Key components that exist in cleartext 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.
Modified
p. 185 → 187
•and ensure that it prevents the determination of the key component without visible damage to the packaging.
21-3.1.b Examine 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.
•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.
Modified
p. 185 → 187
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.c Examine/observe cleartext key components to verify they do not exist in non- secure containers, such as databases or in software programs.
Modified
p. 185 → 187
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).
21-3.1.d Examine/observe to 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).
Modified
p. 185 → 187
21-3.2 Inspect each key component/share storage container and verify the following:
21-3.2 Examine/observe each key component/share storage container and verify the following:
Modified
p. 186 → 188
22-1 Verify documented procedures exist for replacing known or suspected compromised keys that include all of the following (22-1.1 through 22-1.5 below):
22-1 Examine documented procedures for replacing known or suspected compromised keys to verify they include all of the following (22-1.1 through 22-1.5 below):
Modified
p. 187 → 190
22-1.4.b Verify notifications include the following:
22-1.4.b Examine/observe notifications to verify they include the following:
Modified
p. 188 → 191
22-3 Through the examination of documented procedures, interviews and observation confirm that Root CAs provide for segmentation of risk to address key compromise.
22-3 Examine documented procedures, interview personnel, and observe processes to confirm that Root CAs provide for segmentation of risk to address key compromise.
Modified
p. 190 → 192
- Reissue and distribute certificates to affected parties, or
Modified
p. 190 → 192
- Reissues and distributes certificates to affected parties, or
Modified
p. 190 → 192
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.b Examine/observe as needed to verify that the following minimum key sizes exist for RSA keys or the equivalent for the algorithm used as defined in Annex C:
Modified
p. 190 → 192
• 2048 for KDHs and POI devices 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.
• 2048 for KDHs and POI devices 22-5.c Examine/observe as needed to verify that KDH keys expire every five years unless another mechanism exists to prevent the use of a compromised KDH private key.
Modified
p. 191 → 194
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.
Note: 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.
Modified
p. 191 → 194
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.
23-2.c Examine network schematics detailing transaction flows with the associated key usage and identification of the sources of the keys used to verify that variants of the MFK are not used external to the logical configuration that houses the MFK.
Modified
p. 192 → 194
Such transformations are only used to generate different types of key-encrypting keys from an initial key-encrypting key, or working keys with different purposes from another working key.
Such transformations are only used to generate different types of key-encrypting keys from an initial key-encrypting key or working keys with different purposes from another working key.
Modified
p. 192 → 195
24-1.a Verify documented procedures are in place for destroying secret or private keys, and their key components that are no longer used or that have been replaced by a new key.
24-1.a Examine documented procedures to verify they are in place for destroying secret or private keys, and their key components that are no longer used or that have been replaced by a new key.
Modified
p. 192 → 195
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.b Observe a sample of keys and key components to verify that they 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.
Modified
p. 193 → 195
For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder.
Note: For example, keys (including components or shares) maintained on paper must be burned, pulped, or shredded in a crosscut shredder.
Modified
p. 193 → 196
24-2.2.b Inspect key-destruction logs and verify that a third-party, non-key-custodian witness signs an affidavit as a witness to the key-destruction process.
24-2.2.b Examine key-destruction logs and verify that a third-party, non-key-custodian witness signs an affidavit as a witness to the key-destruction process.
Modified
p. 193 → 196
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.a Examine documented procedures to verify they include destroying key components of keys once the keys are successfully loaded and validated as operational.
Modified
p. 194 → 196
a) Limited on to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use;
a) Limited on to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use; and
Modified
p. 195 → 198
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.
Note: 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.
Modified
p. 196 → 199
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:
25-1.4.b For organizations that are such a small, modest size that they cannot support the reporting-structure requirement, examine documented procedures and observe they are followed to:
Modified
p. 198 → 202
25-5.1.a Examine documented procedures to verify that:
Modified
p. 200 → 203
• Success or failure of the event 25-6.3.c Examine a sample of application logs to verify they contain the following information:
• Success or failure of the event
Modified
p. 201 → 205
25-7.2.b Verify that IDS coverage includes all database servers, RA application servers and web servers, as well as the intervening segments.
25-7.2.b Examine/observe that IDS coverage includes all database servers, RA application servers and web servers, as well as the intervening segments.
Modified
p. 203 → 207
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.
25.8.8.b Examine 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.
Modified
p. 203 → 207
25.9.c If a manual process is defined, verify that the documented procedures require that it occur at least quarterly.
25.9.c If a manual process is defined, examine documented procedures to verify they require that it occur at least quarterly.
Modified
p. 205 → 209
Note for hybrid decryption solutions: Clear-text cryptographic keys used on the Host System must not be included in any system back-up (refer to Requirement 4D-1.14) 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.
Note for hybrid decryption solutions: Cleartext cryptographic keys used on the Host System must not be included in any system back-up (refer to Requirement 4D-1.14) 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.
Modified
p. 206 → 210
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 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:
Modified
p. 208 → 212
• Determination that the organization exists by using at least one third-party identity-proofing service or database or, alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization;
• organizational documentation issued by or filed with the applicable government agency or competent authority confirms the existence of the organization;
Modified
p. 208 → 212
• Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant’s representative to confirm that the person named as representative has submitted the certificate application.
• Confirmation by telephone, confirmatory postal mail, and/or comparable procedure to the certificate applicant’s representative to confirm that the person 28-5.a Examine documented procedures to verify that unless the certificate request is generated within the same secure room meeting the requirements of the Level 3 environment, they include validating the identity of the certificate requestor and recipient before issuing a digital certificate for the recipient’s associated public key.
Modified
p. 210 → 214
Note: Where POI is mentioned in Requirement 29, the requirements apply to the solution provider managing POI devices prior to deployment to distribution channels or to the merchants that will process payments with the POI device. Merchant protection and use of POI devices once deployed are not the subject of these P2PE requirements and are instead covered by guidance provided to merchants by the solution provider in the P2PE Instruction Manual (PIM). See the PIM Template for more information about …
Note: Where POI is mentioned in Requirement 29, the requirements apply to the solution provider managing PTS POI devices prior to deployment to distribution channels or to the merchants that will process payments with the POI device. Merchant protection and use of PTS POI devices once deployed are not the subject of these P2PE requirements and are instead covered by guidance provided to merchants by the solution provider in the P2PE Instruction Manual (PIM). See the PIM Template for more …
Modified
p. 211 → 215
Note: This applies to SCDs used for key injection or code signing, including display prompts.
Note: This also applies to SCDs used for key injection.
Modified
p. 211 → 215
• SCDs used for key-injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
• SCDs used for key-injection/loading have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 211 → 215
• SCDs used for key-injection/loading or code signing have not been substituted or subjected to unauthorized modifications or tampering.
• SCDs used for key-injection/loading have not been substituted or subjected to unauthorized modifications or tampering.
Modified
p. 212 → 216
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.
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.
Modified
p. 212 → 216
29-1.1.2 All personnel with access to POI devices 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 POI devices and other SCDs as authorized by management. The list of authorized personnel is reviewed at least annually.
29-1.1.2 All personnel with access to PTS POI devices 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 PTS POI devices and other SCDs as authorized by management. The list of authorized personnel is reviewed at least annually.
Modified
p. 212 → 216
29-1.2 POI devices and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords/authentication codes.
29-1.2 PTS POI devices and other SCDs must not use default keys or data (such as keys that are pre-installed for testing purposes) or passwords/authentication codes.
Modified
p. 213 → 217
Note: Chain of custody includes procedures, as stated in Requirement 29-1, that ensure that access to all POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
Note: Chain of custody includes procedures, as stated in Requirement 29-1, that ensure that access to all PTS POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
Modified
p. 213 → 217
29-2.c Verify that the chain-of-custody records identify responsible personnel for each interaction with the device.
29-2.c Examine the chain-of-custody records to verify they identify responsible personnel for each interaction with the device.
Modified
p. 214 → 218
• Upon tamper of the device it becomes infeasible to load any keying material.
• Upon tamper of the device, it becomes infeasible to load any keying material.
Modified
p. 216 → 220
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.
29-4.2 The security policy functionality 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.
Modified
p. 216 → 220
29-4.2.a Obtain and examine the defined security policy to be enforced by the HSM.
29-4.2.a Examine the defined security policy to be enforced by the HSM.
Modified
p. 216 → 221
Note: Examples of sensitive functions include but are not limited to: loading of key components, outputting clear-text key components, and altering HSM configuration.
Note: Examples of sensitive functions include but are not limited to: loading of key components, outputting cleartext key components, and altering HSM configuration.
Modified
p. 217 → 221
29-4.4.4 Maintaining records of the tests and inspections, and retaining records for at least one year.
29-4.4.4 Maintaining records of the tests and inspections and retaining records for at least one year.
Modified
p. 218 → 222
30-1 Not used in P2PE 30-2 Not used in P2PE 30-3 Processes must exist to ensure that key-injection operations are performed and reconciled on an inventory of pre-authorized devices.
30-1 Not used in P2PE 30-2 Not used in P2PE 30-3 Processes must exist to ensure that key-injection operations are performed and reconciled on a defined inventory of devices.
Modified
p. 220 → 224
Requirement 32: Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key, or signing applications to be loaded onto a POI device, must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following:
Requirement 32: Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key or signing applications to be loaded onto a POI device, must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following:
Modified
p. 220 → 224
32-1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, or for signing applications and/or whitelists to be loaded into POI devices, procedures must be documented and implemented to protect against unauthorized access and use.
32-1 For HSMs and other SCDs used for the generation or loading of cryptographic keys for use in POI devices, procedures must be documented and implemented to protect against unauthorized access and use.
Modified
p. 220 → 224
32-1.a Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices, or for signing applications and/or whitelists to be loaded into POI devices.
32-1.a Examine documented procedures to confirm that they specify protection against unauthorized access and use for HSMs and other devices used for the generation or loading of cryptographic keys for use in POI devices.
Modified
p. 221 → 225
• To place the device into a state that allows for the input or output of clear-text key components;
• To place the device into a state that allows for the input or output of cleartext key components;
Modified
p. 221 → 225
• To place the device into a state that allows for the input or output of clear- text key components;
• To place the device into a state that allows for the input or output of cleartext key components;
Modified
p. 222 → 227
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices
• Access to the physically secure, dedicated room housing the CA and RA database and application servers and cryptographic devices Level 1 Barrier 32-2.2 The entrance to the CA facility/building must include the following controls:
Modified
p. 225 → 229
For example, the Level 3 environment may be implemented within a “caged” environment.
Note: For example, the Level 3 environment may be implemented within a “caged” environment.
Modified
p. 226 → 230
For example: The Level 3 room is never occupied by one person except during the time of entry and/or exit, and the period for entry/exit does not exceed 30 seconds.
Note: For example: The Level 3 room is never occupied by one person except during the time of entry and/or exit, and the period for entry/exit does not exceed 30 seconds.
Modified
p. 229 → 233
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.
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 32-3.3.a Examine security system configurations to verify:
Modified
p. 229 → 234
32-3.3.b Verify the IDS and alarms function correctly via:
32-3.3.b Observe the IDS and alarms function correctly by:
Modified
p. 230 → 235
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.
32-5 Examine uninterruptible power source (UPS) system configurations to verify that all access-control and monitoring systems, including intrusion-detection systems, are powered through the UPS.
Modified
p. 230 → 235
32-6.1.b Determine who is authorized to sign off on alarm events.
32-6.1.b Observe who is authorized to sign off on alarm events.
Modified
p. 230 → 235
32-6.2.b Conduct a test to verify the mechanisms work appropriately.
32-6.2.b Test to verify the mechanisms work appropriately.
Modified
p. 231 → 236
32-6.3.c Conduct a test to verify the appropriate response occurs.
32-6.3.c Test to verify the appropriate response occurs.
Modified
p. 232 → 238
• When a KLD is used as an intermediate device to establish keys between POI devices and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection
• When a KLD is used as an intermediate device to establish keys between POI devices and a KIF HSM, it is not possible to insert an unauthorized SCD into the flow without detection 32-8.7 Mechanisms must exist to prevent a non-authorized host from injecting keys into POI devices or an unauthorized POI device from establishing a key with a legitimate KIF component.
Modified
p. 233 → 238
• Effective 1 January 2024 the injection of clear-text secret or private keying material must not be allowed for entities engaged in key injection on behalf of others. This applies to new deployments of POI v5 and higher devices. Subsequent to that date, only encrypted key injection will be allowed for POI v5 and higher devices.
• Effective 1 January 2024 the injection of cleartext secret or private keying material must not be allowed for entities engaged in key injection on behalf of others. This applies to new deployments of POI v5 and higher devices. Subsequent to that date, only encrypted key injection will be allowed for POI v5 and higher devices. (past)
Modified
p. 233 → 238
• Effective 1 January 2026, the same restriction applies to entities engaged in key injection of devices for which they are the processors. Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of clear-text keying material for POI v5 and higher devices.
• Effective 1 January 2026, the same restriction applies to entities engaged in key injection of devices for which they are the processors. Note: This does not apply to key components entered into the keypad of a secure cryptographic device, such as a device approved against the PCI PTS POI Security Requirements. It does apply to all other methods of loading of cleartext keying material for PTS POI v5 and higher devices.
Modified
p. 234 → 239
Note: In KIF environments where Level 1 and Level 2 physical barrier controls are in place and confirmed, the secure room may be implemented within a “caged” environment. A caged environment is an enclosed secure room that meets the criteria of Requirement 32 but is not made of solid walls. Refer to applicable requirements within this Domain for additional information on Level 1 and Level 2 physical barrier controls. All other criteria stated in Requirements 13-9 and 32-9 relating to …
Note: In KIF environments where Level 1 and Level 2 physical barrier controls are in place and confirmed, the secure room may be implemented within a “caged” environment. A caged environment is an enclosed secure room that meets the criteria of Requirement 32 but is not made of solid walls. Refer to applicable requirements within this Domain for additional information on Level 1 and Level 2 physical barrier controls. All other criteria stated in 32-9 relating to cleartext secret and/or …
Modified
p. 236 → 241
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 account-data processing devices placed into service, initialized, deployed, used, and decommissioned 33-1.b Verify that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.
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 account-data processing devices placed into service, initialized, deployed, used, and decommissioned 33-1.b Examine/observe that written records exist for the tests and inspections performed on devices before they are placed into service, as well as devices being decommissioned.
Removed
p. 237
5A-1.2.b Through observation of key-management operations and inspection of SCDs, verify that crypto-periods are defined for every type of key in use.
Modified
p. 237 → 242
See Domain 5 Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
Note: See Domain 5 Normative Annex C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms.
Modified
p. 237 → 242
5A-1.3 Documentation describing the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key-management solution must exist and must be demonstrably in use for all key-management processes.
5A-1.2.b [Removed] 5A-1.3 Documentation describing the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key-management solution must exist and must be demonstrably in use for all key-management processes.
Modified
p. 237 → 242
5A-1.3.a Verify documentation exists describing the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key- management solution.
5A-1.3.a Examine documentation to verify it describes the architecture (including all participating devices and cryptographic protocols), set-up and operation of the key- management solution.
Modified
p. 240 → 245
5H-1.2.b Verify, through the use of forensic tools and/or methods, that the mechanism used to erase the DDK from the host volatile memory, is sufficient to ensure the key cannot be recovered or reconstructed.
5H-1.2.b Test, through the use of forensic tools and/or methods, that the mechanism used to erase the DDK from the host volatile memory, is sufficient to ensure the key cannot be recovered or reconstructed.
Modified
p. 241 → 246
5H-1.5 Verify the encryption mechanism used to protect the DDK between the HSM and the Host System, includes 5H-1.5.1 through 5H-1.5.4.
5H-1.5 Examine/observe the encryption mechanism used to protect the DDK between the HSM and the Host System, includes 5H-1.5.1 through 5H-1.5.4.
Removed
p. 242
5H-1.5.4 The encryption key must have a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices 5H-1.5.4.a Examine documented key-management policies and procedures to verify that the encryption mechanism uses an encryption key that has a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices 5H-1.5.4.b Observe key-management processes to verify that the encryption mechanism uses an encryption key that has a defined cryptoperiod based on the volume of keys it transports and industry recommendations/best practices
Note: Adding, changing, or removing POI and/or HSM types, or critical key-management methods may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
5I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel …
Note: Adding, changing, or removing POI and/or HSM types, or critical key-management methods may require adherence to PCI SSC’s process for P2PE Designated Changes to Solutions. Please refer to the P2PE Program Guide for details about obligations when adding, changing, or removing elements of a P2PE solution.
5I-1.1.a Review component provider’s documented procedures for providing required reporting to applicable solution providers, and interview responsible component-provider personnel …
Modified
p. 243 → 248
5I-1.1 Track status of the deployed key-management services for POIs and HSMs, and provide reports to solution provider annually and upon significant changes, including at least the following:
5I-1.1 Track status of the deployed key-management services for PTS POI devices and HSMs, and provide reports to solution provider annually and upon significant changes, including at least the following:
Modified
p. 243 → 248
• Types/models of POIs and/or HSMs for which keys have been injected
• Types/models of PTS POIs and/or HSMs for which keys have been injected
Modified
p. 243 → 248
• For each type/model of POI and/or HSM:
• For each type/model of PTS POI devices and/or HSM:
Modified
p. 245 → 250
Algorithm TDEA (IFC) (ECDSA, ECDH, ECMQV) (DSA, DH, MQV) Minimum key size in number of bits 5 168 2048 224 2048/224 128 TDEA refers to TDEA (TDES) keys with non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. The DSA key sizes refer to the size of the …
Algorithm TDEA (IFC) (ECDSA, ECDH, ECMQV) (DSA, DH, MQV) AES Minimum key size in number of bits 5 168 2048 224 2048/224 128 TDEA refers to TDEA (TDES) keys with non-parity bits. The RSA key size refers to the size of the modulus. The Elliptic Curve key size refers to the minimum order of the base point on the elliptic curve; this order should be slightly smaller than the field size. The DSA key sizes refer to the size of …
Modified
p. 247 → 252
Some merchants may choose to manage their own P2PE solution on behalf of their own merchant encryption environments rather than fully outsourcing the solution to a third-party solution provider. This type of P2PE solution is defined as a “merchant-managed solution” since the merchant is acting as its own P2PE solution provider. This appendix specifies the additional requirements that must be met for a merchant- managed solution with the objective of reducing the presence of clear-text account data within their encryption …
Some merchants may choose to manage their own P2PE solution on behalf of their own merchant encryption environments rather than fully outsourcing the solution to a third-party solution provider. This type of P2PE solution is defined as a “merchant-managed solution” since the merchant is acting as its own P2PE solution provider. This appendix specifies the additional requirements that must be met for a merchant- managed solution with the objective of reducing the presence of cleartext account data within their encryption …
Modified
p. 248 → 253
Note: If a merchant outsources the decryption environment to a PCI-listed P2PE decryption-management component provider, this appendix would not apply for the merchant-managed solution, and use of a PCI-listed component provider would be noted in the merchant-as-a-solution- provider’s P2PE Report on Validation (P-ROV). If a merchant outsources the decryption environment to a non-listed decryption service provider, this appendix would also not apply and Domain 4 (covering the outsourced decryption services) would be assessed as part of the merchant-as- solution-provider’s P2PE …
Note: If a merchant outsources the decryption environment to a PCI-listed P2PE decryption-management component provider, this appendix will not apply for the merchant-managed solution, and use of a PCI-listed component provider would be noted in the merchant-as-a-solution-provider’s P2PE Report on Validation (P-ROV). If a merchant outsources the decryption environment to a non-listed decryption service provider, this appendix will also not apply, and Domain 4 (covering the outsourced decryption services) would be assessed as part of the merchant-as-solution- provider’s P2PE assessment …
Removed
p. 249
Note: The TMS environment is in scope for PCI DSS Merchant Store Cardholder Data Storage & Processing Payment Decryption Notes Note: This diagram is for illustrative purposes only. Other implementations are acceptable as long as they meet the requirements specified in this appendix.
Note: This diagram focuses on traffic flows related to P2PE transaction processing and may not may not show all relevant payment transaction traffic.
Note: This diagram focuses on traffic flows related to P2PE transaction processing and may not may not show all relevant payment transaction traffic.
Modified
p. 250 → 255
MM-A-1.1.a Interview responsible personnel and review documentation to verify that procedures exist for maintaining documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
MM-A-1.1.a Interview responsible personnel and examine documentation to verify that procedures exist for maintaining documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs.
Modified
p. 250 → 255
MM-A-1.1.b Interview responsible personnel and review merchant documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs to verify that the document is kept current.
MM-A-1.1.b Interview responsible personnel and examine merchant documentation that describes/illustrates the architecture of the merchant-managed P2PE solution, including the flow of data and cryptographic key exchanges, and interconnectivity between all systems within the encryption environment, the merchant decryption environment, and any other CDEs to verify that the document is kept current.
Modified
p. 250 → 255
MM-A-1.2.b Inspect network and system configurations to verify that decryption systems are located on a network that is dedicated to decryption operations.
MM-A-1.2.b Examine network and system configurations to verify that decryption systems are located on a network that is dedicated to decryption operations.
Modified
p. 251 → 256
MM-A-1.3.a Inspect network and system configuration settings to verify that only necessary services, protocols, daemons, etc. are enabled, and any functions not required for performing or supporting decryption operations are disabled or isolated from decryption operations.
MM-A-1.3.a Examine network and system configuration settings to verify that only necessary services, protocols, daemons, etc. are enabled, and any functions not required for performing or supporting decryption operations are disabled or isolated from decryption operations.
Modified
p. 251 → 256
MM-A-1.3.b Review the documented record of services, protocols, daemons, etc. that are required by the decryption systems and verify that each service includes justification.
MM-A-1.3.b Examine the documented record of services, protocols, daemons, etc. that are required by the decryption systems and verify that each service includes justification.
Modified
p. 251 → 256
MM-A-1.4.b Review system configurations and observe processes to verify that systems providing authentication services to system components within the decryption environment reside within the decryption environment and are dedicated to supporting the decryption environment.
MM-A-1.4.b Examine system configurations and observe processes to verify that systems providing authentication services to system components within the decryption environment reside within the decryption environment and are dedicated to supporting the decryption environment.
Modified
p. 252 → 257
MM-A-1.6 All remote access features on all systems in the merchant decryption environment must be permanently disabled and/or otherwise prevented from being used MM-A-1.6 Review system configurations and observe processes to verify that all remote access features on all systems within the merchant decryption environment are permanently disabled and/or otherwise prevented from being used.
MM-A-1.6 All remote access features on all systems in the merchant decryption environment must be permanently disabled and/or otherwise prevented from being used MM-A-1.6 Examine system configurations and observe processes to verify that all remote access features on all systems within the merchant decryption environment are permanently disabled and/or otherwise prevented from being used.
Modified
p. 252 → 257
MM-A-1.7.a Review configurations of all devices and systems in the merchant decryption environment to confirm none of the systems store account data.
MM-A-1.7.a Examine configurations of all devices and systems in the merchant decryption environment to confirm none of the systems store account data.
Modified
p. 252 → 257
MM-A-1.7.b Review data flows and interview personnel to verify that account data is not stored in the merchant decryption environment.
MM-A-1.7.b Examine data flows and interview personnel to verify that account data is not stored in the merchant decryption environment.
Modified
p. 252 → 257
MM-A-2.1 Review documentation and observe network configurations to verify that firewalls are in place between the merchant decryption environment and all other networks.
MM-A-2.1 Examine documentation and observe network configurations to verify that firewalls are in place between the merchant decryption environment and all other networks.
Modified
p. 252 → 257
MM-A-2.1.2.a Review firewall configuration standards to verify that inbound and outbound traffic necessary for performing and/or supporting decryption operations is identified and documented.
MM-A-2.1.2.a Examine firewall configuration standards to verify that inbound and outbound traffic necessary for performing and/or supporting decryption operations is identified and documented.
Modified
p. 253 → 258
MM-A-2.3.a Review document policies and procedures to verify that wireless connections to the decryption environment are prohibited.
MM-A-2.3.a Examine document policies and procedures to verify that wireless connections to the decryption environment are prohibited.
Modified
p. 254 → 259
MM-B-1.1.a Review documentation to verify that inbound and outbound traffic necessary for transaction processing and/or terminal management purposes is identified and documented.
MM-B-1.1.a Examine documentation to verify that inbound and outbound traffic necessary for transaction processing and/or terminal management purposes is identified and documented.
Modified
p. 254 → 259
MM-B-1.2 Processes must be implemented to prevent clear-text account data from being transmitted from the CDE back to the encryption environment.
MM-B-1.2 Processes must be implemented to prevent cleartext account data from being transmitted from the CDE back to the encryption environment.
Modified
p. 254 → 259
MM-B-1.2.a Review documented policies and procedures for the CDE to verify that the transmission of clear-text account data from the CDE back to the encryption environment is prohibited.
MM-B-1.2.a Examine documented policies and procedures for the CDE to verify that the transmission of cleartext account data from the CDE back to the encryption environment is prohibited.
Modified
p. 254 → 259
MM-B-1.2.b Observe processes and interview personnel to verify clear-text account data is prevented from being transmitted from the CDE back to the encryption environment.
MM-B-1.2.b Observe processes and interview personnel to verify cleartext account data is prevented from being transmitted from the CDE back to the encryption environment.
Modified
p. 254 → 259
MM-B-1.2.c Using forensic techniques, observe traffic between the encryption environment and the CDE to verify clear-text account data is not transmitted from the CDE back to the encryption environment.
MM-B-1.2.c Test, using forensic techniques, observe traffic between the encryption environment and the CDE to verify cleartext account data is not transmitted from the CDE back to the encryption environment.
Modified
p. 255 → 260
MM-C-1.1.b For a sample of system components in the CDE and the decryption environment, review system configurations and access-control lists to verify that encryption environment personnel do not have access to any system components in the decryption environment or the CDE.
MM-C-1.1.b For a sample of system components in the CDE and the decryption environment, examine system configurations and access-control lists to verify that encryption environment personnel do not have access to any system components in the decryption environment or the CDE.