During an internal system audit, someone asks, "Is communications traffic encrypted?" and receives the answer, "It is encrypted with TLS." While this exchange used to suffice, over the past one to two years an additional question has emerged: "How many years will that data be stored?"
When these two questions combine, the answer shifts. Intercepting traffic protected by today's encryption won't let attackers read it today, but the premise now accounts for storing intercepted data to decrypt it using future quantum computers. For data retained for over a decade—such as architectural blueprints, legal contracts, HR records, and medical files—encrypting today provides no guarantee against being read in the future.
While this sounds like an issue for large enterprises, its practical impact will arrive handed down as vendor requirements from clients.
"Harvest now, decrypt later" begins being treated as an active threat
The urgency surrounding post-quantum cryptography migration is not because quantum computers will emerge tomorrow. The real problem is the property that intercepted data can be stored and deciphered later.
Standardization initiatives are proceeding on the premise that widely used public-key cryptography can be broken once quantum computers reach sufficient scale. The U.S. National Institute of Standards and Technology (NIST) has released migration guidelines, which are already beginning to surface in procurement requirements, particularly across financial, healthcare, and public sectors.
For Japanese SMBs, tangible impacts will manifest in the following sequence:
- New items appear on client security questionnaires. Questions such as "Do you have a post-quantum cryptography migration plan?" will be added
- It becomes a formal requirement in public and financial projects. Cryptographic algorithms will be explicitly specified in system development scopes
- Migrating based on internal business decisions. This stage comes last
In other words, for most companies, this is not a proactive technology investment, but preparation for questions you cannot afford to leave unanswered. Misunderstanding this positioning will lead you to expand efforts into areas that should not be touched today.
Migration order starts with long-lived data
When people talk about migration, discussions often jump straight to upgrading TLS to newer cipher suites. In reality, the priority is reversed: long-lived data takes precedence over authorization mechanisms.
The reasoning is simple. Today's login sessions expire in a few hours. Even if intercepted today, they hold zero value by the time they can be decrypted a decade later. In contrast, contract files and engineering schematics retain significant value 10 years from now.
| Data type | Lifetime | Migration priority |
|---|---|---|
| Archived documents, engineering blueprints, HR records | 5–30 years | High |
| Service-to-service authentication tokens, API keys | Several months to several years | Medium |
| Login sessions | Several hours | Low |
The middle category—"service-to-service authentication tokens"—is frequently overlooked. Unlike user login sessions, credentials that link systems together can run continuously for years without being rotated. Be sure to examine these when taking inventory.
Implementation is closer at hand than expected
Actual workloads are turning out to be much lighter than the daunting image of "importing specialized libraries, validating them, and rebuilding from scratch."
In Java, for example, starting with JDK 24, lattice-based Key Encapsulation Mechanisms (ML-KEM) and Digital Signature Algorithms (ML-DSA) can be called directly from standard cryptographic APIs without external libraries. This means a substantial portion of the migration effort boils down to "upgrading the JDK."
InfoQ outlines four implementation patterns for Spring Boot, all within scopes that do not fundamentally break existing architectures:
- Encrypting core payload data exchanged between services
- Encrypting specific database columns
- Signing long-term archived documents
- Switching signature algorithms for inter-service tokens
One critical caveat is highlighted here: encrypting columns with new algorithms is not difficult; the challenge lies in architecting the system so keys do not reside in application memory. If encryption keys sit in plaintext inside process memory, upgrading cryptographic schemes offers no additional defense. When migration discussions revolve purely around algorithm names, always confirm where the keys will be stored.
The scope SMBs should address today
There is no need to tackle everything. Right now, only three tasks offer positive return on investment:
First, conduct a cryptography inventory. Build an inventory of where and what encryption schemes are used across internal systems: TLS, database encryption, file storage, and external API authentication. Without this, you cannot draft a migration plan, and you will ultimately need this list anyway to answer client questionnaires.
Second, confirm retention periods. Clarify how many years each data category must be retained. Cross-referencing this against your inventory will automatically establish your priority order.
Third, plan runtime environment upgrades. Whether it is the JDK for Java or runtimes for other languages, ensure systems can be upgraded to versions where new algorithms are supported natively. If runtimes are frozen, you cannot act when migration becomes mandatory. When reviewing business system maintenance costs, incorporating this runtime roadmap is a sensible strategy.
Conversely, switching cryptographic algorithms across all systems immediately is premature for most SMBs. Standards and implementations are still evolving, meaning premature migrations could force rework down the road.
Reaching the point where you can say "we are prepared"
When answering security questionnaires, fulfilling the following levels is practically sufficient:
- Maintaining visibility into cryptographic algorithms used across internal systems
- Understanding retention periods for each class of data
- Establishing migration priorities and rough implementation timelines
At this stage, responding with "we have a plan" rather than "migration is complete" is entirely acceptable. Conversely, writing "under consideration" without an inventory or roadmap will leave you trapped on the next question.
The dynamic is identical to when certificate renewal lifecycles shortened, disrupting operations. Much like server certificate management, organizations with an inventory can respond smoothly, while those without scramble every time.
What to do next
First, create a single-page inventory of the cryptography used in your core systems. It does not need to be exhaustive; writing three lines each detailing "where, what, and for what purpose data is encrypted" is plenty.
Next, check whether you have data retained for longer than 10 years. If you do, that is your initial migration candidate. If not, keeping runtime environment upgrade paths open will suffice for the foreseeable future.
GleamHub offers consultations on custom development, AI, and automation, helping with legacy system cryptography inventories, runtime upgrade planning, and compliance with client security requirements. Because required scopes depend on system architecture and partner demands, please reach out for personalized advice via our contact form.
