Document Comparison
PTS_Program_Guide_v2.0.pdf
→
PTS_Program_Guide_v2.1b.pdf
91% similar
73 → 74
Pages
23743 → 24888
Words
80
Content Changes
Content Changes
80 content changes. 78 administrative changes (dates, page numbers) hidden.
Added
p. 2
December 2022 2.1 Updated firmware expiry, administrative changes, Appendices A and B.
February 2023 2.1a Updated Expiry Date table.
April 2024 2.1b Updated Approval Class Features and Expiry Dates sections.
February 2023 2.1a Updated Expiry Date table.
April 2024 2.1b Updated Approval Class Features and Expiry Dates sections.
Added
p. 18
The ’Guidance’ in the Derived Test Requirements must be fully considered as required unless they stipulate ‘may’ or ‘should’.
Added
p. 22
• Must use the Firmware Expiration Report template.
• Cannot include other evaluation types e.g., rebranding, hardware or firmware deltas, etc.
• The firmware expiry cannot be past the re-evaluation window, such as shown for firmware version 23.01.xx.xx in the table below.
Where the vendor has multiple firmware versions expiring in different years the evaluations can be combined into one report, effectively synchronizing the expiration dates going forward. But, in order to do so, the following conditions must be met:
• The Firmware Expiration evaluation is specific to an Approval Number.
• For example, if firmware version v123.45 is used on devices with Approval Number 4- 12345 and 4-67890, a separate report is required for each Approval Number.
• Under a given Approval Number any or all relevant firmware
•requiring expiration evaluation
•may be included in the evaluation.
• Each firmware version in the report must stand alone⎯i.e., different sections⎯in the evaluation report.
Each firmware version on the Approved Device …
• Cannot include other evaluation types e.g., rebranding, hardware or firmware deltas, etc.
• The firmware expiry cannot be past the re-evaluation window, such as shown for firmware version 23.01.xx.xx in the table below.
Where the vendor has multiple firmware versions expiring in different years the evaluations can be combined into one report, effectively synchronizing the expiration dates going forward. But, in order to do so, the following conditions must be met:
• The Firmware Expiration evaluation is specific to an Approval Number.
• For example, if firmware version v123.45 is used on devices with Approval Number 4- 12345 and 4-67890, a separate report is required for each Approval Number.
• Under a given Approval Number any or all relevant firmware
•requiring expiration evaluation
•may be included in the evaluation.
• Each firmware version in the report must stand alone⎯i.e., different sections⎯in the evaluation report.
Each firmware version on the Approved Device …
Added
p. 27
It is the responsibility of the Laboratory to ensure evaluation test reports and all other information related to report submissions are accurate, complete, and conform to the PTS Program.
For reports on modifications to existing approved devices, termed “delta” letters or reports, the cycle is an initial 28 calendar days, and PCI SSC shall post the revised information to the Website and issue a revised approval letter unless issues or questions arise in a manner similar to the aforementioned. Delta reports are prepared using the major Security Requirements the payment security device was evaluated against when newly approved. When feasible, changes attributed to the delta should use revision marks on the original report. If not feasible⎯e.g., because of numerous deltas on the same device⎯the changes must still be explicitly noted.
For reports on modifications to existing approved devices, termed “delta” letters or reports, the cycle is an initial 28 calendar days, and PCI SSC shall post the revised information to the Website and issue a revised approval letter unless issues or questions arise in a manner similar to the aforementioned. Delta reports are prepared using the major Security Requirements the payment security device was evaluated against when newly approved. When feasible, changes attributed to the delta should use revision marks on the original report. If not feasible⎯e.g., because of numerous deltas on the same device⎯the changes must still be explicitly noted.
Added
p. 32
6. If the licensee vendor wishes to directly manufacture the licensee product or have a third party other than the licensor vendor manufacture the licensee product on its behalf, the product must be reassessed as a new evaluation against the current version of the applicable Security Requirements•unless the licensor vendor can demonstrate that it retains both the intellectual property and engineering control. This is due to the potential for changes in plastics, etc. that may impact the security of the device.
Added
p. 33
For vendors who undergo a legal name change, the existing vendor name will be noted as formerly known as (FKA). FKA will also be used where a vendor makes changes to a previously established “DBA” (see Section A.5).
If two existing listed vendors undergo a merger, or if a vendor is involved in a transaction resulting in a change of the legal entity that is the vendor, the name of the vendor may or may not change as a result. In either case, [devices] listed under the vendor before the transaction will be listed under the name of the surviving/new/resulting vendor, with a brief description of the change (e.g., “XYZ Merged with ABC”). In such cases, evidence of the applicable transaction acceptable to PCI SSC is required along with the PTS Administrative Change Request form.
In all cases, the vendor must also submit a new Vendor Release Agreement under the new company …
If two existing listed vendors undergo a merger, or if a vendor is involved in a transaction resulting in a change of the legal entity that is the vendor, the name of the vendor may or may not change as a result. In either case, [devices] listed under the vendor before the transaction will be listed under the name of the surviving/new/resulting vendor, with a brief description of the change (e.g., “XYZ Merged with ABC”). In such cases, evidence of the applicable transaction acceptable to PCI SSC is required along with the PTS Administrative Change Request form.
In all cases, the vendor must also submit a new Vendor Release Agreement under the new company …
Added
p. 38
RAP Remote Administration Platform for HSMs Remote Administration Solution A non-console-based mechanism for the administration of HSMs that may involve the use of RAP devices or smart card-based implementations.
A PIN entry device (PED) is a class of POI that supports the secure acceptance of a cardholder’s PIN.
A.5 Vendor Name Vendors shall be listed by their full legal name. A vendor’s listing may also include its trade name, alternate name, or doing-business-as name (each a “DBA”). If the vendor requests the listing of a DBA, the vendor must provide a government approved DBA or similar authorization acceptable to PCI SSC. The vendor shall be listed by the full legal name, followed by the DBA.
A PIN entry device (PED) is a class of POI that supports the secure acceptance of a cardholder’s PIN.
A.5 Vendor Name Vendors shall be listed by their full legal name. A vendor’s listing may also include its trade name, alternate name, or doing-business-as name (each a “DBA”). If the vendor requests the listing of a DBA, the vendor must provide a government approved DBA or similar authorization acceptable to PCI SSC. The vendor shall be listed by the full legal name, followed by the DBA.
Added
p. 42
In addition, all options, both security and non-security relevant, must be clearly defined and documented as to the options available and their function in the evaluation report. Security-relevant options must be exhaustively defined and documented in the security policy. For non-security options, the security policy must include a description of the option, but not a full list of all possible values.
Added
p. 45
PIN support PIN Encryption Key Management SRED Key Management Prompt Control PIN-Entry technology ICCR MSR CTLS Display SRED OP Supports ISO Format 4 Interface Isolation
SRED Key Management Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi
PIN Encryption Key Management is only applicable where the SCR does PIN translation in connection with sending the PIN online to a host and must meet the determining keys requirements.
PIN Support PIN Encryption Key Management SRED Key Management Supports ISO Format 4 Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi
PIN support PIN Encryption Key Management SRED Key Management ICCR MSR CTLS SRED OP Supports ISO Format 4 Interface Isolation
PIN support PIN Encryption Key Management SRED Key Management Prompt control PIN-Entry Technology Supports ISO Format 4 Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi
Table 7: Specific Features Feature and Applicability Description PIN Support (EPP, PED, SCR, SCRP, UPT) “PIN support” denotes the type of PIN entry verification that can be supported by the …
SRED Key Management Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi
PIN Encryption Key Management is only applicable where the SCR does PIN translation in connection with sending the PIN online to a host and must meet the determining keys requirements.
PIN Support PIN Encryption Key Management SRED Key Management Supports ISO Format 4 Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi
PIN support PIN Encryption Key Management SRED Key Management ICCR MSR CTLS SRED OP Supports ISO Format 4 Interface Isolation
PIN support PIN Encryption Key Management SRED Key Management Prompt control PIN-Entry Technology Supports ISO Format 4 Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi
Table 7: Specific Features Feature and Applicability Description PIN Support (EPP, PED, SCR, SCRP, UPT) “PIN support” denotes the type of PIN entry verification that can be supported by the …
Added
p. 71
For all POI 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.
Modified
p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version 2.0
Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version 2.1b
Modified
p. 2
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, Keymanagement, 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
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. 6
• 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.
• PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Security Requirements, v4.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. 6
• PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Security Requirements, v4.0 Provide the forms to be used by laboratories and vendors.
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, v6.2
Modified
p. 7
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements, v6.0
• PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Derived Test Requirements, v6.2
Modified
p. 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 online and offline PIN-entry options, 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.
Modified
p. 14
Process Stage Resource/Explanation Illustration Prior to testing Testing and Approval Process Description Figure 1 Obtain appropriate documentation and forms Detailed Evaluation Process Figure 2 Contact a PCI-Recognized Laboratory to initiate testing Preparation for Testing Figure 2 Sign Vendor Release Agreement (VRA) Approval Process Figure 2
Process Stage Resource/Explanation Illustration Prior to testing Testing and Approval Process Description Figure 1 Obtain appropriate documentation and forms Detailed Evaluation Process Figure 2 Contact a PCI-Recognized Laboratory to initiate testing Preparation for Testing Figure 2 Sign Vendor Release Agreement (VRA) Approval Process Figure 2 Submit documentation and materials Requirements for Testing Figure 2 Respond to inquiries from Laboratory Technical Support throughout Testing Figure 2 Receive response or approval letter from PCI SSC Approval Process Figure 2 PTS Device changes …
Modified
p. 19 → 18
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.
The Technical FAQs are also an integral part of the evaluation process. Technical FAQs are identified by major version of the Security Requirements⎯e.g., 4.x, 5.x, 6.x. Each Technical FAQ version is specific to the corresponding major version of Security Requirements. For example, Technical FAQs version 6 is specific to Security Requirements version 6.x and only Security Requirements version 6.x, and so on.
Modified
p. 19 → 18
Modifications, changes, and revisions of PCI SSC-approved devices, termed “deltas,” can occur at any time during the product’s approval. Devices undergoing delta evaluations must take into account the then current Technical FAQs of the associated major version of Security Requirements only for the Security Requirement(s) that are impacted by the delta change. For example, if a change impacts compliance with requirements B1 and B4, only the then current Technical FAQs associated with B1 and B4 must be taken into account …
Modifications, changes, and revisions of PCI SSC-approved devices, termed “deltas,” can occur at any time during the product’s approval. Devices undergoing delta evaluations must take into account the then current Technical FAQs of the associated major version of Security Requirements only for the Security Requirement(s) that are impacted by the delta change. For example, if a change impacts compliance with requirements B1 and B4, only the then current Technical FAQs associated with B1 and B4 must be considered as part …
Modified
p. 22 → 21
This evaluation is in addition to the annual AOV and must take into account changes in the vulnerability landscape.
This evaluation is in addition to the annual AOV and must consider changes in the vulnerability landscape.
Modified
p. 23 → 22
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 2030 A123-xxx-789-xx A123--0AB-xx Firmware # 23.01.xxx xx (2022) 23.02.xxx xx (2023)
Modified
p. 27 → 26
All PCI SSC-approved devices for which the approval has not expired shall be billed an approval-listing fee for all such approvals that existed as 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 …
All PCI SSC-approved devices for which the approval has not expired shall be billed an approval-listing fee for all such approvals that existed as denoted above. Vendors shall not be billed the annual listing fee for “End of Life” (EOL) products for which they have notified PCI SSC in writing at least ninety (90) days prior to the billing date of 1 May. An end-of-life product is a product no longer marketed for new deployments as described in Section A.13, …
Modified
p. 28 → 27
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.
It is the responsibility of the Laboratory and the vendor to allow sufficient time in project scheduling for: device evaluation, report submission for review, inquiry responses and report resubmits, approval process, etc.
Modified
p. 28 → 27
PCI SSC bases its approval solely on the results of the Laboratory evaluation report. All reports, inquiries from report reviewers, and Laboratory responses to inquiries are managed through the Portal. Upon receipt of the test report for a new evaluation, PCI SSC will generally identify any technical issues or questions for resolution by the Laboratory within two weeks (14 calendar days). If the report is deemed by the reviewers as sufficiently deficient in quality, it shall be rejected prior to …
PCI SSC bases its approval solely on the results of the Laboratory evaluation report. All reports, inquiries from report reviewers, and Laboratory responses to inquiries are managed through the Portal. Upon receipt of the test report for a new evaluation, PCI SSC will generally identify any technical issues or questions for resolution by the Laboratory within four weeks (28 calendar days). If the report is deemed by the reviewers as deficient in quality, a reissuance of the report shall be …
Removed
p. 29
For reports on modifications to existing approved devices, termed “delta” letters or reports, the cycle⎯e.g., an initial 14 calendar days⎯is the same, and PCI SSC shall post the revised information to the Website and issue a revised approval letter unless issues or questions arise in a manner similar to the aforementioned. Delta reports are prepared using the major Security Requirements the payment security device was evaluated against when newly approved. When feasible, changes attributed to the delta should use revision marks on the original report. If not feasible⎯e.g., because of numerous deltas on the same device⎯the changes must still be explicitly noted.
Modified
p. 30 → 29
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.
For devices that embed other PCI SSC-approved devices and are therefore basing their security on these approved components (even partially), the expiration date shall be the earliest among all evaluations, including the embedded device itself.
Modified
p. 32 → 31
Additional individual security requirements in POI v6 that were not previously evaluated shall still apply if applicable to the overall UPT evaluation. Furthermore, 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 to expire date among all evaluations, including the embedded device itself.
Additional individual security requirements in POI v6 that were not previously evaluated shall still apply if applicable to the overall UPT evaluation. Furthermore, for devices that embed other PCI SSC-approved devices and are therefore basing their security on these components (even partially), the expiration date shall be the earliest to expire date among all evaluations, including the embedded device itself.
Removed
p. 33
6. If the licensee vendor wishes to directly manufacture the licensee product, or have a third party other than the licensor vendor manufacture the licensee product on its behalf, the product must be reassessed as a new evaluation against the current version of the applicable Security Requirements•unless the licensor vendor can demonstrate that it retains both the intellectual property and engineering control. This is due to the potential for changes in plastics, etc. that may impact the security of the device.
Modified
p. 34 → 33
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 PTS Administrative Change Request form.
Modified
p. 38 → 37
Product Type The product type describes both the approval class of a device and whether the device is a module to be integrated (OEM) or not.
Product Type The product type describes whether or not the device is a module to be integrated (OEM).
Modified
p. 39 → 38
SCR Secure Card Reader approval class SCRP Secure Card Reader PIN approval class SPoC Software-based PIN-entry on COTS SRED Secure Reading and Exchange of Data Terminal Commercial device with a business function. It may be dedicated to payment (POS terminal with integrated or separate PIN pad) or to product-dispensing (for example, an ATM or petrol-dispensing self-service).
Modified
p. 40 → 39
A.1 Point of Interaction (POI) For purposes of these requirements, a POI PIN-acceptance device is defined as:
A.1 Point of Interaction (POI) For purposes of these requirements, a POI device is defined as:
Modified
p. 40 → 39
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 and/or account data, used for the purchase of goods or services or dispensing of cash. An approved POI has met all of the applicable PCI PTS POI requirements for PIN entry and/or account-data entry and has a clearly defined physical and logical boundary for all functions related to PIN entry.
Modified
p. 40 → 39
If the POI device is designed to be embedded into a wider set⎯e.g., vending machine or ATM⎯then EPP or PED approval class would apply. In such case, there can be other functionalities present besides PIN capture and conveyance⎯e.g., display, card reader. Devices entering this category will have the product type 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 noted with the word “OEM” on the listing, to unambiguously advertise the modular nature.
Modified
p. 42 → 40
• 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 …
• Application #, if applicable The model name/number and vendor name must be visually and distinctly present on the device and not be part of a larger character string. The device must show the version numbers of hardware and firmware in accordance with the device’s approval, reflecting information on the Approved Device List. The model name and hardware version must be retrievable from the device by a query. The hardware number must be shown on a label attached to the …
Modified
p. 42 → 41
A.6 Model Name/Number The model name/number cannot contain any variable characters. All devices within a device family that are intended to be marketed under the same approval number must be explicitly named, and pictures of those devices presented in both the evaluation report and for display on the Approved Device List. The vendor cannot use an identical model name for more than one device approved by PCI SSC under a given major version release of the applicable Security Requirements. The …
Removed
p. 43
In addition, all wildcard options, both security and non-security relevant, must be clearly defined and documented as to the options available and their function in both the evaluation report and in the device’s security policy.
Modified
p. 43 → 42
Options that cannot be a variable character include those that directly pertain to meeting applicable Security Requirements. For example, requirements exist for magnetic-stripe readers (MSRs) and integrated circuit card readers (ICCRs). A variable character cannot be used to designate whether a device contains a MSR or an ICCR. A requirement exists for the deterrence of visual observation of PIN values as they are being entered by the cardholder, which can be met by privacy shields or the device’s installed environment …
Options that cannot be a variable character include those that directly pertain to meeting applicable Security Requirements. For example, requirements exist for magnetic-stripe readers (MSRs) and integrated circuit card readers (ICCRs). A variable character cannot be used to designate whether a device contains a MSR or an ICCR. A requirement exists for the deterrence of visual observation of PIN values as they are being entered by the cardholder, which can be met by privacy shields or the device’s installed environment …
Modified
p. 44 → 43
Table 4: Examples on the Use of Hardware #s Hardware # of Payment Security Device in Approved Device List NN-421-000-AB Hardware # NN-421-000-AB of the Device Identifier does not employ the use of the variable "x." Hence, the payment security device being deployed must match the Hardware # exactly 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 for the PTS Device to be considered an approved payment security device (hardware component).
Modified
p. 44 → 43
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 …
NN-4x1-0x0-Ax Hardware # NN-4x1-0x0-Ax of the Device Identifier uses 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 component). However, if the …
Modified
p. 44 → 43
A.8 Security Policy The device vendor provides a user-available security policy that addresses the proper use of the device in a secure fashion, including information on key-management responsibilities, administrative responsibilities, device functionality, identification, and environmental requirements. The security policy must define the roles supported by the device and indicate the services available for each role in a deterministic tabular format. The device is capable of performing only its designed functions•i.e., there is no hidden functionality. The only approved functions performed …
Modified
p. 44 → 43
A.9 Approval Number Approval numbers are assigned by PCI SSC at the time of approval and remain the same for the life of the device’s approval.
Modified
p. 46 → 45
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 in A.14 below for detail) EPP An approval class aimed at secure PIN entry and encryption modules in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader or rely upon external displays or card readers installed in the unattended device.
Modified
p. 46 → 45
An EPP is typically used in an unattended PIN-acceptance device for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary and a tamper-resistant/responsive or tamper-evident shell. At a minimum, a device submitted for EPP approval must contain a PIN-entry keypad along with its built-in secure cryptographic module. Original equipment manufacturers (OEMs) or providers of encrypting PIN pads (EPPs) to unattended PIN- acceptance device manufacturers⎯e.g., ATMs or UPTs⎯and other self-service device …
An EPP is typically used in an unattended PIN-acceptance device for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary and a tamper-resistant/responsive or tamper-evident shell. At a minimum, a device submitted for EPP approval must contain a PIN-entry keypad along with its built-in secure cryptographic module. Original equipment manufacturers (OEMs) or providers of encrypting PIN pads (EPPs) to unattended PIN- acceptance device manufacturers⎯e.g., ATMs or UPTs⎯and other self-service device …
Modified
p. 46 → 45
• Bluetooth Interface Isolation HSM HSMs may support a variety of payment processing and cardholder authentication applications and processes. The processes relevant to the full set of requirements outlined in this document are:
Modified
p. 46 → 45
• Chip Card Transaction Processing
• Chip Card Transaction Processing Remote Administration Restricted Unrestricted Supports ISO Format 4 Remote-managed HSM
Modified
p. 47 → 46
Non-PED An approval class of POI devices that does NOT allow the entry of a PIN for a payment card transaction. This class is for ALL POI devices or device combinations, attended or unattended, which do not support PIN-based payment transactions. OEM product types may require further integration into a POI terminal.
Remote Administration Restricted Unrestricted Supports ISO Format 4 Remote-managed HSM Non-PED An approval class of POI devices that does NOT allow the entry of a PIN for a payment card transaction. This class is for ALL POI devices or device combinations, attended or unattended, which do not support PIN-based payment transactions. OEM product types may require further integration into a POI terminal.
Modified
p. 48 → 47
PIN support PIN Encryption Key Management SRED Key Management Prompt control PIN-Entry Technology Display SRED Supports ISO Format 4 Interface Isolation
• Bluetooth Interface Isolation
• Wi-Fi RAP This is for platforms that are used for remote administration of HSMs. Such administration includes device configuration and may also include clear-text cryptographic key-loading services as part of the same SCD.
• Bluetooth Interface Isolation
• Wi-Fi RAP This is for platforms that are used for remote administration of HSMs. Such administration includes device configuration and may also include clear-text cryptographic key-loading services as part of the same SCD.
Modified
p. 49 → 48
A Secure Card Reader can be
A Secure Card Reader can be:
Modified
p. 49 → 48
• 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 …
• A contactless-only reader SCRs must meet as applicable the ICCR, CTLS, 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, …
Modified
p. 49 → 48
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
•it
If a SCR supports offline PIN authentication via an ICCR component or it formats and encrypts a PIN block to send online directly to the host•it must be validated in conjunction with a specific PIN entry device⎯e.g., PED or EPP⎯to validate the security of the interaction, including the establishment of the keying relationship. The PIN entry device must either be previously approved or obtain approval concurrent with the SCR in the same or a concurrent, separate Laboratory evaluation.
Removed
p. 50
PIN support Prompt control Key management PIN-entry technology
Modified
p. 50 → 49
• Bluetooth Interface Isolation UPT The UPT class of device covers cardholder-operated payment devices that read, capture, and transmit card information in conjunction with an unattended self-service device, including, but not limited to, the following:
Modified
p. 51 → 50
A.13 Expiry Date The expiration date for PCI SSC-approved devices is the date upon which the device’s approval expires. All device approvals expire in accordance with the schedule below.
Modified
p. 52 → 51
“Online” represents that the POI has the capability to support online PIN verification by the payment card’s issuer or its designated processor. To pass testing, POIs that support online PIN entry must support the use of TDES or AES to protect the PIN. Additionally, if the PIN needs to be protected during transport in nonintegrated offline POIs, then the POI must support the use of TDES or AES for that channel. “Offline” means that the POI has the capability to …
Modified
p. 52 → 51
All newly approved offline PIN verification POIs must support both plaintext and enciphered PIN verification.
Note: All newly approved offline PIN verification POIs must support both plaintext and enciphered PIN verification.
Modified
p. 53 → 52
DUKPT is the only unique key per transaction (UKPT) algorithm (ANSI X9.24) that PCI SSC recognizes and approves; all other forms of UKPT tested by the Laboratory will not be depicted in the approval letter or on “Approved PTS Devices” on the Website.
Modified
p. 53 → 52
This is for POI devices supporting the entry of online PINs, and in general, this will be N/A for devices in the Non-PED or SCR approval classes, and by definition, will be N/A for offline PIN only devices.
This is for POI devices supporting the entry of online PINs, and in general, this will be N/A for devices in the Non-PED or SCR approval classes and will be N/A for offline PIN-only devices. SCRPs can indirectly support online PIN in connection with mobile-based solutions via PIN translation.
Modified
p. 53 → 52
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.
SRED Key Management (EPP, PED, SCR, SCRP, UPT) “SRED key management” denotes whether the Laboratory has successfully evaluated the payment security device to support the use of Triple DES (TDES) or AES for Account Data encryption. TDES requires use of at least a triple-length key or DUKPT for account data encryption.
Removed
p. 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. Each component is listed with its approval number.
Modified
p. 54 → 53
• Vendor-controlled: The end-user, acquirer, or reseller cannot modify the attended POS POI’s firmware or POI’s payment application to make changes to the device’s prompts or PIN-entry controls. Only the POI’s original equipment manufacturer has the capability to modify the prompts and controls for PIN entry.
• Vendor-controlled: The end-user, acquirer, or reseller cannot modify the POI’s firmware or POI’s payment application to make changes to the device’s prompts or PIN-entry controls. Only the POI’s original equipment manufacturer has the capability to modify the prompts and controls for PIN entry.
Modified
p. 54 → 53
• Acquirer-controlled: The original equipment manufacturer has shipped the attended POS POI with mechanisms for controlling the POI display and its use in place. These mechanisms can be employed to unlock the POI for updates of the prompts by the acquirer, using proper cryptographically controlled processes as defined in the applicable POI security requirement. The reseller or end-user, if authorized by the acquirer, can also make updates using proper cryptographically controlled processes.
• Acquirer-controlled: The original equipment manufacturer has shipped the POI with mechanisms for controlling the POI display and its use in place. These mechanisms can be employed to unlock the POI for updates of the prompts by the acquirer, using proper cryptographically controlled processes as defined in the applicable POI security requirement. The reseller or end- user, if authorized by the acquirer, can also make updates using proper cryptographically controlled processes.
Modified
p. 54 → 53
PIN-Entry Technology (PED, EPP, UPT) “PIN-entry technology” denotes which technology is implemented in order to capture the cardholder PIN. The value for this field can be:
PIN-Entry Technology (EPP, PED, UPT) “PIN-entry technology” denotes which technology is implemented in order to capture the cardholder PIN. The value for this field can be:
Modified
p. 54 → 53
• N/A: For HSMs, non-PEDs, and for SCRs and SCRPs except as denoted in the SCR or SCRP approval class.
• N/A: For HSMs, non-PEDs, SCRs, and SCRPs.
Removed
p. 55
• PIN entry: The device enables cardholder PIN capture.
Modified
p. 55 → 54
• 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 …
• 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 device in question has been validated to SRED. Furthermore, some device approvals may have versions validated to SRED and some that are not. Where such a mix occurs, only devices using a firmware version designated for SRED are validated to meet the contactless …
Modified
p. 55 → 54
• Display: The device has an integrated display used for cardholder prompts and possibly the presentation of other information.
• Display: The device has an integrated display used for cardholder prompts⎯i.e., prompts for PIN entry⎯and possibly the presentation of other information.
Modified
p. 55 → 54
• SRED: The device has met the applicable Secure Reading and Exchange of Data requirements
• SRED: The device has met the applicable Secure Reading and Exchange of Data requirements.
Removed
p. 56
• 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).
Modified
p. 56 → 55
• 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 for Multi-tenant HSMs
• Interface Isolation In addition, v4 HSMs that meet additional criteria to support remote⎯e.g., non- console⎯administration for configuration and cryptographic key loading, will be noted here as “Remote-managed HSM.” Requirements for Remote-managed HSMs are a subset of those for Multi-tenant HSMs
Modified
p. 57
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 deltas include:
Evaluation of deltas involve the PTS Lab assessing the changes based upon the most current major version of the Security Requirements used for the original evaluation and the most current Technical FAQ publication associated with those requirements. For example, if a device was originally assessed against PTS POI v6.0, any delta evaluation would have to be performed using the most current version of PTS v6.x and the last issued v6.x FAQs. Examples of deltas include:
Modified
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, …
Firmware Change Types Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x v6.x Any firmware change B3 B3 B3, F1, G1, Changes in tamper management, for example, response, detection, and recovery B1 B1 B1 B1 B1 B1 Error handling⎯i.e., buffer overflows A5, B2 A3, B2 A3, B2 A3, B2 A2, B2 A3, D1 Amendments to external communications protocols B2 B2 B2, F1, G1, B2, F1 B2, F1 D1, D2 Change to software/firmware update mechanisms B3, B4 B3, B4 …
Modified
p. 60
Note: SRED deltas on v2.x devices will not be accepted after 31 December 2012.
Note: SRED deltas on v2.x devices are not accepted.
Modified
p. 60
The inclusion of more than four (4) of the identified hardware change types as delineated in the table below in a single delta submission for a previously PCI SSC-approved PTS Device may effectively represent a new device that should be subjected to its own full evaluation against the latest version of the current PTS Standard. Candidates for delta submissions that surpass this threshold which, in the opinion of the PTS Lab, represent a minor change to the approved PTS Device, …
The inclusion of more than four (4) of the identified hardware change types as delineated in the table below in a single delta submission for a previously PCI SSC-approved PTS POI Device may effectively represent a new device that should be subjected to its own full evaluation against the latest version of the current PTS Standard. Candidates for delta submissions that surpass this threshold which, in the opinion of the PTS Lab, represent a minor change to the approved PTS …
Modified
p. 61
For example, a vendor makes a change to the tamper grids and signal routing on six PCBs within a device. According to the delta scoping guidance, the inclusion of four or more hardware change types in a single delta submission for a previously PCI SSC-approved PTS 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 …
For example, a vendor makes a change to the tamper grids and signal routing on six PCBs within a device. According to the delta scoping guidance, the inclusion of four or more hardware change types in a single delta submission for a previously PCI SSC-approved PTS POI Device may effectively represent a new device that should be subject to its own full evaluation against the latest version of the current PTS Standard. In this example, this does not count as …
Modified
p. 61
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 potentialimpact 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
Any change made to the hardware of a PCI SSC-approved PTS device, even to the non-security related components, has the potential to impact the security of the device directly or indirectly. As such, any delta evaluation that includes modifications to the approved device’s hardware
•even the circuitry not related to the security functions of the device
•must, at a minimum, be reviewed by the PTS Lab with respect to the potential impact. For example, for POI devices the following requirements of the …
•even the circuitry not related to the security functions of the device
•must, at a minimum, be reviewed by the PTS Lab with respect to the potential impact. For example, for POI devices the following requirements of the …
Modified
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, …
Hardware Change Types Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x V6.x Any hardware change2 A1, A2, A1, A7 A1, A7 A1, A6, B2, B20 A1, A5, B2, B20 A1, A2, A6, A7, B20, D2 Changes in casing plastics⎯e.g., cover-opening dimensions, areas that permit internal access⎯or output-only displays. Amended devices must remain consistent to the device’s original form factor and visible characteristics.3 A4, A7, A9−A11, A2, A6, A8−A11, A2, A6, A8−A11, B16, D1−D4, A5, A7−A9, A11, B16, …
Modified
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, A6, A8, A9, A11, D1 A2, A6, A8-A10, B16, D1 A5, A7- A9, A11, A4, A6- A8, A10, A5, A8- A10, B5, B15, A13 Replacement or addition of any one reader.5 D1-4 A10, A11, A10, D1-D4, A9, D1-D4 K1-K2 A8, D1-D4 K1-K2 Modifications to communications circuitry.
Modified
p. 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 considered as part of the delta.
Removed
p. 71
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.