Visa Europe revealed important stats about the usage of Contactless Cards.
Poland, Spain and the UK use this payment methd the most,
with UK usage growing by 300% year over year.
Analysis of PCI DSS v4.0 - Part 3: Requirements 3 & 4
David E. Acosta May 24, 2022
21 minutes read
Continuing with the analysis of PCI DSS version 4.0, in this third part of the series we will analyze requirements 3 and 4, which are part of the "Protect Account Data" group, focused on protecting the confidentiality and integrity of payment card data during its storage and transmission through open and public networks.
As with most of the requirements in PCI DSS 4.0, requirements 3 and 4 were renamed to broaden their scope, as well as to align these controls with the applicability of the standard, as specified in section 2 "PCI DSS Applicability Information": PCI DSS requirements apply to entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of the CDE.
Whereas in PCI DSS version 3.2.1 the group names and requirements 3 and 4 referred only to the protection of Cardholder Data, in version 4.0 this term is extended to include not only Cardholder Data but also Sensitive Authentication Data, in accordance with the definitions of these terms in the standard:
Requirement 3: Protect Stored Account Data
As in previous versions of the PCI DSS, this requirement is focused on the protection of card data during storage.
Although this requirement has always included specific controls aimed at protecting the full magnetic stripe data, the PIN/PIN Block and the Card Verification Code, the name of the requirement (Protect stored cardholder data) in past versions of the PCI DSS standard only mentioned cardholder data, which added a point of inconsistency between the controls contained in this requirement and the name of the requirement itself, as it did not explicitly include Sensitive Authentication Data. In version 4.0 of the PCI DSS, this has been resolved and now the name of the requirement (Protect stored account data) is aligned with the types of data it protects (cardholder data and sensitive authentication data, as part of account data).
Some of the most significant changes in this requirement are:
Clarification of card storage types
In version 4.0, a number of long-overdue clarifications have been added to this requirement. In the first instance, an explicit separation of card data storage types is made, including the restrictions and applicability of controls for each:
Persistent or non-volatilestorage: This type of storage is applied when card data is retained after the completion of its business purpose (e.g., an associated transaction). This type of storage includes intentional or unintentional storage on storage media such as hard disks, backup drives, removable storage media, etc. in the form of event log files, history files, trace files, database contents, memory/crash dump files, etc.
For this type of storage, all the controls of requirement 3 are applicable.
Non-persistent or volatilestorage: This type of temporary storage is used when the card data is processed for its commercial purpose only. This type of storage includes RAM and other types of volatile memory, where the information is lost when the electrical flow is interrupted.
For this type of storage, the data must be removed as soon as its business purpose has been completed. However, additional controls such as data encryption are not required as long as the data is not moved to persistent storage, as specified in FAQ 1042.
Controls for the protection of sensitive authentication data
On the other hand, additional clarifications and controls have been added for the protection of Sensitive Authentication Data stored prior to the completion of the authorization process, including:
Inclusion in the retention and secure deletion policy, to limit the storage of this data to the minimum necessary (req. 3.2.1),
Encryption of this data using strong cryptography, even if the PAN data is not present in the environment (req. 3.3.2 and 3.3.3).
These controls will be effective as of March 31, 2025.
Maskingcontrols and 8-digits BINs
Probably one of the controls that generated the most expectations in this new version of the PCI DSS standard was the control related to the masking of PAN data during its display, given the continuous changes in the payment tag criteria related to the entry into force of the eight (8) digit BIN/IIN. In this regard - and in order not to conflict with the payment brands’ criteria - the standard maintained its neutral position by clarifying that, when the PAN is displayed, only the BIN/IIN (regardless of its length) and the last four digits may be displayed. If the display of additional digits is required, it is necessary to maintain a list of roles with this privilege, as well as their business justification.
This control is aligned with FAQ 1492 of February 2021.
PAN copy/relocation when using remote access technology
In PCI DSS v.3.2.1, control 12.3.10 prohibited the copying, moving and storage of card data on local hard drives and removable storage media when accessing this data via remote access technologies, unless there was an authorized business need. This control has been moved from Requirement 12 to Requirement 3 in PCI DSS v4.0, clarifying that its applicability is to PAN data only.
This control will be effective as of March 31, 2025.
Secure PAN storage
One of the flagship PCI DSS controls is the control identifying the authorized methods for storing PAN data. While these methods have not changed between version 3.2.1 (req. 3.4) and version 4.0 (req. 3.5.1), several clarifications have been added:
If a hash is used, the function must be applied to the entire PAN using strong cryptography (req. 184.108.40.206). Likewise, the use of a simple hash function will no longer be allowed. As of March 31, 2025, keyed cryptographic hashing algorithms such as HMAC, CMAC or GMAC must be used. Obviously, keys used for that purpose must comply with the cryptographic key management requirements (reqs. 3.6 and 3.7).
If truncation is used, a hash cannot be used to replace the truncated portion of the PAN. Additionally, if truncated and hashed versions of the same PAN or different truncation formats of the same PAN exist in the same environment, additional controls must be applied (FAQ 2014).
If encryption is used, key management controls must be considered, and robust cryptography must be used.
If tokenization (index tokens) is used, it is recommended that the criteria described in the PCI SSC's Tokenization Product Security Guidelines and ANSI X9.119-2-2017: Retail Financial Services - Requirements For Protection Of Sensitive Payment Card Data - Part 2: Implementing Post-Authorization Tokenization Systems be used.
Use of disk- or partition-level encryption
Another control that had problems in its interpretation/implementation was the control related to the use of disk- or partition-level encryption. By using this mechanism, data is encrypted during storage but is automatically decrypted once the system is running or after successful authentication of a user, so its effectiveness is valid only while the storage medium is offline, protecting the entity if the media is physically removed in an unauthorized manner.
Although it was well known that the use of this type of encryption is only applicable when the PAN is stored in a removable electronic medium, since this restriction is not explicitly stated in control 3.4.1 of PCI DSS v3.2.1, many entities used this mechanism to protect the PAN when it was stored in databases without any additional control (Transparent Data Encryption - TDE is a good example of this), exposing them to unnecessary risk.
To avoid this ambiguity in the interpretation of the control, in version 4.0 requirement 220.127.116.11 clarifies that the use of disk or partition level encryption can only be applied to removable storage media or, if used on other types of media (including server hard disks, hot-swappable drives, bulk tape-backups, etc.), an additional protection mechanism included in control 3.5.1 (hashing, encryption, truncation or tokenization) must be used.
Improved encryption key management processes
Finally, the cryptographic key management controls (req. 3.6 and 3.7) have been updated to include cryptographic services in the cloud, avoid using the same cryptographic key in production and test environments (req. 18.104.22.168, applicable only for service providers, and as of March 31, 2025), use of approved random number generators within a Secure Cryptographic Device (SCD) or other standards (such as ISO 19592) for key generation of keys or key components (req. 22.214.171.124 and 3.7.6) and additional responsibilities in the event that a service provider shares encryption keys with its customers (req. 3.7.9).
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
In PCI DSS version 4.0, requirement 4 was simplified and several clarifications were added regarding the use of strong cryptography, mainly to avoid issues such as the obsolescence of SSL and the use of early versions of TLS years ago. Many concepts that had already been discussed in the Information Supplement - Best Practices for Securing E-commerce were also incorporated, especially those related to the management of digital certificates.
In this regard, the following were the main changes in this requirement:
Its applicability is limited exclusively to PAN transmission over open public networks, including the Internet, wireless technologies (Wi-Fi) and Bluetooth), mobile communications technologies (cellular), and satellite.
Accordingly, encryption of the PAN during transmission within internal networks is not mandatory, but it is a good practice.
In the event that the PAN is transmitted over open public networks, it can be protected by encrypting this data before it is transmitted, encrypting the session over which the data is transmitted, or both.
Depending on the option implemented, the following must be taken into account:
If data is encrypted prior to transmission, the keys used for encryption are covered by Controls 3.6 and 3.7.
If channel encryption is used, it must be validated that:
If certificates are used, they must be trusted and must not be expired or revoked (this control will take effect as of March 31, 2025).
If self-signed certificates are used, they are valid if they are issued by an internal Certificate Authority, if the author of the certificate is confirmed and if the certificate is verified and has not expired.
The protocols used must support only secure versions.
The strength of the cryptography used must be appropriate to the encryption methodology in use.
A list of the keys and certificates used to protect the PAN during its transmission must be kept (this control will be effective as of March 31, 2025).
In the event that the organization may receive unsolicited payment card data through insecure communication channels, there are two options to protect it:
Include the affected channel within the CDE and protect it according to the controls of the standard, or
Implement measures to prevent this channel from being used for card data transmission.
Other controls, such as transmitting the PAN over wireless networks or using end-user messaging technologies, remain valid as long as robust cryptography is used for this purpose.
The next article in this series will discuss PCI DSS requirements 4 and 5, which address protection against malicious code, security updates, change management, and secure development.
Is this your first time reading the Analysis of PCI DSS v4.0 series? Follow the links below to catch up on the previous articles:
I am the Senior Security Consultant in Advantio. I have more than 15 years of experience, working both in South America and Europe. My information security background includes consultancy and audit, training, implementation of security technologies and design and policy development among others.