Reading view

The quantum deadline is unclear. The need to prepare isn’t.

9 September 2026 at 12:07

For the past decade, quantum computing has been relegated to the horizon, a distant, theoretical challenge rather than an immediate operational imperative.

Breakthroughs have generated headlines, but without a firm deadline for when quantum computers could threaten today’s cryptographic standards, CISOs have had little incentive to make quantum readiness an immediate priority. IBM’s 2025 Quantum-Safe Readiness Index shows how much work remains, with the average organization scoring just 25 out of 100.

Yet, that window of preparation is contracting rapidly. This spring, Google warned that “quantum frontiers may be closer than they appear,” pointing to advances in hardware, error correction, and algorithms that are accelerating progress toward cryptographically-relevant quantum computers. Google has since set a 2029 target for completing its own migration to post-quantum cryptography (PQC).

Yet, that growing urgency still comes without a firm deadline. Unlike the fixed, binary deadline of Y2K from years ago, the quantum risk profile is nebulous; the exact threshold of peril remains undefined, even as the required remediation timeline spans several years.

Large enterprises need time to identify cryptographic dependencies, assess legacy infrastructure, coordinate vendors, and secure the budgets required for migration. Those decisions reach well beyond cryptography, affecting how the business plans, funds, and prioritizes risk. In fact, the availability of quantum computing capabilities will touch almost every aspect of companies around the globe.

Turn quantum risk into an enterprise-wide priority

Quantum readiness already has a prescribed technical solution. In 2024, NIST finalized its first set of PQC standards and encouraged organizations to begin transitioning as soon as possible. For some systems, migration may just involve a software update or configuration change. For others it may be much more complex. The challenge for a large enterprise is knowing where those changes need to happen.

A practical first step is to build a cryptographic bill of materials (QBOM), cataloging what cryptography is in use and where, which systems can be updated relatively easily, and where legacy infrastructure may require replacement or another mitigation strategy. This is an intensive effort, but there are software platforms that can help.

Next, organizations should prioritize systems based on the value of the data and how long it needs to remain protected. Financial records or customers’ customer personally identifiable information (PII), for example, may warrant greater urgency than an internal chat log with little long-term value.

Data longevity is especially important because adversaries are already collecting encrypted traffic in the expectation that future quantum computers will be able to read it, a practice known as "harvest now, decrypt later." For sensitive data, the attack may already have happened even though the business impact hasn't.

Data exposure is only one part of that assessment. Public key cryptography (PKC) also underpins authentication, including single sign-on and other mechanisms used to establish identity. If that cryptographic foundation can no longer be trusted, organizations face the risk of impersonation, with consequences for access to applications, infrastructure, and data.

Much of this work sits outside the CISO's direct control. Infrastructure, applications, data, and third-party relationships are often jointly owned across the business, and so are many of the budgets needed to address them. CISOs must make a business risk pitch that shows other leaders – the CIO, CTO, procurement, compliance, and executives – where the greatest risks are and what needs attention first.

Make crypto-agility part of the migration

Preparing for a post-quantum future also requires crypto-agility. Cryptographic standards will continue to evolve as new vulnerabilities emerge and algorithms change. Organizations need systems and platforms that can accommodate those changes without another costly, multi-year migration. That means buying and building in ways that can accommodate a future algorithm change through software rather than hardware rip-and-replace.

The UK's National Cyber Security Centre recommends building that flexibility into PQC migration plans and establishing criteria for retiring traditional algorithms, with the goal of removing sole dependence on traditional public-key cryptography. It also means rethinking how organizations budget for the transition.

Large enterprises often operate on annual budgets approved well in advance and adjusted only slightly throughout the year, but a post-quantum transition may require more flexibility as standards and threats evolve.

This principle should also influence procurement. SOC 2 compliance already requires organizations to scrutinize vendors' privacy policies, certifications, and access controls, but cryptographic dependencies can be another blind spot. Asking which standards a vendor supports, how cryptography can be updated, and what its PQC roadmap looks like can reduce the risk of buying infrastructure that becomes difficult or expensive to migrate later.

The quantum timeline starts with today’s budget

While a firm deadline for quantum readiness remains elusive, budget cycles offer a more disciplined, actionable framework for planning. Executing a multi-year migration requires sustained financial commitment over successive cycles; every passing budget period effectively compresses the available window for remediation.

Most CISOs already understand quantum risk. The challenge is moving quantum readiness from something planned for next quarter or next year into funded work. With only a limited number of budget cycles available for a multi-year migration, repeated delays quickly add up.

The priority is to turn that awareness into an inventory, clear business priorities, and a phased migration plan that can be funded over the coming budget cycles. By starting now, organizations have time to focus on the highest-risk systems and address legacy infrastructure before the timeline becomes critical.

We've featured the best web hosting services.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit

Optical vortices provide a natural way to create topologies

Physics World

By: Paul Mabey

9 September 2026 at 10:26

Structured light is light with a designed spatial pattern. It can be shaped into standard topological structures, such as a twist in its phase or a changing polarisation across the beam. These patterns are useful because they can encode information, probe small distances and create topological field structures.

However, the issue is that is that these carefully engineered patterns often spread or degrade as the beam travels. This is a problem for real-world applications, such as precision metrology and super-resolution sensing.

In a new work, a team of researchers from Singapore and Spain went down a different route. They identified a spin structure which is both a topological texture and topological defect that is not laboriously engineered but appears automatically at the dark core of an optical vortex because Maxwell’s equations require it.

An optical vortex is a dark core in a light beam where the electric field vanishes. Because the field is zero there, the phase cannot be defined. The researchers found that the light around this core has a tiny, ordered spin pattern.

The called this a meronic spin defect. A meron is a texture that covers half of a sphere of possible spin directions, while a defect is a point where the direction becomes undefined. Here, both features occur together: the spin vanishes at the centre but forms a half-sphere-like pattern around it.

Crucially, these defects do not spread out during propagation. The beam might diffract as usual, but the normalised spin and polarisation patterns remain confined on subwavelength scales. They are also more stable against turbulence than standard engineered structures, because they arise intrinsically from Maxwell’s equations rather than from carefully balanced beam components.

Although still a fundamental result, the finding suggests that vortex cores could provide unusually stable and compact building blocks for future structured-light technologies.

Read the full article

Non-spreading meronic spin defects around optical vortices – IOPscience

N. Mata-Cervera et al 2026 Rep. Prog. Phys. 89 077901

The post Optical vortices provide a natural way to create topologies appeared first on Physics World.

Rust 1.98.1 fixes miscompilation bug

InfoWorld

3 September 2026 at 23:49

Hot on the heels of the Rust 1.98.0 release, the Rust team has published Rust 1.98.1, an update that fixes a miscompilation in vtable generation.

Rust 1.98.1 was announced September 3.

A Rust issue opened August 21 (and now closed) noted that Rust 1.98 emits a zero method entry in a compiler-generated vtable, resulting in a segmentation fault and a crash. According to the Rust 1.98.1 release notes:

In Rust 1.98.0, in some circumstances, rustc would incorrectly generate a trait object vtable with a null pointer where a function pointer should be. This leads to undefined behavior in the emitted code. In some cases this may “just” cause segfaults due to the null pointer being loaded, but it is possible for it to be justification for arbitrary effects.

This bug is fixed in Rust 1.98.1. The Rust 1.98.0 release brought algebraic methods for addition, subtraction, multiplication, division, and remainder to floating-point types, allowing optimizations on these operations using algebraic properties of real number.

Users of a previous version of Rust installed via rustup can install Rust 1.98.1 by running the command rustup update stable. The Rust team asks developers who would like to help test future releases to consider using the beta (rustup default beta) and nightly (rustup default nightly) channels and to please report any bugs.

How to keep your mission-critical cloud workloads running

InfoWorld

3 September 2026 at 10:00

Entrusting mission-critical workloads in the cloud puts a lot of pressure on IT operations to build resilience into data infrastructure they don’t even own — to make sure that when an incident happens elsewhere, the lights stay on at home. Fortunately, savvy CIOs are learning they can architect their systems for resilience and high availability to keep mission-critical cloud workloads running when disaster strikes.

When designing for resilient, highly available cloud workloads it is critical to understand the details of your cloud provider’s service level agreement (SLA) and recognize that providers operate on a shared responsibility model. That means there are many things the provider is responsible for, but the workloads you’ve got running on their infrastructure are not among them. With that in mind, we’ll need to focus on three core goals essential to building and maintaining highly available, resilient cloud workloads:

Identify and eliminate single points of failure
Close or mitigate conditions leading to recovery gaps, and
Overcome operational complexity.

Remember, everything fails

Designing for application-level resilience and high availability is predicated on recognizing that everything fails. That’s not pessimism, but realism, and embracing this fact gives you a leg up in architecting resilient IT. Hardware breaks down, disasters occur, mistakes are made, software incompatibilities are common, and limits are exceeded that result in loss of service. There are four categories of failure that need to be taken into consideration when designing for resilience and high availability:

Single point of failure: As the term suggests, this describes a non-redundant device, route, or point of connectivity that results in zero fault tolerance in the event of an incident involving that choke point.
Excessive load: Exceeding the throughput or memory limits of a device or service can result in latency, service degradation, or failure affecting service level agreements (SLA) and service level objectives (SLO).
Misconfigurations and bugs: Perhaps the most common source of failure, these breakdowns often occur during installation, maintenance, and patching leading to the incorrect execution of code.
Shared fate: This type of failure is like non-redundant connectivity. When you rely on third-party services and there is an incident beyond your control affecting a partner, it can result in downtime or service degradation.

Having identified the primary challenges to maintaining service uptime and continuity, let’s explore an approach to achieving resilience through high availability, disaster recovery, and the process of continuous improvement.

Working toward continuous improvement

High availability is often thought of as measured by “X Nines,” representing the percentage of time a service is operational over the course of a specified time frame, usually a year. Six nines of availability, for example, means that a service can be expected to run 99.9999% of the time, or 8759.99 hours out of 8760 in a year. That sounds good until a disaster happens. Then we shift to disaster recovery, or the ability to restore a service and its associated data quickly and correctly when things go wrong. Disaster recovery is often measured and evaluated by a recovery point objective (RPO), which is the maximum acceptable amount of data loss, and a recovery time objective (RTO), which is the maximum acceptable amount of time a service can be down.

By learning from our mistakes, incidents, and the ongoing process of testing, observing, and evaluating IT operations, we apply new information in the goal of continuous improvement to get peak performance out of our investments in IT. But because we’re addressing resilience and high availability in the context of workloads operating in the cloud, we should understand the shared responsibility model that most cloud service providers use. Details may differ from provider to provider, but the shared responsibility model of cloud services is your vendor’s statement of responsibility for maintaining its infrastructure and ability to deliver storage and compute capacity in a region and availability zone where you have a need. In return, you accept responsibility for the configuration, maintenance, availability and operation of the workloads you choose to run on your vendor’s cloud.

SIOS Technology

A cloud service provider will typically operate and maintain physical infrastructure in different areas around the world, with multiple availability zones in each area. Each availability zone will have one or more data centers with its own power, cooling, and other operational support. Data centers are typically located far enough from each other to minimize the chance that a natural or regional disaster will affect multiple data centers, but close enough that they can operate as a single, logical data center — thereby maximizing bandwidth and throughput, while minimizing latency. This is redundancy at scale that eliminates a single point of data center failure.

Designing for application high availability and disaster recovery

To build out or retrofit your infrastructure for application-level resilience and high availability, there are four things you must have: clustering, data replication, failover, and disaster recovery. Let’s look at each and how to architect for them.

Clustering

Clustering is the practice of connecting like and complementary systems to improve availability and reliability. Think of it as putting into practice the maxim “the whole is greater than the sum of its parts.” Traditionally, clustering was achieved using hardware, specifically storage area networks (SAN), to connect and support systems in a physical data center. However, in the cloud age, hardware-based clustering has proven to be expensive and inflexible. Software-based SANless clustering with products such as SIOS LifeKeeper delivers all the benefits of the traditional approach while also working better in cloud and hybrid environments.

SIOS Technology

SANless clusters enable the configuration of nodes based on the organization’s operational priorities and work easily for enterprises running geographically distributed data centers or cloud availability zones. Because SIOS LifeKeeper supports single-site, multi-site, cloud, or mixed environments, and affords real-time access to operational data during incidents requiring failover, it is ideal when mission-critical workloads are distributed across multiple providers. LifeKeeper clusters create redundancy and eliminate single points of failure, both of which are necessary for achieving high availability. For enterprises operating hybrid or multi-cloud infrastructure, this enables you to shift to secondary resources should your primary service experience an outage.

Data replication

IT operations and your mission-critical applications rely on data, so it’s vital to keep data in sync between nodes in real time, whether synchronously or asynchronously, depending on the application. When working to achieve high availability, it’s important to monitor the health of infrastructure elements and the applications you’re running. This ensures that downtime affecting the application and any downstream dependencies is detected so that failover and recovery to a standby node can occur automatically. When everything is in sync and data replication is happening, this ensures complete readiness; there’s no need to rebuild a database or for any manual operations. And with SANless clusters using SIOS DataKeeper, this will happen across availability zones, regions, and to or from on-premises, cloud, or multi-cloud resources in hybrid environments.

SIOS Technology

What’s important here is that the software you use for SANless clustering be application aware. That’s SIOS LifeKeeper. Because high availability and resilience mean not just failing over to standby infrastructure resources, but for properly failing over mission-critical workloads (think SQL Server, SAP, Postgres, or industry-specific applications like Meditech), the software needs to understand how those applications work so that they can recover and restart cleanly. Otherwise, when failover occurs, there’s a good chance that workload is not going to be available, or it could be out of sync. When your software is application-aware, failover and recovery is fast and predictable with no API dependencies or last-minute provisioning.

Failover

With SIOS SANless application-aware clustering and replication in place, you can automate real-time failover and achieve the goal of high availability and resilience. Because we’ve chosen a software-based approach, failover occurs in the data plane, so there’s no need to spin up a new instance following an incident. Everything is already running, in sync, and ready. Furthermore, failover is immediate and it’s predictable. That is what you need when dealing with mission-critical workloads. Consider that many of the mission-critical applications you use were not designed to operate in the cloud, so even if your infrastructure is resilient, the application itself represents a single point of failure. Without replication, application monitoring, and real-time failover automation, you risk loss of revenue, security degradation, or worse.

SIOS Technology

Depending on the size of your enterprise and the industry in which it operates, an hour of downtime can cost $1 million or more, and 90% of organizations report costs of at least $300,000 per hour. Beyond that simple loss of revenue are soft costs associated with reputation damage, lost productivity, missed transactions, and more. Revenue protection is only part of the equation; it is about protecting the business.

Disaster recovery

Any design for high availability and resilience must also take into consideration the risk of a non-IT disaster that disrupts operations. Natural disasters like fires, earthquakes, and floods, or disasters caused by humans like the accidental severing of a trunkline or an act of sabotage conspire to bring operations to a sudden halt. Clustering, replication, and failover all play into disaster recovery, but there are additional considerations that must be addressed. For disaster recovery (DR), you’re going to want geographic distance between your primary site and your DR site to minimize the risk that a regional event doesn’t affect both. That means you’re going to want asynchronous (or near real-time) data replication.

SIOS Technology

Asynchronous replication is typically only a second or less behind synchronous replication, so it is de facto real-time, but that delay allows you to replicate across higher-latency networks and across longer distances. And because replication is happening continuously, even if you have a local failover between node one and node two, replication to the DR node doesn’t stop. Instead, when node two comes online it becomes the source of the mirror replicating to the DR site and back to node one once it is restored.

Patching and planned maintenance

Beyond the simplicity and cost advantages that come from taking a software-based approach to designing your cloud and hybrid infrastructure for high availability there is another big benefit. You are also better prepared to respond to the increased pressure on rapid implementation of software updates and security patches. No one wants to be the person responsible for taking too long to patch for a vulnerability, but every time you touch a system, you’re introducing the risk of error. That risk is greater when dealing with the cloud where you have less control over the underlying infrastructure, more abstraction, and a lot more moving parts.

In short, patches can break things as well as fix them. They have thus become a significant contributing factor as a cause of downtime. With SANless clusters you’re able to minimize that risk by enabling rolling updates, meaning you can patch a secondary server, verify that the patch didn’t break anything, and then patch the original server where the primary application is still running. If something does break on the secondary server, the primary is unaffected and you can quickly recover to the previous state while you figure out what went wrong. This simplifies the process of executing ad hoc patches and performing planned maintenance, mitigating the associated risks.

An investment in cloud and hybrid infrastructure and services doesn’t have to put IT operations at the mercy of a third party. With the right approach, you can design for high availability and resilience and keep your mission-critical workloads running in the cloud even when things outside of your control go wrong.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.