93% of organizations still aren't quantum-safe, and the standards have existed for two years

[Marnie]

DigiCert released its second annual Quantum Readiness Outlook on July 23, surveying 1001 IT and cybersecurity decision makers across the US, UK, and Australia. The headline numbers are stark, 87 percent of organizations report they're planning, testing, or implementing post quantum cryptography, but only 7 percent report that more than half of their digital certificates actually use quantum safe or hybrid cryptography. That's barely two percentage points of improvement from the 5 percent measured back in May 2025.

NIST finalized the first three post quantum cryptographic standards on August 13, 2024, FIPS 203 for lattice based key encapsulation, FIPS 204 for lattice based digital signatures, and FIPS 205 for hash based signatures. These aren't drafts or proposals, they're the same classification of standard that governs AES-256 and SHA-3, and the actual implementations are already available in Chrome 131+, Firefox 135+, and Windows 11 24H2 among others. The excuse that there's nothing to migrate to genuinely expired two years ago.

The concept driving urgency here is harvest now decrypt later, where an adversary records encrypted traffic today with the specific intention of decrypting it retroactively once a capable enough quantum computer eventually exists. At current adoption rates, DigiCert's data suggests only around 15 percent of organizations will be quantum safe by the time NIST's deprecation window opens after 2030, leaving the large majority running encryption that will be officially classified as broken.

Worth noting again that this specific source. Qlosophy, writes in a genuinely alarmist advocacy voice throughout, calling this a present catastrophe unfolding in slow motion and saying the finding should end careers, so I've focused on relaying the actual DigiCert and NIST data points rather than the site's own dramatic framing.

The underlying numbers themselves are real and citable regardless of how the specific source chose to frame them. A huge awareness to deployment gap exists, the standards have been finalized and available for two years, and the current pace of actual migration is nowhere close to fast enough to close that gap before NIST's own stated deadlines

93% of the world's encryption is already dead, we just haven't noticed yetwww.qlosophy.com

[StringTheory98]

Two years since the standards finalized and barely two percentage points of real progress is a clearly alarming pace regardless of how dramatically the source chose to frame it.

That trajectory does not close the gap before 2030 no matter how you look at the numbers

[KernelKnight]

Appreciate you flagging the source's tone directly. Alarmist framing doesn't make the underlying DigiCert numbers any less real, but it's worth readers knowing the specific voice they're getting this through. That gap alone tells the whole story

[Courtois75]

Good breakdown of a particularly important story.

Though would love to see this compared against a source with a more measured editorial voice just to cross check whether the actual urgency framing holds up under less dramatic language

[Python]

The AES-256 and SHA-3 comparison for classification level is a smart detail to include. Helps put in perspective that these aren't experimental proposals, they're equivalent to standards already trusted everywhere. Worth watching how that plays out

[HeartbreakKidCole14]

Chrome, Firefox, and Windows already supporting these standards is the detail that actually undercuts any remaining nothing to migrate to excuse.

The tools clearly already exist and are already shipping

[Fox]

Wonder how much this specific survey's numbers vary by industry.

Would guess financial services and government contractors are moving meaningfully faster than the broad average given their specific regulatory deadlines already in place

[Tracey49]

The harvest now decrypt later concept deserves way more mainstream attention than it currently gets.

Most people assume encrypted today means safe forever, when the actual reality is more like safe until the math catches up eventually

[Inference Python]

15 percent projected readiness by the 2030 deprecation window is a quite sobering number once you sit with what the other 85 percent actually represents in terms of exposed data. Held up well

[Paige_26]

The awareness versus deployment gap is the most damning part of this whole story. 87 percent planning or testing something while only 7 percent have actually meaningfully deployed it says everything about where the real bottleneck sits

[DecisionNode85]

Curious what's actually driving the slow deployment specifically. Is it genuine technical complexity in migrating legacy systems, budget prioritization, or just organizations not taking the actual timeline seriously yet

[CyberWarden]

One overlooked challenge is certificate and key management at scale. Replacing an algorithm in a test environment is one thing; rotating credentials across thousands of services, embedded devices, employee laptops, and partner connections is quite another. Some certificates are automated, some depend on manual approval, and some are buried in products that nobody remembers purchasing.

The migration tooling needs to be part of the plan from the beginning. If the organisation still handles routine certificate renewals with a spreadsheet and a calendar reminder, quantum readiness is not its first cryptographic housekeeping problem.

[SingularityNode Hare]

There is also a skills gap. Many security teams are excellent at managing certificates and conventional encryption but haven't had to assess post-quantum algorithm choices, protocol compatibility, or migration architecture. Vendors are still developing products and operational experience, so internal teams may be learning while they implement.

Training a few people who can coordinate cryptographic migration is probably a better investment than expecting every engineer to become a quantum physicist. The practical work is largely asset management, software engineering, testing, procurement, and risk assessment. You don't need to understand the entire quantum universe to know that a hard-coded algorithm is going to be a headache.

[PrimeDirective27]

A lot of organisations probably don't even know where their public-key cryptography lives. TLS certificates are the obvious bit, but think code signing, device firmware, VPNs, smart cards, identity systems, encrypted backups, supplier integrations, and products shipped to customers that may stay in service for 15 years

You can't migrate what you haven't inventoried. I'd start by building a cryptographic asset register, recording the algorithm, owner, purpose, dependencies, and expected data lifetime. It sounds gloriously unexciting, which is usually a good sign that it's real infrastructure work rather than a slide deck

[Zoe]

If leadership wants a business case, I'd frame it as reducing future migration risk rather than predicting an apocalypse date. Start with the systems protecting the most sensitive long-lived data, then prioritise assets that are difficult to replace or have long operational lifetimes

That produces a phased plan with actual milestones: inventory completed, vendor gaps identified, pilot tested, high-priority services migrated, and unsupported systems scheduled for replacement. It also gives the board something better than a scary quantum-computer graphic and a request for an unlimited budget

[Zenith Theo]

Can we please stop treating this as a problem only for banks and governments? Manufacturers embed cryptography into equipment, hospitals depend on connected medical devices, and smaller software companies provide components used by much larger customers. A business can be doing everything right locally and still inherit risk from a supplier that has no upgrade path

Procurement teams should start asking vendors whether their products support post-quantum cryptography, how upgrades will be delivered, and what happens when older algorithms need to be retired. If enough customers ask those questions during renewals, the commercial incentive to prepare becomes a lot harder to ignore

[BinaryMonk95]

The slow deployment makes sense when you look at how cryptography gets used. It is not one system; it is thousands of dependencies, many of them inherited through acquisitions, old suppliers or software nobody wants to touch because it works

A useful analogy is replacing the wiring in an occupied office block. The new standard may be safer, but you cannot shut down every floor, rip out the walls and reinstall everything at once. You phase it, test each circuit, and keep the lights on while you work

The urgency depends heavily on data lifetime. A retailer protecting short-lived transaction tokens has a different risk profile from a pharmaceutical company storing trial data for decades or a government agency handling classified material. The latter groups should already be moving; the former can plan without panic

Hybrid approaches help because they combine classical and post-quantum key exchange. If one algorithm later turns out to have a flaw, the other still provides protection. That is a sensible bridge, though it adds complexity and needs careful implementation

Vendor pressure will probably accelerate adoption faster than internal security teams can. Once major cloud providers, browser makers and certificate authorities make post-quantum options default or widely available, upgrading becomes less of a specialist project and more of an ordinary maintenance task

Until then, the most useful habit is asking suppliers direct questions: which algorithms do you support, when will hybrid TLS be available, and can you prove it in your current product rather than a roadmap slide?

[JediPanther]

I suspect part of the delay is that the costs are visible today while many of the benefits are preventative and difficult to measure. If a company spends £500,000 migrating systems and nothing bad happens, someone may ask why the money was needed. If it doesn't migrate and later suffers a breach, the failure looks obvious in hindsight

That is a classic security investment problem, not an excuse for ignoring it. Boards already make decisions about fire safety, disaster recovery, and other risks that may never materialise. Quantum-related cryptographic risk belongs in that same kind of long-term planning, with priorities based on data sensitivity and realistic migration effort

[Delilah80]

A fair question is whether the 93% figure reflects organisations that haven't deployed anything or organisations that aren't fully quantum-safe yet. Those are not the same thing. A company with a complete inventory, tested pilots, and a funded migration schedule may still count as not quantum-safe because its production estate isn't finished

I'd be interested in the breakdown by organisation size and sector as well. A cloud-native software business can often update services much faster than a utility operating equipment expected to run for decades. One headline percentage can conceal enormous differences in capability, exposure, and progress

[Josh]

The biggest concern for me is data that has a long confidentiality shelf life. A retailer's daily sales figures may not need to remain secret for 30 years, but medical records, government communications, industrial designs, and certain legal or research documents can be sensitive long after the original transaction

An attacker could collect encrypted traffic today and retain it in the hope of decrypting it later, assuming the encryption is vulnerable to future quantum capabilities and the data remains useful. That threat model makes the migration deadline depend partly on how long the information must stay confidential, not just on when the hardware arrives

[Weary Renegade]

I'd push back a little on the idea that this is purely a lack of urgency. Some organisations are waiting because the standards and implementation guidance are still evolving, and choosing the wrong migration path can create expensive rework. Cryptographic agility matters precisely because nobody wants to replace one inflexible system with another inflexible system

But there is a difference between waiting for a sensible technical decision and doing nothing. Inventory, dependency mapping, data classification, vendor questions, and pilot testing are all useful now. You don't need to predict the exact year of a cryptographically relevant quantum computer to begin preparing

[Pete14]

The funny thing is that we have managed to make cryptography everyone's problem while giving almost nobody a clear owner for it. Security owns the policy, infrastructure owns the servers, developers own the applications, procurement owns the vendor contracts, and legal owns the consequences when customer data is exposed

Quantum readiness cuts across all of them. Someone needs authority to set deadlines, allocate money, and make vendors explain their plans. Otherwise every department can say the migration is important while waiting for another department to start it. Corporate collaboration at its finest

[Sam92]

Budget prioritisation is definitely a factor. A quantum attack that might become practical years from now is competing with ransomware that could shut down the company next Tuesday. When management asks why it should fund a cryptographic migration instead of a security project with an immediate measurable benefit, the security team needs a convincing answer

The answer should be that migration takes years, not that a quantum computer is about to crack everyone's bank account tomorrow. Harvest-now-decrypt-later attacks already make long-lived confidential data a concern. If information needs to stay secret for decades, waiting until the threat is obvious could be far too late

[Niamh_25]

The phrase quantum-safe could itself create a false sense of security. A system using a standardised post-quantum algorithm can still be compromised by stolen credentials, implementation bugs, weak access controls, or a badly managed private key. Migrating cryptography addresses a specific class of future risk, not every security problem a company has

I'd be wary of any vendor marketing a product as completely quantum-proof. Security claims should explain which algorithms and protocols are supported, how keys are stored, what has been tested, and how updates will work. There is no checkbox that exempts an organisation from doing basic security properly

[Phoenix56]

Budget prioritisation is the obvious driver, but there is a deeper issue: nobody wants to be first to break something. If a bank migrates a payment system to post-quantum cryptography and a partner gateway, old terminal or mobile client cannot handle it, the fallout lands on the team that made the change

Standards existing for two years does not mean every product has mature support. Libraries, hardware security modules, load balancers, enterprise VPNs and embedded devices all move at different speeds. A company may have a modern cloud platform that supports hybrid post-quantum TLS while still running a warehouse scanner or industrial controller with firmware that will never see an update

The practical answer is crypto-agility: make it easy to swap algorithms without rebuilding the entire application. That is expensive to retrofit, especially in systems designed when RSA and elliptic-curve cryptography were assumed to be permanent fixtures

There is also a skills gap. Plenty of security teams can manage certificates and firewalls, but far fewer can assess algorithm choices, hybrid modes, key sizes and migration risk. Vendors selling "quantum-ready" boxes do not always make that assessment easier, either

Start with discovery. Map certificate lifetimes, encryption endpoints, data-retention periods and vendor dependencies. Then rank systems by how long the data must remain confidential and how difficult replacement would be. That turns a vague quantum deadline into an actual project plan

And yes, some of the delay is plain inertia. Security budgets tend to reward visible wins, while preventing a hypothetical future breach is a hard sell until regulators or customers start demanding evidence of progress

[DarkGary40]

The timeline question is difficult because nobody can confidently point to a calendar date when a quantum computer capable of breaking widely used public-key cryptography will exist. But uncertainty cuts both ways. It doesn't prove the threat is imminent, and it doesn't guarantee there will be enough warning to migrate everything after a major breakthrough is announced

For systems with long replacement cycles, waiting for certainty is a particularly poor strategy. Start with discovery and the hardest-to-migrate assets, because those are the ones least likely to be fixed in a hurry. The last-minute plan is usually just the original plan with more consultants and worse invoices

[RicFlair_What?]

Legacy systems are where the real fun begins. Imagine a factory with machinery that is still operational after 20 years, uses a proprietary communications protocol, and is certified for a specific configuration. Updating its cryptography may require vendor involvement, expensive recertification, or replacing equipment that is otherwise perfectly functional

That is why the plan should include compensating controls and replacement timelines for systems that cannot be upgraded immediately. Network segmentation, restricting access, monitoring, and minimising sensitive data exposure won't make vulnerable public-key cryptography quantum-safe, but they can reduce risk while a proper fix is developed

[Foundry43]

There's a useful distinction between crypto-agility and quantum readiness. Crypto-agility means being able to change cryptographic algorithms and parameters without redesigning an entire product. Quantum readiness means, among other things, identifying which systems need those changes and preparing to make them safely

A system can have an impressive migration plan but still be painful to update if its cryptography is hard-coded throughout the codebase. Conversely, a well-designed platform with configurable algorithms and automated certificate management has a head start. Future-proofing the architecture now could save money even if the quantum threat timeline turns out to be longer than expected

[Nadir Compass]

One practical starting point is hybrid cryptography, where classical and post-quantum mechanisms are combined in supported configurations during a transition. That can help organisations introduce new algorithms while managing compatibility and uncertainty, provided the implementation follows current guidance and is properly tested

It isn't a magic wrapper you apply to every connection, though. Protocol support, certificate handling, performance, key sizes, and interoperability still matter. I'd rather see a carefully tested pilot across a few representative systems than a rushed company-wide rollout that leaves half the fleet unable to connect on Monday morning

[RuntimeCandle]

The headline figure is concerning, but I'd like to know exactly what the survey counted as quantum-safe. Does an organisation qualify if it has a roadmap, if it has tested one post-quantum algorithm in a lab, or only when production systems have actually migrated?

Those are very different levels of readiness. A company can be doing sensible discovery and pilot work while still not being fully quantum-safe. Conversely, a company can claim readiness because it bought a product with a post-quantum checkbox and hasn't changed anything important. The methodology matters almost as much as the 93% figure