Document Comparison
PTS_Program_Guide_v2.1b.pdf
→
PTS_Program_Guide_v2.2.pdf
91% similar
74 → 75
Pages
24888 → 25952
Words
226
Content Changes
Content Changes
226 content changes. 78 administrative changes (dates, page numbers) hidden.
Added
p. 2
June 2025 2.2 Updated for Biometric Readers and third-party applications, Firmware Expiry, Expiry of Approval, Device Identifier, Model Name/Number, Expiry Date Table and Appendix B.
Added
p. 8
Figure 1. Life Cycle of PCI PTS POI Modular Security Requirements
Figure 2. Device Security Flow
Figure 2. Device Security Flow
Added
p. 21
To reinstate firmware that has expired, it is required to do a full evaluation against sections B and D of the DTRs, in addition to DTRs E10, E11, and E12. The evaluation test report shall state that this is a full evaluation for a previously-expired firmware version(s).
Added
p. 42
In addition, all available options and their functions
•both security and non-security relevant
•must be clearly defined and documented in the evaluation report. Security-relevant options must be exhaustively defined and documented in the security policy. For non-security options, the security policy must include a description of the option, but not a full list of all possible values.
•both security and non-security relevant
•must be clearly defined and documented in the evaluation report. Security-relevant options must be exhaustively defined and documented in the security policy. For non-security options, the security policy must include a description of the option, but not a full list of all possible values.
Added
p. 48
• A biometric-only reader Biometric Readers (BRs) approved as SCRs must implement logical protection.
Added
p. 51
Note: All newly-approved offline PIN verification POIs must support enciphered PIN verification. Cleartext offline PIN should also be supported until no longer required by those organizations that manage compliance programs (such as payment brands and acquirers).
The use of a device with components⎯e.g., EPPs, card readers⎯that are different than those listed as an approved component for that device invalidates that device’s approval. RAP devices may be listed as an approved component of one or more associated HSMs. For v4 and higher HSMs, the HSM must be validated to the “Remote-Managed HSM” requirements.
• Third-Party Applications POI v7 devices with the ‘third-party application’ feature notation on the PTS approval listing may support third-party applications that are restricted by the POI device to operate in either a non-secure processor or in an isolated memory space (i.e., virtual machine), segmenting the application from access to both input channels and cleartext sensitive data. Such applications are …
The use of a device with components⎯e.g., EPPs, card readers⎯that are different than those listed as an approved component for that device invalidates that device’s approval. RAP devices may be listed as an approved component of one or more associated HSMs. For v4 and higher HSMs, the HSM must be validated to the “Remote-Managed HSM” requirements.
• Third-Party Applications POI v7 devices with the ‘third-party application’ feature notation on the PTS approval listing may support third-party applications that are restricted by the POI device to operate in either a non-secure processor or in an isolated memory space (i.e., virtual machine), segmenting the application from access to both input channels and cleartext sensitive data. Such applications are …
Added
p. 61
Notwithstanding the aforementioned, device modification submissions where changes are sufficient to require a full evaluation and new approval number will receive a new listing. These devices may additionally be listed under the approval number of the existing previously approved (unmodified) device if:
1. The changes do not include altering or replacing the security processor.
2. The new device maintains the same external appearance of the existing previously approved device.
3. The new device remains functionally equivalent to the existing previously approved device, not adding, modifying, or removing features relied upon to meet the PCI PTS requirements of the original listing.
4. The new device is differentiated from the existing previously approved device by changes to both the hardware version and model name.
5. The security requirements used are not expired for use in new evaluations (resulting in a new approval number).
Examples of instances where co-listing would be considered for a modified device that has undergone …
1. The changes do not include altering or replacing the security processor.
2. The new device maintains the same external appearance of the existing previously approved device.
3. The new device remains functionally equivalent to the existing previously approved device, not adding, modifying, or removing features relied upon to meet the PCI PTS requirements of the original listing.
4. The new device is differentiated from the existing previously approved device by changes to both the hardware version and model name.
5. The security requirements used are not expired for use in new evaluations (resulting in a new approval number).
Examples of instances where co-listing would be considered for a modified device that has undergone …
Added
p. 62
• V7.x: Requirements A1, A2, A6, A7, B20, & D2
Added
p. 66
B.6 Applicability of Technical FAQs During Delta Evaluations Technical FAQs are updated regularly to not only add clarification to requirements in order to provide a consistent and level playing field in the applications of those requirements, but may also address new security threats that have arisen. As such, Technical FAQs are generally effective immediately upon publication.
B.7 Considerations for Updated Components in Integrated Terminals Vendors with PCI SSC-approved PTS Devices that integrate other PTS Program-approved OEM components (such as unattended payment terminals) may seek delta evaluations on such devices for changes that occur to the embedded OEM components. This includes replacing any OEM component with a different mode⎯e.g., a separately-approved OEM ICCR produced by one vendor is replaced in the final form factor of the integrated terminal or UPT with a different model, even if from a different vendor. This allowance applies as long as the vendor continues to have control …
B.7 Considerations for Updated Components in Integrated Terminals Vendors with PCI SSC-approved PTS Devices that integrate other PTS Program-approved OEM components (such as unattended payment terminals) may seek delta evaluations on such devices for changes that occur to the embedded OEM components. This includes replacing any OEM component with a different mode⎯e.g., a separately-approved OEM ICCR produced by one vendor is replaced in the final form factor of the integrated terminal or UPT with a different model, even if from a different vendor. This allowance applies as long as the vendor continues to have control …
Modified
p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version 2.1b
Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version 2.2
Modified
p. 2
October 2011 1.1 Added approval classes for encrypting card readers and non-PEDs.
October 2011 1.1 Added Approval Classes for encrypting card readers and non-PEDs.
Modified
p. 2
September 2013 1.3 Updated for POI v4 and clarification for Integration, Open Protocols, SRED, device archival, determination of approval status, delta evaluations, submittal deadlines, fees, secure card readers and non- PEDs.
September 2013 1.3 Updated for POI v4 and clarification for Integration, Open Protocols, SRED, device archival, determination of approval status, delta evaluations, submittal deadlines, fees, secure card readers and non-PEDs.
Modified
p. 2
Updated for POI v5 and HSM v3. Testing timeframes restated. Added new HSM approval class information for Key Loading Devices and Remote Administration Platforms. Clarifications to product types for self- contained OEM products.
Updated for POI v5 and HSM v3. Testing timeframes restated. Added new HSM Approval Class information for Key Loading Devices and Remote Administration Platforms. Clarifications to product types for self-contained OEM products.
Modified
p. 2
March 2018 1.8 Added SCRP approval class, including SCRP-only specifications for new approvals and expiry dates. Added requirement for annual Attestation of Validation regarding firmware changes (Section 3). Changes in side- channel testing. Added Appendix D: PTS Attestation of Validation. Errata.
March 2018 1.8 Added SCRP Approval Class, including SCRP-only specifications for new approvals and expiry dates. Added requirement for annual Attestation of Validation regarding firmware changes (Section 3). Changes in side-channel testing. Added Appendix D: PTS Attestation of Validation. Errata.
Modified
p. 6
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, v6.2
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, v7.0
Modified
p. 6
• PTS POI Security Requirements Technical FAQs for use with Version 6
• PTS POI Security Requirements Technical FAQs for use with Version 7
Modified
p. 6
The documents below are routinely updated. The current versions should be referenced when using the Program Guide. Current standards are generally available at www.pcisecuritystandards.org.
Modified
p. 7
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements, v6.2
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements, v7.0
Modified
p. 7
• Payment Card Industry Vendor Release Agreement (VRA) Contains the terms and conditions that govern the exchange of information between vendors and PCI SSC and related PTS Program terms.
• Payment Card Industry Vendor Release Agreement (VRA) Contains the terms and conditions that govern the exchange of information between vendors and PCI SSC, and related PTS Program terms.
Modified
p. 7
The documents described above are available in the “PTS” and “PIN” subsections of the “Document Library“ section of the PCI SSC Website. Earlier versions of the documents are available in the Archived Documents section of the Website.
The documents described above are available in the “PTS” and “PIN” subsections of the “Document Library“ section of the PCI SSC Website. Earlier versions of the documents are available in the “Archived Documents” section of the Website.
Modified
p. 9
• “Participating Payment Brand” means a payment card brand that, as of the time in question, is then formally admitted as (or an affiliate of) a member of PCI SSC pursuant to its governing documents.
• “Participating Payment Brand” means a payment card brand that, as of the time in question, is then formally admitted as (or an affiliate of) a member of PCI SSC, pursuant to its governing documents.
Modified
p. 11
Except where noted, this document refers to POI devices and HSMs as “payment security devices.” Device vendors wishing to have their device model(s) approved by PCI SSC may contact one of the PCI-Recognized Laboratories and complete the appropriate PCI SSC forms (included in the applicable Security Requirements). The vendor will then submit the device, together with any additional documentation required by the Laboratory, for evaluation and compliance validation against the applicable Security Requirements. Upon completion of the evaluation, PCI SSC …
Figure 3. PCI PTS Device Program Protection Framework Except where noted, this document refers to POI devices and HSMs as “payment security devices.” Device vendors wishing to have their device model(s) approved by PCI SSC may contact one of the PCI-Recognized Laboratories and complete the appropriate PCI SSC forms (included in the applicable Security Requirements). The vendor will then submit the device, together with any additional documentation required by the Laboratory, for evaluation and compliance validation against the applicable Security …
Modified
p. 11
• PCI SSC recommends that the POI device receive EMV Level 1 approval first, if applicable, and then PCI SSC approval prior to submitting it for any appropriate EMV Level 2 testing. (With regards to EMV Level 1 approval, there should be little or no overlap in testing processes with the PCI PTS POI security approval.)
• PCI SSC recommends that the POI device receive EMV® Level 1 approval first, if applicable, and then PCI SSC approval before submitting it for any appropriate EMV® Level 2 testing. (With regard to EMV® Level 1 approval, there should be little or no overlap in testing processes with the PCI PTS POI security approval.)
Modified
p. 12
PCI SSC’s modular PTS approach provides a comprehensive evaluation process to address the diversity of payment security device architectures, product options, and integration models. It potentially optimizes evaluation costs and time when laboratories are reviewing non-conventional architectures, the PCI SSC approval of product types, and the maintenance of existing approvals (changes in security components, etc.).
PCI SSC’s modular PTS approach provides a comprehensive evaluation process to address the diversity of payment security device architectures, product options, and integration models. It potentially optimizes evaluation costs and time when laboratories simultaneously review non-conventional architectures, the PCI SSC approval of product types, and the maintenance of existing approvals (changes in security components, etc.).
Modified
p. 12
This modular approach supports the submission of devices in accordance with the product types and approval classes defined in Appendix A.
This modular approach supports the submission of devices by the product types and Approval Classes defined in Appendix A.
Modified
p. 12
Table 1: Evaluation Modules In order to capture the diversity of Security Requirements in a single compliance evaluation process by the Laboratory, the PCI PTS POI Security Requirements are split into the following evaluation modules:
Table 1. Evaluation Modules To capture the diversity of security requirements in a single compliance evaluation process by the Laboratory, the PCI PTS POI Security Requirements are split into the following evaluation modules:
Modified
p. 12
Device Integration Requirements Requirements for integration of previously approved components aiming to help minimize resulting impairment of overall security as stated in the Security Requirements, including security management requirements applicable to the integrated device.
Device Integration Requirements Requirements for integration of previously-approved components, aiming to help minimize resulting impairment of overall security as stated in the Security Requirements, including security management requirements applicable to the integrated device.
Modified
p. 12
Products supporting open protocols or seeking to have the secure reading and exchange of data (SRED) designation must be evaluated against the relevant Security Requirements as designated in Appendix B: Applicability of Requirements in the PTS POI Modular Security Requirements. See the columns for “Implements Open Protocols” and “Protects Account Data” for requirements that must be met in addition to other applicable requirements.
Products supporting open protocols, seeking to have the secure reading and exchange of data (SRED) designation, or seeking notation of “Function Provided of Biometric Reader” must be evaluated against the relevant Security Requirements as designated in Appendix B, “Applicability of Requirements” in the PTS POI Modular Security Requirements. See the columns for “Implements Open Protocols,” “Protects Account Data,” and “Biometric Reader” for specific requirements that must be met in addition to other applicable requirements.
Modified
p. 12
PCI SSC approval of any device using a communication method that uses a wireless, local, or wide area network to transport data is subject to open protocols evaluation. This includes, but is not limited to, Bluetooth, Wi-Fi, Cellular (GPRS, CDMA), or Ethernet. A serial point-to-point connection would not need to be assessed unless that connection is wireless or through a hub, switch, or other multiport device. In addition, any communication that uses a public domain protocol or security protocol would …
PCI SSC approval of any device using a communication method that uses a wireless, local, or wide area network to transport data is subject to open protocols evaluation. This includes, but is not limited to, Bluetooth, Wi-Fi, cellular (GPRS, CDMA), or ethernet. A serial point-to-point connection would not need to be assessed unless that connection is wireless or through a hub, switch, or other multiport device. In addition, any communication that uses a public domain protocol or security protocol would …
Modified
p. 13
The overall intent of the SRED validation requirement is to help ensure that implementations of account data protection in PCI SSC-approved devices are fully robust as evidenced by validation and approval against the SRED requirements. However, the requirement is not intended to inhibit the vendor from implementing account data protections that, while not sufficient to meet the applicable SRED requirements, may still provide some lesser level of protection for account data. Thus, a vendor may implement account data protections and …
The overall intent of the SRED validation requirement is to help ensure that implementations of account- data protection in PCI SSC-approved devices are fully robust, as evidenced by validation and approval against the SRED requirements. However, the requirement is not intended to inhibit the vendor from implementing account data protections that, while not sufficient to meet the applicable SRED requirements, may still provide some lesser level of protection for account data. Thus, a vendor may implement account-data protections and not …
Modified
p. 13
All N/A responses require reporting on testing performed (including interviews conducted and documentation reviewed) and must explain how it was determined that the requirement does not apply within the scope of the PTS Device evaluation.
All “N/A” responses require reporting on testing performed (including interviews conducted and documentation reviewed), and must explain how it was determined that the requirement does not apply within the scope of the PTS Device evaluation.
Modified
p. 13
The Laboratory will validate payment security devices against the Life Cycle Security Requirements as specified in the PCI PTS POI Modular Security Requirements or PCI PTS HSM Modular Security Requirements. This is done via documentation reviews and by means of evidence that procedures are properly implemented and used. Any nonconformity with these requirements will be reported to PCI SSC for review. This information is required as part of the approval process.
The Laboratory will validate payment security devices against the “Life Cycle” Security Requirements as specified in the PCI PTS POI Modular Security Requirements or PCI PTS HSM Modular Security Requirements. This is done via documentation reviews and utilizes evidence that procedures are properly implemented and used. Any non-conformity with these requirements will be reported to PCI SSC for review. This information is required as part of the approval process.
Modified
p. 14
Table 2: Testing and Approval Process Illustration The table below and the charts on the following pages outline and illustrate the PCI SSC payment security device testing and approval process.
Table 2. Testing and Approval Process Illustration The table below and the charts on the following pages outline and illustrate the PCI SSC payment security device testing and approval process.
Modified
p. 14
Process Stage Resource/Explanation Illustration Prior to testing Testing and Approval Process Description Figure 1 Obtain appropriate documentation and forms Detailed Evaluation Process Figure 2 Contact a PCI-Recognized Laboratory to initiate testing Preparation for Testing Figure 2 Sign Vendor Release Agreement (VRA) Approval Process Figure 2 Submit documentation and materials Requirements for Testing Figure 2 Respond to inquiries from Laboratory Technical Support throughout Testing Figure 2 Receive response or approval letter from PCI SSC Approval Process Figure 2 PTS Device changes …
Process Stage Resource/Explanation Illustration Prior to testing Testing and Approval Process Description Figure 4 Obtain appropriate documentation and forms Detailed Evaluation Process Figure 5 Contact a PCI-Recognized Laboratory to initiate testing Preparation for Testing Figure 5 Sign Vendor Release Agreement (VRA) Approval Process Figure 5 Submit documentation and materials Requirements for Testing Figure 5 Respond to inquiries from Laboratory Technical Support throughout Testing Figure 5 Receive response or approval letter from PCI SSC Approval Process Figure 5 PTS Device changes …
Modified
p. 15
Figure 1: PTS Device Testing Inquiry Flow Chart
Figure 4. PTS Device Testing Inquiry Flow Chart
Modified
p. 16
Figure 2: PTS Device Approval Flow Chart
Figure 5. PTS Device Approval Flow Chart
Modified
p. 17
Figure 3: PTS Device Change Request Chart
Figure 6. PTS Device Change-Request Chart
Removed
p. 18
The ’Guidance’ in the Derived Test Requirements must be fully considered as required unless they stipulate ‘may’ or ‘should’.
Modified
p. 18
The Technical FAQs are also an integral part of the evaluation process. Technical FAQs are identified by major version of the Security Requirements⎯e.g., 4.x, 5.x, 6.x. Each Technical FAQ version is specific to the corresponding major version of Security Requirements. For example, Technical FAQs version 6 is specific to Security Requirements version 6.x and only Security Requirements version 6.x, and so on.
The “Guidance” in the Derived Test Requirements must be fully considered as required unless it stipulates “may” or “should.” The Technical FAQs are also an integral part of the evaluation process. Technical FAQs are identified by major version of the Security Requirements⎯e.g., 4.x, 5.x, 6.x. Each Technical FAQ version is specific to the corresponding major version of Security Requirements. For example, Technical FAQs version 6 is specific to Security Requirements version 6.x, and only Security Requirements version 6.x, and so …
Modified
p. 18
Modifications, changes, and revisions of PCI SSC-approved devices, termed “deltas,” can occur at any time during the product’s approval. Devices undergoing delta evaluations must take into account the then current Technical FAQs of the associated major version of Security Requirements only for the Security Requirement(s) that are impacted by the delta change. For example, if a change impacts compliance with requirements B1 and B4, only the then current Technical FAQs associated with B1 and B4 must be considered as part …
Modifications, changes, and revisions of PCI SSC-approved devices, termed “deltas,” can occur at any time during the product’s approval. Devices undergoing delta evaluations must take into account the then-current Technical FAQs of the associated major version of Security Requirements•only for the Security Requirement(s) that are impacted by the delta change. For example, if a change impacts compliance with Requirements B1 and B4, only the then-current Technical FAQs associated with B1 and B4 must be considered as part of the delta …
Modified
p. 18
In the year the prior Security Requirements are retired from use, any vendor using those Security Requirements for a new evaluation must have the device in evaluation 60 days prior to the version’s retirement date, and PCI SSC must be notified in writing by each PCI-Recognized Laboratory of the specific devices they have under evaluation. The final Laboratory evaluation reports must be received by PCI SSC by the end of that 60-day timeline. If the devices require changes based upon …
In the year the prior Security Requirements are retired from use, any vendor using those Security Requirements for a new evaluation must have the device in evaluation 60 days prior to the version’s retirement date, and PCI SSC must be notified in writing by each PCI-Recognized Laboratory of the specific devices it has under evaluation. PCI SSC must receive the final Laboratory evaluation reports by the end of that 60-day timeline. If the devices require changes based upon PCI SSC …
Modified
p. 19
Examples of documents and items to submit to a PCI-Recognized Laboratory include the following, as applicable for the device approval class:
Examples of documents and items to submit to a PCI-Recognized Laboratory include the following, as applicable for the device Approval Class:
Modified
p. 19
3. A user-available security policy for posting with the approval at the Website. The document must contain at a minimum all prescribed information in the applicable Derived Test Requirements.
3. A user-available security policy. to be posted with the approval on the Website. The document must contain, at a minimum, all prescribed information in the applicable Derived Test Requirements.
Modified
p. 19
4. Three (3) working POI devices (for HSMs, consult with the Laboratory) with operator’s manual or instructions. Additionally, for POI devices undergoing new evaluations, the vendor shall provide two working devices to the Lab for archiving by PCI SSC as delineated below.
4. Three (3) working POI devices (for HSMs, consult with the Laboratory) with operator’s manual or instructions. Additionally, for POI devices undergoing new evaluations, the vendor shall provide two working devices to the Lab for archiving, as delineated below.
Modified
p. 19
• Change control logs
• Change-control logs
Modified
p. 19
9. Additional documentation, such as (a) block diagrams, schematics, and flowcharts, which will aid in the payment security device evaluation, and (b) device form factor and related images for (if approved by PCI SSC) publication on the Approved Device List and related PCI SSC use. The Laboratory may request additional evaluation material when necessary.
9. Additional documentation, such as (a) block diagrams, schematics, and flowcharts, which will aid in the payment security device evaluation, and (b) device form factor and related images for publication on the Approved Device List (if approved by PCI SSC) and related PCI SSC use. The Laboratory may request additional evaluation material when necessary.
Modified
p. 20
Following a successful evaluation, the PTS Lab must provide to PCI SSC two sample devices. The shipping address and local contact are indicated below. Experimental data from certain performed tests must be retained for future provision to PCI SSC on an as-needed basis. This applies to all new evaluations that result in a new approval number. It does not apply to delta evaluations. It also does not apply to a situation where the vendor is merely rebranding another vendor's previously …
Following a successful evaluation, the PTS Lab must provide two sample devices to PCI SSC. The shipping address and local contact are indicated below. Experimental data from certain performed tests must be retained for future provision to PCI SSC on an as-needed basis. This applies to all new evaluations that result in a new approval number. It does not apply to delta evaluations. It also does not apply to a situation where the vendor is merely rebranding another vendor's previously-approved …
Modified
p. 20
• Device samples: Two (2) terminals containing the same keys and applications as those supplied to the PCI-Recognized Laboratory. This includes all approval classes. For large items, please notify via contact details below before shipping. If a device has different variants, the Lab shall send two different variants, selecting those two that most represent the range of all variants. Provision of device samples is a necessary part of a device’s approval. These will be securely retained and may be used …
• Device samples: Two (2) terminals containing the same keys and applications as those supplied to the PCI-Recognized Laboratory. This includes all Approval Classes. For large items, please notify via the contact details below before shipping. If a device has different variants, the Lab shall send two different variants, selecting those two that most represent the range of all variants. Provision of device samples is a necessary part of a device’s approval. These will be securely retained and may be …
Modified
p. 20
Before a letter of approval is issued and listing is posted to the Approved Device List, the Lab must post to the secure PCI SSC web portal made available to the Lab (the “Portal”) the shipping company and associated tracking number for the device samples.
Before a letter of approval is issued and the device is posted to the Approved Device List, the Lab must post to the secure PCI SSC web portal made available to the Lab (the “Portal”) the shipping company and associated tracking number(s) for the device samples.
Modified
p. 20
• Robust side-channel testing is an important part of device evaluation. Relevant side-channel test data (digitally represented waveforms and associated numerical data) produced by an evaluation must be stored by the Laboratory for at least six months following device approval. PCI SSC shall request some or all of this data to be provided as necessary. Labs should communicate with PCI SSC to resolve any questions on this matter.
• Robust side-channel testing is an important part of device evaluation. Relevant side-channel test data (digitally represented waveforms and associated numerical data) produced by an evaluation must be stored by the Laboratory for at least six months following device approval. PCI SSC shall request some or all of this data, to be provided as necessary. Labs should communicate with PCI SSC to resolve any questions on this matter.
Modified
p. 20
• Robust logical-anomalies testing is an important part of device evaluation. Relevant fuzzing data examples (output data and/or logs, reports, etc.), providing a representative and comprehensible summary of the fuzzing attack test runs must be presented within accompanying evaluation reports, indicating what testing was performed and why, and in sufficient detail to explain testing rationale and conclusions.
• Robust logical-anomalies testing is an important part of device evaluation. Relevant fuzzing data examples (output data and/or logs, reports, etc.), providing a representative and comprehensible summary of the fuzzing attack test runs, must be presented within accompanying evaluation reports, indicating what testing was performed and why, and in sufficient detail to explain testing rationale and conclusions.
Modified
p. 20
Attn: MasterCard Global Products and MasterCard Worldwide 5 Booths Park Chelford Road Knutsford Cheshire WA16 8QZ UK Contact: Mrs. Deborah Corness Telephone: +44 (0)1565 626500 Fax: +44 (0)7738 202 663 E-mail: deborah_corness@mastercard.com
Attn: MasterCard Global Products and MasterCard Worldwide 5 Booths Park Chelford Road Knutsford Cheshire WA16 8QZ UK Contact: Mrs. Deborah Corness Telephone: +44 (0)1565 626500 Fax: +44 (0)7738 202 663 E-mail: Deborah_Corness@mastercard.com
Modified
p. 21
• see Appendix D) for that device, confirming adherence to the Program Guide
•i.e., either the hardware and firmware has not been amended or the changes made are either within the wildcard parameters or were submitted for evaluation. The vulnerability process reported on in the AOV must include all physical interfaces and their corresponding logical protocols as defined in D1. For all devices, the vendor must provide evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists by …
•i.e., either the hardware and firmware has not been amended or the changes made are either within the wildcard parameters or were submitted for evaluation. The vulnerability process reported on in the AOV must include all physical interfaces and their corresponding logical protocols as defined in D1. For all devices, the vendor must provide evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists by …
• see Appendix D) for that device, confirming adherence to the Program Guide
•i.e., either the hardware and firmware has not been amended or the changes made are either within the wildcard parameters or were submitted for evaluation. The vulnerability process reported on in the AOV must include all physical interfaces and their corresponding logical protocols as defined in Requirement D1. For all devices, the vendor must provide evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists …
•i.e., either the hardware and firmware has not been amended or the changes made are either within the wildcard parameters or were submitted for evaluation. The vulnerability process reported on in the AOV must include all physical interfaces and their corresponding logical protocols as defined in Requirement D1. For all devices, the vendor must provide evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists …
Modified
p. 21
PCI SSC may elect to send an e-mail reminder to the vendor contact (as identified in the most recent approval) within 30 days of the triennial anniversary for a particular firmware version approved under PTS version 6 (or higher).
PCI SSC may elect to send an e-mail reminder to the vendor contact (as identified in the most recent approval) within 30 days of the triennial anniversary for a particular firmware version approved under PTS POI v6 (or higher).
Modified
p. 21
This evaluation is in addition to the annual AOV and must consider changes in the vulnerability landscape.
This evaluation is in addition to the annual AOV and must consider changes in the vulnerability landscape. This section only applies to POI devices.
Modified
p. 22
• Cannot include other evaluation types e.g., rebranding, hardware or firmware deltas, etc.
• Cannot include other evaluation types (e.g., rebranding, hardware or firmware deltas, etc.).
Modified
p. 22
Where the vendor has multiple firmware versions expiring in different years the evaluations can be combined into one report, effectively synchronizing the expiration dates going forward. But, in order to do so, the following conditions must be met:
Where the vendor has multiple firmware versions expiring in different years, the evaluations can be combined into one report, effectively synchronizing the expiration dates going forward. However, to do so, the following conditions must be met:
Modified
p. 22
• Under a given Approval Number any or all relevant firmware
•requiring expiration evaluation
•may be included in the evaluation.
•requiring expiration evaluation
•may be included in the evaluation.
• Under a given Approval Number, any or all relevant firmware
•requiring expiration evaluation
•may be included in the evaluation.
•requiring expiration evaluation
•may be included in the evaluation.
Modified
p. 22
• When a firmware version has gone past the window for re-evaluation and approval, the expiration year will change color to RED.
• When a firmware version has exceeded the window for re-evaluation and approval, the expiration year will change color to RED.
Modified
p. 22
Company Firmware Expiry Date Number Version Approval Approval Expiry Date XYZ Inc.
Table 3. Example of Firmware Expiry Evaluation Company Firmware Expiry Date Number Version Approval Approval Expiry Date XYZ Inc.
Modified
p. 22
Hardware # A123-xxx-456-xx 4-98765 6.x PED 30 Apr 2030 A123-xxx-789-xx A123--0AB-xx Firmware # 23.01.xxx xx (2022) 23.02.xxx xx (2023)
Hardware # A123-xxx-456-xx 4-98765 6.x PED 30 Apr 2032 A123-xxx-789-xx A123--0AB-xx Firmware # 23.01.xxx xx (2022) 23.02.xxx xx (2023)
Modified
p. 23
Vendors are encouraged to contact a PCI-Recognized Laboratory directly in regard to the above services and any associated fees. However, the Labs cannot offer any advice on the actual design of the POI device or HSM.
Vendors are encouraged to contact a PCI-Recognized Laboratory directly regarding the above services and any associated fees. However, the Labs cannot offer any advice on the actual design of the POI device or HSM.
Modified
p. 23
The Laboratory may perform a pre-evaluation of a vendor payment security device and decide that there are deficiencies that would prevent an approval. The Lab may then respond to the vendor with a list of all the aspects of the payment security device that should be addressed before the formal testing process begins.
The Laboratory may perform a pre-evaluation of a vendor payment security device and decide that there are deficiencies that would prevent approval. The Lab may then respond to the vendor with a list of all the aspects of the payment security device that should be addressed before the formal testing process begins.
Modified
p. 24
The testing timeframes are estimates based on the assumption that the payment security device successfully completes testing. If problems are found during testing, discussions between the Laboratory and the vendor may be required. Such discussions may impact testing times and cause delays and/or end the test cycle prior to completion of all tests.
The testing timeframes are estimates based on the assumption that the payment security device successfully completes testing. If problems are found during testing, discussions between the Laboratory and the vendor may be required. Such discussions may impact testing times and cause delays and/or end the test cycle before completion of all tests.
Modified
p. 24
During the testing process, all the applicable test procedures are run according to the applicable PCI SSC Derived Test Requirements. Any discrepancies discovered are reported to the vendor. All applicable tests should be run during a single test cycle, unless:
During testing, all test procedures are run according to the applicable PCI SSC Derived Test Requirements. Any discrepancies discovered are reported to the vendor. All applicable tests should be run during a single test cycle, unless:
Modified
p. 24
There is no provision for interrupting the test cycle and re-starting the cycle again at a later date.
There is no provision for interrupting the test cycle and re-starting the cycle at a later date.
Modified
p. 25
Laboratory evaluation work shall occur using approved Laboratory personnel and equipment. Device testing for PTS Program approvals shall be done in the PCI-Recognized Laboratory facility and not at vendor site unless:
Laboratory evaluation work shall occur using approved Laboratory personnel and equipment. Device testing for PTS Program approvals shall be done in a PCI-Recognized Laboratory facility and not at vendor site, unless:
Modified
p. 25
• The Laboratory work is in connection with evaluating policies and procedures of the vendor.
• The Laboratory work is in connection with evaluating the vendor’s policies and procedures.
Modified
p. 25
• Evaluating Life Cycle Security Requirements.
• The Laboratory is evaluating “Life Cycle” Security Requirements.
Modified
p. 26
All PCI SSC-approved devices for which the approval has not expired shall be billed an approval-listing fee for all such approvals that existed as denoted above. Vendors shall not be billed the annual listing fee for “End of Life” (EOL) products for which they have notified PCI SSC in writing at least ninety (90) days prior to the billing date of 1 May. An end-of-life product is a product no longer marketed for new deployments as described in Section A.13, …
All PCI SSC-approved devices for which the approval has not expired shall be billed an approval-listing fee for all such approvals that exist as noted previously. Vendors shall not be billed the annual listing fee for “End-of-Life” (EOL) products for which they have notified PCI SSC in writing at least ninety (90) days prior to the billing date of 1 May. An end-of-life product is a product no longer marketed for new deployments as described in Section A.13, “Additional Information.” …
Modified
p. 27
Before PCI SSC will review any evaluation report for device approval, PCI SSC must have on file a copy of the then most current version of the VRA on the Website, signed by the applicable vendor. The current version of the VRA is available on the Website. Generally, the vendor will provide its signed VRA to the PTS Lab in connection with the device evaluation process.
Before PCI SSC will review any evaluation report for device approval, PCI SSC must have on file a copy of the then-most-current version of the VRA on the Website, signed by the applicable vendor. The current version of the VRA is available on the Website. Generally, the vendor will provide its signed VRA to the PTS Lab in connection with the device evaluation process.
Modified
p. 27
Vendors or other third parties licensing PCI SSC-approved products from other vendors to market or distribute under their own names must also sign the most current version of the VRA prior to the issuance of the approval and provide the same to the applicable Laboratory, for the Laboratory to deliver to PCI SSC along with the evaluation report.
Vendors or other third parties licensing PCI SSC-approved products from other vendors to market or distribution under their own names must also sign the most current version of the VRA prior to the issuance of the approval, and provide the same to the applicable Laboratory, for the Laboratory to deliver to PCI SSC along with the evaluation report.
Modified
p. 27
The Laboratory is responsible for ensuring evaluation test reports and all other information related to report submissions are accurate, complete, and conform to the PTS Program.
Modified
p. 27
PCI SSC bases its approval solely on the results of the Laboratory evaluation report. All reports, inquiries from report reviewers, and Laboratory responses to inquiries are managed through the Portal. Upon receipt of the test report for a new evaluation, PCI SSC will generally identify any technical issues or questions for resolution by the Laboratory within four weeks (28 calendar days). If the report is deemed by the reviewers as deficient in quality, a reissuance of the report shall be …
PCI SSC bases its approval solely on the results of the Laboratory evaluation report. All reports, inquiries from report reviewers, and Laboratory responses to inquiries are managed through the Portal. Upon receipt of the test report for a new evaluation, PCI SSC will generally identify any technical issues or questions for resolution by the Laboratory within four weeks (28 calendar days). If the report is deemed by the reviewers as deficient in quality, a reissuance of the report shall be …
Modified
p. 28
Note: PCI SSC will not grant any “partial approvals” based upon the ability of a PTS Device to meet some
•but not all
•of the applicable required Physical or Logical SecurityRequirements For various reasons, including revocation of approval, information on approval letters may become inaccurate. Therefore, the Website is considered the authoritative source and should always be used to validate the approval status of a vendor’s product.
•but not all
•of the applicable required Physical or Logical Security
Note: PCI SSC will not grant any “partial approvals” based upon the ability of a PTS Device to meet some
•but not all
•of the applicable required Physical or Logical Security Requirements.
•but not all
•of the applicable required Physical or Logical Security Requirements.
Modified
p. 29
Seven days prior to the listing, a reminder notification will be sent to both the vendor’s primary business and technical contacts. The notification will confirm the listing of the device on the Approved Device List and the date to list and instruct the contacts to contact the PTS Program Manager mailbox (PCIPTS@pcisecuritystandards.org) if a change to the listing date is required. Subsequently:
Seven days prior to the listing, a reminder notification will be sent to both the vendor’s primary business and technical contacts. The notification will confirm the listing of the device on the Approved Device List, the listing date, and instructions to contact the PTS Program Manager mailbox (PCIPTS@pcisecuritystandards.org) if a change to the listing date is required. Subsequently:
Modified
p. 29
• If there is not a response from the vendor, the device will be listed on the original specified date.
• If there is no response from the vendor, the device will be listed on the original specified date.
Modified
p. 29
• If the date to list the device falls on a U.S. weekend or holiday, the device will be listed the next following business day.
• If the date to list the device falls on a U.S. weekend or holiday, the device will be listed the next business day.
Modified
p. 29
For devices that embed other PCI SSC-approved devices and are therefore basing their security on these approved components (even partially), the expiration date shall be the earliest among all evaluations, including the embedded device itself.
Figure 7. Relationship Between v6 Requirements and Testing For devices that embed other PCI SSC-approved devices and are therefore basing their security on these approved components (even partially), the expiration date shall be the earliest among all evaluations, including the embedded device itself.
Modified
p. 30
1. No Impact on Security Requirements: New Testing is Not Required to Maintain Approval If hardware or firmware (including software that impacts security) in the previously approved payment security device is revised, but that revision is deemed to be minor and does not negatively impact security, then documentation of the change can be submitted to the Laboratory for review. It is strongly recommended that the vendor use the same Laboratory that was used for the original evaluation.
1. No Impact on Security Requirements: New Testing is Not Required to Maintain Approval If hardware or firmware (including software that impacts security) in the previously-approved payment security device is revised, but that revision is deemed to be minor and does not negatively impact security, then documentation of the change can be submitted to the Laboratory for review. It is strongly recommended that the vendor use the same Laboratory that was used for the original evaluation.
Modified
p. 30
Where appropriate, the Laboratory will issue a letter to PCI SSC describing the nature of the change, stating that it does not impact the POI’s or HSM’s compliance with the applicable Security Requirements. PCI SSC will then review the letter to determine whether the change has any impact on the approval status of the payment security device.
Where appropriate, the Laboratory will issue a letter to PCI SSC describing the nature of the change, stating that it does not impact the POI’s or HSM’s compliance with the applicable Security Requirements. PCI SSC will then review the letter to determine whether the change impacts the approval status of the payment security device.
Modified
p. 30
2. Potential Impact on Security Requirements: New Testing is Required to Maintain Approval If changes to the device are determined to impact payment security device security, the device must undergo a security evaluation of those changes. Once that is completed, the Laboratory will submit a new evaluation report to PCI SSC for re-approval consideration. In this scenario, the vendor must first submit documentation of the change to the Laboratory, which will determine (in accordance with applicable Security Requirements) whether the …
2. Potential Impact on Security Requirements: New Testing is Required to Maintain Approval If changes to the device are determined to impact device security, the device must undergo a security evaluation of those changes. Once completed, the Laboratory will submit a new evaluation report to PCI SSC for re-approval consideration. In this scenario, the vendor must first submit documentation of the change to the Laboratory, which will determine (per applicable Security Requirements) whether the change impacts device security.
Modified
p. 31
• UPT evaluation reports containing separately approved OEM components must at a minimum contain a summary table of all requirements (whether Yes or N/A) of any module that is relevant to the final form factor of the UPT. This table may reference the pertinent OEM component for compliance to any specific requirement.
• UPT evaluation reports containing separately-approved OEM components must, at a minimum, contain a summary table of all requirements (whether answered “Yes” or “N/A”) of any module that is relevant to the final form factor of the UPT. This table may reference the pertinent OEM component for compliance with any specific requirement.
Modified
p. 31
• If such Lab is unable to rely, where necessary, on information that is available in reports that are not available to the Lab, and the Lab is unable to perform the degree of necessary additional work to achieve such reliance, the Lab evaluating the final form factor must decline the engagement.
• If such Lab is unable to rely, where necessary, on information that is provided in reports that are not available to the Lab, and the Lab is unable to perform the degree of necessary additional work to achieve such reliance, the Lab evaluating the final form factor must decline the engagement.
Modified
p. 31
• In all cases, PCI SSC may reject the report if, in the judgment of PCI SSC, the report does not contain adequate information to substantiate the conclusions of compliance to overall UPT criteria.
• In all cases, PCI SSC may reject the report if, in the judgment of PCI SSC, the report does not contain adequate information to substantiate the conclusions of compliance with overall UPT criteria.
Modified
p. 31
OEM components approved against earlier versions of the applicable Security Requirements are only allowed for use in obtaining an overall UPT approval evaluation without additional testing of those components if they are no more than one major version of the applicable Security Requirements earlier. For example, EPPs evaluated and approved using PCI POI v5.x can be used without additional testing of requirements they have previously met as part of an overall POI v6 evaluation. However, EPPs that were evaluated and …
OEM components approved against prior versions of the requirements can only be used to obtain an overall UPT approval •without needing additional testing of those components •if they are no more than one major version away from the previously-approved Security Requirements. For example, EPPs evaluated and approved using PCI POI v5.x can be used without additional testing of requirements they have previously met as part of an overall POI v6 evaluation. However, EPPs that were evaluated and approved using PCI …
Modified
p. 32
2. All such requests must be received by PCI SSC as a delta request from a PCI-Recognized Laboratory. If the only change is to the nameplate of the product, PCI SSC will not charge a new fee for its review and approval of the licensee product but, as noted above, will charge annual listing fees to applicable vendors for the licensee product and original product.
2. All such requests must be received by PCI SSC as a delta request from a PCI-Recognized Laboratory. If the only change is to the nameplate of the product, PCI SSC will not charge a new fee for its review and approval of the licensee product but, as noted previously, will charge annual listing fees to applicable vendors for the licensee product and original product.
Modified
p. 32
5. As noted, licensed products requiring physical and/or logical changes will incur a new Acceptance fee. However, as long as the licensor vendor continues the manufacture of the device on behalf of the licensee vendor, the licensee product can be evaluated against the security requirement’s version against which the original product was evaluated and approved, even though those requirements may be expired for new approvals.
5. As noted, licensed products requiring physical and/or logical changes will incur a new Acceptance fee. However, as long as the licensor vendor continues to manufacture the device on behalf of the licensee vendor, the licensee product can be evaluated against the Security Requirements version the original product was evaluated and approved against, even if those requirements may be expired for new approvals.
Modified
p. 32
6. If the licensee vendor wishes to directly manufacture the licensee product or have a third party other than the licensor vendor manufacture the licensee product on its behalf, the product must be reassessed as a new evaluation against the current version of the applicable Security Requirements•unless the licensor vendor can demonstrate that it retains both the intellectual property and engineering control. This is due to the potential for changes in plastics, etc. that may impact the security of the …
6. If the licensee vendor wishes to directly manufacture the licensee product or have a third party other than the licensor vendor manufacture the licensee product on its behalf, the product must be reassessed as a new evaluation against the current version of the applicable Security Requirements•unless the licensor vendor can demonstrate that it retains both the intellectual property and engineering control. This is due to the potential for changes in plastics, etc., that may impact the device security.
Modified
p. 32
Vendors seeking multiple separate approval listings for their own products are subject to the same conditions for items 2, 3, 4, and 5 as applicable.
Vendors seeking multiple separate approval listings for their own products are subject to the same conditions for items 2, 3, 4, and 5, as applicable.
Modified
p. 32
• The device must be fully capable of performing its intended functionality for the approval class it is evaluated against and can be sold as is as a fully functional product. This does not preclude the device requiring additional software such as payment applications, but the firmware of the device must meet all applicable Security Requirements.
• The device must be fully capable of performing its intended functionality for the approval class it is evaluated against, and can be sold as is as a fully-functional product. This does not preclude the device from requiring additional software such as payment applications, but the device’s firmware must meet all applicable Security Requirements.
Modified
p. 32
• Each of the second vendors that use the device design and/or manufacture the device must have its own full evaluation (NOT A DELTA) and separate listing for the device on the Approved Device List.
• Each of the subsequent vendors that use the device design and/or manufacture the device must have their own full evaluation (not a delta) and separate listing for the device on the Approved Device List.
Modified
p. 33
For vendors who undergo a legal name change, the existing vendor name will be noted as formerly known as (FKA). FKA will also be used where a vendor makes changes to a previously established “DBA” (see Section A.5).
For vendors who undergo a legal name change, the existing vendor name will be noted as “formerly known as” (FKA). FKA will also be used where a vendor makes changes to a previously-established “DBA” (see Section A.5).
Modified
p. 33
If two existing listed vendors undergo a merger, or if a vendor is involved in a transaction resulting in a change of the legal entity that is the vendor, the name of the vendor may or may not change as a result. In either case, [devices] listed under the vendor before the transaction will be listed under the name of the surviving/new/resulting vendor, with a brief description of the change (e.g., “XYZ Merged with ABC”). In such cases, evidence of …
If two existing listed vendors undergo a merger, or if a vendor is involved in a transaction resulting in a change of the legal entity that is the vendor, the vendor’s name may or may not change as a result. In either case, devices listed under the vendor before the transaction will be listed under the name of the surviving/new/resulting vendor, with a brief description of the change (e.g., “XYZ Merged with ABC”). In such cases, evidence of the applicable …
Modified
p. 33
In all cases, the vendor must also submit a new Vendor Release Agreement under the new company name or resulting company, and a revised security policy must be submitted as a delta report via one of the Labs reflecting the applicable change. If the appearance of the device changes to reflect a new name (labels or faceplate), a delta report must be obtained via one of the Labs in accordance with PTS Program delta requirements and procedures.
In all cases, the vendor must also submit a new Vendor Release Agreement under the new company name or resulting company, and a revised security policy must be submitted as a delta report •via one of the Labs •reflecting the applicable change. If the device’s appearance changes to reflect a new name (labels or faceplate), a delta report must be obtained via one of the Labs, in accordance with PTS Program delta requirements and procedures.
Modified
p. 33
Vendors who wish to change a model name of an approved device must also use the PTS Administrative Change Request form. However, if any devices have been sold under the prior model name, both names will be listed. Additionally, a new security policy must be created, and either must reference both the new and old names or be listed in parallel to the existing policy. Furthermore, images for the device used on the Website must include both the prior and …
Vendors who wish to change the model name of an approved device must also use the PTS Administrative Change Request form. However, if any devices have been sold under the prior model name, both names will be listed. Additionally, a new security policy must be created, and must either reference both the new and old names, or be listed in parallel to the existing policy. Furthermore, images for the device used on the Website must include both the prior and …
Modified
p. 33
The contacts for the PTS Program are as follows: Primary Business, Secondary Business, Technical, and Billing. At minimum, the vendor must provide a primary business and a billing contact. At least two separate points of contact should be provided. Vendors are responsible for keeping their company contact information current to receive important communications from PCI SSC regarding the PTS Program.
The contacts for the PTS Program are as follows: Primary Business, Secondary Business, Technical, and Billing. At a minimum, the vendor must provide a primary business contact and a billing contact. At least two separate points of contact should be provided. Vendors are responsible for keeping their company contact information current in order to receive important communications from PCI SSC regarding the PTS Program.
Modified
p. 34
Notification to PCI SSC must take place no later than 24 hours after the vendor first discovers the security breach or compromise.
Notification to PCI SSC must occur no later than 24 hours after the vendor first discovers the security breach or compromise.
Modified
p. 34
• The number of compromised accounts, (if known)
• The number of compromised accounts (if known)
Modified
p. 34
PCI SSC, as agreed within the terms of the Vendor Release Agreement, may share this information with PCI-Recognized Laboratories to enable an evaluation of the security breach or compromise to be performed to mitigate or prevent further security breaches or compromises. As a result of this notification, PCI SSC will work with the vendor to correct any security weaknesses and will produce a guideline document to be issued to that vendor’s customers, informing them of any potential vulnerability and detailing …
PCI SSC, as agreed within the terms of the Vendor Release Agreement, may share this information with PCI-Recognized Laboratories to enable the performance of an evaluation of the security breach or compromise to mitigate or prevent further security breaches or compromises. As a result of this notification, PCI SSC will work with the vendor to correct any security weaknesses and will produce a guideline document to be issued to that vendor’s customers, informing them of any potential vulnerability and detailing …
Modified
p. 35
• Contact the vendor to inform them that their product has a security weakness, or has been compromised and, where possible, share information relating to the actual weakness or compromise.
• Contact the vendor to inform them that its product has a security weakness, or has been compromised and, where possible, share information about the actual weakness or compromise.
Modified
p. 36
No vendor or other third party may refer to a payment security device as “PCI Approved,” or otherwise state or imply that PCI SSC has, in whole or part, approved any aspect of a vendor or its payment security devices, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in an approval letter signed by PCI SSC. All other references to PCI SSC’s approval are strictly and …
No vendor or other third party may refer to a payment security device as “PCI-Approved,” or otherwise state or imply that PCI SSC has, in whole or part, approved any aspect of a vendor or its payment security devices, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in an approval letter signed by PCI SSC. All other references to PCI SSC’s approval are strictly and actively …
Modified
p. 36
When granted, an approval is provided by PCI SSC to ensure certain security and operational characteristics important to the achievement of PCI SSC’s goals, but the approval does not under any circumstances include any endorsement or warranty regarding the functionality, quality, or performance of any particular product or service. PCI SSC does not warrant any products or services provided by third parties. Approval does not, under any circumstances, include or imply any product warranties from PCI SSC, including, without limitation, …
When granted, an approval is provided by PCI SSC to ensure certain security and operational characteristics important to the achievement of PCI SSC’s goals, but the approval does not under any circumstances include any endorsement or warranty regarding the functionality, quality, or performance of any particular product or service. PCI SSC does not warrant any products or services provided by third parties. Approval does not, under any circumstances, include or imply any product warranties from PCI SSC, including, without limitation, …
Modified
p. 37
EPP Encrypting PIN pad; approval class, designating embeddable (OEM) devices to be integrated into a cardholder-operated terminal. See Appendix A.
EPP Encrypting PIN pad; Approval Class, designating embeddable (OEM) devices to be integrated into a cardholder-operated terminal. See Appendix A.
Modified
p. 37
Evaluation Framework Set of requirements for vendors, test methodology for laboratories, approval process for products, and PCI SSC approval list pertaining to a given payment security device type (POI device, HSM).
Evaluation Framework Set of requirements for vendors, test methodology for laboratories, approval process for products, and PCI SSC-approval list pertaining to a given payment security device type (POI device, HSM).
Modified
p. 37
HSM Hardware security module; approval class aimed at devices supporting a variety of payment processing and cardholder authentication applications and processes. See Appendix A.
HSM Hardware security module; Approval Class aimed at devices supporting a variety of payment processing and cardholder authentication applications and processes. See Appendix A.
Modified
p. 37
Hybrid Reader A device that incorporates capabilities for the capture of card data from either a magnetic-stripe card or an integrated-circuit card (aka a smart or chip card).
Hybrid Reader A device that incorporates capabilities for to capture card data from either a magnetic-stripe card or an integrated-circuit card (aka a smart or chip card).
Modified
p. 37
ICCR Integrated-circuit card reader KLD Key-Loading Device MSR Magnetic-stripe reader OEM Original equipment manufacturer Payment Security Device Any complete device (for example, a consumer-facing PIN-acceptance device or an HSM) whose characteristics contribute to the security of retail electronic payments or other financial transactions.
ICCR Integrated-circuit card reader KLD Key-loading device MSR Magnetic-stripe reader OEM Original equipment manufacturer Payment Security Device Any complete device (for example, a consumer-facing PIN-acceptance device or an HSM) whose characteristics contribute to the security of retail electronic payments or other financial transactions.
Modified
p. 37
PED PIN entry device; approval class for devices with PIN-entry and PIN- processing ability, either attended or unattended, whose primary purpose is to capture and convey the PIN to an ICCR and/or to another processing device, such as a host system. A PED must have an integrated display unless dedicated to PIN entry only. See Appendix A.
PED PIN-entry device; Approval Class for devices with PIN-entry and PIN- processing ability, either attended or unattended, whose primary purpose is to capture and convey the PIN to an ICCR and/or to another processing device, such as a host system. A PED must have an integrated display unless dedicated to PIN entry only. See Appendix A.
Modified
p. 38
SCR Secure Card Reader approval class SCRP Secure Card Reader PIN approval class SPoC Software-based PIN-entry on COTS SRED Secure Reading and Exchange of Data Terminal Commercial device with a business function. It may be dedicated to payment (POS terminal with integrated or separate PIN pad) or to product-dispensing (for example, an ATM or petrol-dispensing self-service).
SCR Secure Card Reader Approval Class SCRP Secure Card Reader − PIN Approval Class SPoC Software-based PIN-entry on COTS SRED Secure Reading and Exchange of Data Terminal Commercial device with a business function. It may be dedicated to payments (POS terminal with integrated or separate PIN pad) or to product-dispensing (for example, an ATM or petrol-dispensing self-service).
Modified
p. 38
UPT Unattended payment terminal; approval class, designating cardholder- operated payment devices (self-service) that read, capture, and transmit card information in conjunction with an unattended self-service device. See Appendix A.
UPT Unattended payment terminal; Approval Class, designating cardholder- operated payment devices (self-service) that read, capture, and transmit card information in conjunction with an unattended self-service device. See Appendix A.
Modified
p. 39
A device that provides for the entry of PINs and/or account data, used for the purchase of goods or services or dispensing of cash. An approved POI has met all of the applicable PCI PTS POI requirements for PIN entry and/or account-data entry and has a clearly defined physical and logical boundary for all functions related to PIN entry.
A device that provides for the entry of PINs and/or account data, used for the purchase of goods or services or dispensing of cash. An approved POI has met all of the applicable PCI PTS POI requirements for PIN entry and/or account-data entry and has a clearly-defined physical and logical boundary for all functions related to PIN entry.
Modified
p. 39
A PIN entry device (PED) is a class of POI that supports the secure acceptance of a cardholder’s PIN.
A PIN-entry device (PED) is a class of POI that supports the secure acceptance of a cardholder’s PIN.
Modified
p. 39
In addition, non-PIN-acceptance POI devices can be validated and approved if compliant to the Secure Reading and Exchange of Data (SRED) requirements, and if applicable, to the Open Protocols requirements. These devices shall be explicitly noted as not approved for PIN acceptance.
In addition, non-PIN-acceptance POI devices can be validated and approved if compliant with the “Secure Reading and Exchange of Data (SRED)” requirements and, if applicable, to the “Open Protocols” requirements. These devices shall be explicitly noted as “Not Approved” for PIN acceptance.
Modified
p. 39
Secure Card Readers and Secure Card Readers − PIN must be validated to the requirements as delineated in Appendix B: Applicability of Requirements of the PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements.
Secure Card Readers and Secure Card Readers − PIN must be validated against the requirements as delineated in Appendix B, “Applicability of Requirements” within the PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements.
Modified
p. 39
All approval classes are subject to the Life Cycle Security Requirements.
All approval classes are subject to the “Life Cycle” Security Requirements.
Modified
p. 39
A POI device may be standalone and not embeddable, in which case the PED approval class may be applicable. This class may apply to both attended and unattended. However, vendors may decide to list an unattended terminal under the UPT class, when meeting the appropriate requirements.
A POI device may be standalone and not embeddable, in which case the PED approval class may be applicable. This class may apply to both attended and unattended devices. However, vendors may decide to list an unattended terminal under the UPT class when it meets the appropriate requirements.
Modified
p. 39
If the POI device is designed to be embedded into a wider set⎯e.g., vending machine or ATM⎯then EPP or PED approval class would apply. In such case, there can be other functionalities present besides PIN capture and conveyance⎯e.g., display, card reader. Devices entering this category will have the product type noted with the word “OEM” on the listing, to unambiguously advertise the modular nature.
If the POI device is designed to be embedded into a wider set⎯e.g., vending machine or ATM⎯then EPP or PED Approval Classes would apply. In such a case, there can be other functionalities present besides PIN capture and conveyance⎯e.g., display, card reader. Devices entering this category will have the product type noted with the word “OEM” on the listing in order to unambiguously advertise the modular nature.
Modified
p. 39
POI devices that combine goods⎯e.g., petrol⎯or services (ticketing machine) delivery with PIN-based payment are eligible for the UPT approval class. These POIs can possibly include approved OEM modules.
POI devices that combine goods⎯e.g., petrol⎯or services- (ticketing machine) delivery with PIN-based payments are eligible for the UPT Approval Class. These POIs can possibly include approved OEM modules.
Modified
p. 40
Furthermore, this document introduces a two-tier approval structure for HSMs. These tiers differentiate only in the Physical Security Requirements section as delineated in the PCI PTS HSM Modular Derived Test Requirements. HSMs may be approved as designed for use in controlled environments as defined in ISO 13491-2: Banking
• Secure Cryptographic Devices (retail) or approved for use in any operational environment. These categories are:
• Secure Cryptographic Devices (retail) or approved for use in any operational environment. These categories are:
Furthermore, this document introduces a two-tier approval structure for HSMs. These tiers differ only in the “Physical” Security Requirements section as delineated in the PCI PTS HSM Modular Derived Test Requirements. HSMs may be approved as designed for use in controlled environments as defined in ISO 13491-2: Banking
• Secure Cryptographic Devices (retail) or approved for use in any operational environment. These categories are:
• Secure Cryptographic Devices (retail) or approved for use in any operational environment. These categories are:
Modified
p. 40
• Approval is valid only when 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.
• Approval is valid only when deployed in Controlled Environments or more robust environments⎯e.g., Secure Environments⎯as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy.
Modified
p. 40
• Application #, if applicable The model name/number and vendor name must be visually and distinctly present on the device and not be part of a larger character string. The device must show the version numbers of hardware and firmware in accordance with the device’s approval, reflecting information on the Approved Device List. The model name and hardware version must be retrievable from the device by a query. The hardware number must be shown on a label attached to the …
• Application #, if applicable The model name/number and vendor name must be visually and distinctly present on the device and not be part of a larger character string. The device must show the version numbers of hardware and firmware in accordance with the device’s approval, reflecting information on the Approved Device List. The model name and hardware version must be retrievable from the device by a query. The hardware number must be shown on a label attached to the …
Modified
p. 41
Table 3: Example of a Device Identifier (five components) Component Description Vendor Name Acme POI Model Name/Number PIN Pad 600 Hardware # NN-421-000-AB Firmware # Version 1.01 Application # PCI 4.53 The Device identifier will be included in the approval letter and on the Website. If an identical payment security device is used across a family of devices, vendors are cautioned against using a Hardware # (see below) that may restrict approval to only that payment security device model.
Table 4. Example of a Device Identifier (Five Components) Component Description Vendor Name Acme POI Model Name/Number PIN Pad 600 Hardware # NN-421-000-AB Firmware # Version 1.01 Application # PCI 4.53 The Device Identifier will be included in the approval letter and on the Website. If an identical payment security device is used across a family of devices, vendors are cautioned against using a Hardware # (see A.7) that may restrict approval to only that payment security device model.
Modified
p. 41
A.5 Vendor Name Vendors shall be listed by their full legal name. A vendor’s listing may also include its trade name, alternate name, or doing-business-as name (each a “DBA”). If the vendor requests the listing of a DBA, the vendor must provide a government approved DBA or similar authorization acceptable to PCI SSC. The vendor shall be listed by the full legal name, followed by the DBA.
A.5 Vendor Name Vendors shall be listed by their full legal name. A vendor’s listing may also include its trade name, alternate name, or doing-business-as name (each a “DBA”). If the vendor requests the listing of a DBA, the vendor must provide a government-approved DBA or similar authorization acceptable to PCI SSC. The vendor shall be listed by the full legal name, followed by the DBA.
Modified
p. 41
A.6 Model Name/Number The model name/number cannot contain any variable characters. All devices within a device family that are intended to be marketed under the same approval number must be explicitly named, and pictures of those devices presented in both the evaluation report and for display on the Approved Device List. The vendor cannot use an identical model name for more than one device approved by PCI SSC under a given major version release of the applicable Security Requirements. The …
A.6 Model Name/Number The model name/number cannot contain any variable characters. All devices within a device family that are intended to be marketed under the same approval number must be explicitly named, and pictures of those devices provided in both the evaluation report and for display on the Approved Device List. The vendor cannot use an identical model name for more than one device approved by PCI SSC under a given major version release of the applicable Security Requirements. This …
Removed
p. 42
In addition, all options, both security and non-security relevant, must be clearly defined and documented as to the options available and their function in the evaluation report. Security-relevant options must be exhaustively defined and documented in the security policy. For non-security options, the security policy must include a description of the option, but not a full list of all possible values.
Modified
p. 42
The "x" field(s) has/have been assessed by the Laboratory and PCI SSC as to not impact the POI’s or HSM’s compliance with applicable Security Requirements or the vendor's approval. To ensure that the payment security device has been approved by PCI SSC, acquiring customers or their designated agents are strongly advised to purchase and deploy only those payment security devices with the Hardware # whose fixed alphanumeric characters match exactly the Hardware # depicted on the Approved Device List.
The "x" field(s) has been assessed by the Laboratory and PCI SSC as to not impact the POI’s or HSM’s compliance with applicable Security Requirements or the vendor's approval. To ensure that the payment security device has been approved by PCI SSC, acquiring customers or their designated agents are strongly advised to purchase and deploy only those payment security devices with the Hardware # whose fixed alphanumeric characters match exactly the Hardware # depicted on the Approved Device List.
Modified
p. 42
Options that cannot be a variable character include those that directly pertain to meeting applicable Security Requirements. For example, requirements exist for magnetic-stripe readers (MSRs) and integrated circuit card readers (ICCRs). A variable character cannot be used to designate whether a device contains a MSR or an ICCR. A requirement exists for the deterrence of visual observation of PIN values as they are being entered by the cardholder, which can be met by privacy shields or the device’s installed environment …
Options that cannot be a variable character include those that directly pertain to meeting applicable Security Requirements. For example, requirements exist for magnetic-stripe readers (MSRs) and integrated circuit card readers (ICCRs). A variable character cannot be used to designate whether a device contains an MSR or an ICCR. A requirement exists for the deterrence of visual observation of PIN values as they are being entered by the cardholder, which can be met by privacy shields, the device’s installed environment, or …
Modified
p. 42
If a device supports SRED or OP, some options that might normally be acceptable for identification by a wildcard variable would not be permitted. Examples include the addition of contactless readers or the inclusion of different communication packages. In such cases, the specific configurations validated by the PCI-Recognized Laboratory must be explicitly noted on the approval.
If a device supports SRED or OP, some options that might normally be acceptable for identification by a wildcard variable would not be permitted. Examples include the addition of contactless readers or the inclusion of different communication packages. In such cases, the specific configurations validated by the PCI-Recognized Laboratory must be explicitly noted in the approval.
Modified
p. 42
For HSMs, an example would be non-PCI mode⎯e.g., FIPS⎯or PCI mode support. If wildcards are used, the specific configurations validated by the PCI-Recognized Laboratory must be explicitly noted on the approval.
For HSMs, an example would be non-PCI mode⎯e.g., FIPS⎯or PCI mode support. If wildcards are used, the specific configurations validated by the PCI-Recognized Laboratory must be explicitly noted in the approval.
Modified
p. 43
Table 4: Examples on the Use of Hardware #s Hardware # of Payment Security Device in Approved Device List NN-421-000-AB Hardware # NN-421-000-AB of the Device Identifier does not employ the use of the variable "x." Hence, the payment security device being deployed must match the Hardware # exactly for the PTS Device to be considered an approved payment security device (hardware component).
Table 5. Examples of the Use of Hardware #s Hardware # of Payment Security Device in Approved Device List NN-421-000-AB Hardware # NN-421-000-AB of the Device Identifier does not employ the use of the variable "x." Hence, the payment security device being deployed must match the Hardware # exactly for the PTS Device to be considered an approved payment security device (hardware component).
Modified
p. 43
A.8 Security Policy The device vendor provides a user-available security policy that addresses the proper use of the device in a secure fashion, including information on key-management responsibilities, administrative responsibilities, device functionality, identification, and environmental requirements. The security policy must define the roles supported by the device and indicate the services available for each role in a deterministic tabular format. The device is capable of performing only its designed functions•i.e., there is no hidden functionality. The only approved functions performed …
A.8 Security Policy The device vendor provides a user-available security policy that addresses the proper use of the device in a secure fashion, including information on key-management responsibilities, administrative responsibilities, device functionality, identification, and environmental requirements. The security policy must define the roles the device supports and indicate the services available for each role in a deterministic tabular format. The device is capable of performing only its designed functions•i.e., there is no hidden functionality. The only functions the device performs …
Modified
p. 44
Vendors manufacturing self-contained OEM products that are “bolt on” or drop in type modules
•i.e., fully functional PED modules integrating all required components
•for UPTs may choose to partner with final form factor vendors of those UPTs⎯e.g., automated fuel dispenser or kiosk vendors. The OEM vendor’s product may meet most of the overallUPT Security Requirements, and the OEM vendor may submit that product in conjunction with additional information from the final form factor vendor on behalf of that vendor, such as …
•i.e., fully functional PED modules integrating all required components
•for UPTs may choose to partner with final form factor vendors of those UPTs⎯e.g., automated fuel dispenser or kiosk vendors. The OEM vendor’s product may meet most of the overall
Vendors manufacturing self-contained OEM products that are “bolt on” or drop-in type modules
•i.e., fully functional PED modules integrating all required components
•for UPTs may choose to partner with final form factor vendors of those UPTs⎯e.g., automated fuel dispenser or kiosk vendors. The OEM vendor’s product may meet most of the overall “UPT” Security Requirements, and the OEM vendor may submit that product in conjunction with additional information from the final form factor vendor on behalf of that vendor
•such as AFD or …
•i.e., fully functional PED modules integrating all required components
•for UPTs may choose to partner with final form factor vendors of those UPTs⎯e.g., automated fuel dispenser or kiosk vendors. The OEM vendor’s product may meet most of the overall “UPT” Security Requirements, and the OEM vendor may submit that product in conjunction with additional information from the final form factor vendor on behalf of that vendor
•such as AFD or …
Modified
p. 44
The OEM vendor’s product cannot receive a UPT approval because the actual final form factor product may have additional cardholder interfaces⎯e.g., displays or data input devices⎯or other characteristics that are within the scope of the UPT Security Requirements. The final form factor vendor’s product would receive the UPT approval. The OEM vendor’s product would be assigned a separate approval number and would be listed separately; in addition, it would be listed as an approved component of the UPT product, similar …
The OEM vendor’s product cannot receive a UPT approval because the actual final form factor product may have additional cardholder interfaces⎯e.g., displays or data input devices⎯or other characteristics that are within the scope of the “UPT” Security Requirements. The final form factor vendor’s product would receive the UPT approval. The OEM vendor’s product would be assigned a separate approval number and would be listed separately; in addition, it would be listed as an approved component of the UPT product, similar …
Modified
p. 45
Table 5: Approval Class Descriptions Class Description Potential Features (see Table 7 in A.14 below for detail) EPP An approval class aimed at secure PIN entry and encryption modules in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader or rely upon external displays or card readers installed in the unattended device.
Table 6. Approval Class Descriptions Class Description Potential Features (see Table 8 in A.14 for details) EPP An Approval Class aimed at secure PIN entry and encryption modules in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device.
Modified
p. 45
An EPP is typically used in an unattended PIN-acceptance device for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary and a tamper-resistant/responsive or tamper-evident shell. At a minimum, a device submitted for EPP approval must contain a PIN-entry keypad along with its built-in secure cryptographic module. Original equipment manufacturers (OEMs) or providers of encrypting PIN pads (EPPs) to unattended PIN- acceptance device manufacturers⎯e.g., ATMs or UPTs⎯and other self-service device …
An EPP is typically used in an unattended PIN-acceptance device for PIN entry and is controlled by a device controller. An EPP has a clearly-defined physical and logical boundary and a tamper-resistant/responsive or tamper-evident shell. At a minimum, a device submitted for EPP approval must contain a PIN-entry keypad along with its built-in secure cryptographic module. Original equipment manufacturers (OEMs) or providers of encrypting PIN pads (EPPs) to unattended PIN- acceptance device manufacturers⎯e.g., ATMs or UPTs⎯and other self-service device types …
Modified
p. 45
PIN support PIN Encryption Key Management SRED Key Management Prompt Control PIN-Entry technology ICCR MSR CTLS Display SRED OP Supports ISO Format 4 Interface Isolation
PIN support PIN Encryption Key Management SRED Key Management Prompt Control PIN-Entry technology ICCR MSR CTLS BR Display SRED OP Third-Party Applications Supports ISO Format 4 Interface Isolation
Modified
p. 45
• Bluetooth Interface Isolation HSM HSMs may support a variety of payment processing and cardholder authentication applications and processes. The processes relevant to the full set of requirements outlined in this document are:
• Wi-Fi PQC HSM HSMs may support a variety of payment processing and cardholder authentication applications and processes. The processes relevant to the full set of requirements outlined in this document are:
Modified
p. 46
• Export of a key from one secure cryptographic device (SCD) to another SCD in clear-text, component, or enciphered form;
• Export of a key from one secure cryptographic device (SCD) to another SCD in cleartext, component, or enciphered form;
Modified
p. 46
• Temporary storage of the key in clear-text, component, or enciphered form within an SCD during transfer.
• Temporary key storage in cleartext, component, or enciphered form within an SCD during transfer.
Modified
p. 46
Multi- tenant HSMs intended for multi-tenant usage•i.e., multi- organizational usage.
Multi- Tenant HSMs intended for multi-tenant usage•i.e., multi- organizational usage.
Modified
p. 46
Remote Administration Restricted Unrestricted Supports ISO Format 4 Remote-managed HSM Non-PED An approval class of POI devices that does NOT allow the entry of a PIN for a payment card transaction. This class is for ALL POI devices or device combinations, attended or unattended, which do not support PIN-based payment transactions. OEM product types may require further integration into a POI terminal.
Remote Administration Restricted Unrestricted Supports ISO Format 4 Remote-managed HSM Non-PED An Approval Class of POI devices that does not allow the entry of a PIN for a payment card transaction. This class is for all POI devices or device combinations, attended or unattended, that do not support PIN-based payment transactions. OEM product types may require further integration into a POI terminal.
Modified
p. 46
The device or any combination of hardware can be used as evaluated to operate in an acquirer network. The firmware must include an acquirer-approved payment application necessary for its operation.
The device or any combination of hardware can be used (as evaluated) to operate in an acquirer network. The firmware must include an acquirer-approved payment application necessary for its operation.
Modified
p. 46
Non-PED POI devices intended for use in an attended environment must be self-contained, fully functional units that are capable of processing payment transactions and must include a merchant interface necessary for their operation.
Non-PED POI devices intended for use in an attended environment must be self-contained, fully functional units that are capable of processing payment transactions, and must include a merchant interface necessary for their operation.
Modified
p. 46
Non-PED POI devices (terminals) are validated to the Secure Reading and Exchange of Data requirements and, if applicable, the Open Protocols requirements. These non-PED POI devices are NOT approved for PIN acceptance.
Non-PED POI devices (terminals) are validated to the “Secure Reading and Exchange of Data” requirements and, if applicable, the “Open Protocols” requirements. These non- PED POI devices are not approved for PIN acceptance.
Modified
p. 46
SRED Key Management Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi
• Bluetooth Interface Isolation
• Wi-Fi
SRED Key Management Third-Party Applications Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi
• Bluetooth Interface Isolation
• Wi-Fi
Modified
p. 47
PIN support PIN Encryption Key Management SRED Key Management Prompt control PIN-Entry Technology Display SRED Supports ISO Format 4 Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi RAP This is for platforms that are used for remote administration of HSMs. Such administration includes device configuration and may also includeclear-text cryptographic key-loading services as part of the same SCD.
• Bluetooth Interface Isolation
• Wi-Fi RAP This is for platforms that are used for remote administration of HSMs. Such administration includes device configuration and may also include
PIN support PIN Encryption Key Management SRED Key Management Prompt control PIN-Entry Technology Display SRED Third-Party Applications Supports ISO Format 4 Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi RAP This is for platforms that are used for remote administration of HSMs. Such administration includes device configuration and may also include cleartext cryptographic key-loading services as part of the same SCD.
• Bluetooth Interface Isolation
• Wi-Fi RAP This is for platforms that are used for remote administration of HSMs. Such administration includes device configuration and may also include cleartext cryptographic key-loading services as part of the same SCD.
Modified
p. 48
• May be defined as an OEM product type to be integrated into a POI terminal or ATM.
• May be defined as an OEM product-type to be integrated into a POI terminal or ATM.
Modified
p. 48
OEM product types may contain a payment application and be capable of stand-alone usage or can be a slave device to process account data securely (SRED) and, if applicable, perform offline PIN verification and require connection to a secure module, terminal, or PIN pad.
OEM product-types may contain a payment application and be capable of stand-alone usage, or can be a child device to process account data securely (SRED) and, if applicable, perform offline PIN verification and require connection to a secure module, terminal, or PIN pad.
Modified
p. 48
SCRs must meet, as applicable, the ICCR, MSR, CTLS, and/or BR requirements designated in Appendix B of the PCI PTS POI Security Requirements and the “Secure Reading and Exchange of Data” requirements. If the device is capable of communicating over an IP network or uses a public domain protocol (such as but not limited to Wi-Fi or Bluetooth), then requirements specified in the “Open Protocols” requirements must also be met. Other requirements, such as B1 “Self-tests,” and B9 “Random Numbers,” …
Modified
p. 48
If a SCR supports offline PIN authentication via an ICCR component or it formats and encrypts a PIN block to send online directly to the host•it must be validated in conjunction with a specific PIN entry device⎯e.g., PED or EPP⎯to validate the security of the interaction, including the establishment of the keying relationship. The PIN entry device must either be previously approved or obtain approval concurrent with the SCR in the same or a concurrent, separate Laboratory evaluation.
If an SCR supports offline PIN authentication via an ICCR component or it formats and encrypts a PIN block to send online directly to the host, it must be validated in conjunction with a specific PIN-entry device⎯e.g., PED or EPP⎯to validate the security of the interaction, including the establishment of the keying relationship. The PIN-entry device must either be previously approved or obtain approval concurrent with the SCR in the same, or a concurrent, separate Laboratory evaluation.
Modified
p. 48
PIN Encryption Key Management is only applicable where the SCR does PIN translation in connection with sending the PIN online to a host and must meet the determining keys requirements.
PIN Encryption Key Management is only applicable where the SCR does PIN translation in connection with sending the PIN online to a host, and must meet the determining keys’ requirements.
Modified
p. 49
• A hybrid reader that includes a magnetic stripe card reader and contact and/or contactless chip card functionality SCRPs must meet as applicable the ICCR requirements designated in Appendix B of the PCI PTS POI Security Requirements and the Secure Reading and Exchange of Data requirements. If the device is capable of communicating over an IP network or uses a public domain protocol (such as but not limited to Wi-Fi or Bluetooth), it must meet the applicable Open Protocols requirements. …
• A hybrid reader that includes a magnetic-stripe card reader and contact and/or contactless chip card functionality SCRPs must meet, as applicable, the ICCR requirements designated in Appendix B of the PCI PTS POI Security Requirements and the “Secure Reading and Exchange of Data” requirements. If the device is capable of communicating over an IP network or uses a public domain protocol (such as but not limited to Wi-Fi or Bluetooth), it must meet the applicable “Open Protocols” requirements. Other …
Modified
p. 49
SCRPs perform PIN translation from PIN blocks received from the payment application on the COTS device to a PIN block either for conveyance to the processing host or for offline verification to the contact chip card.
SCRPs perform PIN translation from PIN blocks received from the payment application on the COTS device to a PIN block, either for conveyance to the processing host or for offline verification to the contact chip card.
Modified
p. 49
PIN support PIN Encryption Key Management SRED Key Management ICCR MSR CTLS SRED OP Supports ISO Format 4 Interface Isolation
PIN support PIN Encryption Key Management SRED Key Management ICCR MSR CTLS BR SRED OP Supports ISO Format 4 Interface Isolation
Modified
p. 49
• Bluetooth Interface Isolation UPT The UPT class of device covers cardholder-operated payment devices that read, capture, and transmit card information in conjunction with an unattended self-service device, including, but not limited to, the following:
• Wi-Fi PQC UPT The UPT class of device covers cardholder-operated payment devices that read, capture, and transmit card information in conjunction with an unattended self-service device, including, but not limited to, the following:
Modified
p. 49
• Automated Fuel Dispenser
Modified
p. 49
• Vending Machine UPTs may have a compound architecture directly combining payments and the delivery of services and/or goods.
Modified
p. 50
A.13 Expiry Date The expiration date for PCI SSC-approved devices is the date upon which the device’s approval expires. All device approvals expire in accordance with the schedule below.
A.13 Expiry Date The expiration date for PCI SSC-approved devices is the date upon which the device’s approval expires. All device approvals expire in accordance with the following schedule.
Modified
p. 50
Table 6: Approval Expiry Dates Requirements Version Used During Evaluation at Laboratory Expiration of Requirements Approval Expiration of Device Models Version 4.x of PCI PTS HSM Modular Security Requirements
Table 7. Approval Expiry Dates Requirements Version Used During Evaluation at Laboratory Expiration of Requirements Approval Expiration of Device Models Version 7.x of PCI PTS POI Modular Security Requirements
Modified
p. 50
POI v6 firmware expires three years from the date of approval but shall not expire past the overall approval expiration of the device.
POI v6 or higher firmware expires three years from the date of approval but shall not expire past the overall approval expiration of the device.
Removed
p. 51
Note: All newly approved offline PIN verification POIs must support both plaintext and enciphered PIN verification.
However, under current testing, all newly evaluated offline POI devices must support both plaintext and enciphered PIN verification.
However, under current testing, all newly evaluated offline POI devices must support both plaintext and enciphered PIN verification.
Modified
p. 51
Table 7: Specific Features Feature and Applicability Description PIN Support (EPP, PED, SCR, SCRP, UPT) “PIN support” denotes the type of PIN entry verification that can be supported by the POI.
Table 8. Specific Features Feature and Applicability Description PIN Support (EPP, PED, SCR, SCRP, UPT) “PIN support” denotes the type of PIN-entry verification that can be supported by the POI.
Modified
p. 51
“Online” represents that the POI has the capability to support online PIN verification by the payment card’s issuer or its designated processor. To pass testing, POIs that support online PIN entry must support the use of TDES or AES to protect the PIN. Additionally, if the PIN needs to be protected during transport in nonintegrated offline POIs, then the POI must support the use of TDES or AES for that channel. “Offline” means that the POI has the capability to …
“Online” represents that the POI can support online PIN verification by the payment card’s issuer or its designated processor. To pass testing, POIs that support online PIN entry must support the use of TDES or AES to protect the PIN. Additionally, if the PIN needs to be protected during transport in non- integrated offline POIs, then the POI must support the use of TDES or AES for that channel. “Offline” means that the POI can support offline PIN verification by …
Modified
p. 51
Unless otherwise noted, the “Offline” designation, without any suffix, in the Approved Device List represents that the POI has the capability to support both plaintext and enciphered offline PIN verification. The “Offline (p)” designation with the “(p)” as a suffix represents that the offline POI has the capability of performing only plaintext offline PIN verification.
Unless otherwise noted, the “Offline” designation, without any suffix, in the Approved Device List, represents that the POI can support both cleartext and enciphered offline PIN verification. The “Offline (c)” designation with the “(c)” as a suffix represents that the offline POI can perform only cleartext offline PIN verification. The “Offline (e)” designation with the “(e)” as a suffix represents that the offline POI has the capability of performing only enciphered offline PIN verification.
Modified
p. 52
Where AES is used, that will be explicitly noted in conjunction with the MK/SK, DUKPT and/or Fixed Key methodologies.
Where AES is used, it will be explicitly noted in conjunction with the MK/SK, DUKPT, and/or Fixed Key methodologies.
Modified
p. 52
Where AES is used, that will be explicitly noted in conjunction with the MK/SK, DUKPT and/or Fixed Key methodologies.
Where AES is used, it will be explicitly noted in conjunction with the MK/SK, DUKPT, and/or Fixed Key methodologies.
Modified
p. 52
DUKPT is the only unique key per transaction (UKPT) algorithm (ANSI X9.24) that PCI SSC recognizes and approves; all other forms of UKPT tested by the Laboratory will not be depicted in the approval letter or on “Approved PTS Devices” on the Website.
DUKPT is the only unique- key-per-transaction (UKPT) algorithm (ANSI X9.24) that PCI SSC recognizes and approves; all other forms of UKPT tested by the Laboratory will not be depicted in the approval letter or on “Approved PTS Devices” on the Website.
Modified
p. 52
This is for POI devices supporting the entry of online PINs, and in general, this will be N/A for devices in the Non-PED or SCR approval classes and will be N/A for offline PIN-only devices. SCRPs can indirectly support online PIN in connection with mobile-based solutions via PIN translation.
This is for POI devices supporting the entry of online PINs, and in general, this will be N/A for devices in the Non-PED or SCR Approval Classes, and will be N/A for offline PIN-only devices. SCRPs can indirectly support online PIN in connection with mobile-based solutions via PIN translation.
Modified
p. 52
PIN Encryption Key Management is only applicable for SCRs where the SCR does PIN translation in connection with sending the PIN online to a host.
For SCRs, PIN encryption key management only applies where the SCR does PIN translation in connection with sending the PIN online to a host.
Modified
p. 52
Note: POI v5 and v6 devices used for online PIN must support ISO PIN Block Format 4 (AES).
Note: POI v5 and higher devices used for online PIN must support ISO PIN Block Format 4 (AES).
Modified
p. 52
SRED Key Management (EPP, PED, SCR, SCRP, UPT) “SRED key management” denotes whether the Laboratory has successfully evaluated the payment security device to support the use of Triple DES (TDES) or AES for Account Data encryption. TDES requires use of at least a triple-length key or DUKPT for account data encryption.
SRED Key Management (EPP, PED, SCR, SCRP, UPT) “SRED key management” denotes whether the Laboratory has successfully evaluated the payment security device to support using Triple DES (TDES) or AES for account-data encryption. TDES requires using at least a triple-length key or DUKPT for account-data encryption.
Modified
p. 52
Format-preserving encryption (FPE) shall be denoted where one of the ANSI, ISO or NIST approved algorithms are used.
Format-preserving encryption (FPE) shall be denoted where one of the ANSI, ISO, or NIST-approved algorithms are used.
Modified
p. 53
• Vendor-controlled: The end-user, acquirer, or reseller cannot modify the POI’s firmware or POI’s payment application to make changes to the device’s prompts or PIN-entry controls. Only the POI’s original equipment manufacturer has the capability to modify the prompts and controls for PIN entry.
• Vendor-controlled: The end-user, acquirer, or reseller cannot modify the POI’s firmware or POI’s payment application to make changes to the device’s prompts or PIN-entry controls. Only the POI’s original equipment manufacturer can modify the prompts and controls for PIN entry.
Modified
p. 53
• Acquirer-controlled: The original equipment manufacturer has shipped the POI with mechanisms for controlling the POI display and its use in place. These mechanisms can be employed to unlock the POI for updates of the prompts by the acquirer, using proper cryptographically controlled processes as defined in the applicable POI security requirement. The reseller or end- user, if authorized by the acquirer, can also make updates using proper cryptographically controlled processes.
• Acquirer-controlled: The original equipment manufacturer has shipped the POI with mechanisms for controlling the POI display and its use in place. These mechanisms can be employed to unlock the POI for updates to the prompts by the acquirer, using proper cryptographically-controlled processes as defined in the applicable POI security requirement. The reseller or end- user, if authorized by the acquirer, can also make updates using proper cryptographically-controlled processes.
Modified
p. 53
Prompt control is not applicable for devices without a display.
Modified
p. 53
Devices must be deployed locked. In any case, the acquiring customer is always responsible to ensure that appropriate processes and documented procedures are in place to control the POI display and usage.
Devices must be locked when deployed. In any case, the acquiring customer is always responsible to ensure that appropriate processes and documented procedures are in place to control the POI display and usage.
Modified
p. 53
PIN-Entry Technology (EPP, PED, UPT) “PIN-entry technology” denotes which technology is implemented in order to capture the cardholder PIN. The value for this field can be:
PIN-Entry Technology (EPP, PED, UPT) “PIN-entry technology” denotes which technology is implemented to capture the cardholder PIN. The value for this field can be:
Modified
p. 53
• Physical keypad: Set of buttons arranged in a block which bears digits and optionally letters, in conformance with ISO 9564.
• Physical keypad: Set of buttons arranged in a block, which bears digits and (optionally) letters, in conformance with ISO 9564.
Modified
p. 53
• Touch screen: Display that can detect the presence and location of a touch within the display area and enable the cardholder entering his or her PIN.
• Touch screen: Display that can detect the presence and location of a touch within the display area and enables the cardholder to enter their PIN.
Modified
p. 53
Approved Components (PED, RAP, UPT) “Approved components” contains, when relevant, the list of approved components that are part of the approved device, and which have successfully undergone a distinct evaluation. Each component is listed with its approval number. The use of a device with components⎯e.g., EPPs, card readers⎯that are different than that listed as an approved component for that device invalidates that device’s approval. RAP devices may be listed as an approved component of one or more associated HSMs. For …
Approved Components (PED, RAP, UPT) “Approved components” contains, when relevant, the list of approved components that are part of the approved device, and which have successfully undergone a distinct evaluation. Each component is listed with its approval number.
Modified
p. 54
Note: Contactless readers are only considered compliant for P2PE usage if the device in question has been validated to SRED. Furthermore, some device approvals may have versions validated to SRED and some that are not. Where such a mix occurs, only devices using a firmware version designated for SRED are validated to meet the contactless reader Security Requirements. For devices with contactless readers using firmware that is not validated to SRED, the contactless readers are not validated to any Security …
Modified
p. 54
• SRED: The device has met the applicable Secure Reading and Exchange of Data requirements.
• SRED: The device has met the applicable “Secure Reading and Exchange of Data” requirements.
Modified
p. 54
• OP: The device has met the applicable Open Protocols requirements.
• OP: The device has met the applicable “Open Protocols” requirements.
Modified
p. 54
• Remote Administration: The HSM has been evaluated in conjunction with a remote administration solution and assessed against all requirements from the “Remote Administration” column in Appendix B of the HSM Security Requirements. Additionally, for v4 and higher HSMs, the HSM itself meets the Remote-Managed HSM Security Requirements as delineated in Appendix B of the HSM Security Requirements.
• Remote Administration: The HSM has been evaluated in conjunction with a remote administration solution and assessed against all requirements from the “Remote Administration” column in Appendix B of the HSM Security Requirements. Additionally, for v4 and higher HSMs, the HSM itself meets the “Remote-Managed HSM” Security Requirements as delineated in Appendix B of the HSM Security Requirements.
Removed
p. 55
• Remote-managed HSM Devices must support key blocks using the ANSI X9.143 key-derivation methodology for TDES keys, and for AES keys, must support either the X9.143 methodology or the ISO 20038 methodology. In either case, equivalent methods can be used where subject to an independent expert review and where that review is publicly available. The link provided here is where a vendor who implements a proprietary method has had that method validated in accordance with PCI-prescribed criteria as equivalent.
Modified
p. 55
• Approval is valid only when 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.
• Approval is valid only when deployed in controlled environments or more robust environments⎯e.g., secure environments⎯as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy.
Modified
p. 55
Devices supporting ISO PIN Block Format 4 (AES) will be noted here. For additional information on whether the MK/SK, DUKPT or Fixed Key methodologies are supported for AES PIN Blocks, see the Key Management section. POI v5 and higher devices supporting online PIN and HSM v4 and higher devices supporting PIN processing are required to support ISO PIN Block Format 4.
Devices supporting ISO PIN Block Format 4 (AES) will be noted here. For additional information on whether the MK/SK, DUKPT, or Fixed Key methodologies are supported for AES PIN Blocks, see the “Key Management” section. POI v5 and higher devices supporting online PIN, and HSM v4 and higher devices supporting PIN processing are required to support ISO PIN Block Format 4.
Modified
p. 55
• Interface Isolation In addition, v4 HSMs that meet additional criteria to support remote⎯e.g., non- console⎯administration for configuration and cryptographic key loading, will be noted here as “Remote-managed HSM.” Requirements for Remote-managed HSMs are a subset of those for Multi-tenant HSMs
• Interface Isolation In addition, v4 HSMs that meet additional criteria to support remote⎯e.g., non- console⎯administration for configuration and cryptographic key loading, will be noted here as “Remote-managed HSM.” Requirements for Remote-managed HSMs are a subset of those for Multi-tenant HSMs.
Modified
p. 57
PCI SSC recognizes that vendors may need to make maintenance fixes to PTS validated devices that the vendor has already sold but still supports. In addition, vendors may wish to port updated versions of validated firmware that were assessed against newer versions of the Security Requirements to products for which the approval has expired. This may occur when customers wish to standardize their deployments against a given version of firmware and/or to add functionality to those devices.
PCI SSC recognizes that vendors may need to make maintenance fixes to PTS-validated devices that the vendor has already sold but still supports. In addition, vendors may wish to port updated versions of validated firmware that were assessed against newer versions of the Security Requirements to products for which the approval has expired. This may occur when customers wish to standardize their deployments against a given version of firmware and/or to add functionality to those devices.
Modified
p. 57
Evaluation of deltas involve the PTS Lab assessing the changes based upon the most current major version of the Security Requirements used for the original evaluation and the most current Technical FAQ publication associated with those requirements. For example, if a device was originally assessed against PTS POI v6.0, any delta evaluation would have to be performed using the most current version of PTS v6.x and the last issued v6.x FAQs. Examples of deltas include:
Evaluation of deltas involves the PTS Lab assessing the changes based upon the most current major version of the Security Requirements used for the original evaluation and the most current Technical FAQ publication associated with those requirements. For example, if a device was originally assessed against PTS POI v6.0, any delta evaluation would have to be performed using the most current version of PTS v6.x and the last issued v6.x FAQs. Examples of deltas include:
Modified
p. 57
• Revisions to existing firmware or hardware on previously approved devices to add, modify, or delete functionality1.
• Revisions to existing firmware or hardware on previously-approved devices to add, modify, or delete functionality1.
Modified
p. 57
• Adding EMV Level 1 to an existing approval.
• Adding EMV® Level 1 to an existing approval.
Modified
p. 57
Delta evaluations are not permitted to take a product previously approved by PCI SSC under an earlier major version number of the PTS POI Standard
•e.g., 5.x
•to an approval under another major version number
•e.g., 6.x.
•e.g., 5.x
•to an approval under another major version number
•e.g., 6.x.
Delta evaluations may not take a product previously approved by PCI SSC under an earlier major version number of the PTS POI Standard
•e.g., 5.x
•to an approval under another major version number
•e.g., 6.x.
•e.g., 5.x
•to an approval under another major version number
•e.g., 6.x.
Modified
p. 58
B.3 Determining Whether a Delta is Permissible The potential for changes and their impacts cannot be identified in advance. Changes need to be assessed on a case-by-case basis. Vendors should contact one of the PTS Labs for guidance. PTS Labs shall consult with PCI SSC on an as-needed basis in advance of submitting a delta report to determine whether a set of changes is too great to be addressed under the delta process. The Laboratories will determine whether the change …
B.3 Determining Whether a Delta is Permissible The potential for changes and their impacts cannot be identified in advance. Changes need to be assessed on a case-by-case basis. Vendors should contact one of the PTS Labs for guidance. PTS Labs shall consult with PCI SSC on an as-needed basis before submitting a delta report to determine whether a set of changes is too great to be addressed under the delta process. The Laboratories will determine whether the change impacts security. …
Modified
p. 58
B.3.1 Sample Impacts of Certain Changes The following subsections itemize a non-exhaustive list of example changes that, taken individually, are permissible for consideration through the delta process. The inclusion of too many such changes, especially when considering a series of changes to the device’s hardware, must be considered as a new device requiring a full evaluation to the latest version of the current PTS Standard.
B.3.1 Sample Impacts of Certain Changes The following subsections itemize a non-exhaustive list of example changes that, taken individually, are permissible for consideration through the delta process. Including too many such changes, especially when considering a series of changes to the device’s hardware, must be considered as a new device requiring a full evaluation against the latest version of the current PTS Standard.
Modified
p. 58
B.3.2 Firmware Changes In general, any and all changes made to the firmware that runs on a previously PCI SSC-approved PTS Device may be considered in a single delta evaluation except where the change is viewed as too pervasive, such as a change in the OS•e.g., changing from a proprietary to an open-based system. The following table identifies different types of firmware changes and the PTS requirements that, at a minimum, should be considered when assessing each type of change. …
B.3.2 Firmware Changes In general, any change made to the firmware that runs on a previously PCI SSC-approved PTS Device may be considered in a single delta evaluation, except where the change is viewed as too pervasive, such as a change in the OS•e.g., changing from a proprietary to an open-based system. However, adding a firmware variant (e.g., two versions of Linux) is allowed and requires that all logical requirements be validated as if it were a new evaluation.
Modified
p. 59
Table 8: Firmware Change Types and Impacted Requirements Acceptable firmware changes that may be considered in a delta evaluation include, but are not limited to:
Table 9. Firmware Change Types and Impacted Requirements Acceptable firmware changes that may be considered in a delta evaluation include, but are not limited to:
Modified
p. 59
Firmware Change Types Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x v6.x Any firmware change B3 B3 B3, F1, G1, Changes in tamper management, for example, response, detection, and recovery B1 B1 B1 B1 B1 B1 Error handling⎯i.e., buffer overflows A5, B2 A3, B2 A3, B2 A3, B2 A2, B2 A3, D1 Amendments to external communications protocols B2 B2 B2, F1, G1, B2, F1 B2, F1 D1, D2 Change to software/firmware update mechanisms B3, B4 B3, B4 …
Firmware Change Types Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x v6.x v7.x Any firmware change B3 B3 B3, F1, G1, H1, B20, D2, E2 Changes in tamper management, for example, response, detection, and recovery B1 B1 B1 B1 B1 B1 B1 Error handling⎯i.e., buffer overflows A5, B2 A3, B2 A3, B2 A3, B2 A2, B2 A3, D2 A3, D2 Amendments to external communications protocols B2 B2 B2, F1, G1, H1, B2, F1 B2, F1 D1, D2 …
Modified
p. 60
N/A N/A B17-19, B2.1, B2.2, B4, B5, B6, B7, B9, B10, B12, B16, B16.1, B16.2, B17, B19, B22−B26, A2, A4, A6, A7, A10-A14, B.3.3 Hardware Changes Changes made by vendors to the hardware of previously PCI SSC-approved PTS Devices are permissible only if the scope of such changes is limited. The following table identifies different types of hardware changes and the PTS requirements that, at a minimum, should be considered when assessing each type of change. PTS Labs assessing such …
N/A N/A B17-19, A2, A4, A6, A7, A10- A14, B1, B2, B2.1, B2.2, B4-B7, B9, B10, B12, B16, B17, B19, B22- A6, A7, A10-14, B2.1, B2.2, B4- B10, B12, B16, B17, B19, B22- B26, D1 B.3.3 Hardware Changes Changes made by vendors to the hardware of previously PCI SSC-approved PTS Devices are permissible only if the scope of such changes is limited. The following table identifies different types of hardware changes and the PTS requirements that, at a minimum, should …
Modified
p. 60
The inclusion of more than four (4) of the identified hardware change types as delineated in the table below in a single delta submission for a previously PCI SSC-approved PTS POI Device may effectively represent a new device that should be subjected to its own full evaluation against the latest version of the current PTS Standard. Candidates for delta submissions that surpass this threshold which, in the opinion of the PTS Lab, represent a minor change to the approved PTS …
The inclusion of more than four (4) of the identified hardware change-types as delineated in the table below in a single delta submission for a previously PCI SSC-approved PTS POI Device may effectively represent a new device that should be subjected to its own full evaluation against the latest version of the current PTS Standard. Candidates for delta submissions that surpass this threshold, which, in the opinion of the PTS Lab, represent a minor change to the approved PTS POI …
Removed
p. 61
Replacing a PCB does not count as a single change. All changes related to the PCB change need to be taken into account. For example, changing the PCB re-routes the tamper grid and signals. That would count as one. Moving a processor would also count as a change and needs to be assessed accordingly. Any other security-relevant changes resulting from the change in the PCB would also add toward the change count.
Modified
p. 61
For example, a vendor makes a change to the tamper grids and signal routing on six PCBs within a device. According to the delta scoping guidance, the inclusion of four or more hardware change types in a single delta submission for a previously PCI SSC-approved PTS POI Device may effectively represent a new device that should be subject to its own full evaluation against the latest version of the current PTS Standard. In this example, this does not count as …
For example, a vendor makes a change to the tamper grids and signal routing on six PCBs within a device. According to the delta scoping guidance, the inclusion of four or more hardware change-types in a single delta submission for a previously PCI SSC-approved PTS POI Device may effectively represent a new device that should be subject to its own full evaluation against the latest version of the current PTS Standard. In this example, this does not count as six …
Modified
p. 61
A device submitted with internal hardware changes sufficient to require a new evaluation⎯but with no external changes⎯cannot be submitted as a delta, even though the external appearance is identical. The degree of changes made internally requires that the device receive a full evaluation against the currently available requirements version for use in new evaluations. If the evaluation is successful, it will result in a new approval number. Furthermore, while the new device will have a different hardware version than the …
A device submitted with internal hardware changes sufficient to require a new evaluation⎯but with no external changes⎯cannot be submitted as a delta, even though the external appearance is identical. The degree of changes made internally requires that the device receive a full evaluation against the currently-available requirements version for use in new evaluations. If the evaluation is successful, it will result in a new approval number. Furthermore, while the new device will have a different hardware version than the existing …
Modified
p. 61 → 62
Any change made to the hardware of a PCI SSC-approved PTS device, even to the non-security related components, has the potential to impact the security of the device directly or indirectly. As such, any delta evaluation that includes modifications to the approved device’s hardware
•even the circuitry not related to the security functions of the device
•must, at a minimum, be reviewed by the PTS Lab with respect to the potential impact. For example, for POIdevices the following requirements of the …
•even the circuitry not related to the security functions of the device
•must, at a minimum, be reviewed by the PTS Lab with respect to the potential impact. For example, for POI
Any change made to the hardware of a PCI SSC-approved PTS device, even to the non-security- related components, has the potential to impact the device security directly or indirectly. As such, any delta evaluation that includes modifications to the approved device’s hardware
•even to the circuitry not related to the security functions of the device
•must, at a minimum, be reviewed by the PTS Lab with respect to the potential impact. For example, for POI devices, the following requirements of the applicable …
•even to the circuitry not related to the security functions of the device
•must, at a minimum, be reviewed by the PTS Lab with respect to the potential impact. For example, for POI devices, the following requirements of the applicable …
Modified
p. 62 → 63
Table 9: Acceptable Hardware Changes Acceptable hardware changes that may be considered in a delta evaluation include, but are not limited to:
Table 10. Acceptable Hardware Changes Acceptable hardware changes that may be considered in a delta evaluation include, but are not limited to:
Modified
p. 62 → 63
Hardware Change Types Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x V6.x Any hardware change2 A1, A2, A1, A7 A1, A7 A1, A6, B2, B20 A1, A5, B2, B20 A1, A2, A6, A7, B20, D2 Changes in casing plastics⎯e.g., cover-opening dimensions, areas that permit internal access⎯or output-only displays. Amended devices must remain consistent to the device’s original form factor and visible characteristics.3 A4, A7, A9−A11, A2, A6, A8−A11, A2, A6, A8−A11, B16, D1−D4, A5, A7−A9, A11, B16, …
Hardware Change Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x v6.x v7.x Any hardware change2 A1, A2, A1, A7 A1, A7 A1, A6, B2, B20 A1, A5, B2, B20 A1, A2, A6, A7, B20, D2 A1, A2, A6, A7, B20, D2 Changes in casing plastics⎯e.g., cover- opening dimensions, areas that permit internal access⎯or output-only displays. Amended devices must remain consistent with the device’s original form factor and visible characteristics.3 A4, A7, A9−A11, A2, A6, A8−A11, A2, A6, …
Modified
p. 62 → 63
A5, D1 A2, A3, A11, D1 A2, A3, A10, D1 Modifications or replacement of any processor used by the device. 4 A5, A6, A7, A9, B1-B10, A3, A4, A6, A8, B1-B15, A3, A4, A6, A8, A11, B1-B19, A3, A4, A5, A7, A10, B2−B19, A2, A3, A4, A6, A9, B2−B19, A3, A4, A5, A6, A7, B2- B19, B21 2 This item is not to be included in the count of changes when determining whether the number of changes in a single …
A5, D1 A2, A3, A11, D1 A2, A3, A10, D1 2 This item is not to be included in the count of changes when determining whether the number of changes in a single delta submission is within the acceptable range of four (4). Any hardware change requires a change in hardware version number done in accordance with Appendix A.
Removed
p. 63
A5-A7, A9, B2, B8, D1, A3, A4, A6, A8, A11, B2, A3, A4, A6, A8, A10, B2, B7, B16, A2-A5, A7, A9, B7, B16, A2-A4, A6, A8, B7, B16, A3, A5, A7, A8, A10, A13, B5, B15, B21, D12, Modifications to major components (other than communications or power) of the PCB circuitry⎯e.g., audio circuitry, heater circuitry, printer, display etc.,⎯as well as addition or removal of a PCB (or FPCB). 6, A5, A8 A3, A5 A3, A5 A3, A11 A2, A10 A3, B5 5 Each reader change counts as a separate hardware change•e.g., if both the MSR and ICCR are changed, that counts as two separate hardware changes. However, a change involving a hybrid reader counts as only one hardware change.
Modified
p. 63 → 64
A2, A6, A8, A9, A11, D1 A2, A6, A8-A10, B16, D1 A5, A7- A9, A11, A4, A6- A8, A10, A5, A8- A10, B5, B15, A13 Replacement or addition of any one reader.5 D1-4 A10, A11, A10, D1-D4, A9, D1-D4 K1-K2 A8, D1-D4 K1-K2 Modifications to communications circuitry.
A2, A6, A8, A9, A11, D1 A2, A6, A8-A10, B16, D1 A5, A7- A9, A11, A4, A6- A8, A10, A10, A13, B5, A10, A13, B5, Replacement or addition of any one reader.5 D1-D4 A10, A11, D1- A10, D1-D4, A9, D1-D4 K1-K2 Modifications to communications circuitry.
Modified
p. 63 → 64
A5 A3 A3 A3 A2 A3 A3 Changes in PCB or FPCB stack-up⎯e.g., adding or removing layers, shuffling layers⎯and/or change in PCB geometry⎯e.g., board outline, thickness.
Modified
p. 64 → 65
B.5 Delta Documentation Requirements B.5.1 Reporting Guidance for PTS Vendors All changes made to PCI SSC-approved PTS Devices must be disclosed by the PTS vendor. It is recommended PTS vendors submit a Change Analysis document to the PTS Lab that contains the following information at a minimum:
B.5 Delta Documentation Requirements B.5.1 Reporting Guidance for PTS Vendors All changes made to PCI SSC-approved PTS Devices must be disclosed by the PTS vendor. It is recommended that PTS vendors submit a Change Analysis document to the PTS Lab that contains the following information, at a minimum:
Modified
p. 64 → 65
• Details of the currently approved PTS Device on the Approved Device List that is being used as a reference for the evaluation;
• Details of the currently-approved PTS Device on the Approved Device List that is being used as a reference for the evaluation;
Modified
p. 64 → 65
• Explanation of how and why PTS Security Requirements are impacted;
• Explanation of how and why PTS Security Requirements are impacted; 6 This excludes rerouting of circuits.
Modified
p. 64 → 66
• Description of how the identification (versioning) of the change fits into vendor’s configuration- control methodology.
• Description of how the identification (versioning) of the change fits into the vendor’s configuration-control methodology.
Modified
p. 64 → 66
B.5.2 Reporting Requirements for PTS Labs Delta evaluation reports must present all relevant information on changes and changes’ evaluation, equivalent to the levels of detail specified in DTRs. PTS Labs must provide the following documentation with each delta submission:
B.5.2 Reporting Requirements for PTS Labs Delta evaluation reports must present all relevant information on changes and change evaluations, equivalent to the levels of detail specified in the DTRs. PTS Labs must provide the following documentation with each delta submission:
Removed
p. 65
B.6 Applicability of Technical FAQs During Delta Evaluations Technical FAQs are updated on a regular basis to not only add clarification to requirements in order to provide a consistent and level playing field in the applications of those requirements but may also address new security threats that have arisen. As such, Technical FAQs are generally effective immediately upon publication.
Modified
p. 65 → 66
• A table that depicts the following information about every change embodied in the update to the approved PTS Device from the previously approved configuration:
• A table that depicts the following information about every change to the approved PTS Device from the previously-approved configuration:
Modified
p. 65 → 66
• Updated responses to the affected PTS Security Requirements that clearly depict any changes that are necessary to the reference evaluations.
• Updated responses to the affected PTS Security Requirements that clearly depict any necessary changes to the reference evaluations.
Modified
p. 65 → 67
Furthermore, it is not sufficient for the Lab to determine that the change does not lessen the security of the device. Due to the evolution of threats and attack techniques from the time of the original evaluation (which may have occurred many years earlier), the Lab must determine that the device still meets the relevant Security Requirements impacted by the change, given the changes in attack vectors. This is because, whether deltas are done to enhance or fix functionality or …
Furthermore, it is not sufficient for the Lab to determine that the change does not lessen the device’s security. Due to the evolution of threats and attack techniques from the time of the original evaluation (which may have occurred many years earlier), the Lab must determine that the device still meets the relevant Security Requirements impacted by the change, given the changes in attack vectors. This is because, whether deltas are completed to enhance or fix functionality, or for other …
Modified
p. 65 → 67
In all cases, the PTS Lab performing the evaluation must advise PCI SSC of the circumstances, and PCI SSC will make the final decision based upon the circumstances. Additionally, for both new and delta evaluations, the PTS Lab will also state in their submission the version of the Security Requirements used in the evaluations, as well as the publication date of the technical FAQs used.
In all cases, the PTS Lab performing the evaluation must advise PCI SSC of the circumstances, and PCI SSC will make the final decision based upon the circumstances. Additionally, for both new and delta evaluations, the PTS Lab will also state in its submission the version of the Security Requirements used in the evaluations, as well as the publication date of the Technical FAQs used.
Modified
p. 66 → 67
In all cases, though, any Security Requirements impacted will be assessed, including those not previously applicable⎯e.g., if the new casing introduces additional cardholder-interface devices not present in the original evaluation.
In all cases, however, any Security Requirements impacted will be assessed, including those not previously applicable⎯e.g., if the new casing introduces additional cardholder-interface devices not present in the original evaluation.
Modified
p. 68 → 69
Primary Business Contact Contact Name Business Title Contact E-mail Contact Phone Secondary Business Contact Contact Name Business Title Contact E-mail Contact Phone Billing Contact (invoices will be sent to this individual/email address) Contact Name Business Title Contact E-mail Contact Phone Technical Contact Contact Name Business Title Contact E-mail Contact Phone
Primary Business Contact Contact Name Business Title Contact E-mail Contact Phone Secondary Business Contact Contact Name Business Title Contact E-mail Contact Phone Billing Contact (Invoices will be sent to this individual/e-mail address) Contact Name Business Title Contact E-mail Contact Phone Technical Contact Contact Name Business Title Contact E-mail Contact Phone
Modified
p. 70 → 71
The PTS vendor should complete all applicable sections and submit this document along with copies of all required validation documentation to PCIPTS@pcisecuritystandards.org per PCI SSC’s instructions for report submission as described in the PTS Device Testing and Approval Program Guide.
The PTS vendor should complete all applicable sections and submit this document, along with copies of all required validation documentation, to PCIPTS@pcisecuritystandards.org per PCI SSC’s instructions for report submission as described in the PTS Device Testing and Approval Program Guide.
Modified
p. 71 → 72
B: All hardware and firmware changes have been assessed by a PTS Lab in a report submitted to PCI SSC, including those hardware or firmware versions noted as using a validated wildcard versioning methodology. This includes for POI devices all vulnerabilities identified by the vendor in each of the protocols and interfaces defined in POI security requirement D1 as evidenced by the vulnerability assessment process enumerated under E10 through E12 of the POI DTRs.
B: All hardware and firmware changes have been assessed by a PTS Lab in a report submitted to PCI SSC, including those hardware or firmware versions noted as using a validated wildcard versioning methodology. This includes, for POI devices, all vulnerabilities identified by the vendor in each of the protocols and interfaces defined in POI Security Requirement D1 as evidenced by the vulnerability assessment process enumerated under E10 through E12 of the POI DTRs.
Modified
p. 73 → 74
Part 2. Device Approval Information For each applicable device, indicate hardware and firmware submission status as either: A: No modifications have been made to the hardware or firmware versions as listed on the Approved Device List; B: All hardware and firmware changes have been assessed by a PTS Lab in a report submitted to PCI SSC, including those hardware or firmware versions noted as using a validated wildcard versioning methodology.
Part 2. Device Approval Information For each applicable device, indicate hardware and firmware submission status as either: A: No modifications have been made to the hardware or firmware versions as listed on the Approved Device List. B: All hardware and firmware changes have been assessed by a PTS Lab in a report submitted to PCI SSC, including those hardware or firmware versions noted as using a validated wildcard versioning methodology.