Document Diff - PCI Watch

Added p. 2

May 2026 2.3 Updated Related Publications, Detailed Evaluation Process, Firmware Expiry, Updated Approval Classes, Expiry Dates, Functions Provided and Additional Information.

Added p. 6

• Key Management and Operations Security and Test Requirements The Key Management Operations Standard defines security requirements, test requirements, and guidance for entities involved in the operation and management of cryptographic keys and the systems that use them for the security of account data

Added p. 22

• Firmware reassessments are not required if the three-year firmware expiry will occur after the overall device approval expires.

• Firmware reassessments are not required for device approvals that have been designated “End-of-Life” (EOL).

Added p. 47

• Chip Card Transaction Processing Partitioned HSM (v5 only) PIN Processing (v5 only) Processes Operational Keys (v5 only) Remote Administration Remote-managed HSM (v3 and v4 only) Supports ISO Format 4 Restricted Unrestricted HSM Solution (v5 only) HSM Solutions 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:

• Card Production and Personalization

• Cash Card Reloading

Direct Key Loading (v5 only) Processes Operational Keys (v5 only) Remote Administration (v5 only)

Added p. 57

• Direct Key Loading: Functionality allowing for key loading using a directly connected cable.

• HSM Cluster: Functionality that allows a group of physical HSMs to appear as a single device.

• Partitioned HSM: An HSM that can be partitioned and appears to users as multiple separate HSMs.

• PIN Processing: Functionality related to the handling of PINs in transaction processing.

• Processes Operational Keys: Functionality that must be met by all devices that handle cryptographic keys used for payment operations.

• Remote Administration: For v5 HSMs, the functionality related to remote administration applies to HSMs that can be remotely administered, as well as Remote Administration Platforms.

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 (EOL), as delineated in 5.4, “Approval-Listing Fee,” and thus the device is no longer available for purchase except for maintenance purposes. Devices …

Modified p. 1

Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version ~~2.2~~

Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version 2.3

Removed p. 6

• 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.

• PTS PIN Security Requirements Technical FAQs for use with Version 3

Modified p. 6

• 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.

• PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Security Requirements, v5.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

• 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.

• PTS HSM Security Requirements Technical FAQs for use with Version 5 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. 7

• 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.

• PCI PIN Transaction Security (PTS) Hardware Security Module (HSM) Modular Derived Test Requirements, v5.0 Provide specific direction to vendors on methods the Laboratories may apply when testing against the Security Requirements.

Modified p. 18

Modifications, changes, and revisions of PCI SSC-approved devices, termed “deltas,” can occur at any time during the product’s approval. Devices undergoing delta evaluations must take into account the ~~then-current~~ Technical FAQs of the associated major version of Security Requirements•only for the Security Requirement(s) that are impacted by the delta change. For example, if a change impacts compliance with Requirements B1 and B4, only the then-current Technical FAQs associated with B1 and B4 must be considered as part of the delta …

Modifications, changes, and revisions of PCI SSC-approved devices, termed “deltas,” can occur at any time during the product’s approval. Devices undergoing delta evaluations must take into account the then- current Technical FAQs of the associated major version of Security Requirements•only for the Security Requirement(s) that are impacted by the delta change. For example, if a change impacts compliance with Requirements B1 and B4, only the then-current Technical FAQs associated with B1 and B4 must be considered as part of the …

Modified p. 18

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 …

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. Twelve months subsequent to publication of the new major release, the older version of Security Requirements will only be available for delta evaluations.

Removed p. 22

Hardware # A123-xxx-456-xx 4-98765 6.x PED 30 Apr 2032 A123-xxx-789-xx A123--0AB-xx Firmware # 23.01.xxx xx (2022) 23.02.xxx xx (2023)

Modified p. 22

Table 3. Example of Firmware Expiry Evaluation ~~Company Firmware Expiry Date~~ Number Version Approval Approval Expiry Date XYZ Inc.

Table 3. Example of Firmware Expiry Evaluation Number Version Approval Approval Expiry Date XYZ Inc.

Modified p. 26 → 27

All PCI SSC-approved devices for which the approval has not expired shall be billed an approval-listing fee for all such approvals that exist as noted previously. Vendors shall not be billed the annual listing fee for “End-of-Life” (EOL) products for which they have notified PCI SSC in writing at least ninety (90) days prior to the billing date of 1 May. An end-of-life product is a product no longer marketed for new deployments as described in Section ~~A.13,~~ “Additional Information.” …

All PCI SSC-approved devices for which the approval has not expired shall be billed an approval-listing fee for all such approvals that exist as noted previously. Vendors shall not be billed the annual listing fee for “End-of-Life” (EOL) products for which they have notified PCI SSC in writing at least ninety (90) days prior to the billing date of 1 May. An end-of-life product is a product no longer marketed for new deployments as described in Section A.14, “Additional Information.” …

Modified p. 28 → 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 required Physical or Logical Security Requirements.

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.

Modified p. 31 → 32

OEM components approved against prior versions of the requirements can only be used to obtain an overall UPT approval

•without needing additional testing of those components

•if they are no more than one major version away from the previously-approved Security Requirements. For example, EPPs evaluated and approved using PCI POI ~~v5.x~~ can be used without additional testing of requirements they have previously met as part of an overall POI v6 evaluation. However, EPPs that were evaluated and approved using PCI EPP ~~v4.x~~ …

OEM components approved against prior versions of the requirements can only be used to obtain an overall UPT approval

•without needing additional testing of those components

•if they are no more than one major version away from the previously-approved Security Requirements. For example, EPPs evaluated and approved using PCI POI v6.x can be used without additional testing of requirements they have previously met as part of an overall POI v6 evaluation. However, EPPs that were evaluated and approved using PCI EPP v5.x …

Modified p. 33 → 34

Vendors who wish to change the model name of an approved device must also use the PTS Administrative Change Request ~~form.~~ However, if any devices have been sold under the prior model name, both names will be listed. Additionally, a new security policy must be created, and must either reference both the new and old names, or be listed in parallel to the existing policy. Furthermore, images for the device used on the Website must include both the prior and …

Vendors who wish to change the model name of an approved device must also use the PTS Administrative Change Request form and submit it via a PCI-Recognized Laboratory. However, if any devices have been sold under the prior model name, both names will be listed. Additionally, a new security policy must be created, and must either reference both the new and old names, or be listed in parallel to the existing policy. Furthermore, images for the device used on the …

Modified p. 38

PTS Device A POI device or HSM as defined in ~~A.10.~~

PTS Device A POI device or HSM as defined in A.11.

Modified p. 40 → 41

Furthermore, this document introduces a two-tier approval structure for HSMs. These tiers differ only in the “Physical” Security Requirements section as delineated in the PCI PTS HSM Modular Derived Test Requirements. HSMs may be approved as designed for use in ~~controlled environments~~ as defined in ISO 13491-2: Banking

• Secure Cryptographic Devices (retail) or approved for use in any operational environment. These categories are:

Furthermore, this document introduces a two-tier approval structure for HSMs. These tiers differ only in the “Physical” Security Requirements section as delineated in the PCI PTS HSM Modular Derived Test Requirements. HSMs may be approved as designed for use in an environment meeting at least the security requirements of a Controlled Environment as defined in the Key Management and Operations Security and Test Requirements or else approved for use in any operational environment. These categories are:

Modified p. 40 → 41

• Approval is valid only when deployed in Controlled ~~Environments or more robust environments⎯e.g., Secure Environments⎯as~~ defined in ~~ISO 13491-2~~ and in the device’s PCI HSM Security Policy.

• Approval is valid only when deployed in an environment meeting at least the security requirements of a Controlled Environment as defined in the Key Management and Operations Security and Test Requirements and in the device’s PCI HSM Security Policy.

Modified p. 40 → 41

• Approval is valid in any environment.

• Approval is valid in any operational environment.

Modified p. 41 → 42

A.6 Model Name/Number The model name/number cannot contain any variable characters. All devices within a device family that are intended to be marketed under the same approval number must be explicitly named, and pictures of those devices provided in both the evaluation report and for display on the Approved Device List. The vendor cannot use an identical model name for more than one device approved by PCI SSC under a given major version release of the applicable Security Requirements. This …

Modified p. 43 → 44

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 …

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 …

Modified p. 43 → 44

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).

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. 45

• Wi-Fi PQC HSM HSMs may support a variety of payment processing and cardholder authentication applications and processes. The processes relevant to the full set of requirements outlined in this document are:

Modified p. 45 → 46

Table 6. Approval Class Descriptions Class Description Potential Features (see Table 8 in A.14 for details) EPP An Approval Class aimed at secure PIN entry and encryption modules in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device.

Table 6. Approval Class Descriptions Approval Class Description Potential Features (see Table 8 in A.14 for details) EPP An Approval Class aimed at secure PIN entry and encryption modules in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device.

Modified p. 45 → 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 self-service device types …

An EPP is typically used in an unattended PIN-acceptance device for PIN entry and is controlled by a device controller. An EPP has a clearly-defined physical and logical boundary and a tamper-resistant/responsive or tamper-evident shell. At a minimum, a device submitted for EPP approval must contain a PIN-entry keypad along with its built-in secure cryptographic module. Original equipment manufacturers (OEMs) or providers of encrypting PIN pads (EPPs) to unattended PIN-acceptance device manufacturers⎯e.g., ATMs or UPTs⎯and other self-service device types can …

Modified p. 45 → 46

PIN ~~support~~ PIN Encryption Key Management SRED Key Management Prompt Control PIN-Entry technology ICCR MSR CTLS BR Display SRED OP Third-Party Applications Supports ISO Format 4 Interface Isolation

PIN Support PIN Encryption Key Management SRED Key Management Prompt Control PIN-Entry technology ICCR MSR CTLS BR Display SRED OP Third-Party Applications Supports ISO Format 4 Interface Isolation

Modified p. 45 → 47

• Chip Card Transaction Processing Remote Administration ~~Restricted Unrestricted~~ Supports ISO Format 4 ~~Remote-managed HSM~~

• Chip Card Transaction Processing HSM Cluster PIN Processing Processes Operational Keys Remote Administration Supports ISO Format 4 Restricted Unrestricted

Modified p. 46 → 48

• Import of key components into an SCD from a ~~tamper- evident~~ package;

• Import of key components into an SCD from a tamper-evident package;

Modified p. 46 → 48

Multi- Tenant HSMs intended for multi-tenant usage•i.e., multi- organizational usage.

Direct Key Loading (v5 only) Processes Operational Keys (v5 only) Multi- Tenant HSM (v4 only) HSMs intended for multi-tenant usage•i.e., multi- organizational usage.

Modified p. 46 → 48

Remote Administration ~~Restricted Unrestricted~~ Supports ISO Format 4 Remote-managed HSM Non-PED An Approval Class of POI devices that does not allow the entry of a PIN for a payment card transaction. This class is for all POI devices or device combinations, attended or unattended, that do not support PIN-based payment transactions. OEM product types may require further integration into a POI terminal.

Remote Administration Supports ISO Format 4 Remote-managed HSM Restricted Unrestricted Non-PED An Approval Class of POI devices that does not allow the entry of a PIN for a payment card transaction. This class is for all POI devices or device combinations, attended or unattended, that do not support PIN-based payment transactions. OEM product types may require further integration into a POI terminal.

Modified p. 47 → 49

PIN ~~support~~ PIN Encryption Key Management SRED Key Management Prompt control PIN-Entry Technology ~~Display SRED~~ Third-Party Applications Supports ISO Format 4 Interface Isolation

• Bluetooth Interface Isolation

• Wi-Fi RAP This is for platforms that are used for remote administration of HSMs. Such administration includes device configuration and may also include cleartext cryptographic key-loading services as part of the same SCD.

PIN Support PIN Encryption Key Management SRED Key Management Prompt control PIN-Entry Technology Third-Party Applications Supports ISO Format 4 Interface Isolation

• Bluetooth Interface Isolation

• Wi-Fi RAP This is for platforms that are used for remote administration of HSMs. Such administration includes device configuration and may also include cleartext cryptographic key-loading services as part of the same SCD.

Removed p. 49

• Wi-Fi PQC UPT The UPT class of device covers cardholder-operated payment devices that read, capture, and transmit card information in conjunction with an unattended self-service device, including, but not limited to, the following:

Modified p. 49 → 51

PIN ~~support~~ PIN Encryption Key Management SRED Key Management ~~ICCR MSR CTLS BR SRED OP~~ Supports ISO Format 4 Interface Isolation

PIN Support PIN Encryption Key Management SRED Key Management Supports ISO Format 4 Interface Isolation • Bluetooth Interface Isolation

• Wi-Fi

Modified p. 49 → 52

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

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

Removed p. 50

Table 7. Approval Expiry Dates Requirements Version Used During Evaluation at Laboratory Expiration of Requirements Approval Expiration of Device Models Version 7.x of PCI PTS POI Modular Security Requirements

Modified p. 50 → 53

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.

PCI SSC device approvals expire six years past the effective date of a subsequent major (6.0, 7.0, etc.) update of the applicable Security Requirements.

Modified p. 53 → 56

• Acquirer-controlled: The original equipment manufacturer has shipped the POI with mechanisms for controlling the POI display and its use in place. These mechanisms can be employed to unlock the POI for updates to the prompts by the acquirer, using proper cryptographically-controlled processes as defined in the applicable POI security requirement. The reseller or ~~end- user,~~ if authorized by the acquirer, can also make updates using proper cryptographically-controlled processes.

• Acquirer-controlled: The original equipment manufacturer has shipped the POI with mechanisms for controlling the POI display and its use in place. These mechanisms can be employed to unlock the POI for updates to the prompts by the acquirer, using proper cryptographically-controlled processes as defined in the applicable POI security requirement. The reseller or end-user, if authorized by the acquirer, can also make updates using proper cryptographically-controlled processes.

Modified p. 53 → 56

Approved Components (PED, RAP, UPT) “Approved components” contains, when relevant, the list of approved components that are part of the approved device, and which have successfully undergone a distinct evaluation. ~~Each component is listed with its approval number.~~

Approved Components (PED, RAP, UPT) “Approved components” contains, when relevant, the list of approved components that are part of the approved device, and which have successfully undergone a distinct evaluation.

Modified p. 53 → 56

The use of a device with components⎯e.g., EPPs, card readers⎯that are different than those listed as an approved component for that device invalidates that device’s approval. ~~RAP devices may be listed as an approved component of one or more associated HSMs. For v4 and higher HSMs, the HSM must be validated to the “Remote-Managed HSM” requirements.~~

The use of a device with components⎯e.g., EPPs, card readers⎯that are different than those listed as an approved component for that device invalidates that device’s approval.

Modified p. 54 → 57

~~• Remote Administration: The HSM has~~ been evaluated in conjunction with a ~~remote~~ administration solution and assessed against all requirements from the “Remote Administration” column in Appendix B of the HSM Security Requirements. Additionally, for v4 ~~and higher~~ HSMs, the HSM itself meets the ~~“Remote-Managed~~ HSM” Security Requirements as delineated in Appendix B of the HSM Security Requirements.

For v3 and v4, HSMs have been evaluated in conjunction with a remote- administration solution and assessed against all requirements from the “Remote Administration” column in Appendix A of the HSM Security Requirements. Additionally, for v4 HSMs, the HSM itself meets the “Remote- Managed HSM” Security Requirements as delineated in Appendix B of the HSM Security Requirements.

Removed p. 55

• Approval is valid only when deployed in controlled environments or more robust environments⎯e.g., secure environments⎯as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy.

• 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. 55 → 58

• Approval is valid in any environment.

• Approval is valid in any operational environment.

Modified p. 55 → 58

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:

This will also be used for v2, v3, v4 and v5 HSMs to delineate whether they are approved for restricted or unrestricted usage as delineated in the HSM Security Requirements:

Removed p. 56

• Post Quantum Cryptography (PQC):

Modified p. 56 → 59

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 to determine the approved version(s).

• Post Quantum Cryptography (PQC) 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 to determine the approved version(s).

Modified p. 59 → 62

Firmware Change ~~Types~~ Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x v6.x v7.x Any firmware change B3 B3 B3, F1, G1, H1, B20, D2, E2 Changes in tamper management, for example, response, detection, and recovery B1 B1 B1 B1 B1 B1 B1 Error handling⎯i.e., buffer overflows A5, B2 A3, B2 A3, B2 A3, B2 A2, B2 A3, D2 A3, D2 Amendments to external communications protocols B2 B2 B2, F1, G1, H1, B2, F1 B2, F1 D1, D2 …

Firmware Change Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x v6.x v7.x Any firmware change B3 B3 B3, F1, G1, H1, B20, D2, E2 Changes in tamper management, for example, response, detection, and recovery B1 B1 B1 B1 B1 B1 B1 Error handling⎯i.e., buffer overflows A5, B2 A3, B2 A3, B2 A3, B2 A2, B2 A3, D2 A3, D2 Amendments to external communications protocols B2 B2 B2, F1, G1, H1, B2, F1 B2, F1 D1, D2 D1, …

Modified p. 60 → 63

N/A N/A B17-19, A2, A4, A6, A7, A10- A14, B1, B2, B2.1, B2.2, B4-B7, B9, B10, B12, B16, B17, B19, B22- A6, A7, A10-14, B2.1, B2.2, B4- B10, B12, B16, B17, B19, B22- B26, D1 B.3.3 Hardware Changes Changes made by vendors to the hardware of previously PCI SSC-approved PTS Devices are permissible only if the scope of such changes is limited. The following table identifies different types of hardware changes and the PTS requirements that, at a minimum, should …

N/A N/A B17-19, A2, A4, A6, A7, A10- A14, B1, B2, B2.1, B2.2, B4-B7, B9, B10, B12, B16, B17, B19, B22- A6, A7, A10-14, B2.1, B2.2, B4- B10, B12, B16, B17, B19, B22- B26, D1

Modified p. 60 → 64

The inclusion of more than four (4) of the identified hardware change-types as delineated in the table below in a single delta submission for a previously PCI SSC-approved PTS POI Device may effectively represent a new device that should be subjected to its own full evaluation against the latest version of the current PTS Standard. Candidates for delta submissions that surpass this threshold, which, in the opinion of the PTS Lab, represent a minor change to the approved PTS POI …

Modified p. 61 → 64

Notwithstanding the aforementioned, device modification submissions where changes are sufficient to require a full evaluation and new approval number will receive a new listing. These devices may additionally be listed under the approval number of the existing previously approved (unmodified) device if:

Notwithstanding the aforementioned, device modification submissions where changes are sufficient to require a full evaluation and new approval number will receive a new listing. These devices may additionally be listed under the approval number of the existing previously approved (unmodified) device as a Delta Refresh, if:

Modified p. 63 → 66

Hardware Change Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x v6.x v7.x Any hardware change2 A1, A2, A1, A7 A1, A7 A1, A6, B2, B20 A1, A5, B2, B20 A1, A2, A6, A7, B20, D2 A1, A2, A6, A7, B20, D2 Changes in casing plastics⎯e.g., ~~cover- opening~~ dimensions, areas that permit internal access⎯or ~~output-only~~ displays. Amended devices must remain consistent with the device’s original form factor and visible characteristics.3 A4, A7, A9−A11, A2, A6, A8−A11, A2, A6, …

Hardware Change Impacted Requirements PTS POI Standard Version v1.x v2.x v3.x v4.x v5.x v6.x v7.x Any hardware change2 A1, A2, A1, A7 A1, A7 A1, A6, B2, B20 A1, A5, B2, B20 A1, A2, A6, A7, B20, D2 A1, A2, A6, A7, B20, D2 Changes in casing plastics⎯e.g., cover-opening dimensions, areas that permit internal access⎯or output- only displays. Amended devices must remain consistent with the device’s original form factor and visible characteristics.3 A4, A7, A9−A11, A2, A6, A8−A11, A2, A6, …

Modified p. 63 → 66

A5, D1 A2, A3, A11, D1 A2, A3, A10, D1 2 This item is not to be included in the count of changes when determining whether the number of changes in a single delta submission is within the acceptable range of four (4). Any hardware change requires a change in hardware version number done in accordance with Appendix A.

A5, D1 A2, A3, A11, D1 A2, A3, A10, D1 Modifications or replacement of any processor used by the device.4 A5, A6, A7, A9, B1-B10, A3, A4, A6, A8, B1-B15, A3, A4, A6, A8, A11, B1-B19, A3, A4, A5, A7, A10, B2−B19, A2, A3, A4, A6, A9, B2−B19, A3, A4 - A7, B2 - B19, B21, C1, 2 This item is not to be included in the count of changes when determining whether the number of changes in a single …

Modified p. 64 → 67

A2, A6, A8, A9, A11, D1 A2, A6, A8-A10, B16, D1 A5, A7- A9, A11, A4, ~~A6- A8, A10,~~ A10, A13, B5, A10, A13, B5, Replacement or addition of any one reader.5 D1-D4 A10, A11, ~~D1-~~ A10, D1-D4, ~~A9,~~ D1-D4 K1-K2 Modifications to communications circuitry.

A2, A6, A8, A9, A11, D1 A2, A6, A8-A10, B16, D1 A5, A7- A9, A11, A4, A6-A8, A10, A13, B5, A10, A13, B5, Replacement or addition of any one reader.5 D1-D4 A10, A11, D1-D4 A10, D1-D4, A8, D1-D4 K1-K2 Modifications to communications circuitry.

Modified p. 64 → 67

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- D14, E1, A3, A5, A7, A8, A10, A13, B5, B15, B21, D12- D14, E1, 4 Each ~~processor modification or replacement~~ counts as a separate hardware ~~change⎯e.g.,~~ if both the ~~secure processor~~ and ~~application processor~~ are ~~modified, it would count~~ as two …

A5-A7, A9, B2, B8, D1, A3, A4, A6, A8, A11, B2, B7, A3, A4, A6, A8, A10, B2, B7, B16, A2-A5, A7, A9, B7, B16, A2-A4, A6, A8, B7, B16, D1, D4, F1, K3, L1, L3 A3, A5, A7, A8, A10, A13, B5, B15, B21, D12- D14, E1, A3, A5, A7, A8, A10, A13, B5, B15, B21, D12- D14, E1, Modifications to major components (other than communications or power) of the PCB circuitry⎯e.g., audio circuitry, heater circuitry, printer, display etc.,⎯as …

Modified p. 65 → 68

• Explanation of how and why PTS Security Requirements are impacted; ~~6 This excludes rerouting of circuits.~~

• Explanation of how and why PTS Security Requirements are impacted;

Modified p. 72 → 75

PTS Approval Approval Expiry Date Model Name Firmware Firmware submission status for the 12 months ending December 31 of the prior

PTS Approval Approval Expiry Date Model Name Firmware Firmware submission status for the 12 months ending December 31 of the prior year

Modified p. 74 → 77

PTS Approval Number Model Name Type A or B Application Version (if applicable)

PTS Approval Number Model Name Type A or B Hardware Application Version (if applicable)

Document Comparison

Content Changes