What Happened This Week in Quantum-Safe Cryptography, and Why Crypto-Agility Is the Capability That Lasts

‍TLDR: This week in quantum-safe cryptography, artificial intelligence (AI) helped factor RSA-896, a 270-digit Rivest-Shamir-Adleman (RSA) challenge number. Java 27 made hybrid post-quantum key exchange the default in Transport Layer Security (TLS) 1.3. Remaining Federal Information Processing Standards (FIPS) 140-2 certificates moved to the Historical List. The lesson: build crypto-agility.

What is crypto-agility? Crypto-agility is an organization's ability to find, replace, and update cryptographic algorithms, keys, certificates, and protocols quickly and safely, without unnecessary application rewrites or operational disruption. It turns cryptographic change from a disruptive project into a routine, governed, and repeatable process.

The destination may be post-quantum cryptography. The durable capability is the ability to keep moving.

Each of this week's developments tells a different story. The first is a moment in cryptographic history: a well-known RSA challenge number fell with help from AI-assisted engineering. The second is about enterprise deployment: post-quantum protection for TLS connections is now arriving through a mainstream software upgrade that millions of applications already depend on. The third is a long-planned deadline arriving on schedule, as the FIPS 140-2 program formally gives way to FIPS 140-3.

For years, conversations about quantum readiness have started with a single question: when will a cryptographically relevant quantum computer (CRQC) arrive? That question still matters, but it is no longer the most useful one. The more practical question is this: how prepared is the organization for cryptography to keep changing?

This article explains each development in plain terms, separates real signals from hype, and shows why crypto-agility is the capability that will outlast any single migration project.

‍

What Happened This Week in Quantum-Safe Cryptography?

This week brought three developments in quantum-safe cryptography, each driven by a different force. AI changed the economics of an established attack method, a major software platform made post-quantum key exchange a default, and a standards deadline reshaped procurement. All three point in the same direction.

None of these events means that today's strong encryption is suddenly broken. Together, though, they show how quickly the conditions around cryptography are shifting, and why quantum security has become an operational discipline rather than a future research topic. The table below summarizes the week at a glance.

News summary updated September 29, 2026. This section is refreshed as new developments emerge; the guidance that follows is designed to stay relevant as the news changes.

RSA-896 Factored With AI-Assisted Engineering

Researchers reported the factorization of RSA-896, a 270-digit number from the long-running RSA challenge list. The RSA challenge numbers were published as public benchmarks for the difficulty of factoring, which is the mathematical problem that RSA encryption relies on.

The notable part of this result is how it was achieved. AI tools helped adapt CADO-NFS (Crible Algébrique: Distribution, Optimisation), an open-source implementation of the Number Field Sieve (NFS), so it could run on GPUs at large scale. The Number Field Sieve is the best-known classical method for factoring large numbers, and it has been studied for decades. What changed was the effort required to engineer, port, and tune that method for modern hardware.

The RSA-896 result came 16 days after the AI-assisted factorization of RSA-260, which used the same general mathematical approach. Two milestones in quick succession suggest that the pace is being set by engineering speed, not by a breakthrough in mathematics.

Java 27 Brings Hybrid Post-Quantum Key Exchange to TLS 1.3

With Java 27, applications that use Java's standard Secure Sockets Layer (SSL) application programming interfaces (APIs) can gain hybrid post-quantum key exchange in TLS 1.3 by default after upgrading. For many organizations, this means post-quantum protection for data in transit could arrive as part of a normal platform update, without any change to application code.

"Hybrid" means that two key exchange methods run together. A classical algorithm, such as an elliptic curve exchange, is combined with a post-quantum algorithm, and the resulting session key depends on both. The connection stays protected unless both algorithms are broken. This design gives organizations the confidence of long-tested classical cryptography alongside new resistance to quantum attacks.

FIPS 140-2 Certificates Move to the NIST Historical List

The National Institute of Standards and Technology (NIST) has moved remaining FIPS 140-2 certificates to its Historical List. A module on the Historical List is still documented, but it is no longer the reference point for new federal acquisitions. Agencies can continue to use existing modules within their own risk decisions, yet new purchases are expected to rely on modules with current validation.

For organizations that supply cryptographic technology to new federal systems, current FIPS 140-3 validation now matters directly. It affects which products can be proposed, how contracts are written, and how quickly suppliers can respond to requests for proposals.

‍

What Does AI-Assisted Cryptanalysis Change?

AI-assisted cryptanalysis changes the cost and accessibility of established attack methods. It does not change the underlying mathematics that protects well-configured modern encryption.

This distinction matters for security leaders. Historically, running the Number Field Sieve against a large RSA challenge required rare specialist knowledge and months of careful engineering. When AI tools can help adapt that software to widely available GPU hardware, the barrier to entry drops. More teams can attempt large computations, and they can iterate faster.

The practical effect is a shift in risk assumptions. Security margins that were calculated based on how hard an attack was to engineer, rather than how hard it was to compute, deserve a second look. Risk planning should now assume that the effort gap between a published method and a working, optimized attack will keep shrinking.

Why RSA-2048 Is Still Out of Reach, and Why That Isn't the Whole Story

RSA-2048 remains well beyond current demonstrations. RSA-896 is an 896-bit number with 270 digits. RSA-2048 is a 2048-bit number with 617 digits. Because the work required by the Number Field Sieve grows extremely quickly as numbers get larger, the jump from 896 bits to 2048 bits is not a matter of adding more GPUs. It is a gap of many orders of magnitude, and no public result suggests that classical methods are close to closing it.

That is not the whole story, however. Many enterprises still run legacy systems, embedded devices, and older integrations that rely on RSA keys of 1024 bits or shorter. NIST SP 800-131A has long directed organizations away from these key sizes, but real environments rarely match policy on paper. Falling engineering costs make those forgotten keys a more attractive target, and they strengthen the case for finding them now.

How AI Cryptanalysis Relates to the Quantum Threat

Classical AI-assisted factoring and quantum attacks are separate threats. AI-assisted factoring speeds up classical methods on classical hardware. The quantum threat comes from Shor's algorithm, which could break RSA and elliptic curve cryptography (ECC) efficiently if run on a cryptographically relevant quantum computer.

Both pressures, however, converge on the same conclusion: RSA and ECC need a planned retirement path. One pressure erodes the margin on weaker keys today. The other threatens the underlying math of all key sizes in the future.

The Harvest Now, Decrypt Later (HNDL) risk adds urgency. Adversaries can capture encrypted traffic today and store it until decryption becomes possible. Data that must stay confidential for many years, such as health records, financial data, intellectual property, and government information, is already subject to HNDL risk if it travels over connections protected only by classical key exchange.

Is Post-Quantum Cryptography Becoming Part of Routine Infrastructure?

Yes. Post-quantum cryptography (PQC) is increasingly delivered through the upgrade cycles that organizations already run, including language runtimes, operating systems, browsers, and libraries.

This is a significant change in how migration happens. Early PQC planning often assumed that every application would need its own dedicated project. Java 27 shows a different pattern: a mainstream platform ships post-quantum protection as a default, and applications gain it by staying current. For security engineers, the work shifts from building post-quantum support to confirming it, testing it, and closing the gaps that defaults cannot reach.

What Hybrid Post-Quantum TLS Means for Java Applications

For teams running Java workloads, hybrid post-quantum TLS brings several practical considerations:

• Default behavior. Applications that rely on the standard Java Secure Socket Extension (JSSE) and its default configuration can offer a hybrid key exchange group during the TLS 1.3 handshake. Teams that override named groups through system properties such as jdk.tls.namedGroups, or through code, should review those settings so they do not unintentionally disable the new default.

• The algorithm behind it. The post-quantum component is the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), standardized by NIST in FIPS 203. Hybrid groups pair ML-KEM with a classical elliptic curve exchange, following the approach described in Internet Engineering Task Force (IETF) drafts on hybrid key exchange in TLS 1.3 and ML-KEM hybrid groups. Release details are documented by the OpenJDK project.

• Interoperability testing. Both sides of a connection must support the same hybrid group for it to be used. Test against peers, partner endpoints, load balancers, and middleboxes such as TLS inspection proxies, some of which may not yet handle the new groups correctly.

• Handshake size and performance. ML-KEM public keys and ciphertexts are larger than classical elliptic curve values, so the ClientHello message grows. In some networks, this can push the handshake across packet boundaries and expose older devices that mishandle larger messages. Compute overhead is generally modest, but latency-sensitive services should be measured before and after the upgrade.

• Upgrade planning. Moving to a new Java Development Kit (JDK) release involves regression testing, dependency updates, and change management. Treat the post-quantum benefit as a reason to prioritize the upgrade, not as a reason to skip the usual testing.

Why Default Protection Still Requires Visibility

Default upgrades only help systems that are actually upgraded. In most enterprises, a meaningful share of cryptography sits outside the main upgrade path.

Common blind spots include applications pinned to older JDK versions, unmanaged or bundled libraries, embedded and operational technology devices, custom TLS stacks, and third-party services whose cryptography the organization does not control. Without a cryptographic inventory, teams cannot tell which connections gained post-quantum protection after an upgrade and which remain purely classical. Visibility is what turns a helpful default into a verifiable result.

‍

What Does the Move to FIPS 140-3 Mean for Enterprises and Suppliers?

The move to FIPS 140-3 means current validation becomes the baseline for new federal procurement. Organizations that buy or sell cryptographic technology should confirm module status now rather than waiting for a contract to force the issue.

FIPS 140-3 is the current NIST standard for validating cryptographic modules, and the Cryptographic Module Validation Program (CMVP) manages the validation process. For security leaders, the transition is a reminder that compliance dates are not distant events. They become part of today's procurement environment long before the final deadline, because buyers plan purchases years in advance.

How the FIPS 140-2 Historical List Affects Procurement

Buyers should check vendor documentation and module certificates for the validation standard, certificate status, and the specific module version covered. A product that relied on a FIPS 140-2 certificate may still function well, but it may no longer meet the expectations of new federal acquisitions.

Suppliers should review which of their products depend on modules that have moved to the Historical List, track the status of FIPS 140-3 submissions in the CMVP queue, and communicate clear timelines to customers. Procurement teams in regulated industries outside government often follow federal practice, so the effect reaches well beyond federal contracts.

Aligning Validation With Post-Quantum Planning

Module validation, post-quantum migration, and algorithm transition guidance are often handled by different teams. They work better as a single planning view.

Three sources belong in that view. FIPS 140-3 defines how cryptographic modules are validated. The National Security Agency's Commercial National Security Algorithm Suite (CNSA) 2.0 sets timelines for moving National Security Systems to quantum-resistant algorithms. NIST SP 800-131A provides guidance on transitioning away from older algorithms and key lengths. When teams plan together, a module refresh can deliver both current validation and post-quantum readiness, rather than requiring two separate replacement cycles.

‍

Why Is Crypto-Agility the Question That Matters Now?

Crypto-agility matters now because cryptography is changing from several directions at once, and no single migration will be the last one. The organizations best positioned for the future are those that can change cryptography repeatedly, safely, and at speed.

This is the central reframe. The old question was: "When will a cryptographically relevant quantum computer arrive?" Nobody can answer it with precision, and planning around a single date encourages delay. The new question is: "How prepared is the organization for cryptography to keep changing?" That question can be answered, measured, and improved today.

Crypto-agility defined: Crypto-agility is the capability to discover, replace, and govern cryptographic algorithms, keys, and certificates across an enterprise with minimal disruption. It lets organizations respond to new attacks, standards, and requirements through controlled configuration changes instead of costly application rewrites.

The Five Forces Driving Cryptographic Change

Five forces are now pushing cryptography to change at once, and each one moves on its own schedule:

1. Quantum computing. Progress toward a CRQC threatens RSA and ECC, and HNDL makes that threat relevant to data being sent today.

2. AI-assisted cryptanalysis. AI lowers the engineering cost of established attacks and shortens the time between a published method and a working implementation.

3. Standards. NIST standards such as FIPS 203, along with algorithm transition guidance, set new targets and retire old ones on defined schedules.

4. Software platforms. Runtimes, libraries, and browsers now ship post-quantum defaults, changing cryptography across large parts of the estate through ordinary upgrades.

5. Procurement requirements. Validation rules and contract terms, such as the FIPS 140-3 transition, turn cryptographic choices into buying decisions.

The Four Questions Every Organization Should Be Able to Answer

If those five forces explain why cryptography keeps changing, four questions show whether an organization can keep up:

• Where does cryptography live? Across applications, networks, cloud services, devices, Public Key Infrastructure (PKI), and third-party connections.

• What depends on it? Which business services, data flows, and customers would be affected if an algorithm, key, or certificate changed.

• Who owns it? Which team is accountable for each cryptographic asset and has the authority to change it.

• How quickly can it change? Whether an update is a configuration change, a library upgrade, a vendor request, or a full redesign.

Most organizations can answer these for a few well-known systems. Very few can answer them across the whole enterprise, and that gap is where crypto-agility work begins.

Post-Quantum Cryptography Is the Destination; Agility Is the Capability

A one-time migration project is not enough. Treating PQC as a single project assumes that once the new algorithms are deployed, the work is done. History suggests otherwise.

Algorithms, parameters, and validation requirements will continue to evolve after the first PQC rollout. New research may adjust recommended parameter sets. Implementations will receive security fixes. Additional algorithms will be standardized, and older ones will be deprecated. Hybrid configurations used during the transition will eventually need to be simplified. An organization that treats migration as a finish line will face the same scramble next time. An organization that builds agility can treat each change as routine.

‍

How Do You Build Crypto-Agility Into Enterprise Security Operations?

Building crypto-agility into enterprise security operations requires three foundations: continuous discovery, clear dependency mapping with ownership, and cryptographic abstraction that lets algorithms change without major rewrites.

Start With Continuous Cryptographic Discovery and Inventory

A point-in-time audit captures cryptography as it looked on the day of the scan. Within weeks, new deployments, certificate renewals, library updates, and configuration changes make that snapshot incomplete. Continuous discovery keeps the inventory current by monitoring applications, networks, and infrastructure on an ongoing basis.

A Cryptographic Bill of Materials (CBOM) is a structured way to document the output. A CBOM records the algorithms, keys, certificates, protocols, and libraries used by each application or system, across source code, runtime environments, network traffic, and PKI. Just as a software bill of materials describes software components, a CBOM describes cryptographic components, making them searchable, comparable, and ready for policy checks. For a step-by-step method that turns this inventory into a prioritized plan, see our guide to cryptographic discovery and building a risk-based post-quantum migration plan.

Map Dependencies and Assign Ownership

An inventory becomes useful when each cryptographic asset is linked to the business services it supports, the data it protects, how long that data must stay confidential, and the person or team accountable for it.

This mapping allows remediation to be prioritized by risk rather than by technology. A quantum-vulnerable key protecting long-retention customer data on an internet-facing service belongs near the top of the list. The same algorithm protecting short-lived internal test traffic can wait. Clear ownership also prevents the common failure in which everyone agrees a change is needed, but no one has the authority to make it.

Abstract Cryptography So Algorithms Can Change Without Major Rewrites

Cryptographic abstraction separates application logic from specific algorithm choices. Instead of hard-coding an algorithm into every application, teams use shared libraries, services, or providers that expose cryptographic functions through stable interfaces.

Policy-driven algorithm selection builds on this by defining approved algorithms and parameters centrally, so a change in policy flows to every consumer with little or no application code change. Centralized key management adds consistent control over key generation, rotation, storage, and retirement. Together, these practices reduce the time and cost of each future change. The first migration becomes an investment that makes every later migration faster.

‍

How enQase Helps Organizations Keep Moving

enQase gives enterprises continuous visibility into where cryptography lives, what depends on it, who owns it, and how quickly it can change. That visibility is the foundation of crypto-agility and quantum-safe cryptography at enterprise scale.

Continuous Visibility Into Where Cryptography Lives

enQase continuously discovers cryptographic assets across applications, infrastructure, networks, and certificates, then builds a living cryptographic inventory with dependency mapping. Instead of a one-time report, security teams gain an up-to-date view that shows which systems gained post-quantum protection after an upgrade, which still rely on vulnerable RSA and ECC, and where legacy key sizes remain. Learn more about enQase quantum risk and cryptographic discovery.

A Platform Built for Ongoing Quantum-Safe Migration

enQase supports crypto-agility and hybrid migration that evolves with NIST standards. The platform integrates into existing environments without requiring wholesale system replacement, so organizations can move from classical to hybrid to fully post-quantum configurations at a pace that matches their risk and business priorities. As algorithms, parameters, and requirements change, the same platform supports the next move. Explore how enQase approaches post-quantum cryptography, or visit the enQase Future-Ready Quantum Security Platform.

‍

Frequently Asked Questions (FAQ)

1. What happened this week in quantum-safe cryptography?

Three developments stood out. AI-assisted engineering helped factor the 270-digit RSA-896 challenge number. Java 27 made hybrid post-quantum key exchange the default in TLS 1.3 for applications using standard interfaces. Remaining FIPS 140-2 certificates moved to the NIST Historical List. Together, they show cryptography is changing on several fronts at once.

2. Does the RSA-896 factorization mean RSA-2048 is broken?

No. RSA-2048 remains well beyond current demonstrations. The gap between 896 bits and 2048 bits represents many orders of magnitude more work for classical factoring methods. The result matters because AI is lowering the engineering cost of known attacks, which increases pressure on shorter legacy keys and reinforces the need to plan RSA retirement.

3. What is hybrid post-quantum key exchange in TLS 1.3?

Hybrid post-quantum key exchange combines a classical algorithm, such as an elliptic curve exchange, with a post-quantum algorithm, such as ML-KEM, during the TLS 1.3 handshake. The session key depends on both, so the connection stays protected unless both algorithms are broken. It provides quantum resistance while keeping proven classical protection in place.

4. Do I get post-quantum protection automatically by upgrading Java?

Often, but not always. Applications using Java's standard TLS interfaces and default settings can gain hybrid key exchange after upgrading to Java 27. The peer must also support the hybrid group. Custom configurations, older JDK versions, third-party libraries, and middleboxes may prevent it, so a cryptographic inventory is needed to confirm results.

5. What happens to FIPS 140-2 validated products now?

Their certificates now sit on the NIST Historical List. Existing deployments may continue under an agency's own risk decisions, but these modules are no longer the reference point for new federal acquisitions. Buyers should check vendor certificates, and suppliers should plan for FIPS 140-3 validated modules to stay competitive in federal and regulated markets.

6. What is crypto-agility, and why does it matter before quantum computers arrive?

Crypto-agility is the ability to find and replace cryptographic algorithms, keys, and certificates quickly, without unnecessary application rewrites. It matters now because AI, standards, software defaults, and procurement rules are already forcing change, and HNDL puts long-retention data at risk today. Agility prepares organizations for the first PQC migration and every change after it.

7. How does enQase help organizations prepare for ongoing cryptographic change?

enQase provides continuous cryptographic discovery and inventory, dependency mapping, and support for hybrid and post-quantum migration aligned with NIST standards. It integrates into existing environments without wholesale replacement, giving security teams ongoing visibility into where cryptography lives, what depends on it, who owns it, and how quickly it can change.

‍

Keep Moving With enQase

This week's developments came from AI, from a mainstream software platform, and from a standards program reaching a planned milestone. None of them signals imminent collapse. All of them show that cryptography will keep changing, and that readiness is measured by how well an organization can respond.

The destination may be post-quantum cryptography. The durable capability is the ability to keep moving.

Ready to see where your cryptography stands? Book a cryptographic inventory and crypto-agility readiness review with enQase. Our team will help you map where cryptography lives, what depends on it, who owns it, and how quickly it can change, so your organization is prepared for post-quantum cryptography and every change that follows.

‍