Document Comparison

Table 2: Summary of Changes P2PE v2.0 P2PE v3.0 CHANGE TYPE Title The P2PE Standard has been renamed:

“Point-to-Point Encryption Solution Security Requirements and Testing Procedures” “Point-to-Point Encryption Security Requirements and Testing Procedures” Clarification Various Sections N/A All references to domain applicability relative to assessment responsibilities (e.g., which Domains each Component Provider Type must assess to) have been removed. This encompasses the following changes:

• "Alignment of P2PE Requirements with Entities Offering P2PE Services” section has been removed.

• “P2PE Solution and/or Component Validation Workflow at a Glance’ flowchart diagram has been removed.

• Appendix A, “P2PE Domain Responsibility Scenarios,” has been removed.

Restructure Entire Document

• All references to Domains were updated throughout the document as applicable based on the revised numbering of 1 through 5.

• Domain 4 for Merchant-managed Solutions has been moved to (replaced the existing) Appendix A. As a result, the Domains were renumbered, with Domain 5 becoming Domain 4 and Domain …

Clarification P2PE Solutions: Hardware Decryption or Hybrid Decryption Removed text box regarding Hardware/Hardware and Hardware/Hybrid.

SCD Domain Applicability

• Added context for FIPS 140-3, as well as clarified (by adding) context for software and whitelist signing.

• Added emphasis on scope of assessing an SCD.

Evolving and Clarification P2PE Solutions and Use of P2PE Applications and/or P2PE Non-payment Software Assessment and validation context removed and moved to Program Guide.

Removal and Restructure Alignment of P2PE Requirements with Entities Offering P2PE N/A Section has been removed and will be captured in the P2PE Program documents.

Removal and Restructure Relationship between P2PE and other PCI Standards Removed references to PA-DSS and added context for FIPS 140-3.

Removal and P2PE Program Guide

• Changed context of “Designated Change” to “Delta Change.”

• Added context regarding Merchant-managed solutions (MMS).

Evolving and Clarification At-a-glance P2PE Workflow and Implementation Diagrams

• Removed the diagram “P2PE Solution and/or Component Validation Workflow at a Glance.”

• Updated diagram “Example P2PE …

• Clarified (by adding) context regarding Domain 5 applying to SCDs used for signing non-payment software as well as the associated cryptographic keys and key management.

Clarification 1A-1.x, 1A-2.x Clarified scope regarding clear-text account data Clarification 1B-1.1

• Minor restructuring of requirement.

• Added context of POI vendor default passwords.

• Removed test procedure 1B-1.1.c.

• Removed test procedure 1B-3.2.c.

Clarification, Evolving, and Restructure Changed context of two-factor to multi-factor.

Added clarity to note regarding remote access to a terminal management system (TMS) or similar system.

Clarification 1B-2.4.x 1B-2.5x Renumbered as follows:

• 1B-2.4.2 to 1B-2.5.1

• 1B-2.4.3 to 1B-2.5.2 Restructure 1B-3.1 Clarified (by changing) context of “authentication” to “verification.” Clarification 1B-3.2

• Added a note listing the minimum elements of a “system build.”

Additional Guidance 1B-3.4 N/A Requirement removed. Removal 1B-3.5 1B-3.4 1B-3.5 renumbered to 1B-3.4. Restructure 1B-5.1 Test procedure 1B-5.1.c added. New 1C-1.1 N/A Requirement removed. Removal 1C-1.2x 1C-1.1x Requirements 1C-1.2 (and its sub-requirements) renumbered to 1C-1.1 and 1C-1.1.x.

• Clarified scope of clear-text account data.

Clarification 1C-2.x

• Clarified context by changing “application” to “non-payment software.”

• Clarified context of using an SCD for signing.

Clarification 1D-1.1 Modified note to account for the “Delta Change” process detailed in the Program Guide.

Clarification 1D-1.2.1 N/A Removed requirement. Removal 1D-1.2.2 1D-1.2.1 Renumbered 1D-1.2.2 to 1D-1.2.1. Restructure 1D-1.3 N/A Removed requirement. Removal 1D-1.4 1D-1.3 Renumbered 1D-1.4 to 1D-1.3. Restructure 1E-1.1 Clarified context of “merchant location.” Clarification Overview Revised note removing references to PA-DSS and clarifying intent.

2A-2.1, 2A-3.2 Clarified intent. Clarification 2B-1.1.1 Clarified test procedure 2B-1.1.1. Clarification 2B-4, 2B-4.1

• Removed Note under 2B-4.

• Added new note to 2B-4.1 and clarified intent of requirement.

Clarification, Additional Guidance N/A 2B-4.2 Added new Requirement 2B-4.2. New 2C-2.1.2 Clarified intent regarding use of an SCD. Clarification 3A-3.3 Added context of retention duration. Evolving 3A-4x N/A 3A-4 (including all sub-requirements) has been removed.

Restructure Domain 5 Domain 4

• Domain 4 is now “Domain 4: …

• Added context for FIPS 140-3.

• Therefore, Domain 5 now contains the entirety of what was in Domain 6 plus Annexes A and B. In addition, Annex A and Annex B have been removed and all the “unique” requirements in both Annexes are now in Domain 5.

• All the requirements from Domain 6 that are now in Domain 5 that originate from the PCI PIN Standard have been renumbered identically to match between the P2PE and PIN Standards.

Restructure Applicability of Domain 6 and Annexes to P2PE Solution Providers and N/A Table removed. Removal Definitions and Definitions and Annex

• Context regarding Annex A and Annex B has been removed.

Restructure 6B-1.1 5-1

• Clarified that key generation must occur within an SCD.

• Revised test procedure “c.” Clarification 6B-2.1.1 6-1.1 Clarified intent with revised wording. Clarification 6B-2.1.2 6-1.2 Clarified context of key generation and revised guidance in the note.

Clarification 6B-2.1.3 6-1.3 Modified requirement to …

Additional Guidance 6C-2 9 Clarified this requirement also applies to keys moved between locations of the same organization.

Clarification 6C-2.2 9-2 Clarified that key-compromise process involves both a documented analysis and confirmation.

Clarification N/A 9-6 Added requirement for when components or shares of multiple keys are being sent simultaneously between the same sending and receiving custodians.

6C-3.1 10-1

• Fixed error in v2.0 for double-length key context. Only triple-length keys are allowed as indicated in Annex C.

• Added an additional test procedure Clarification 6C-3.2 N/A Removed due to redundancy with 6C-3.1 (now 10-1). Removal 6C-3.3 N/A Removed due to redundancy with 6A-1.1 (now 5A- 1.1).

6D-1.1 12-1 Added new test procedure. New 6D-1.2 12-2 Added additional context to test procedure “a.” Evolving 6D-1.3 12-3

• Clarified that dual control includes use of separate key-loading devices for each component/share.

• Clarified that for devices that do not support two or more passwords/authentication codes, each half of the split …

• Added note regarding replacing or disabling firmware and modified PEDs being managed in accordance with 13-9.

• Added test procedure “b.” Additional Guidance, 6D-2.3 13-3 Added test procedure “c.” New 6D-2.4.1 13-4.1 Added note regarding PCI-approved KLDs. Additional Guidance 6D-2.4.2 13-4.2 Added note regarding insufficient means to meet the requirement.

Additional Guidance 6D-3.1 14-1 Added context of authentication codes. Clarification 6D-3.2 14-2 Clarified that 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).

Added two future dated restrictions:

• Effective 1 January 2021, the injection of clear- text secret or private keying material shall not be allowed for entities engaged in key injection on behalf of others. Only encrypted key injection shall be allowed for POI v3 and higher devices.

• Effective 1 January 2023, the same restriction applies to entities engaged in key injection of devices for which …

• 6E-2.5 in Annex B is now 18-5.

• 6E-2.5 in Annex A1 is now 18-7.

Restructure 6E-3.1 19-1 Added context regarding derivation keys. Evolving and Clarification 6E-3.2 19-2 Added context that private keys used for remote key distribution shall not be used in connection with any other purpose.

Clarification 6E-4.3 20-3 Added note to clarify that the same BDK with the same KSN installed in multiple injection systems or installed multiple times within the same injection system will not meet uniqueness requirements.

Clarification 6E-4.4 20-4 Revised test procedure. Clarification 6F-1 21 Added note to clarify that key-injection facilities may have clear-text keying material outside of an SCD when used within a secure room in accordance with Requirement 32.

Additional Guidance 6F-2 22 Added “key determined to be compromised” instead of “known or suspected compromise key.” Clarification 6F-2.1 22-1.3 Added clarification to existing note. Clarification 6F-5.1.4 25-1.4 Specified additional criteria for key custodians. Evolving 6F-6.1 …

• Certificates associated with encryption for remote key-distribution functions must not be used for any other purpose.

• Certificates associated with authentication of the KDH must not be used for any other purpose.

• Certificates associated with authentication of the POI must not be used for any other purpose.

• Certificates associated with authentication of POI firmware and POI applications must not be used for any other purpose.

Clarification 6F-1.4 21-4 Clarified context of using an SCD as well as key shares.

Clarification 6F-2.8 22-5 Updated requirement incorporating future dated requirement requiring 2048-bit RSA as the date is past.

6F-5.2 25-2 Clarified that individual user IDs may be assigned to a role or group.

Clarification Clarified where requirements apply to CAs operated online.

Clarification 6F-5-8.3 25-8.3 Added context for NIST SP800-63b. Evolving 6G-3.4 32-4 Modified to reflect that non-CA personnel must sign an access logbook when entering the Level 3 environment.

Clarification 6G-3.7.1 32-7.1 Added additional context regarding recording …

• Clarified that key-injection platforms and systems shall include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs. Modified PEDs that have not been validated to the PCI KLD approval class must be managed equivalent to personal computers as noted in Requirement 13-9.

Additional Guidance 6A-1.4 1-4 Added context of getting approval numbers as well as reviewing the approval listings for any implementation- specific notes.

6A-1.5 1-5 Clarified intent of requirement. Clarification 6C-3.1 10-1 Clarified that key-conveyance requirements apply to between locations or systems within the same key- injection facility.

Clarification 6D-2.9 13-9 Added sunset dates for allowed usage of PCs to load clear-text secret and/or private keys and/or their components where they exist in unprotected memory outside the secure boundary of an SCD. Specifically:

• Effective 1 January 2021, entities engaged in key loading on behalf of others shall not be allowed to use PC-based …