Document Comparison
PTS_Program_Guide_v1-8.pdf
→
PTS_Program_Guide_v2.0.pdf
74% similar
56 → 73
Pages
18869 → 23743
Words
250
Content Changes
Content Changes
250 content changes. 85 administrative changes (dates, page numbers) hidden.
Added
p. 2
June 2020 1.9 Migrated program-related Technical FAQs; updated Appendix D, “PTS Attestation of Validation”; added Appendix E, “PTS Device Attestation”; eliminated Vendor Questionnaire; errata.
Added
p. 7
PCI-Recognized Laboratories List
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.
• “Approved Device List” means the list of PCI SSC-approved PIN Transaction Security Devices appearing on the Website.
• “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.
• “PCI-Recognized Laboratory” (also referred to as a “PTS Lab,” “Laboratory” or “Lab”) refers to a test laboratory that is at the time currently recognized and approved by PCI SSC for purposes of performing testing of PTS Devices for PTS Program purposes.
• “Technical FAQ” or “FAQ” means a technical frequently asked question posted and answered by PCI SSC on 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.
• “Approved Device List” means the list of PCI SSC-approved PIN Transaction Security Devices appearing on the Website.
• “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.
• “PCI-Recognized Laboratory” (also referred to as a “PTS Lab,” “Laboratory” or “Lab”) refers to a test laboratory that is at the time currently recognized and approved by PCI SSC for purposes of performing testing of PTS Devices for PTS Program purposes.
• “Technical FAQ” or “FAQ” means a technical frequently asked question posted and answered by PCI SSC on the Website.
• …
Added
p. 10
PCI SSC has established the PIN Transaction Security framework to address the security evaluation and approval of payment security devices.
All devices submitted for security evaluation and approval are to be evaluated against the applicable Security Requirements. The Approved Device List provides a full list of payment security devices recognized as meeting applicable PCI PTS Program requirements.
This process helps to ensure that all payment security devices can be evaluated under a common process and is intended to improve overall security for cardholder and other sensitive data. Resulting stakeholder benefits include:
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 …
All devices submitted for security evaluation and approval are to be evaluated against the applicable Security Requirements. The Approved Device List provides a full list of payment security devices recognized as meeting applicable PCI PTS Program requirements.
This process helps to ensure that all payment security devices can be evaluated under a common process and is intended to improve overall security for cardholder and other sensitive data. Resulting stakeholder benefits include:
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 …
Added
p. 14
An “N/A” response is acceptable in two cases:
1. Compliance is achieved by meeting another requirement option, if one exists.
2. The characteristics governed by the requirement are absent in the device. The Laboratory will verify through testing and review that all responses are appropriate.
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.
1. Compliance is achieved by meeting another requirement option, if one exists.
2. The characteristics governed by the requirement are absent in the device. The Laboratory will verify through testing and review that all responses are appropriate.
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.
Added
p. 18
Figure 3: PTS Device Change Request Chart
Upon publication of a major new release⎯e.g., 4.x, 5.x, 6.x⎯there will be a 12-month period of overlap with the existing version, beginning the month of the year the newer major version is published. During that period, vendors may choose to submit a device under either version of the applicable Security Requirements. The exception for this is SCRPs, which for new approvals must always use the most current version of the Security Requirements. Twelve months subsequent to publication of the new major release, the older version of Security Requirements will only be available for delta evaluations.
Upon publication of a major new release⎯e.g., 4.x, 5.x, 6.x⎯there will be a 12-month period of overlap with the existing version, beginning the month of the year the newer major version is published. During that period, vendors may choose to submit a device under either version of the applicable Security Requirements. The exception for this is SCRPs, which for new approvals must always use the most current version of the Security Requirements. Twelve months subsequent to publication of the new major release, the older version of Security Requirements will only be available for delta evaluations.
Added
p. 21
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 approved product. However, if a vendor is rebranding a product and additionally makes other changes, such as in the firmware, it does apply. They are summarized as follows:
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 …
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 …
Added
p. 22
DTR B16 Application Separation DTR B17 Minimal Configuration DTR B22 Remote Access DTR D2 Logical Anomalies DTR E10 Vendor Vulnerability Assessment Procedures DTR E11 Vulnerability Assessment of all Interfaces DTR E12 Vulnerability Disclosure
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).
This evaluation is in addition to the annual AOV and must take into account changes in the vulnerability landscape.
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).
This evaluation is in addition to the annual AOV and must take into account changes in the vulnerability landscape.
Added
p. 23
• 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 reaches the end of the expiration year, it will change color to ORANGE.
• When a firmware version reaches the end of the expiration year, it will change color to ORANGE.
Added
p. 23
Company Firmware Expiry Date Number Version Approval Approval Expiry Date XYZ Inc.
Hardware # A123-xxx-456-xx 4-98765 6.x PED 30 Apr 2020 A123-xxx-789-xx A123-xxx-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 2020 A123-xxx-789-xx A123-xxx-0AB-xx Firmware # 23.01.xxx xx (2022) 23.02.xxx xx (2023)
Added
p. 24
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.
Added
p. 26
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:
• The Laboratory work is in connection with evaluating policies and procedures of the vendor.
• Evaluating Life Cycle Security Requirements.
• Where necessary, to review source code.
Any work completed outside the PCI-Recognized Laboratory facility must be clearly documented in the PTS Device evaluation report.
• The Laboratory work is in connection with evaluating policies and procedures of the vendor.
• Evaluating Life Cycle Security Requirements.
• Where necessary, to review source code.
Any work completed outside the PCI-Recognized Laboratory facility must be clearly documented in the PTS Device evaluation report.
Added
p. 28
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.
Notwithstanding anything to the contrary, if the applicable vendor has the most current version of the VRA from the Website on file and in effect with PCI SSC, that VRA will cover and apply to all vendor products submitted to PCI SSC for approval.
It is the responsibility of the Laboratory and the vendor to allow sufficient time in project scheduling: device evaluation, report submission for review, inquiry responses and report resubmits, approval process, etc.
PCI SSC bases its approval solely on the results of the Laboratory …
Notwithstanding anything to the contrary, if the applicable vendor has the most current version of the VRA from the Website on file and in effect with PCI SSC, that VRA will cover and apply to all vendor products submitted to PCI SSC for approval.
It is the responsibility of the Laboratory and the vendor to allow sufficient time in project scheduling: device evaluation, report submission for review, inquiry responses and report resubmits, approval process, etc.
PCI SSC bases its approval solely on the results of the Laboratory …
Added
p. 30
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:
• If there is not a response from the vendor, the device will be listed on the original specified date.
• 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 there is not a response from the vendor, the device will be listed on the original specified date.
• 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.
Added
p. 31
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.
• 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.
• All requirements impacted⎯e.g., additional cardholder input mechanisms, displays, controllers, etc.⎯by the final form factor of the UPT must be addressed in detail for each impacted requirement.
• Where the Lab evaluating the final form factor is not the same as the Lab that …
• 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.
• All requirements impacted⎯e.g., additional cardholder input mechanisms, displays, controllers, etc.⎯by the final form factor of the UPT must be addressed in detail for each impacted requirement.
• Where the Lab evaluating the final form factor is not the same as the Lab that …
Added
p. 33
1. The licensee vendor cannot directly make the request. The licensor vendor must make the request on behalf of the licensee vendor.
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.
3. There is no PCI SSC requirement for the licensee product to reference or list the licensor vendor.
4. Products may be licensed from another vendor even if the version of the Security Requirements against which the original product was approved by PCI SSC is retired from use for new evaluations, as long as the approval has not expired.
5. As noted, licensed products requiring physical and/or …
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.
3. There is no PCI SSC requirement for the licensee product to reference or list the licensor vendor.
4. Products may be licensed from another vendor even if the version of the Security Requirements against which the original product was approved by PCI SSC is retired from use for new evaluations, as long as the approval has not expired.
5. As noted, licensed products requiring physical and/or …
Added
p. 34
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.
Updated contact information should be provided to a PCI-Recognized Laboratory via the Administrative Change Request form.
Updated contact information should be provided to a PCI-Recognized Laboratory via the Administrative Change Request form.
Added
p. 39
PTS Device A POI device or HSM as defined in A.10.
PTS-POI The sub-framework of the PCI SSC PTS Device security framework that addresses the security of consumer-facing devices.
PTS Program The program operated by PCI SSC for purposes of supporting the PTS evaluation, security, testing, and approval framework.
PTS-POI The sub-framework of the PCI SSC PTS Device security framework that addresses the security of consumer-facing devices.
PTS Program The program operated by PCI SSC for purposes of supporting the PTS evaluation, security, testing, and approval framework.
Added
p. 42
• Application #, if applicable The model name/number 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 device and be distinctly identified as the hardware version⎯e.g., HW#, HWID, etc. The firmware and application version numbers, and optionally the hardware version number, must be shown on the display or printed during startup or on request. This includes all Security Requirements addressed in testing, including SRED and Open Protocols. If the hardware version label is not visible when the device is installed, such as on an EPP in an ATM, other means …
Added
p. 44
A.7 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 by the device are those allowed by the policy.
Added
p. 46
PIN support Prompt control Key management PIN-entry technology ICCR MSR CTLS SRED OP 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:
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.
Added
p. 51
A.12 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, except for SCRPs. For SCRPs, the approvals will expire five years after the date of approval.
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 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
Added
p. 51
PCI SSC device approvals expire six years past the effective date of a subsequent major (5.0, 6.0, etc.) update of the applicable Security Requirements.
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 firmware expires three years from the date of approval but shall not expire past the overall approval expiration of the device.
Added
p. 53
Note: Fixed Key is not allowed for POI v6 and higher devices.
Note: Fixed Key is not allowed for POI v6 and higher devices.
SRED Key Management (PED, EPP, 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.
A MK/SK (master key, session key), DUKPT and/or Fixed designation denote that the device has been evaluated successfully to support the implementation of TDES for that particular key-management method(s).
Where AES is used, that will be explicitly noted in conjunction with the MK/SK, DUKPT and/or Fixed Key methodologies.
Format-preserving encryption (FPE) shall be denoted where one of the ANSI, ISO or NIST approved algorithms are used.
Note: The FPE notation is only presented for POI v6 and higher devices.
Note: Fixed Key is not allowed for POI v6 and higher devices.
SRED Key Management (PED, EPP, 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.
A MK/SK (master key, session key), DUKPT and/or Fixed designation denote that the device has been evaluated successfully to support the implementation of TDES for that particular key-management method(s).
Where AES is used, that will be explicitly noted in conjunction with the MK/SK, DUKPT and/or Fixed Key methodologies.
Format-preserving encryption (FPE) shall be denoted where one of the ANSI, ISO or NIST approved algorithms are used.
Note: The FPE notation is only presented for POI v6 and higher devices.
Added
p. 54
A device cannot support both a physical keypad version and a touchscreen version under the same approval where both can be used for PIN entry. It may support a device that has both interfaces in connection with providing support for national or local disability laws.
This will also be used for v2, v3, and v4 HSMs to delineate whether they are approved for restricted or unrestricted usage as delineated in the HSM Security Requirements:
• Supports ISO Format 4 (AES) PIN Blocks This field will also be used for notation for POI v6 and higher devices supporting Bluetooth and/or Wi-Fi that have been architected and evaluated to support unauthenticated wireless communications using those technologies.
• Interface Isolation
• Interface Isolation In addition, 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 …
This will also be used for v2, v3, and v4 HSMs to delineate whether they are approved for restricted or unrestricted usage as delineated in the HSM Security Requirements:
• Supports ISO Format 4 (AES) PIN Blocks This field will also be used for notation for POI v6 and higher devices supporting Bluetooth and/or Wi-Fi that have been architected and evaluated to support unauthenticated wireless communications using those technologies.
• Interface Isolation
• Interface Isolation In addition, 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 …
Added
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.
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 v6.1 (the most current version of PTS v6.x and the last issued v6.x FAQs). Examples of …
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 v6.1 (the most current version of PTS v6.x and the last issued v6.x FAQs). Examples of …
Added
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 impacts security. In all cases, changes that impact security require an evaluation that must be presented in the delta report. At a minimum, for a given change type, all requirements identified in the tables below must be assessed for security impact. A rationale must be presented in the delta report for each change that is determined to not have a security impact.
Added
p. 59
Firmware Change Types Impacted Requirements PTS 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 B3, B4, J4 B3, B4, B4.1, J4 B3, B4, B4.1, J4 New firmware/application authentication scheme B4 B4 B4 B4, B4.1 B4, B4.1 B2, B2.1 Amendments to PIN-digit timeouts B7, C3 B6, B10 B6, B10 B6, B10 B6, B10 B4, B8 Amendments to cryptographic functions; including PIN block formats and changes in random number process (for example, generation, seeding method, and algorithm) B12, B13, D4 B6, B9, B12, B13, B6, B9, B12, …
Added
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 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 changes but rather counts as a single change since they are all of the same change “type.” This meets the criteria for a delta.
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 …
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 …
Added
p. 62
Hardware Change Types Impacted Requirements PTS 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, A4, A6−A8, A10, B16, A5, A7- A9, B5, B15, B21, A13, A14, A11, A12, Modification to tamper/removal switches⎯e.g., changes to materials, performance, location, circuitry, tamper response, etc.⎯or tamper- resistance/evidence features.
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, …
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, …
Added
p. 63
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, Modifications to communications circuitry.
A2, A3, B2, D1, F1, G1, Modifications to power circuitry. A5 A3 A3 A3 A2 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.
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, …
A2, A3, B2, D1, F1, G1, Modifications to power circuitry. A5 A3 A3 A3 A2 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.
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, …
Added
p. 64
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:
• The number of any identified hardware change types;
• The number of any identified hardware change types;
Added
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.
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 for other purposes, the end result is to extend the life of …
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 for other purposes, the end result is to extend the life of …
Added
p. 67
Job Title of Individual Requesting Change Role (Primary Business, Secondary Business, Billing, Technical) Description of PTS Vendor Change(s) Type of Change (check all that apply) Business Name Business Website Mailing Address Billing Address Device Model Name(s) Billing Contact Name/Address Technical Contact Name/Address Primary Business Contact Name/Address Secondary Business Contact Name/Address Briefly describe reason for change(s) Revised Company Details New Business Name New Website New Mailing Address New Billing Address
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/email address) Contact Name Business Title Contact E-mail Contact Phone Technical Contact Contact Name Business Title Contact E-mail Contact Phone
Added
p. 71
A: No modifications requiring a delta evaluation have been made to the hardware or firmware version.
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.
For all devices, the vendor shall provide evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists by providing a copy of the vendor’s sign-off form specified in POI Requirement E10 for the prior year ending 31 December.
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.
For all devices, the vendor shall provide evidentiary materials that an auditable record of an ongoing vulnerability assessment process exists by providing a copy of the vendor’s sign-off form specified in POI Requirement E10 for the prior year ending 31 December.
Added
p. 72
Part 1. PTS Vendor Company name:
Business address: City:
State/Province: Country: Postal code:
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.
PTS Approval Number Model Name Type A or B Application Version (if applicable)
Business address: City:
State/Province: Country: Postal code:
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.
PTS Approval Number Model Name Type A or B Application Version (if applicable)
Modified
p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version 1.8
Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version 2.0
Modified
p. 2
October 2011 1.1 Add 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
July 2012 1.2 Added HSM v2 and clarifications for Fees, Approval Classes, and Expiry Dates
July 2012 1.2 Added HSM v2 and clarifications for Fees, Approval Classes, and Expiry Dates.
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
March 2014 1.4 Changes in device sample requirements. Additions to compromise notification process. Defined new device category
•Devices with Expired Approval. Provided additional clarifications for Approval Class Features
•PIN support, Key management, and Functions Provided. Updated definitions for non-PEDs and SCRs.Further explanations on the delta-evaluation process.
•Devices with Expired Approval. Provided additional clarifications for Approval Class Features
•PIN support, Key management, and Functions Provided. Updated definitions for non-PEDs and SCRs.
March 2014 1.4 Made changes in device sample requirements. Made additions to compromise notification process. Defined new device category
•Devices with Expired Approval. Provided additional clarifications for Approval Class Features
•PIN support, Key management, and Functions Provided. Updated definitions for non-PEDs and SCRs. Provided further explanations on the delta-evaluation process.
•Devices with Expired Approval. Provided additional clarifications for Approval Class Features
•PIN support, Key management, and Functions Provided. Updated definitions for non-PEDs and SCRs. Provided further explanations on the delta-evaluation process.
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.
Removed
p. 5
• PIN Transaction Security (PTS) Hardware Security Module (HSM) Security Requirements, v3.0
Evaluation Vendor Questionnaires
• PIN Transaction Security (PTS) Hardware Security Module (HSM) Evaluation Vendor Questionnaire, v3.0 Solicit additional information from vendors to support their claims of the conformity of their devices to those requirements.
Evaluation Vendor Questionnaires
• PIN Transaction Security (PTS) Hardware Security Module (HSM) Evaluation Vendor Questionnaire, v3.0 Solicit additional information from vendors to support their claims of the conformity of their devices to those requirements.
Modified
p. 5 → 6
• PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, v5.1
• PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Security Requirements, v4.0 Provide the forms to be used by laboratories and vendors.
Modified
p. 5 → 6
• PIN Security Requirements and Test Procedures, v2.0 POI and HSM contain the physical and logical security device requirements as well as device management requirements for activity prior to initial key loading.
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, v6.0 POI and HSM contain the physical and logical security device requirements as well as device management requirements for activity prior to initial key loading.
Modified
p. 5 → 6
PIN contains a complete set of requirements for the secure management, processing, and transmission of personal identification number (PIN) data during online and offline payment card transaction processing at ATMs and attended and unattended point-of-sale (POS) terminals.
• PCI PIN Security Requirements and Testing Procedures, v3.1 PIN contains a complete set of requirements for the secure management, processing, and transmission of personal identification number (PIN) data during online and offline payment card transaction processing at ATMs and attended and unattended point-of-sale (POS) terminals.
Modified
p. 5 → 6
• PTS POI Security Requirements Technical FAQs for use with Version 5
• PTS POI Security Requirements Technical FAQs for use with Version 6
Modified
p. 5 → 6
• PTS PIN Security Requirements Technical FAQs for use with Version 2
• PTS PIN Security Requirements Technical FAQs for use with Version 3
Modified
p. 5 → 6
• Hardware Security Module (HSM) Technical FAQs for use with Version 3 Provide additional and timely clarifications to the application of the Security Requirements. The FAQs are an integral part of those requirements and shall be fully considered during the evaluation process.
• PTS HSM Security Requirements Technical FAQs for use with Version 4 Provide additional and timely clarifications to the application of the above Security Requirements. The FAQs are an integral part of the Security Requirements and shall be fully considered during the evaluation process.
Modified
p. 5 → 6
Note: These documents are routinely updated and reaffirmed. The current versions should be referenced when using these requirements. The most current standards will be available at www.pcisecuritystandards.org.
Note: The documents below are routinely updated. The current versions should be referenced when using the Program Guide. Current standards generally are available at www.pcisecuritystandards.org.
Modified
p. 5 → 7
• PIN Transaction Security (PTS) Point of Interaction (POI) Modular Evaluation Vendor Questionnaire, v5.1
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements, v6.0
Removed
p. 6
• PIN Transaction Security (PTS) Point of Interaction (POI) Derived Test Requirements, v5.1
Modified
p. 6 → 7
• PIN Transaction Security (PTS) Hardware Security Module (HSM) Derived Test Requirements, v3.0 Provide specific direction to vendors on methods the test laboratories may apply when testing against the requirements Recognized Laboratories List
• PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Derived Test Requirements, v4.0 Provide specific direction to vendors on methods the Laboratories may apply when testing against the Security Requirements.
Modified
p. 6 → 7
• Payment Card Industry (PCI) Recognized Laboratories Currently recognized laboratories for PTS device testing.
• Payment Card Industry (PCI)-Recognized Laboratories List List on the Website of test laboratories recognized and approved by PCI SSC as PTS Labs.
Modified
p. 6 → 7
• Payment Card Industry Vendor Release Contains the terms and conditions that govern the exchange of information between vendors and the PCI SSC Approved Terminal Models List
• 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. 6 → 7
• Approved PIN Transaction Security Devices List of PCI SSC Approved PIN Transaction Security Devices The documents above described are available in the “PIN Transaction Security” section of the PCI SSC website•www.pcisecuritystandards.org. Earlier versions of the documents are available can be found in the PIN Transaction Security Document Archive of the same website.
• Approved PIN Transaction Security Devices List on the Website of PCI SSC-approved PIN Transaction Security Devices.
Removed
p. 7
a) Offer payment cards for one or more of the participating payment brands (issuers);
b) Accept such payment cards for cash disbursement and directly or indirectly enter the resulting transaction receipt into interchange (acquirers); or
c) Offer financial services to merchants or authorized third parties who accept such payment cards for merchandise, services, or cash disbursement, and directly or indirectly enter the resulting transaction receipt into interchange (acquirers).
In accordance with any mandates issued by the participating payment brands, customers should use the testing and approval results from PCI SSC when making decisions about purchasing devices that have been approved within the PCI PTS framework.
b) Accept such payment cards for cash disbursement and directly or indirectly enter the resulting transaction receipt into interchange (acquirers); or
c) Offer financial services to merchants or authorized third parties who accept such payment cards for merchandise, services, or cash disbursement, and directly or indirectly enter the resulting transaction receipt into interchange (acquirers).
In accordance with any mandates issued by the participating payment brands, customers should use the testing and approval results from PCI SSC when making decisions about purchasing devices that have been approved within the PCI PTS framework.
Modified
p. 7 → 8
PCI SSC reserves the right to change, amend, or withdraw security requirements at any time. If such a change is required, PCI SSC will endeavor to work closely with customers1 and vendors to help reduce the impact of any changes.
PCI SSC reserves the right to change, amend, or withdraw Security Requirements at any time. If such a change is required, PCI SSC endeavors to work closely with vendors and other affected stakeholders to help reduce the impact of any changes.
Removed
p. 8
• “PCI participants” or “PCI payment brand participants” means any entity then-currently admitted as a member of the Council in accordance with the Delaware Limited Liability Company Act. The PCI participants as of the date hereof are American Express Travel Related Services Company, Inc., DFS Services LLC (Discover), JCB Advanced Technologies, Inc., MasterCard International Incorporated, and Visa Holdings, Inc.
Modified
p. 8 → 9
• Point of interaction (POI) and hardware security module (HSM) security requirements,
• PCI PTS Point of interaction (POI) and Hardware Security Module (HSM) Security Requirements,
Modified
p. 8 → 9
• “PCI SSC,” “PCI,” or “Council” refers to the PCI Security Standards Council, LLC, a Delaware limited liability company, which consists of the payment card brands referenced above under “PCI participants.”
• “PCI SSC” refers to PCI Security Standards Council, LLC, a Delaware limited liability company.
Modified
p. 8 → 9
• “Point of interaction (POI) devices” refers broadly to all PIN-acceptance devices, used in consumer-facing transactions. Other consumer-facing device types, as delineated in Appendix A, may be included in the POI framework, to address any emerging threats to cardholder or PCI participants’ sensitive data.
• “Point of interaction (POI) devices” refers broadly to all PIN-acceptance devices used in consumer-facing transactions. Other consumer-facing device types, as delineated in Appendix A, may be included in the POI framework to address any emerging threats to cardholder or other payment card industry (PCI) participants’ sensitive data.
Modified
p. 8 → 9
• “Hardware security modules (HSMs)” refers to secure cryptographic devices used for PIN processing, card personalization, cryptographic-key management and data protection.
• “Hardware security modules (HSMs)” refers to secure cryptographic devices used for PIN processing, card personalization, cryptographic-key management, and data protection.
Modified
p. 8 → 9
• “PIN Transaction Security” refers to the framework within PCI standards and requirements that deals with the evaluation and approval of payment security devices.
• “PIN Transaction Security” refers to the framework within PCI SSC’s standards and requirements that deals with the evaluation and approval of payment security devices.
Removed
p. 9
This Payment Card Industry PIN Transaction Security Device Testing and Approval Program Guide reflects an alignment with the participating payment brands to a standard set of:
• Security requirements,
• Testing methodologies, and
Note: Approvals are granted directly through PCI SSC and are coordinated by the participating PCI payment brands through the PCI PTS Program process.
All devices submitted for security evaluations and approval have been evaluated against the applicable aligned Payment Card Industry (PCI) PTS Security Requirements. The PCI Approval Lists provide a full list of payment security devices recognized as meeting PCI PTS Requirements.
This collaborative effort ensures that all payment security devices will be evaluated under a common process offering a high degree of assurance. This arrangement is intended to improve the overall security for cardholder and other sensitive data by removing conflicting requirements. All stakeholders in the payments value chain benefit from the aligned requirements:
• Vendors are able to reduce the …
• Security requirements,
• Testing methodologies, and
Note: Approvals are granted directly through PCI SSC and are coordinated by the participating PCI payment brands through the PCI PTS Program process.
All devices submitted for security evaluations and approval have been evaluated against the applicable aligned Payment Card Industry (PCI) PTS Security Requirements. The PCI Approval Lists provide a full list of payment security devices recognized as meeting PCI PTS Requirements.
This collaborative effort ensures that all payment security devices will be evaluated under a common process offering a high degree of assurance. This arrangement is intended to improve the overall security for cardholder and other sensitive data by removing conflicting requirements. All stakeholders in the payments value chain benefit from the aligned requirements:
• Vendors are able to reduce the …
Modified
p. 9 → 10
• Customers benefit from a broader selection of secure devices.
• Customers benefit from a broader selection of PCI SSC-approved payment security devices.
Modified
p. 9 → 10
• Merchants, financial institutions, processors, and other third parties are assured that they will be using products that have met the required level of assurance.
• Merchants, financial institutions, processors, and other third parties gain assurance that they will be using products that have met the applicable Security Requirements.
Removed
p. 10
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 the PCI SSC may contact one of the PCI-recognized laboratories and complete the appropriate PCI forms (included in the PCI PTS Security Requirements and the PCI Vendor Questionnaires themselves). The vendor will then submit the device, together with any additional documentation required by the laboratory, for evaluation and compliance validation against the PCI PTS Security Requirements. Upon completion of the evaluation, PCI SSC will review the evaluation report. When the device model meets the PCI requirements, it will be approved and listed on the PCI PTS website. An approval letter will be issued confirming successful completion of the process.
Modified
p. 10 → 11
• PCI SSC recommends that the POI device receive EMV Level 1 approval first, if applicable, and then PCI 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 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.)
Modified
p. 10 → 11
• If the POI device can support both types of PIN-entry options, online and offline, inform the laboratory to evaluate both at the same time, or have the laboratory indicate future support for both options in the evaluation report. In order to have the POI device’s approval indicate support of both options, the vendor must ensure that after the second PIN-entry option evaluation has been performed, the laboratory includes both in its report.
• If the POI device can support both types of PIN-entry options, online and offline, inform the Laboratory to evaluate both at the same time, or have the Laboratory indicate future support for both options in the evaluation report. In order to have the POI device’s approval indicate support of both options, the vendor must ensure that after the second PIN-entry option evaluation has been performed, the Laboratory includes both in its report.
Removed
p. 11
Requirements and Evaluation Module Name Description POI Device Core Requirements Core logical and physical requirements of PIN acceptance devices Device Integration Requirements7 Ensures that the integration of previously approved components does not impair the overall security as stated in the security requirements and includes security management requirements applicable to the integrated device.
Open Protocols (OP) The interface of POI terminals to open networks using open protocols Secure Reading and Exchange of Data (SRED) To support secure encryption of account data in the Device Management Security Requirements Considers how the device is produced, controlled, transported, stored, and used throughout its life cycle.
The first two modules roughly correspond to previous versions of the PCI PED, EPP, and UPT Security Requirements manuals.
Products are not required to support open protocols or the secure reading and exchange of data (SRED); however, if they do, those modules are mandatory for evaluation and approval.
Open Protocols (OP) The interface of POI terminals to open networks using open protocols Secure Reading and Exchange of Data (SRED) To support secure encryption of account data in the Device Management Security Requirements Considers how the device is produced, controlled, transported, stored, and used throughout its life cycle.
The first two modules roughly correspond to previous versions of the PCI PED, EPP, and UPT Security Requirements manuals.
Products are not required to support open protocols or the secure reading and exchange of data (SRED); however, if they do, those modules are mandatory for evaluation and approval.
Modified
p. 11 → 12
This modular approach supports the submission of devices in accordance with the product types and approval classes defined in Appendix A.
Modified
p. 11 → 12
Table 1: Evaluation Modules In order to capture the diversity of security requirements in a single compliance assessment process by the laboratory, the PTS POI Security Requirements are split into the following evaluation modules:
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:
Modified
p. 11 → 12
•such as an EPP, card readers, etc.
Each PCI SSC-approved product that incorporates separate modules
•such as an EPP, card readers, etc.
•such as an EPP, card readers, etc.
Modified
p. 11 → 12
•must complete the integration requirements.
•must satisfy the corresponding PCI SSC integration requirements.
Modified
p. 11 → 13
The overall intent of the SRED validation requirement is to ensure that implementations of account data protection are fully robust as evidenced by validation and approval against the SRED module. However, the requirement is not intended to inhibit the vendor from implementing account data protections that are not sufficient to meet the SRED module but which still may provide some lesser level of protection for account data. Thus a vendor implementing account data protections and not seeking SRED as an …
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 …
Modified
p. 12 → 14
Any product that incorporates separate modules, such as EPPs, card readers, etc., must complete the integration requirements. Products are not required to support open protocols or the secure reading and exchange of data; however, if they do, then those modules are mandatory for evaluation and approval.
Note: “Not Applicable” cannot be used for implementations that provide only partial aspects of a defined Approval Class to validate the device to that Approval Class. Any product that incorporates separate modules, such as EPPs, card readers, etc., must satisfy the integration requirements. Products are not required to support open protocols or the secure reading and exchange of data; however, if they do, those requirements are mandatory for evaluation and approval.
Modified
p. 12 → 14
Terminal manufacturers may purchase PCI-approved secure components from various vendors and integrate them into their final solutions, which themselves can be approved against the PCI PTS requirements.
Terminal manufacturers may purchase PCI SSC-approved secure components from various vendors and integrate them into their final solutions, which themselves can be approved against the Security Requirements.
Modified
p. 12 → 14
The laboratory will validate payment security devices against the Device Management Requirements as specified in the PCI PTS POI Modular Security Requirements or PCI HSM Security Requirements. This is done via documentation reviews and by means of evidence that procedures are properly implemented and used. Any variances to these requirements will be reported to PCI 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 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.
Modified
p. 12 → 14
Table 2: Testing and Approval Process Illustration The table below and the charts on the following pages outline and illustrate the 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. 12 → 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 test laboratory to initiate testing Preparation for Testing Figure 2 Sign NDA and release agreement Approval Process Figure 2 Submit documentation and materials Requirements for Testing Figure 2 Respond to inquiries from test laboratory Technical Support throughout Testing Figure 2 Receive response or approval letter from PCI SSC Approval Process Figure 2 PTS …
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
Removed
p. 16
Upon publication of a major new release (e.g., 3.x, 4.x, 5.x) there will be a twelve-month period of overlap beginning May of the year the newer major version is published. Vendors may choose during that period to submit a device under either version of the security requirements. The exception for this is SCRPs, which for new approvals must always use the most current version of the Security Requirements. As of 1 May of the following year, the older version of security requirements will only be available for delta evaluations.
As of 1 May, the vendor must complete and submit to PCI an Attestation of Validation (AOV) confirming adherence to the program guide•i.e., either the firmware has not been amended or the changes made are within the wildcard parameters or the changes were submitted for evaluation. For devices supporting open protocols, the vendor must provide evidentiary materials that an auditable record of …
As of 1 May, the vendor must complete and submit to PCI an Attestation of Validation (AOV) confirming adherence to the program guide•i.e., either the firmware has not been amended or the changes made are within the wildcard parameters or the changes were submitted for evaluation. For devices supporting open protocols, the vendor must provide evidentiary materials that an auditable record of …
Modified
p. 16 → 19
The Technical FAQs are an integral part of the evaluation process. Technical FAQs are identified by major version of security requirements, e.g., 1.x, 2.x, 3.x. Each Technical FAQ version is specific to the corresponding major version of security requirements. For example, Technical FAQs version 3 is specific to security requirements version 3.x and only security requirements version 3.x, and so on.
The Technical FAQs are 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.
Modified
p. 16 → 19
The Technical FAQs are periodically updated and are generally effective upon publication. Depending on the nature of the FAQ (e.g., clarification vs. addressing an eminent threat), their applicability may be deferred for devices under evaluation at the time of publication.
The Technical FAQs are periodically updated and are generally effective upon publication. Depending on the nature of the FAQ⎯e.g., clarification vs. addressing an eminent threat⎯its applicability may be deferred for a period of time for devices under evaluation at the time of publication.
Modified
p. 16 → 19
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 taken into account …
Modified
p. 16 → 19
Devices for which the approval has expired may also undergo deltas. This is because vendors may need to make maintenance fixes to devices that the vendor has already sold but must still provide support for. In addition, vendors may wish to port updated versions of firmware that were approved against newer security requirements to products for which the approval has expired. This may occur because customers of a vendor wish to standardize their deployment against a given version of firmware …
Devices for which the approval has expired may also undergo delta evaluations. This is because vendors may need to make maintenance fixes to devices that the vendor has already sold but must still provide support for. In addition, vendors may wish to port updated versions of firmware that were approved against newer Security Requirements to products for which the approval has expired. This may occur because customers of a vendor wish to standardize their deployment against a given version of …
Modified
p. 16 → 19
In the year the prior requirements are retired from use, any vendor using those requirements for a new evaluation must have the device in evaluation by 1 March of that year and PCI 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 prior to 1 May of that year. If the devices require changes based upon PCI review of the evaluation …
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 …
Modified
p. 17 → 20
Examples of documents and items to submit to a PCI-recognized payment security device test laboratory include as applicable for 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. 17 → 20
1. Completed appropriate PCI Security Requirements forms for device.
1. Completed appropriate Security Requirements forms for device.
Modified
p. 17 → 20
2. Completed appropriate PCI Evaluation Vendor Questionnaire for device.
2. Completed Laboratory vendor questionnaire for device.
Modified
p. 17 → 20
3. A user-available security policy for posting with the approval at www.pcisecuritystandards.org.
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.
Modified
p. 17 → 20
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 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 by PCI SSC as delineated below.
Modified
p. 17 → 20
5. The necessary hardware and software accessories to perform simulated PIN-based payment transactions (for HSMs, consult with the laboratory).
5. The necessary hardware and software accessories to perform simulated PIN-based payment transactions (for HSMs, consult with the Laboratory).
Modified
p. 17 → 20
6. Documentation that describes all functions used for data input and output that can be used by third-party application developers. Specifically, functions associated with key management, PIN management, and user interfaces (such as display and key pad) must be described. (An API manual is an example of documentation that could fulfill this requirement.)
6. Documentation that describes all functions used for data input and output that can be used by third-party application developers. Specifically, functions associated with key management, PIN management, and user interfaces (such as display and keypad) must be described. (An API manual is an example of documentation that could fulfill this requirement.)
Modified
p. 17 → 20
8. Instructions and accessories (such as key loaders) that will allow the test laboratory engineers to use all special modes that the payment security device supports•including key loading, key selection, key zeroization, and other key-management and maintenance functions.
8. Instructions and accessories (such as key loaders) that will allow the Laboratory engineers to use all special modes that the payment security device supports•including key loading, key selection, key zeroization, and other key-management and maintenance functions.
Modified
p. 17 → 20
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 PTS Device Approval 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 (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.
Removed
p. 18
Following a successful evaluation, the PTS test laboratory must provide the Council 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 the Council on an as-needed basis. This applies to all new evaluations that result in a new approval number. It does not apply to deltas. It also does not apply to a situation where the vendor is merely rebranding another vendor's previously approved product. However, if a vendor is rebranding a product and additionally makes other changes, such as in the firmware, it does apply. Additional details and updates on these matters will be available in communications from PCI to Labs and Vendors. This is summarized as follows.
Modified
p. 18 → 21
• 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. Provision of device samples is a necessary part of a device’s approval. These will be securely retained and may be used to assess vulnerability to new attack techniques. If a model is ever compromised in the field, the retained samples may be used to investigate …
• 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 …
Modified
p. 18 → 21
• Robust side-channel testing is an important part of device assessment. 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. The Council shall request some or all of this data to be provided as necessary. Laboratories should communicate with the Council 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. 18 → 21
• Robust logical-anomalies testing is an important part of device assessment. Relevant fuzzing data examples (output data and/or logs, reports, etc.), providing a representative and comprehendible summary of the fuzzing attack test runs must be presented within or accompanying evaluation reports, indicating what testing was performed and why, 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. 18 → 21
Attn: MasterCard Global Products and Solutions MasterCard Worldwide 5 Booths Park Chelford Road Cheshire WA16 8QZ 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
Removed
p. 19
The testing lab may perform a pre-assessment 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.
Modified
p. 19 → 24
• Guidance on designing payment security devices to conform to the PCI security requirements
• Guidance on designing payment security devices to conform to the applicable Security Requirements.
Modified
p. 19 → 24
• Review of a vendor’s payment security device design, response to questions via e-mail or phone, and participation in conference calls to clarify requirements
• Review of a vendor’s payment security device design, response to questions via e-mail or phone, and participation in conference calls to clarify requirements.
Modified
p. 19 → 24
• A preliminary physical security assessment on a vendor’s hardware
• A preliminary physical security evaluation on a vendor’s hardware.
Modified
p. 19 → 24
• Guidance on bringing a vendor’s payment security devices into compliance with the PCI requirements if areas of non-compliance are identified during the evaluation.
• Guidance on bringing a vendor’s payment security devices into compliance with the applicable Security Requirements if areas of non-compliance are identified during the evaluation.
Modified
p. 19 → 24
Vendors are encouraged to contact a PCI-recognized laboratory directly in regard to the above services and any fees associated with them. However, the laboratories cannot offer any advice on the actual design of the POI device or HSM.
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.
Modified
p. 19 → 24
PCI SSC currently recognizes a series of laboratories for PTS device testing. The current list of recognized PTS test labs may be found at the PCI SCC website, in the “PTS Approved Devices” section.
PCI SSC currently recognizes a series of laboratories for PTS Device testing. The current list of PTS Labs may be found on the Website, on the “Approved PTS Devices” page.
Modified
p. 19 → 24
The vendor pays all laboratory evaluation fees directly to the laboratory.
The vendor pays all Laboratory testing and evaluation fees directly to the Laboratory.
Modified
p. 20 → 25
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 prior to completion of all tests.
Modified
p. 20 → 25
During the testing process, all the applicable test procedures are run according to the applicable PCI Derived Test Requirements. Any discrepancies discovered are reported to the vendor. All applicable tests should be run during a single test cycle, unless:
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:
Modified
p. 20 → 25
If a test cycle has ended with discrepancies discovered, the vendor is notified that the payment security device has failed the test cycle. The laboratory will issue a final report that addresses the discrepancies.
If a test cycle has ended with discrepancies discovered, the vendor is notified that the payment security device has failed the test cycle. The Laboratory will issue a final report that addresses the discrepancies.
Modified
p. 20 → 26
It is recommended that the vendor make available a technical resource person to assist with any questions that may arise during laboratory testing. During the evaluation, and to expedite the process, a vendor contact should be “on call” to discuss discrepancies and respond to questions from the laboratory.
It is recommended that the vendor make available a technical resource person to assist with any questions that may arise during Laboratory testing. During the evaluation, and to expedite the process, the vendor contact should be “on call” to discuss discrepancies and respond to questions from the Laboratory.
Modified
p. 21 → 27
All approved devices for which the approval has not expired shall be billed an approval-listing fee for all such approvals that existed as of 1 May. Vendors shall not be billed the annual listing fee for “End of Life” (EOL) products for which they have notified PCI in writing 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. This applies only to an entire …
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 of 1 May. Vendors shall not be billed the annual listing fee for “End of Life” (EOL) products for which they have notified PCI SSC in writing 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 …
Removed
p. 22
In all cases, the vendor release agreement, unless superseded or otherwise terminated in accordance with provisions within the agreement, shall only require a single submission to cover all submitted vendor products.
PCI SSC will base their approval solely on the results of the laboratory evaluation report. Upon receipt of the test report for a new evaluation, the PCI SSC have two weeks (14 calendar days) from receipt of that report to identify any technical issues or questions for resolution by the test laboratory. If no issues or questions to the laboratory are identified within this time frame, PCI SSC shall post the approval information to the website and issue an approval letter. If questions or issues are identified and sent to the laboratory, the cycle resets to one week (seven calendar days) after receipt of a complete and acceptable response from the laboratory. The seven-day reset start does not occur until …
PCI SSC will base their approval solely on the results of the laboratory evaluation report. Upon receipt of the test report for a new evaluation, the PCI SSC have two weeks (14 calendar days) from receipt of that report to identify any technical issues or questions for resolution by the test laboratory. If no issues or questions to the laboratory are identified within this time frame, PCI SSC shall post the approval information to the website and issue an approval letter. If questions or issues are identified and sent to the laboratory, the cycle resets to one week (seven calendar days) after receipt of a complete and acceptable response from the laboratory. The seven-day reset start does not occur until …
Modified
p. 22 → 28
Vendors or other third parties licensing approved products from other vendors to market or distribute under their own names shall also need to sign a vendor release agreement prior to the issuance of the approval.
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.
Modified
p. 23 → 29
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 requiredphysical or logical security requirements For various reasons, including revocation of approval, information on approval letters may become inaccurate. Therefore, the PCI 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
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 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 Requirements 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.
Modified
p. 23 → 30
The following diagram shows the relationship between the expiration of device model tested under Version 5 of PCI PTS POI Security Requirements and its laboratory testing work.
The following diagram shows the relationship between the expiration of device model tested under Version 6 of PCI PTS POI Security Requirements and its Laboratory testing work.
Modified
p. 23 → 30
For devices that embed other PCI-approved devices and are therefore basing their security on these sub-components (even partially), the renewal/expiration date shall be the earliest among all evaluations, including the embedded device itself.
For devices that embed other PCI SSC-approved devices and are therefore basing their security on these sub-components (even partially), the expiration date shall be the earliest among all evaluations, including the embedded device itself.
Removed
p. 24
If payment security device vendors can modularize the payment security device functionality, it would help minimize re-evaluations due to hardware changes that do not impact payment security device security.
Modified
p. 24 → 31
1. No Impact on Security Requirements: New Testing is Not Required to Maintain Approval If hardware or firmware (including software which 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 as was used for the original evaluation.) Where appropriate, the …
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. 24 → 31
If the change is determined not to impact security, the new hardware and/or firmware version number would be considered “Approved” and:
Modified
p. 24 → 31
• The approved payment security device listing on the PCI website would be updated accordingly with the new information, and
• The approved payment security device listing on the Approved Device List would be updated accordingly with the new information, and
Modified
p. 24 → 31
2. Potential Impact on Security Requirements: New Testing is Required to Maintain Approval If changes to the device do impact payment security device security requirements, the device must undergo another security evaluation. The laboratory will then submit a new evaluation report to the PCI SSC for re-approval consideration. (In this scenario, the vendor must first submit documentation of the change to the laboratory, which will determine whether the nature of the change impacts payment security device security in accordance with …
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 …
Removed
p. 25
1. Vendor describes the design of the new (or similar) payment security device model in the form of a product revision document.
2. Vendor sends the documentation to the selected laboratory for review.
3. Laboratory reviews the documentation (and possibly payment security device samples).
4. Laboratory treats the document review process like a product revision of an existing approved payment security device.
5. Laboratory then sends a letter to the vendor informing it whether or not a full test evaluation will be required.
2. Vendor sends the documentation to the selected laboratory for review.
3. Laboratory reviews the documentation (and possibly payment security device samples).
4. Laboratory treats the document review process like a product revision of an existing approved payment security device.
5. Laboratory then sends a letter to the vendor informing it whether or not a full test evaluation will be required.
Modified
p. 25 → 34
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 else will be listed in parallel to the existing policy. Furthermore, images for the device used on the www.pcisecuritystandards.org website must include both …
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 …
Modified
p. 26 → 35
• Key-loading facility The vendor must also provide immediate feedback about any potential impact this (possible or actual) breach may or will have.
• Key-loading facility The vendor must also provide immediate feedback about any potential impact this (possible or actual) breach may have had or will have.
Modified
p. 26 → 35
Notification must take place no later than 24 hours after the vendor first discovers the security breach or compromise.
Notification to PCI SSC must take place no later than 24 hours after the vendor first discovers the security breach or compromise.
Modified
p. 26 → 35
PCI SSC, as agreed within the terms of the Payment Card Industry 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 …
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 …
Modified
p. 27 → 36
• Notify PCI payment brand participants that a security weakness or compromise has occurred.
• Notify the Participating Payment Brands that a security weakness or compromise has occurred.
Modified
p. 27 → 36
• Attempt to obtain the compromised terminal to evaluate exactly how the compromise occurred. This may include utilizing PCI-recognized laboratories.
• Attempt to obtain the compromised terminal to evaluate exactly how the compromise occurred. This may include utilizing PCI-Recognized Laboratories.
Modified
p. 27 → 36
• Work with the vendor to try and mitigate or prevent further compromises.
• Work with the vendor to try to mitigate or prevent further compromises.
Modified
p. 27 → 36
• Perform evaluations on the compromised product either internally or under the terms of PCI SSC’s Payment Card Industry Vendor Release Agreement, using PCI-recognized laboratories to identify the cause of the compromise.
• Perform evaluations on the compromised product either internally or under the terms of the Vendor Release Agreement, using PCI-Recognized Laboratories to identify the cause of the compromise.
Modified
p. 27 → 36
PCI SSC reserves the right to withdraw approval of a POI device or HSM and accordingly update the PCI PTS Device Approval List. Some of the reasons for withdrawal of approval are:
PCI SSC reserves the right to withdraw approval of any PTS Device and accordingly update the Approved Device List. Some of the reasons for withdrawal of approval are:
Modified
p. 27 → 36
• It is clear that the payment security device does not offer sufficient protection against current threats and does not conform to security requirements. If PCI SSC considers that the payment security device has a security weakness or has been compromised, PCI SSC will notify the vendor in writing of its intent to withdraw its approval of that payment security device.
• It is clear that the payment security device does not offer sufficient protection against current threats and does not conform to applicable Security Requirements. If PCI SSC considers that the payment security device has a security weakness or has been compromised, PCI SSC will notify the vendor in writing of its intent to withdraw its approval of that payment security device.
Modified
p. 27 → 36
• The vendor does not either meet contractual obligations vis-à-vis PCI SSC or strictly follow the terms of participation on the PCI PTS program as described in this document or the Payment Card Industry Vendor Release Agreement.
• The vendor either does not meet contractual obligations vis-à-vis PCI SSC or strictly follow the terms of participation in the PTS Program as described in the Program Guide or in the Vendor Release Agreement.
Modified
p. 28 → 37
PCI SSC’s approval applies only to payment security devices that are identical to the payment security device tested by a PCI Security Standards Council recognized laboratory. If any aspect of the payment security device is different from that which was tested by the laboratory
•even if the payment security device conforms to the basic product description contained in the approval letter
•then the payment security device model should not be considered approved, nor promoted as approved. For example, if a payment security …
•even if the payment security device conforms to the basic product description contained in the approval letter
•then the payment security device model should not be considered approved, nor promoted as approved. For example, if a payment security …
PCI SSC’s approval applies only to payment security devices that are identical to the payment security device tested by a PTS Lab and ultimately approved by PCI SSC. If any aspect of the payment security device is different from that which was tested by the Laboratory and approved by PCI SSC
•even if the payment security device conforms to the basic product description contained in the approval letter
•then the payment security device model should not be considered approved, nor promoted as …
•even if the payment security device conforms to the basic product description contained in the approval letter
•then the payment security device model should not be considered approved, nor promoted as …
Modified
p. 28 → 37
No vendor or other third party may refer to a payment security device as “PCI Approved,” nor 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. All other references to PCI SSC’s approval are strictly and actively prohibited by PCI …
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 …
Modified
p. 28 → 37
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, …
Removed
p. 29
KLD Key-Loading Device MSR Magnetic-stripe reader.
OEM Original equipment manufacturer.
PCI PTS Device Security Evaluation Program The PCI SSC evaluation framework for payment system devices.
POI Point of interaction.
OEM Original equipment manufacturer.
PCI PTS Device Security Evaluation Program The PCI SSC evaluation framework for payment system devices.
POI Point of interaction.
Modified
p. 29 → 38
COTS Commercial-off-the-Shelf device. A mobile device (e.g., smartphone or tablet) that is designed for mass-market distribution and is not designed specifically for payment processing.
COTS Commercial-off-the-Shelf device. A mobile device⎯e.g., smartphone or tablet⎯that is designed for mass-market distribution and is not designed specifically for payment processing.
Modified
p. 29 → 38
Device Payment device; may be part of a terminal.
CTLS Contactless Device Payment device; may be part of a terminal.
Modified
p. 29 → 38
Evaluation Framework Set of requirements for vendors, test methodology for laboratories, approval process for products, and 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. 29 → 38
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) ICCR Integrated-circuit card reader.
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).
Modified
p. 29 → 38
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. 29 → 38
PED PIN entry device; approval class aimed at devices with PIN-entry and PIN- processing ability, either attended or unattended, whose primary purpose is to capture and convey the PIN to an ICC reader 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. 29 → 38
POI Device Device used in the point of interaction with a consumer.
POI Point of interaction POI Device Device used in the point of interaction with a consumer.
Removed
p. 30
PTS PIN Transaction Security, the PCI SSC framework for payment security devices. Refers to POI devices and HSMs, collectively.
PTS Devices Payment security devices, POI devices, and HSMs.
SCR Secure Card Reader approval class SCRP Secure Card Reader PIN approval class.
PTS Devices Payment security devices, POI devices, and HSMs.
SCR Secure Card Reader approval class SCRP Secure Card Reader PIN approval class.
Modified
p. 30 → 39
PTS-HSM The sub-framework of the PCI-PTS device security framework that addresses the security of HSMs PTS-POI The sub-framework of the PCI-PTS device security framework that addresses the security of consumer-facing devices RAP Remote Administration Platform for HSMs.
PTS-HSM The sub-framework of the PCI SSC PTS Device security framework that addresses the security of HSMs.
Modified
p. 30 → 39
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).
RAP Remote Administration Platform for HSMs 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).
Modified
p. 31 → 40
A device that provides for the entry of PINs, 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 online and/or offline PIN 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, 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 online and/or offline PIN entry and has a clearly defined physical and logical boundary for all functions related to PIN entry.
Modified
p. 31 → 40
In addition, non-PIN-acceptance POI devices can be validated and approved if compliant to the Secure Reading and Exchange of Data (SRED) module, and if applicable, the Open Protocols Module. 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 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.
Modified
p. 31 → 40
Secure Card Readers must be validated to the Core and SRED 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 to the requirements as delineated in Appendix B: Applicability of Requirements of the PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements.
Modified
p. 31 → 40
All approval classes are subject to the Device Management Security Requirements.
All approval classes are subject to the Life Cycle Security Requirements.
Modified
p. 31 → 40
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 property prefixed with the word “OEM” on the main page of 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 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 property prefixed with the word “OEM” on the main page of the listing, to unambiguously advertise the modular nature.
Modified
p. 31 → 40
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 payment are eligible for the UPT approval class. These POIs can possibly include approved OEM modules.
Modified
p. 31 → 40
POI devices submitted for testing must be properly identified so that PCI participants’ customers or their agents can be certain of acquiring a POI that has been approved by PCI.
POI devices submitted for testing must be properly identified so that PCI SSC participants’ customers or their agents can be certain of acquiring a POI that has been approved by PCI SSC.
Modified
p. 32 → 41
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 HSM 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 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:
Modified
p. 32 → 41
• 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 ⎯e.g., Secure Environments⎯as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy.
Modified
p. 32 → 41
A.3 Devices with Expired Approval These are devices whose approval has expired as delineated in the “Expiry Date” section of this document. For specific information regarding payment brand usage mandates for expired devices, please contact the payment brand(s) of interest.
A.3 Devices with Expired Approval These are devices whose approval has expired as delineated in the “Expiry Date” section of this document. For specific information regarding Participating Payment Brand usage mandates for expired devices, please contact the Participating Payment Brand(s) of interest.
Removed
p. 33
• Application #, if applicable In order to ensure that the payment security device has received an approval, acquiring customers or their designated agents are strongly advised to purchase and deploy only those payment security device models with the information that matches exactly the designations given in the components of the Point of Interaction Device Identifier or the Hardware Security Module Identifier.
Modified
p. 33 → 42
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 PCI 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 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.
Modified
p. 33 → 42
A.5 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 approval listing.
A.5 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.
Removed
p. 34
The firmware version number may also be subject to the use of variables in a manner consistent with hardware version numbers The "x" field(s) has/have been assessed by the laboratory and PCI SSC as to not impact the POI’s or HSM’s security requirements or the vendor's approval. To ensure that the payment security device has been approved, 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 PCI PTS Device Approval List.
Modified
p. 34 → 43
Vendors may have produced payment security devices with the same model name/number (prior to validation of compliance by the laboratory) that do not meet the payment security device security requirements
Vendors may have produced payment security devices with the same model name/number (prior to validation of compliance by the Laboratory) that do not meet the applicable payment security device Security Requirements.
Modified
p. 34 → 44
Table 4: Examples on the Use of Hardware #s Hardware # of Payment Security Device in the Approval 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 in order for the PTS device to be considered an approved payment security device (hardware component).
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 in order for the PTS Device to be considered an approved payment security device (hardware component).
Modified
p. 34 → 44
NN-4x1-0x0-Ax Hardware # NN-4x1-0x0-Ax of the Device Identifier does employ the use of the variable "x." Hence, the payment security device being deployed must match the Hardware # exactly in only those position(s) where there is no "x." Actual Hardware # of POI Supplied by NN-421-090-AC If the PCI website lists NN-421-000-AB as the Hardware # in the Device Identifier, then the payment security device with the Hardware # NN-421-090-AC cannot be considered an approved payment security device (hardware component). …
NN-4x1-0x0-Ax Hardware # NN-4x1-0x0-Ax of the Device Identifier does employ the use of the variable "x." Hence, the payment security device being deployed must match the Hardware # exactly in only those position(s) where there is no "x." Actual Hardware # of POI Supplied by NN-421-090-AC If the PCI SSC Website lists NN-421-000-AB as the Hardware # in the Device Identifier, then the payment security device with the Hardware # NN-421-090-AC cannot be considered an approved payment security device (hardware …
Modified
p. 34 → 44
NN-421-090-YC If the PCI website lists NN-4x1-0x0-Ax as the Hardware # in the Device Identifier, then the payment security device with the Hardware # NN-421-090-YC cannot be considered an approved payment security device (hardware component).
NN-421-090-YC If the PCI SSC Website lists NN-4x1-0x0-Ax as the Hardware # in the Device Identifier, then the payment security device with the Hardware # NN-421-090-YC cannot be considered an approved payment security device (hardware component).
Removed
p. 35
A.9 Product Type The product type gives an insight on both the approval class of a device, and whether the device is a module to be integrated (OEM) or is ready-to-deploy equipment. The product type may be prefixed with “OEM” if the approved device is clearly designed to be integrated into a wider set, or as a non-PED to clearly differentiate a non-PIN-acceptance POI device from a PIN-acceptance POI device.
Modified
p. 35 → 45
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 …
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 …
•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 …
Modified
p. 35 → 45
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, and in addition, as an approved component of the UPT product, similar to …
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 …
Removed
p. 36
• PIN-entry technology
Modified
p. 36 → 46
Table 5: Approval Class Descriptions Class Description Potential Features (see Table 7 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 5: Approval Class Descriptions Class Description Potential Features (see Table 7 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.
Modified
p. 36 → 46
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 …
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 …
Removed
p. 37
• Chip Card Transaction Processing KLD An SCD that may be used for securely receiving, storing, and transferring data between compatible cryptographic and communications equipment. Key-transfer and loading functions include the following:
Modified
p. 37 → 47
• Export of a key from one secure cryptographic device (SCD) to another SCD in plaintext, component, or enciphered form;
• Export of a key from one secure cryptographic device (SCD) to another SCD in clear-text, component, or enciphered form;
Modified
p. 37 → 47
• Export of a key component from an SCD into a tamper- evident package (e.g., blind mailer);
• Export of a key component from an SCD into a tamper-evident package⎯e.g., blind mailer;
Modified
p. 37 → 47
• Import of key components into an SCD from a tamper- evident package; Temporary storage of the key in plaintext, component, or enciphered form within an SCD during transfer.
• Temporary storage of the key in clear-text, component, or enciphered form within an SCD during transfer.
Removed
p. 38
PED An approval class aimed at POI devices, originally designed for supporting payment with PIN entry, and dedicated to payment. A PED must have an integrated display unless dedicated to PIN entry only. This class may cover both attended and unattended environments and OEM or stand-alone products.
Modified
p. 38 → 47
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. 38 → 47
Non-PED POI devices (terminals) are validated to the Secure Reading and Exchange of Data Module and, if applicable, the Open Protocols Module. 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. 38 → 48
Display PIN support Prompt control Key management PIN-entry technology RAP This is for platforms that are used for remote administration of HSMs. Such administration may include device configuration and cryptographic key-loading services.
Modified
p. 39 → 49
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 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.
Modified
p. 39 → 49
• A chip-card-only reader
• A contact chip-card-only reader
Modified
p. 39 → 49
• A contactless-only reader SCRs must meet as applicable the ICCR and/or MSR requirements designated in Appendix B of the PCI PTS POI Security Requirements and the Secure Reading and Exchange of Data Module. 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 Module must also be met. Other requirements, such as B1, Self-tests, and B9, …
• A contactless-only reader SCRs must meet as applicable the ICCR and/or MSR 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 Open Protocols requirements must also be met. Other requirements, such as B1, Self-tests, and B9, Random …
Modified
p. 39 → 49
If a SCR processes PINs
•i.e., it 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 entrydevice (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, …
•i.e., it 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
If a SCR processes PINs
•i.e., it 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 …
•i.e., it 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 …
Modified
p. 40 → 50
A Secure Card Reader PIN (SCRP or SCR-PIN) can be
A Secure Card Reader PIN (SCRP or SCR-PIN) can be:
Modified
p. 40 → 50
• A reader supporting both contact and 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 Module. 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 Module must also be met. Other requirements in …
• 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. …
Modified
p. 40 → 50
PIN support Key management ICCR MSR CTLS SRED OP 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. 40 → 50
PIN support Prompt control Key management PIN-entry technology A.11 Version Version refers to the version of the security requirements the device has been evaluated against. Each approval class may follow its own version release schedule.
PIN support Prompt control Key management PIN-entry technology
Removed
p. 41
Note: Readers should note that the approval cycle for PCI-approved devices is different than that of pre-PCI approved devices. Approvals for most pre-PCI devices ended on 31 December 2007.
Removed
p. 42
Key Management (PED, EPP, SCRP, UPT) “Key management” denotes whether the laboratory has successfully evaluated the payment security device to support the use of Triple DES (TDES) or AES for PIN encryption for online PIN. TDES requires use of at least a double-length key.
A MK/SK (master key, session key), DUKPT, and/or Fixed designation denote that the device has been evaluated successfully to support the implementation of TDES for that particular key- management scheme(s).
Where AES is used, that will be explicitly noted in conjunction with the MK/SK, DUKPT or Fixed Key methodologies.
A MK/SK (master key, session key), DUKPT, and/or Fixed designation denote that the device has been evaluated successfully to support the implementation of TDES for that particular key- management scheme(s).
Where AES is used, that will be explicitly noted in conjunction with the MK/SK, DUKPT or Fixed Key methodologies.
Modified
p. 42 → 52
Table 7: Specific Features Feature and Applicability Description PIN Support (PED, EPP, SCR, SCRP, UPT) “PIN Support” denotes the type of PIN entry verification that can be supported by the POI. “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 …
Table 7: Specific Features Feature and Applicability Description PIN Support (PED, EPP, SCR, SCRP, UPT) “PIN support” denotes the type of PIN entry verification that can be supported by the POI. “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 …
Modified
p. 42 → 52
Unless otherwise noted, the “Offline” designation, without any suffix, in the PCI PTS Device Approval 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 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.
Modified
p. 42 → 53
DUKPT is the only unique key per transaction (UKPT) algorithm (ANSI X9.24) that PCI recognizes and approves; all other forms of UKPT tested by the laboratory will not be depicted in the approval letter or on the PCI PTS website.
Note: 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. 42 → 53
Note: POI v5 devices used for online PIN must support ISO PIN Block Format 4 (AES).
Note: POI v5 and v6 devices used for online PIN must support ISO PIN Block Format 4 (AES).
Modified
p. 43 → 54
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.
Modified
p. 43 → 54
• 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 enable the cardholder entering his or her PIN.
Modified
p. 43 → 54
Approved Components (PED, UPT) “Approved components” contains, when relevant, the list of approved subcomponents that are part of the approved device, and which have successfully undergone a distinct evaluation.
Approved Components (PED, UPT) “Approved components” contains, when relevant, the list of approved subcomponents 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. 43 → 54
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.
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.
Removed
p. 44
Additional Information This field may be used to place any additional pertinent information. For example, when a vendor has changed the status of a device to end-of-life as delineated in Section 4.3
• Fees and thus the device is no longer available for purchase except for maintenance purposes subject to payment brand rules. This will also be used for v2 HSMs to delineate whether they are approved for restricted or unrestricted usage as delineated in the HSM Security Requirements:
• Fees and thus the device is no longer available for purchase except for maintenance purposes subject to payment brand rules. This will also be used for v2 HSMs to delineate whether they are approved for restricted or unrestricted usage as delineated in the HSM Security Requirements:
Modified
p. 44 → 55
Note: Contactless readers are only considered compliant for P2PE usage if the Approval Class 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 …
• Card reader capabilities: The device has components that can capture card data, such as magnetic-stripe reader (MSR) or ICC reader (ICCR) or Contactless (CTLS). Note: Contactless readers are only considered compliant for P2PE usage if the Approval Class 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 …
Modified
p. 44 → 55
• SRED: The device has met the requirements in the Secure Reading and Exchange of Data module.
• SRED: The device has met the applicable Secure Reading and Exchange of Data requirements
Modified
p. 44 → 55
• OP: The device has met the requirements in the Open Protocols module.
• OP: The device has met the applicable Open Protocols requirements.
Modified
p. 44 → 56
• 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⎯e.g., Secure Environments⎯as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy.
Modified
p. 44 → 56
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.
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. 44 → 56
Device Form All security-relevant components (PIN pad, display, card reader(s)) of the device are shown in one or more pictures. At least one of the pictures must fulfill the requirement that the hardware version number must be shown on a label attached to the device. Note that for devices with multiple approved hardware versions, only one such illustration is necessary to facilitate purchasers of these devices recognizing how to determine the approved version(s).
• Remote-managed HSM Device Form All security-relevant components (PIN pad, display, card reader(s)) of the device are shown in one or more pictures. At least one of the pictures must fulfill the requirement that the hardware version number must be shown on a label attached to the device. Note that for devices with multiple approved hardware versions, only one such illustration is necessary to facilitate purchasers of these devices recognizing how to determine the approved version(s).
Removed
p. 45
Revisions to approved devices are termed “deltas.” Delta reviews involve the Recognized PTS Laboratory (or “PTS Lab”) assessing the changes based upon the most current major version of the security requirements used for the original assessment and the most current FAQ publication associated with those requirements. For example, if a device was originally assessed against PTS POI v4.0, any delta assessments would have to be performed using v4.1 (the most current version of PTS v4.x and the last issued v4.x FAQs). Examples of deltas include:
FAQs need only be applied to any area of the device that is impacted by the changes made by the vendor. For example, if a vendor were to make changes to the hardware layout of the POI design but did not change the firmware in any way, any updated FAQ entries that impact firmware only would not be applied to the delta evaluation. This is further …
FAQs need only be applied to any area of the device that is impacted by the changes made by the vendor. For example, if a vendor were to make changes to the hardware layout of the POI design but did not change the firmware in any way, any updated FAQ entries that impact firmware only would not be applied to the delta evaluation. This is further …
Modified
p. 45 → 57
This appendix is meant to provide guidance on whether changes made by vendors to a validated PTS device (whether POI or HSM) are limited enough in scope such that it is permissible that said changes to the validated PTS device may be assessed as a “delta” to the original validation.
This appendix provides guidance on whether changes made by vendors to a validated PTS Device (whether POI or HSM) are limited enough in scope such that it is permissible that said changes to the validated PTS Device may be assessed as a “delta” to the original validation. Any hardware changes to a PCI SSC-approved device that has been deployed must result in a new hardware version #. Any firmware changes to a PCI SSC-approved device must result in a new …
Modified
p. 45 → 57
B.2 What is a Delta Evaluation? All initial evaluations under a major version (e.g., 1.x, 2.x, 3.x. 4.x, 5.x etc.) of the security requirements for a given product shall constitute a new evaluation and shall receive a new approval number.
B.2 What is a Delta Evaluation? All initial evaluations under a major version⎯e.g., 1.x, 2.x, 3.x. 4.x, 5.x, 6.x, etc.⎯of the Security Requirements for a given product shall constitute a new evaluation and shall receive a new approval number.
Modified
p. 45 → 57
• Revisions to existing firmware or hardware on previously approved devices to add or modify functionality;
• Revisions to existing firmware or hardware on previously approved devices to add, modify, or delete functionality1.
Modified
p. 45 → 57
• Adding EMV Level 1 to an existing approval;
• Adding EMV Level 1 to an existing approval.
Modified
p. 45 → 57
• Maintenance fixes on devices that have expired approvals;
• Maintenance fixes on devices that have expired approvals.
Modified
p. 45 → 57
• Assessment of a device for offline PIN entry where the existing approval is only for online PIN entry, or vice versa;
• Evaluation of a device for offline PIN entry where the existing approval is only for online PIN entry, or vice versa.
Modified
p. 45 → 57
• The porting of a new set of firmware to an existing approved device.
• The porting of a new set of firmware to an existing PCI SSC-approved device.
Modified
p. 45 → 57
Delta evaluations are not permitted to take a product previously approved under an earlier major version number of the PTS POI Standard
•e.g.,4.x
•to an approval under another major version number
•e.g.,5.x.
•e.g.,
•to an approval under another major version number
•e.g.,
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.
Removed
p. 46
Firmware Change Types Impacted Requirements PTS Standard Version v1.x v2.x v3.x v4.x v5.x Any firmware change N/A N/A N/A B20 B20 Firmware changes with no apparent impact on PCI Requirements B3 B3 G1, H1, I1 B3, F1 B3, F1 Amendments in secure tamper-recovery methodology B1 B1 B1 B1 B1 Error handling (i.e., buffer overflows) A5, B2 A3, B2 A3, B2 A3, B2 A2, B2 Amendments to external communications protocols B2 B2 B2, F1 B2, F1 Change to software/firmware update mechanisms B3, B4 B3, B4 B3, B4, B3, B4, B4.1, J4 B3, B4, B4.1, J4
Modified
p. 46 → 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 assessment 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. 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.
Modified
p. 46 → 58
B.3.2 Firmware Changes In general, any and all changes made to the firmware that runs on a previously approved PTS device may be considered in a single delta assessment 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. PTS …
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. …
Modified
p. 46 → 59
Table 8: Firmware Change Types and Impacted Requirements Acceptable firmware changes that may be considered in a delta assessment include, but are not limited to:
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:
Modified
p. 47 → 60
N/A N/A B17-19, B.3.3 Hardware Changes Changes made by vendors to the hardware of previously approved PTS devices are permissible so long as 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 changes may rationalize the exclusion of any identified requirement or the inclusion of additional requirements based on their assessment of …
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 …
Removed
p. 48
Hardware Change Types Impacted Requirements PTS Standard Version v1.x v2.x v3.x v4.x v5.x Any hardware change2 A1, A2, A3, C1 A1, A7 A1, A7 Changes in casing plastics (e.g., cover- opening dimensions, areas that permit internal access, changes to PED look and feel, etc.) or output-only displays. Amended devices must remain consistent to the device’s original form factor.
A4, A7, A9-A11, A2, A6, A8-A11, A2, A6, A8-A11, B16, D1- A5, A7-A9, A11 B16, D1- A4, A6-A8, A10 B16, 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).
A4, A7, A9-A11, A2, A6, A8-A11, A2, A6, A8-A11, B16, D1- A5, A7-A9, A11 B16, D1- A4, A6-A8, A10 B16, 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).
Modified
p. 48 → 61
Any change made to the hardware of an approved PED, even to the non-security related components, has the potential to directly or indirectly impact the security of the device. As such, any delta assessment 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 on the followingsecurity requirements of the applicable version of the PTS …
•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 on the following
Any change made to the hardware of a PCI SSC-approved PED, even to the non-security related components, has the potential to directly or indirectly impact the security of the device. 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 on the following requirements of the applicable version of the Security …
•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 on the following requirements of the applicable version of the Security …
Modified
p. 48 → 61
• V1.x: Requirements A1, A2, A3 & C1;
• V1.x: Requirements A1, A2, A3, & C1
Modified
p. 48 → 61
• V2.x: Requirements A1 & A7; and
• V2.x: Requirements A1 & A7
Modified
p. 48 → 61
• V3.x: Requirements A1 & A7 and
• V3.x: Requirements A1 & A7
Modified
p. 48 → 61
• V4x: Requirements A1, A6, B1 & B20
• V4.x: Requirements A1, A6, B2, & B20
Modified
p. 48 → 61
• V5x: Requirements A1, A5, B1 and B20
• V5.x: Requirements A1, A5, B2, & B20
Modified
p. 48 → 62
Table 9: Acceptable Hardware Changes Acceptable hardware changes that may be considered in a delta assessment include, but are not limited to:
Table 9: Acceptable Hardware Changes Acceptable hardware changes that may be considered in a delta evaluation include, but are not limited to:
Removed
p. 49
A5, A8 A3, A5 A3, A5 A3, A11 A2, A10 B.4 Engaging a PTS Lab to Perform a Delta Assessment Vendors may select a different PTS Lab to perform a delta assessment than the PTS Lab used to perform the initial evaluation or prior delta evaluation. However, the subsequent PTS Lab (“Delta Lab”) is free to determine the level of reliance they wish to place upon the prior PTS Lab’s work and will be responsible for any claims of compliance which are generated through the delta review; and this may result in additional work than would otherwise be necessary. For Version 3 or higher reports, the Delta Lab shall have access to the prior PTS Lab’s report(s), including any delta or OEM component reports subsequent to the original evaluation. If those reports are not available, the Delta Lab shall decline the engagement or else must complete a full evaluation of …
Modified
p. 50 → 64
• Name of the approved PTS device;
• Name of the approved PTS Device;
Modified
p. 50 → 64
• Details of the currently approved PTS device on the List of Approved PTS Devices that is being used as a reference for the assessment;
• Details of the currently approved PTS Device on the Approved Device List that is being used as a reference for the evaluation;
Modified
p. 50 → 64
• Explanation of how and why PTS requirements are impacted;
• Explanation of how and why PTS Security Requirements are impacted;
Modified
p. 50 → 64
B.5.2 Reporting Requirements for PTS Laboratories 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 changes’ evaluation, equivalent to the levels of detail specified in DTRs. PTS Labs must provide the following documentation with each delta submission:
Modified
p. 50 → 64
• A high-level description of the changes that have been made to the approved PTS device;
• A high-level description clearly defining all of the changes that have been made to the approved PTS Device;
Modified
p. 50 → 64
• The reference approval report and any subsequent delta submissions upon which the current delta submission is based; and
• The reference approval report and any subsequent delta submissions upon which the current delta submission is based, and
Modified
p. 50 → 65
• 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 embodied in the update to the approved PTS Device from the previously approved configuration:
Modified
p. 50 → 65
• A high-level assessment of the security impact of the change;
• A high-level evaluation of the security impact of the change;
Modified
p. 50 → 65
• A high-level description of the testing completed, if any, used to validate the assessment;
• A high-level description of the completed testing, if any, used to validate the evaluation;
Modified
p. 50 → 65
• Updated responses to the affected PTS Security Requirements that clearly depict any changes that are necessary to the reference assessments.
• Updated responses to the affected PTS Security Requirements that clearly depict any changes that are necessary to the reference evaluations.
Removed
p. 51
B.7 Considerations for Updated Components in Integrated Terminals Vendors with approved PTS devices that integrate other PTS-approved OEM components (such as unattended payment terminals) may seek delta assessments on such devices for changes that occur to the embedded OEM components, including replacement of any given 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 over the final assembly and manufacture of the integrated terminal or UPT.
Modified
p. 51 → 65
The intent is not to cause a device in evaluation to fail due to the publication of FAQs subsequent to the approval of that device. This may, however, be necessary if known exploits exist that significantly change the threat environment for the device from when it was originally evaluated. Unless one or more such exploits exist, a product currently in evaluation will generally not be subject to new FAQs issued during the product’s evaluation. This does not exempt a product …
The intent is not to cause a device in evaluation to fail due to the publication of such FAQs subsequent to the approval of that device. This may, however, be necessary if known exploits exist that significantly change the threat environment for the device from when it was originally evaluated. Unless one or more such exploits exist, a product currently in evaluation will generally not be subject to new FAQs issued during the product’s evaluation. This does not exempt a …
Modified
p. 51 → 65
Devices undergoing delta evaluations must take into account the current 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 current FAQs associated with B1 and B4 must be taken into account as part of the delta.
Devices undergoing delta evaluations must take into account the current 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 current FAQs associated with B1 and B4 must be taken into account as part of the delta.
Modified
p. 51 → 65
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 their submission the version of the Security Requirements used in the evaluations, as well as the publication date of the technical FAQs used.
Modified
p. 51 → 66
Changes that occur in the final form factor itself (e.g., the housing), because of the complexity of integration, must undergo testing as a new evaluation against a version of requirements that has not been retired from use for new evaluations.
Changes that occur in the final form factor itself⎯e.g., the housing, because of the complexity of integration⎯must undergo testing as a new evaluation against a version of the Security Requirements that has not been retired from use for new evaluations.
Modified
p. 51 → 66
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, 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.
Removed
p. 52
Job Title of Individual Requesting Change Role (Primary, Billing, Technical) Description of Change(s) Type of Change (check all that apply) Business Name Business Address Device Model Name(s) Name/Address Briefly describe reason for change(s) Revised Company Details New Business Name New Website Mailing Address Billing Address Device Model(s) PTS Approval Number Model Name New Model Details New Model Name Image included *
Removed
p. 53
Primary/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 Supporting Documentation Required Administrative Change (this form) Security Policy Vendor Release (VRA) Device Images* Company Name Change X X X X Device Model name X X X Primary Contact Name X * If applicable images must be submitted via a delta submission.
Removed
p. 55
A: No modifications have been made to the firmware version; B: Firmware version noted uses a validated wildcard versioning methodology, and only “No Impact” changes have been made; or C: All changes have been submitted for evaluation by a PTS laboratory that did not fit into category B. This includes for POI devices all vulnerabilities identified by the vendor in each of the protocols and interfaces defined in POI security requirement F1 as evidenced by the vulnerability assessment process enumerated under Section G of the POI DTRs.
Modified
p. 55 → 71
PTS Approval Number Model Name Firmware submission status for the 12 months ending December 31 of the prior year
PTS Approval Approval Expiry Date Model Name Firmware Firmware submission status for the 12 months ending December 31 of the prior