October 26, 2026, 8:00 a.m. (JST)
[Japan] Advances in PQC (post-quantum cryptography), AI, cloud adoption, and API integration are significantly changing the fundamentals of data protection in the payments sector. Moving forward, security will require not only tracking the location of confidential data but also effectively managing the encryption, keys, API keys, and secrets used to protect that data.Thales DIS Japan, which participates in PCI SSC activities and is engaged in both the practical implementation and standardization of payment data protection, will explain—based on the Data Security Posture Management (DSPM) framework—the need for data protection, a cryptographic inventory with an eye toward PQC, key sovereignty, and an integrated data security infrastructure.(From a presentation at the “Payment Security Forum 2026 Fall” held on September 25, 2026)
Thales DIS Japan Co., Ltd. Cybersecurity & Digital Identity
Cybersecurity Product Business Division, First Sales Department: Mr. Takeshi Sato, Cyras
Where Is the Data, and What Protects It
? Controls, Change Management, and Verification Are Critical
I have given this presentation a somewhat provocative title: “PCI DSS 4.1? 5.0?” What I would like to discuss is what kind of data protection and key controls will become important in the future when we overlay the direction of data protection that PCI DSS has indicated thus far with the changes currently occurring in the external environment.
Thales is a French technology company with the French government as a major shareholder, operating in more than 100 countries worldwide. More than 35,000 companies globally and over 3,000 financial institutions use our solutions.
We hold a solid position in the financial markets and serve as the backbone supporting transactions behind the scenes. For example, we protect 80% of all global POS transactions, and our company embodies the pinnacle of various technologies. Additionally, within the PCI SSC, Thales participates as a member of the Board of Advisors and as a Principal Participating Organization.Thales offers hardware security modules (HSMs)—dedicated devices for the secure storage and use of cryptographic keys—as products that form the core of payment infrastructure, and holds a significant market share. Many customers in Japan also use our products, and some of you may be familiar with “payShield.”
Thales participates in the activities of the PCI SSC and is involved in discussions regarding both the practical aspects of payment data protection and the standards themselves. While this presentation does not serve as a preview of future PCI DSS requirements, we will examine the key issues companies should prepare for based on the direction of the standards to date and changes in the market.
I would like to pose questions from three perspectives: “Where is the data located?”, “What is protecting it?”, and “Is it properly controlled and managed for changes, and can this be proven?” This is not merely a technical discussion. It is also a question of whether companies can fulfill their accountability regarding data protection.
Multiple Key Management Systems and Data Protection Tools
How Should Japanese Companies Implement Cross-Functional Controls?
As I explained at the previous Payment Security Forum, an interesting incident occurred. It was reported that Microsoft provided the FBI with BitLocker recovery keys stored in the cloud, based on a valid warrant. The key point here is that the encryption algorithm itself was not cracked.Even if data is encrypted, if a recovery key can be obtained, anyone—whether an authorized user or an attacker—may be able to access the data. In other words, it is not simply a matter of “whether the data is encrypted.” It is crucial to consider “who holds the key,” “where it is stored,” and “who has access to it.”
The questions we want to raise here are: “Are the data and the keys managed by the same entity?” “Is the system designed so that cloud service providers or third-party contractors can decrypt the data?” and “Do you know who has access to recovery keys and other critical keys?”
Here are three key figures: 41% of Japanese companies have five or more external key management systems, and 73% use five or more data protection tools, including encryption.
On the other hand, 57% of Japanese companies cite HNDL (Harvest Now, Decrypt Later) attacks as their greatest concern. We publish an annual threat report, and our latest 2026 edition is based on an analysis of responses from 201 Japanese companies.
HNDL is a simple attack strategy that involves “stealing encrypted data now and decrypting it later.” In other words, just because a third party—such as an attacker—cannot decrypt the data at this moment does not guarantee its long-term security.
In our view, there is nothing inherently wrong with using multiple key management systems or data protection tools. We believe it is perfectly natural to utilize different mechanisms depending on the specific use case—whether it involves the cloud, different regions, business units, or regulatory requirements. What is important is whether companies have “established common policies across the organization” and “designated a clear person in charge of overall oversight.”“Can we visualize what is being used and where?”, “Can we centrally assess the status of key management and data protection?”, and “Can we identify exceptions, duplications, and management oversights?” The ability to exercise cross-functional control over these multiple mechanisms is a critical challenge in ensuring long-term security.
It’s not
enough to simply “have encryption in place.” The responsibility to demonstrate that it “is effective against threats”
A look at the actual PCI DSS requirements reveals that the importance of “effective controls”—which involve not only implementing encryption but also operating and managing it appropriately—is growing.
To give a very general example, in traditional audits, I believe the main points of evaluation by QSAs (Qualified Security Assessors) were whether “confidential data is properly encrypted” and whether “strong cryptographic algorithms are used.”
In contrast, QSAs now ask about matters such as: “Are keys properly segregated between production and test environments?”; “Who has access to the master key, and how are those permissions segregated and distributed?”; and “Can you prove that third parties—such as outsourced vendors or cloud service providers—cannot decrypt the data?”
A prime example of this is the approach to disk encryption. In short, it’s no longer enough to simply say, “We’ve implemented encryption. That’s it.”In the current PCI landscape, both the market and regulators now demand not only the fact that encryption is implemented but also the ability to demonstrate—in other words, to fulfill “accountability”—that these measures are actually effective against anticipated threats.
Under PCI DSS, it is becoming increasingly important not only to implement encryption but also to demonstrate that data is effectively protected—including through key access management and segregation of duties. The question is not merely “Is encryption in place?” but “Is that encryption actually effective?”We believe that demonstrating this effectiveness will continue to be strongly demanded as we consider the future of PCI DSS.
With
an eye toward the commercialization of quantum computers, Prepare for systematic procurement and migration without waiting for “Q-Day”
The next question is whether the cryptographic technologies currently in use can maintain sufficient security for the duration required to protect the data. In other words, it is a matter of how to ensure security over the medium to long term. Furthermore, it is also important to determine whether a smooth transition to new cryptographic methods is possible if vulnerabilities are discovered in the algorithms currently in use.“Crypto-agility”—the ability to adapt flexibly to such changes in cryptographic technology—is essential. In fact, changing cryptographic schemes may require extensive adjustments, including protocols, libraries, and hardware such as HSMs. A prime example of the need to confront these challenges head-on is the transition to PQC (post-quantum cryptography).
Here are a few examples of external developments regarding PQC. In June 2026, the U.S. federal government announced a policy to transition high-value assets and high-impact systems to PQC by the end of 2030 for key establishment and by the end of 2031 for digital signatures.
In Singapore, the Cyber Security Agency of Singapore (CSA) has published the “Quantum-Safe Migration Handbook.” This handbook outlines specific approaches for ensuring quantum security, including the assessment of quantum risks, the identification of cryptographic assets, the assurance of crypto-agility, and a phased transition to PQC.For C2 owners (critical infrastructure), milestones have been set: submission of migration plans by March 27, six months from now; implementation of quantum-safe measures or preparations for such measures in new procurements starting in 28; and full migration by the end of 31.
What is particularly important is not accurately predicting “when quantum computers will become operational,” but rather proceeding with preparations now so that the transition can be completed by that time.While the year 2035 is cited as a general benchmark for the market as a whole, the precise prediction of “D-Day”—the day a quantum computer capable of breaking current public-key cryptography emerges—is not the critical issue in itself. The real question is whether deadlines have been set and whether planning, procurement, and migration have begun by working backward from those deadlines.PQC is no longer merely a future technology trend; it has become a challenge that requires preparation starting now, taking into account the time needed for the transition. In fact, since the transition to PQC may take several years, it is recommended to begin identifying and prioritizing quantum-vulnerable cryptographic systems now.
There is another important point to consider. When companies procure or upgrade systems and servers, it is not uncommon for the planning process itself to span several years. Similarly, when transitioning to PQC, it is necessary to proceed in stages: first, assess the current cryptographic environment and identify critical systems; then, verify vendors’ implementation plans, evaluate products, and conduct proof-of-concept (PoC) tests.Therefore, for systems that will be used over the long term—such as over the next 5, 7, or 10 years—we believe it is necessary to verify at this stage whether they will be capable of supporting PQC in the future, or at the very least, whether they are designed to allow for the updating of cryptographic algorithms as needed.
Identifying and Prioritizing
Targets for PQC Compliance Confirm Vendor Roadmaps Early
During the PCI SSC session, it was indicated that the target for the PCI revision is the second quarter of 2028. We believe that if we wait to begin PQC preparations until the specific details are revealed, we may not be able to meet the deadlines for the next system procurement or renewal.
Of course, this does not mean migrating everything to PQC immediately. What we should start doing now is identifying the affected systems and cryptographic assets, prioritizing them based on risk, and reviewing vendors’ implementation roadmaps. The transition to PQC is likely to be a long-term process; some estimates suggest that large financial institutions may require up to about 10 years to complete the transition.
The figure below illustrates a general example of the process for transitioning to PQC. It is not necessary to replace all cryptographic methods from the outset. The first priority is to identify what cryptographic technologies are currently in use and where they are being used.Conduct an inventory of the cryptographic assets currently in use—such as keys, certificates, cryptographic algorithms, cryptographic libraries, and communication protocols—to clarify which assets are subject to migration and establish priorities.
Next, determine what each cryptographic asset is protecting.For example, the migration priority will vary depending on whether the data being protected loses its value quickly or needs to remain confidential for 10 or 20 years. Additionally, identify which systems, APIs, certificates, products, and external services use those cryptographic assets, and assess the time required for changes and the scope of their impact.
To do this, it is important to conduct an inventory from two perspectives: “cryptographic assets” and “data.” Regarding data, we identify where specific data is located, what type of data it is, how critical it is, and how long it needs to be protected.Regarding cryptographic assets, we identify where specific elements—such as keys, certificates, cryptographic algorithms, and APIs—are being used. By correlating these two sets of information and clarifying “which data needs to be protected, with which cryptographic methods or keys, and until when,” we determine the migration priorities.
■Contact
Information 
Thales DIS Japan Co.
, Ltd. Cybersecurity
Products Division URL: https://cpl.thalesgroup.com/ja
Email: cpl.jpsales@thalesgroup.com
