CISA’s IoT Crackdown: What 21 Billion Devices Mean NowCybersecurity
CISA’s IoT Crackdown: What 21 Billion Devices Mean Now
A federal directive, a record-breaking botnet, and a 32-day remediation gap just rewrote the rules for enterprise IoT security. Here’s what CISOs need to act on, and why zero trust alone won’t save them.
On January 7, 2026, a botnet called RondoDox fired more than 40,000 automated attack attempts at HPE OneView servers in a single four hour window. Not routers. Not smart cameras. A data center management platform running inside government agencies, banks, and industrial manufacturers. Check Point Research caught it live, and CISA added the underlying flaw to its Known Exploited Vulnerabilities catalog the same day.
That attack is the clearest signal yet that enterprise IoT security has moved past the consumer-gadget stage. The threat now targets the infrastructure running your business, and federal regulators noticed before most private companies did. One month later, CISA issued a binding directive that private-sector security leaders are already treating as the new baseline, whether or not it legally applies to them.
The scale problem: 21 billion devices and counting
Ask ten analyst firms how many IoT devices exist right now and you’ll get ten different numbers, because they’re all measuring slightly different things on different dates. The most current, most cited figure comes from IoT Analytics‘ State of IoT 2025 report: roughly 21.1 billion connected IoT devices worldwide by the end of 2025, up 14% year over year, with the installed base projected to hit 39 billion by 2030.
If you’ve seen the “17 billion devices” figure floating around, that’s not wrong, it’s just old. That number reflects an October 2024 snapshot. By mid-2026, the real count sits closer to the low twenties, and it keeps climbing at double-digit rates every year. Every one of those billions of devices is a potential entry point, and most of them were never designed with security as a priority.
The headline stat that actually holds up: You may have seen claims that “68% of IoT devices run unpatched firmware.” We couldn’t verify that figure against any named source. What the research does support is more precise and arguably more useful: the IoT Security Foundation found that 60% of IoT security breaches trace back to unpatched firmware, making it the single largest documented cause of compromise, ahead of weak credentials or supply-chain attacks.
Firmware maintenance is the harder half of that problem. Research from ORDR, citing Forescout telemetry, found that 32% of deployed routers run firmware that will never receive another patch, full stop. The vendor has moved on, the support window has closed, and the device stays plugged in anyway. Forescout’s broader 2026 research puts the average router or switch at 32 vulnerabilities per device, and routers and switches now account for 34% of the most critical vulnerabilities found across enterprise networks.
Metric
Figure
Source
Global connected IoT devices (2025)
21.1 billion, +14% YoY
IoT Analytics
Breaches traced to unpatched firmware
60%
IoT Security Foundation
Routers running firmware that will never be patched
32%
ORDR / Forescout
Average vulnerabilities per router/switch
32
Forescout
Edge vulnerabilities fully remediated
54% (32-day median)
Verizon 2025 DBIR
Peak DDoS traffic from a hijacked-IoT botnet
29.7 Tbps
Cloudflare, Q3 2025
Inside CISA’s BOD 26-02
On February 5, 2026, CISA issued Binding Operational Directive 26-02, “Mitigating Risk From End-of-Support Edge Devices.” It requires federal civilian agencies to find, patch, and eventually rip out any edge device, including IoT edge devices, routers, firewalls, switches, and wireless access points, that no longer receives vendor security updates.
The timeline is specific and unforgiving:
Immediate: Patch where feasible.
3 months (by May 5, 2026): Complete inventory of end-of-support edge devices.
12 months (by February 5, 2027): Decommission those devices.
18 months (by August 5, 2027): Full removal from the network.
24 months (by February 5, 2028): Continuous discovery process in place permanently.
CISA Acting Director Madhu Gottumukkala didn’t soften the message when the directive dropped: “Unsupported devices pose a serious risk to federal systems and should never remain on enterprise networks.”
The directive is technically federal-only. In practice, it’s already becoming the industry’s reference clock. CISA, the FBI, and the UK’s National Cyber Security Centre have all publicly urged private companies to adopt the same timeline, and Help Net Security’s breakdown of the order notes the same pattern security teams have seen with prior directives: what starts as a federal mandate becomes an insurance underwriting question within a year.
If you’re running a regulated business, expect your cyber insurance renewal and your next audit to start asking about edge-device lifecycle management using this exact framework, whether you’re a federal contractor or not.
The EU has its own clock running in parallel. The Cyber Resilience Act’s 24-hour early warning obligation for actively exploited vulnerabilities kicks in on September 11, 2026, with full security-by-design and lifetime patching requirements following in December 2027. We’ve covered the CRA’s compliance mechanics and deadlines in detail in our EU Cyber Resilience Act deadline explainer, so we won’t repeat it here. What matters for this piece is that two major regulatory regimes are converging on the same conclusion at the same time: the era of shipping IoT hardware and walking away from it is over.
The breaches that forced the issue
Regulators don’t move this fast without a body count. 2025 and early 2026 gave them plenty of evidence.
BadBox 2.0
Google disclosed this one in July 2025. It’s the largest known botnet built from internet-connected TVs, streaming boxes, and digital photo frames, compromised through outdated firmware and infecting more than a million devices in the United States alone. Nobody bought a hacked photo frame on purpose. The firmware just never got a security update, and an entire product category quietly became attack infrastructure.
Aisuru and Kimwolf
This is the botnet pair that broke the DDoS record books. Cloudflare mitigated a 29.7 Tbps attack in Q3 2025, sourced from an estimated 300,000 to 700,000 hijacked routers, DVRs, and IP cameras. Microsoft Azure absorbed a separate 15.72 Tbps flood in October 2025 tied to the same infrastructure. By early 2026, authorities confirmed the combined Aisuru and Kimwolf networks had compromised more than 3 million devices globally, according to reporting from Swif.ai’s IoT security roundup.
For scale: Mirai, the botnet that defined this entire threat category back in 2016, recruited 600,000 devices using just 60 default credential combinations and still managed a 1.2 Tbps attack that knocked major sites offline. A decade of public warnings, published source code, and industry conferences later, the same playbook, default credentials plus unpatched firmware, just produced an attack 24 times larger.
RondoDox against enterprise infrastructure
The HPE OneView campaign matters because of what it targeted, not just how big it was. Consumer routers and cameras are the old story. A data center management platform is the new one. Our read: this is the clearest evidence yet that IoT-botnet tactics have graduated from consumer gadgets to core enterprise infrastructure, and security budgets built around “protect the smart thermostats” haven’t caught up.
The financial exposure backs that up. Aggregated breach-cost research from Vectra.ai and ORDR puts the average IoT security incident at roughly $330,000, climbing to an average of $10 million per incident in healthcare specifically, where connected medical devices and unpatched firmware collide with regulatory exposure and patient safety.
Why zero trust breaks down in IoT and OT
Ask any vendor and zero trust is the answer to everything, including this. Ask the people actually implementing it, and you get a more complicated picture.
“We all agree: zero trust is necessary. But it’s been hard to implement. It doesn’t matter what you read or which framework you follow. The core issue is that we have a concept with principles and tenets, but not enough guidance on how to implement it.”
Morey Haber, Chief Security Advisor, BeyondTrust, via Network World
Haber’s framing is the industry-consensus version: zero trust works in theory, execution is the bottleneck. The sharper critique comes from people who’ve responded to what happens when it fails.
“The biggest security incidents in 2026 will stem from compromised identities within supposedly zero trust environments. The illusion of control will persist until identity management becomes contextual and adaptive, powered by AI that can interpret intent, not just credentials.”
Ariel Parnes, COO, Mitiga (former IDF Unit 8200 colonel), via SecurityWeek
Parnes is describing a real gap: zero trust verifies credentials, not intent, and IoT devices generally don’t have the kind of identity infrastructure that makes that verification meaningful in the first place. Most IoT hardware simply can’t run the components a standard zero-trust architecture assumes. No multi-factor authentication. No client certificates. Not enough compute to support continuous verification. You can’t authenticate your way around hardware that was never built to authenticate.
CSO Online’s analysis of the IoT and OT gap makes the sharpest structural point in the whole debate: zero trust governs access, but it doesn’t model consequence. Two systems can be fully isolated at the network layer, properly segmented, verified access on paper, and still be functionally inseparable through a shared controller, a common protocol translator, or a vendor’s remote update service. You can pass every zero-trust audit and still have a single point of failure nobody mapped.
Timeline expectations get a reality check too.
“We will eventually get there, but timelines extend well beyond 2026 due to fundamental structural barriers. Private data exchanges must simultaneously secure data flows across partners’ legacy systems, cloud environments, and on-premise infrastructure, while maintaining operational compatibility with hundreds of exchange participants at varying security maturity levels.”
Dario Perfettibile, VP and GM of European Operations, Kiteworks, via SecurityWeek
Put those three quotes together and you get the honest 2026 state of the industry: zero trust is the right direction, badly under-implemented, structurally mismatched to most IoT hardware, and years away from covering the gap even under optimistic timelines.
What enterprise security teams should do now
The Verizon 2025 Data Breach Investigations Report, drawn from more than 22,000 incidents and 12,195 confirmed breaches, found a 34% year-over-year rise in successful vulnerability exploits, with an eightfold jump in exploitation of edge devices and VPN concentrators. Among breaches that started with vulnerability exploitation, edge devices and VPNs accounted for 22%, up from just 3% the year before. Only 54% of edge vulnerabilities were fully remediated in the observation window, and the median time to fix one was 32 days.
That 32-day number is the one worth pinning to your dashboard. It’s a real industry benchmark you can measure your own remediation SLA against, not a vendor’s aspirational target.
Given all of that, the realistic model for 2026 isn’t “implement zero trust everywhere.” It’s a two-tier approach: identity-based zero trust for the IT systems that can actually support it, and network-based segmentation with behavioral monitoring for the IoT and OT fleet that can’t. Treating “we did zero trust” as a finished project, when your IoT devices sit entirely outside that perimeter by design, is the exact gap that shows up in next year’s breach report.
Practical steps that map directly to what’s driving this shift:
Inventory first. CISA’s own timeline gives federal agencies three months just to find every end-of-support edge device. If a federal agency needs that long, assume your enterprise network has blind spots too.
Benchmark against 32 days. Use the DBIR’s median remediation time as your internal SLA target, and track what percentage of your edge vulnerabilities actually get fully closed, not just acknowledged.
Segment what you can’t authenticate. If a device can’t run MFA or a client certificate, it goes on an isolated network segment with active behavioral monitoring, not on the same trust tier as your laptops.
Watch the procurement deadline. By January 4, 2027, vendors selling consumer IoT to the U.S. federal government must carry the FCC’s Cyber Trust Mark. That’s a voluntary label today. It becomes a de facto procurement filter in eighteen months, and enterprise buyers will likely start asking for it too.
For a deeper look at how these device counts are actually measured, our breakdown of Gartner’s edge computing numbers is worth a read. And if your IoT exposure runs through industrial or OT systems specifically, we’ve also mapped the ROI math behind GE and Shell’s industrial IoT deployments, which is a useful counterweight when your CFO asks why security spending on OT devices matters as much as the operational upside.
Frequently asked questions
How many IoT devices are there in 2026?
Estimates vary by firm and methodology, but IoT Analytics reports roughly 21.1 billion connected IoT devices as of the end of 2025, up 14% year over year, with the installed base forecast to reach 39 billion by 2030.
What percentage of IoT breaches are caused by unpatched firmware?
Research from the IoT Security Foundation attributes roughly 60% of IoT security breaches to unpatched firmware, making it the single largest documented cause of IoT compromise, ahead of weak credentials or supply-chain attacks.
What is CISA BOD 26-02?
CISA Binding Operational Directive 26-02, issued February 5, 2026, requires U.S. federal civilian agencies to inventory, decommission, and replace edge devices, including IoT edge devices, routers, and firewalls, that no longer receive vendor security updates, on a 3-to-24-month timeline.
Does zero trust work for IoT devices?
Only partially. Most IoT devices lack the compute power to run standard zero-trust components like multi-factor authentication or client certificates, so security teams typically apply a two-tier model: identity-based zero trust for IT systems, and network-based segmentation and behavioral monitoring for IoT and OT devices that can’t participate directly.
Where this goes next
Here’s what’s actually different now. Enterprise IoT security stopped being a device-hygiene checklist item somewhere between the RondoDox campaign and CISA’s February directive, and became a board-level compliance question with a hard clock attached. The 21 billion devices already deployed aren’t getting replaced overnight, the firmware problem isn’t getting solved by a single patch cycle, and zero trust isn’t the finished solution the marketing suggests.
Over the next 6 to 18 months, watch three things specifically: whether private-sector cyber insurers start writing CISA’s timeline into policy requirements, whether the EU CRA’s September 2026 incident-reporting deadline produces the first wave of public disclosure data on IoT breach frequency, and whether the two-tier zero-trust model becomes the named industry standard or stays an informal workaround.
The organizations that treat this quarter’s device inventory as a compliance chore will be the ones explaining a breach to their board next year. The ones that treat it as the actual security perimeter it is will just be doing their jobs.
Want this kind of analysis before it hits your feed? Subscribe to The Neural Loop at neuralwired.com/newsletter.
The EU Cyber Resilience Act’s IoT Deadline Is Coming, and the Rulebook Isn’t Ready
By NeuralWired Staff · Updated July 11, 2026 · 10 min read
Your engineering team has 14 months to make every connected product legally sellable in the EU. The regulator that set that deadline hasn’t finished writing the rules you’re supposed to follow to meet it. That’s not a hypothetical, it’s the state of the EU Cyber Resilience Act as of this week: zero harmonized standards published, zero notified bodies designated, and a September 2026 reporting deadline that arrives regardless.
If you build or sell connected hardware into Europe, this is the piece to read before you plan next quarter’s roadmap.
Most coverage of the Cyber Resilience Act (Regulation (EU) 2024/2847) leads with December 2027, the full-compliance deadline. That’s the wrong date to anchor your planning on. The Act entered into force on December 10, 2024, and it front-loads real obligations well before 2027 hits.
Date
What Happens
Dec 10, 2024
CRA enters into force
Jun 11, 2026
Rules for conformity assessment (notified) bodies begin to apply
Sep 11, 2026
Mandatory vulnerability and incident reporting begins: 24-hour early warning, 72-hour detailed report, 14-day final report
Dec 11, 2026
Target date for a “sufficient number” of notified bodies to be designated under Article 35
Dec 11, 2027
Full applicability: CE marking, conformity assessment, and technical documentation become mandatory
September 11, 2026 is the date to internalize. It’s roughly two months out, it applies to products you’ve already shipped, and it’s not contingent on any standard being finished. If your product has a known exploited vulnerability after that date, the clock on reporting it starts regardless of where your compliance program stands.
The Infrastructure Gap Nobody Budgeted For
Here’s the part of the story that hasn’t gotten enough attention: the scaffolding the CRA depends on to actually function isn’t built yet.
The European Commission asked CEN, CENELEC, and ETSI to develop 41 harmonized standards under Standardization Request M/606, split across horizontal (general) and vertical (product-specific) requirements. As of June 4, 2026, not one of them has been approved or published in the Official Journal. Every standard is still in draft. That matters because publication is what triggers the “presumption of conformity,” the mechanism that lets a manufacturer self-declare compliance instead of hiring a third party to check its work.
Why this is worse than it sounds: accreditation and designation of new conformity-assessment bodies typically takes 12 to 18 months. Even a fast start from EU member states in mid-2026 likely doesn’t produce meaningful assessment capacity until well into 2027, compressing what should be an 18-month compliance runway into a matter of months for higher-risk product categories.
Adding to the pressure: the Commission decided on February 16, 2026 to repeal the RED Cyber Delegated Regulation, the interim cybersecurity framework many IoT vendors currently lean on, effective December 11, 2027. That’s the same day the CRA becomes the only game in town. There’s no overlap buffer if the new standards slip.
“62% of people in Europe were unaware of what they needed to do last year. This year it’s 66%, statistically the same.”
Christopher “CRob” Robinson, Chief Security Architect, OpenSSF, quoted in DevOps.com, May 2026
Robinson’s data comes from OpenSSF and the Linux Foundation’s 2026 CRA Awareness and Readiness Report, and the numbers get more uncomfortable outside Europe. Among US and Canadian respondents, 72% said they were unfamiliar with a regulation that may legally apply to them the moment they sell a connected product to an EU customer. Only 34% of CRA-aware respondents could correctly name December 2027 as the full compliance date.
Why the EU Built This: 21.9 Billion Devices, Record-Breaking Botnets
None of this exists in a vacuum. There are an estimated 21.9 billion active connected IoT devices globally in 2026, per IoT Analytics tracking, and a meaningful share of them are running the security posture of a decade ago. Research compiled by Phosphorus and Dexpose puts roughly 75% of IoT devices in the field on default passwords, with close to 98% of IoT device traffic still moving in plaintext.
That’s the raw material for what’s already happening. The Aisuru botnet, built largely from compromised consumer routers, CCTV cameras, and DVRs, hit a peak of 29.7 Tbps and 14.1 billion packets per second in 2026, breaking the previous DDoS record within months of it being set. Every one of those compromised devices is a product that, under a functioning CRA, should have shipped with better default security and a working vulnerability-disclosure process.
This is the regulation’s actual argument: product-level security obligations, not just entity-level ones like NIS2 already covers. Whether the compliance infrastructure catches up to that ambition in time is a separate question.
What Changes on Your Engineering Roadmap Starting Now
If you lead product, engineering, or security at a company selling connected hardware into the EU, including companies headquartered outside it, a few things stop being someday problems.
Classification can’t wait for the standards
Waiting for a finished harmonized standard before you classify your product (default, Important Class I/II, or Critical) isn’t a viable strategy anymore. Manufacturers currently have to document compliance against Annex I’s essential requirements directly, without the shortcut a published standard would provide.
Notified-body conversations need to start now, not in 2027
If your product lands in Important or Critical tiers (routers, VPNs, smart locks, security cameras, identity hardware), the constraint isn’t going to be your paperwork. It’s going to be the queue. A notified body has to appear in NANDO before it can issue a valid assessment, and that list is currently empty.
SBOMs stop being optional
Only about 32% of manufacturers currently produce a Software Bill of Materials for all of their products, and roughly 51% still passively depend on upstream open-source maintainers to catch and fix security issues. Under CRA’s supply-chain accountability rules, that gap is now a liability, not just a hygiene issue.
Reporting infrastructure needs to work by September 11
The 24-hour, 72-hour, 14-day reporting cascade applies to products already on the market, not just new launches. If your incident-response process can’t hit those windows today, that’s the highest-priority gap to close.
The upside most vendors miss: procurement teams and enterprise customers are already starting to ask for CRA evidence well ahead of the 2027 deadline. Being able to say “yes, here’s our documentation” is turning into a sales advantage months before it becomes a legal requirement.
Is December 2027 Realistic? The Critics Say No
The timeline problem isn’t just that standards are late. It’s that some of them are scheduled to arrive after the deadline they’re supposed to support. Security researcher Sarah Fluchs has documented the delivery schedule in detail: the horizontal standard covering vulnerability handling targets August 30, 2026, but the horizontal standard covering generic cybersecurity requirements isn’t due until October 30, 2027, essentially the eve of full applicability, leaving manufacturers almost no runway to build a compliance program against a finished reference point.
Scope is a second, older fault line. When the CRA was still a proposal, the Open Source Initiative and 17 other organizations warned that its definition of “commercial activity” created real legal uncertainty for developers, and risked discouraging the open-source ecosystems that have historically been more responsive on security, not less. Amendments added an open-source exemption and a new “open source steward” category before final passage, but the underlying scope ambiguity hasn’t fully gone away. NLnet Labs, maintainer of widely used DNS and routing software, has separately pushed the Commission on whether the “occasional supplies” exemption meaningfully applies to software as foundational as BIND or MINIX, both decades-old, both embedded in critical infrastructure.
Our read: this signals a regulation whose ambition outran its own build schedule. That’s not unusual for first-of-its-kind product security law. It does mean the manufacturers who treat 2027 as the actual planning deadline, rather than September 2026, are the ones most likely to get caught by a slipped standard or a full notified-body queue.
One more thing worth correcting: the widely repeated claim that “90% of products can self-assess” isn’t an official CRA statistic. It’s an estimate based on how narrow the Important and Critical categories are, and it’s worth treating as a caveat rather than a guarantee for your specific product line.
A Practical Compliance Roadmap
Classify now, against Annex I directly. Don’t wait for a published standard to tell you what tier you’re in.
Start notified-body conversations immediately if you’re in Important Class I/II or Critical territory. The queue, not the documentation, is the bottleneck.
Stand up SBOM generation as a permanent engineering practice, not a pre-launch checklist item.
Build (or stress-test) your 24/72-hour reporting pipeline before September 11, 2026, using your current, already-shipped product line as the test case.
Budget for a 10-year vulnerability record retention and 5-year minimum security-update commitment. This is a lifecycle obligation, not a one-time certification.
Track the standards calendar directly rather than relying on secondhand summaries. Target dates slip, and your compliance plan needs to move with them.
Frequently Asked Questions
When does the EU Cyber Resilience Act take effect?
The CRA entered into force December 10, 2024. Vulnerability and incident reporting obligations begin September 11, 2026. Full compliance, including CE marking, conformity assessment, and all essential cybersecurity requirements, becomes mandatory December 11, 2027, across all 27 EU member states.
What products does the Cyber Resilience Act cover?
The CRA covers any hardware or software product with digital elements whose intended or foreseeable use includes a direct or indirect connection to a device or network, from smart home devices and routers to enterprise software. Products already regulated elsewhere, like medical devices and vehicles, and non-commercial open-source software are excluded.
What are the penalties for CRA non-compliance?
Penalties reach up to €15 million or 2.5% of global annual turnover, whichever is higher, for breaches of essential cybersecurity requirements. Lower tiers of €10 million/2% and €5 million/1% apply to lesser infringements, alongside possible product recalls and EU market-access bans.
Does the Cyber Resilience Act apply to US companies?
Yes. Any manufacturer placing a product with digital elements on the EU market is in scope, regardless of where it’s headquartered. A US firmware vendor selling into Germany or a Korean device maker with EU distributors both fall under CRA obligations.
Are there harmonized standards for CRA compliance yet?
No. As of mid-2026, no CRA harmonized standard has been published in the EU Official Journal, so the presumption of conformity isn’t available for any product category yet. Manufacturers currently have to document compliance through direct reference to Annex I’s essential requirements.
What is a notified body under the CRA?
A notified body is a third-party conformity assessment organization designated by an EU member state to evaluate Important and Critical products that can’t be self-assessed. As of mid-2026, member states can formally designate these bodies, but none had appeared in the EU’s NANDO database yet.
What This Means Going Forward
The Cyber Resilience Act isn’t in danger of being delayed. The dates in the regulation are fixed, and the Commission has given no signal it plans to move them. What’s genuinely uncertain is whether the standards and notified-body infrastructure catch up in time for manufacturers to comply the way the law assumes they will, through self-assessment against a finished, published standard.
Over the next six to eighteen months, watch three things: whether the first horizontal standard actually publishes near its August 2026 target, how many notified bodies appear in NANDO by the December 2026 target date, and whether the Commission issues any interim guidance to bridge manufacturers through the gap. Any of the three slipping further pushes real compliance risk earlier into 2027, not later.
The companies that treat September 2026 as the real starting gun, not December 2027, are the ones least likely to be caught mid-recall when the infrastructure finally arrives.
Want the next regulatory deadline before it becomes a headline? Subscribe to The Neural Loop at neuralwired.com/newsletter.
91% of Enterprises Aren’t Ready for Quantum-Safe Migration
Cybersecurity / Enterprise IT
91% of Enterprises Aren’t Ready for Quantum-Safe Migration
NIST finalized its post-quantum encryption standards two years ago. Government deadlines start hitting in January 2027. And most security teams still haven’t mapped where their own vulnerable encryption lives.
By NeuralWired Staff · Updated July 2026 · 11 min read
Somewhere in your infrastructure right now is a TLS certificate, a VPN tunnel, or a code-signing key protected by encryption that a sufficiently powerful quantum computer will eventually break. You probably don’t know exactly where. Neither does most of the industry.
That’s the uncomfortable starting point for quantum-safe encryption migration, the multi-year project of replacing RSA and elliptic-curve cryptography with algorithms designed to survive an attack from a quantum computer. The National Institute of Standards and Technology (NIST) finalized the first official post-quantum cryptography (PQC) standards back in August 2024. Two years later, the vast majority of enterprises haven’t started implementing them, even as the first hard regulatory deadlines approach.
The number you’ll see everywhere isn’t real. A widely circulated claim that “78% of enterprise IT teams haven’t started migration” doesn’t trace back to any known survey. The closest verified figures: 91% of surveyed cybersecurity professionals say their organization has no roadmap for quantum threats (Trusted Computing Group), and only 5% have actually implemented quantum-safe encryption (DigiCert). Both numbers are arguably worse than 78%, and both are attributable.
On August 13, 2024, NIST released the first three finalized post-quantum cryptography standards, capping an eight-year public evaluation process that started with a 2016 call for proposals. The agency describes them as designed to resist attacks from quantum computers that would otherwise threaten the encryption protecting everything from confidential email to e-commerce transactions.
Three standards, three jobs:
Standard
What it does
Based on
FIPS 203
Key exchange (ML-KEM)
CRYSTALS-Kyber
FIPS 204
Digital signatures (ML-DSA)
CRYSTALS-Dilithium
FIPS 205
Backup signature scheme (SLH-DSA)
SPHINCS+
A fourth algorithm, FALCON, is still working its way toward publication as FIPS 206. NIST added a fifth, HQC, in March 2025 as a non-lattice-based backup, in case a future breakthrough finds a weakness in the lattice math that FIPS 203 and 204 depend on. Redundancy by design, not an afterthought.
Dustin Moody, the mathematician who leads NIST’s PQC project, put the urgency plainly at the time of release:
“We encourage system administrators to start integrating the new standards into their systems immediately, because full integration will take time.”
Dustin Moody, NIST PQC Project Lead, 2024
That quote is now two years old. It hasn’t aged into irrelevance. It’s aged into an indictment.
The readiness gap, in real numbers
Here’s what enterprise quantum readiness actually looks like right now, pulled from the surveys with disclosed methodology and sample size:
91% of surveyed cybersecurity professionals say their organization has no roadmap to defend against quantum threats, according to the Trusted Computing Group’s State of PQC Readiness report, based on 1,500 professionals across the US and Europe.
81% of professionals in the same TCG survey believe their current crypto-libraries and hardware security modules aren’t ready for the migration at all.
46.4% of organizations admit that substantial portions of their encrypted data could be exposed once a cryptographically relevant quantum computer exists.
Across a 2026 internet-wide scan of 32,011 domains, hybrid post-quantum TLS certificate adoption came back at effectively zero, meaning the certificates authenticating most public websites remain entirely classical.
The “actively transitioning” figure you’ll sometimes see quoted at 40% (from a 2026 Entrust/Ponemon study) is technically accurate but softer than it sounds. It includes planning and risk-assessment work, not completed deployment. Don’t let a vendor deck blur that line for you. Assessment isn’t migration.
IBM’s Quantum-Safe Readiness Index, cited widely in industry roundups, puts the average enterprise score at 25 out of 100. Useful directionally. Less useful as a rigorous benchmark, since IBM hasn’t published transparent, peer-reviewable methodology behind that number the way TCG and DigiCert have for theirs.
Why the timeline suddenly feels shorter
Here’s the part that should actually change your planning horizon. Google researchers published work in early 2026, reported by The Register, showing that running Shor’s algorithm against elliptic curve cryptography (ECDLP-256) would require roughly 20 times fewer physical qubits than previous estimates assumed. That doesn’t hand anyone a working quantum computer. It moves the goalposts closer, and it’s a bigger deal than the 2024 NIST finalization itself, because it’s new information rather than a milestone everyone already priced in.
Google also quietly moved up its own internal target for completing its quantum-safe transition to 2029, an acceleration signal from a company with more visibility into the state of quantum hardware than almost anyone outside a national lab.
The deadlines that are actually coming
Regulatory pressure, not abstract risk, is what actually moves budget. Here’s what’s on the calendar:
January 1, 2027: Under the NSA’s CNSA 2.0 framework, all new national security system acquisitions must be CNSA 2.0-compliant by default. If you sell into the defense or intelligence supply chain, this deadline is closer than your last migration cycle took to complete.
2028: The UK’s National Cyber Security Centre wants discovery and cryptographic asset inventory work done by this date, as phase one of a three-phase roadmap.
2035: Both the US (NSM-10) and UK targets converge on full quantum-resistant deployment by this year. The White House has estimated the cost of the federal government’s own migration at roughly $7.1 billion over the 2025 to 2035 decade.
Sector-specific cost estimates make the stakes concrete. Boston Consulting Group figures cited in recent research put automotive manufacturers’ PQC transition costs at $400 to 750 million, driven by the sheer complexity of patching cryptography embedded across vehicle fleets. Manufacturing, utilities, and transportation face a comparatively modest $10 to 20 million. Your industry determines your number more than your headcount does.
Why cryptographers are betting real money against each other
If you want proof that “urgency” isn’t a settled question even among people who build this stuff for a living, look at what happened in April 2026. Cryptography engineer Filippo Valsorda argued that even if quantum computing predictions turn out wrong in a decade, the current probability that they’re right is already too high to ignore. Matthew Green, an applied cryptographer at Johns Hopkins University, publicly disagreed, and then backed it with cash:
“I think this is a good precautionary analysis but I’d bet huge amounts of money against a relevant quantum computer by 2029 or even 2035.”
Matthew Green, Associate Professor of Computer Science, Johns Hopkins University, via The Register
Green and Valsorda formalized it into a $5,000 wager: Green is betting that classical cryptanalysis, not a quantum computer, will break ML-KEM-768 first. That’s not a random internet argument. That’s a specialist who studies exactly this problem, staking real money against the mainstream urgency narrative.
Peter Gutmann, a computer science professor at the University of Auckland, has been even more direct in his skepticism, pointing out in a 2025 interview that quantum computers have yet to factor the number 35, a six-bit problem, while the elliptic curve keys underpinning most of today’s encryption run 256 bits deep. That gap, he argues, isn’t one that recent efficiency papers close on their own.
On the other side, vendors are unambiguous about what to do regardless of the timeline debate. DigiCert’s Kevin Hilscher put it this way in the company’s 2025 readiness report:
“Organizations should already be into the early phases of their quantum readiness plan, starting with asset discovery and risk assessment, with the ultimate goal of crypto-agility.”
Kevin Hilscher, Senior Director of Product Management, DigiCert
Our read: the skeptics aren’t wrong that the exact date is unknowable. They’re arguing about when the threat arrives. Nobody credible is arguing that the migration itself will be fast once it starts. That’s the part that should worry a CISO more than any doomsday date.
What security leaders should do in the next 12 months
This is not a patch cycle. It’s closer to a multi-year infrastructure overhaul, and the planning assumptions bear that out: small organizations are looking at 5 to 7 years for a complete migration, mid-sized enterprises 8 to 12 years, and large distributed enterprises 12 to 15 years or more, according to industry timelines compiled by The Quantum Insider. If your internal plan says “three years, tops,” it’s almost certainly understating the job for anything larger than a small business.
Three things to prioritize now:
1. Build the cryptographic asset inventory you probably don’t have
TLS certificates, VPN configurations, code-signing keys, HSMs, embedded firmware, and third-party vendor dependencies all need to be mapped before you can even scope a migration. Remember that 81% figure from earlier: most security teams believe their own crypto-libraries and HSMs aren’t PQC-ready, and you can’t fix what you haven’t inventoried.
2. Treat “harvest now, decrypt later” as a present-tense problem
Adversaries don’t need a working quantum computer today to benefit from one tomorrow. They can archive your encrypted traffic now and decrypt it later. Any data with a confidentiality requirement longer than roughly a decade, meaning intellectual property, health records, M&A documents, or government contract data, is already exposed under this model. That reframes the whole conversation from a future compliance deadline into a data classification exercise you should be running this quarter.
3. Prioritize crypto-agility over algorithm selection
The specific PQC algorithm you deploy first can be swapped later if your architecture is built correctly now. Betting your entire strategy on picking the “right” algorithm misses the point. Build systems that can change algorithms without a rebuild, and the rest becomes a scheduling problem instead of an existential one.
On budget, 58% of organizations surveyed by TCG plan to allocate 6 to 10% of their IT and security budget to PQC migration. Useful as an internal benchmark if you’re building the business case for headcount or spend.
A caution on the “rush” narrative: Larger key and certificate sizes plus immature implementations have already caused documented performance and interoperability problems in early PQC rollouts. The UK’s NCSC deliberately built its roadmap around a gradual, multi-phase timeline through 2035 rather than a sprint. There’s a real risk in moving faster than your vendors and your own testing can support.
Frequently asked questions
What are NIST’s post-quantum cryptography standards?
NIST finalized three post-quantum cryptography standards on August 13, 2024: FIPS 203 (ML-KEM, for encryption and key exchange), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a hash-based backup signature scheme). A fifth algorithm, HQC, was added in March 2025 as an additional non-lattice-based option.
How long does quantum-safe migration take for an enterprise?
Industry planning estimates range from 5 to 7 years for small organizations to 12 to 15 or more years for large, distributed enterprises, depending on infrastructure complexity, legacy dependencies, and vendor readiness.
What percentage of companies have implemented quantum-safe encryption?
A 2025 DigiCert survey found that only 5% of organizations have implemented quantum-safe encryption, despite 69% recognizing quantum computing as a risk to current encryption standards.
What is “harvest now, decrypt later”?
It describes adversaries collecting and storing encrypted data today with the intent of decrypting it once a sufficiently powerful quantum computer exists. Data that needs to stay confidential for a decade or more is already exposed under this model, regardless of when quantum computers actually arrive.
When will quantum computers break current encryption?
There’s no consensus. Estimates range from 10 to 30 years based on current error-correction and qubit-stability hurdles, while recent efficiency research suggests the window may be compressing faster than previously assumed. Experts like Matthew Green and Peter Gutmann remain publicly skeptical of near-term timelines.
Where this goes next
Two things are true at once, and the industry keeps treating them as contradictory when they’re not. Nobody knows exactly when a quantum computer capable of breaking today’s encryption will exist. And the migration required to get ahead of it takes so long that “wait and see” isn’t actually a viable strategy for any organization with data that needs to stay secret past 2035.
Watch three things over the next 6 to 18 months: whether the January 2027 CNSA 2.0 acquisition deadline actually forces national security vendors to demonstrate compliance or slips, whether Google’s 2029 internal target holds as other hyperscalers respond, and whether the Green-Valsorda wager becomes a recurring reference point as more cryptographers stake public positions on timeline.
None of that changes what you should be doing this quarter: inventory your cryptographic assets, classify your long-lived data, and build for crypto-agility before you pick a single algorithm to bet on.
Quantum vs Classical Computing: What CTOs Need to Know in 2026
Enterprise Technology
Quantum Computing vs Classical Computing: The 2026 Enterprise Reality Check
By NeuralWired Staff · June 30, 2026 · 12 min read
A CISO at a mid-size healthcare company asked us a blunt question last month: should she be worried about data her organization encrypted five years ago? The honest answer is yes, and the reason has nothing to do with quantum computers being fast. It has to do with quantum computing vs classical computing working on fundamentally different principles, and one narrow but consequential category of problems where that difference now matters enormously: breaking the encryption protecting your archives.
That’s the story most coverage gets backwards. Quantum machines aren’t about to replace your CRM, your payroll system, or your e commerce backend. They’re about to (eventually) break the math those systems rely on to keep data private. Here’s what’s real, what’s hype, and what enterprise leaders should actually do about it in 2026.
The Real Technical Difference (And Why “Faster” Is the Wrong Frame)
Quantum computers don’t beat classical machines on raw speed, clock for clock. They exploit superposition and entanglement to explore certain solution spaces in a structurally different way, and that only produces an advantage on problems with a specific shape: ones where the solution space scales exponentially. Molecular simulation. Certain optimization problems. Integer factoring, the math behind RSA encryption.
For everyday enterprise computing, the workloads running your business right now, quantum offers nothing. Harvard Quantum Initiative researchers reported in May 2026 that this distinction is precisely why fault tolerance advances are reshaping timelines in some areas and not others. It’s not a general purpose computer that happens to be expensive. It’s a specialized tool, and right now there’s exactly one application area where that specialization has turned into urgency: cryptography.
Why Washington Just Got Involved
On June 22, 2026, the White House issued Executive Order 14413, “Ushering in the Next Frontier of Quantum Innovation.” It establishes the Quantum Computer for Application Development and Discovery Science effort, coordinated through the President’s science and technology advisory structure, aimed at delivering a working quantum computer to a Department of Energy facility. The order also directs federal agencies to stand up a national benchmark assessment center within 180 days.
Government interest at this level is a signal worth reading correctly. It’s not proof that commercial quantum computing has arrived. It’s confirmation that the national security calculus around cryptography has shifted enough to justify a presidential order, which tracks with everything else happening in the field this year.
The Money: Who’s Actually Spending, and How Much
According to McKinsey’s fifth annual Quantum Technology Monitor, released April 20, 2026, more than 300 companies, including Airbus, JPMorgan Chase, and Boehringer Ingelheim, are now actively working with quantum vendors. Quantum computing companies generated over $1 billion in global revenue in 2025, and investment in quantum startups hit $12.6 billion that year, a 6.3x jump from 2024.
McKinsey projects the technology could generate $1.3 trillion to $2.7 trillion in global economic value by 2035, with the underlying hardware and software market itself reaching $43 billion to $71 billion.
“2026 is the year in which quantum computing goes from a mere promise to a strategic management issue.”
Henning Soller, Partner, McKinsey & Company, Quantum Technology Monitor 2026
Here’s the budget benchmark worth knowing: of the companies McKinsey analyzed, 33% spend over $10 million annually on quantum initiatives, 7% spend over $50 million, and the largest single budget identified was $200 million. If your competitors are in that range, a small evaluative pilot makes sense. If they aren’t, building an in house quantum team right now is a real talent market risk, not a strategic head start.
That risk is sharper than it sounds. McKinsey’s own talent analysis found there’s only one qualified quantum candidate for every three open roles, and under half of quantum computing jobs currently get filled.
Worth noting too: 72% of enterprise quantum activity happens at privately owned companies, not public research institutions, and Europe currently leads in actual adoption (43% of analyzed companies) ahead of the US (29%) even though the US pulls in 64% of global investment dollars. Money and deployment aren’t flowing to the same places.
The Encryption Threat: A Number That Keeps Shrinking
This is the part of the story that should be on every CISO’s radar, and it’s moving faster than almost anyone expected. In 2019, Google researcher Craig Gidney estimated it would take roughly 20 million physical qubits to break RSA 2048 encryption using Shor’s algorithm. In a 2025 update, he revised that figure down to under 1 million qubits, a 95% reduction, with the actual attack taking under a week rather than years.
Why this matters today, not in 2030: “Harvest now, decrypt later” is the practice of adversaries collecting encrypted data now with the intent of decrypting it once sufficiently powerful hardware exists. If your organization handles data that needs to stay confidential for a decade or more, healthcare records, government contracts, financial archives, intellectual property, that data is potentially exposed right now, even though no current quantum computer can break it yet.
A March 2026 preprint from researchers at Caltech, Berkeley, and Oratomic, reported by ScienceAlert, estimated Shor’s algorithm could run with as few as 10,000 to 20,000 atomic qubits on neutral atom hardware, with around 26,000 qubits enough to break Bitcoin’s elliptic curve encryption (secp256k1) within days. Separately, a startup called Iceberg Quantum proposed in early 2026 that RSA 2048 could fall to fewer than 100,000 physical qubits using a different error correction approach, though that claim remains unvalidated at scale.
Google took its own warning seriously enough to set an internal 2029 deadline for migrating its infrastructure to post quantum cryptography, announced in a March 25, 2026 company blog post.
The Skeptic Who Changed His Mind
If you only follow one voice in this space, make it Scott Aaronson. He holds the Schlumberger Centennial Chair of Computer Science at UT Austin, co-founded the university’s Quantum Information Center, and sits on the US National Academy of Sciences. For most of the past decade he’s been quantum computing’s most credible skeptic, regularly pushing back against overhyped commercial claims.
“There are these claims about how quantum computing will revolutionize machine learning and optimization and finance and all these industries, where I think skepticism was always warranted. If people are just now coming around to that, well then, welcome.”
Scott Aaronson, UT Austin, IEEE Spectrum
So it matters that on May 1, 2026, Aaronson published a post titled “Will you heed my warnings?” stating that colleagues whose technical judgment he trusts more than his own now expect fault tolerant, crypto breaking quantum computers around 2029. When the field’s biggest doubter starts moving his own estimate forward, that’s a stronger signal than another optimistic vendor press release.
Not everyone in the industry agrees the broader commercial case is there yet. Sebastian Leichenauer, quoted in Forbes in March 2026, put it plainly:
“There is no offering on the market for quantum computing that is really where you need the quantum computer. None of them are really at the point where they can be sort of useful in the sense of, like, you would definitely use it for, say, a commercial application.”
Sebastian Leichenauer, quoted in Forbes, March 26, 2026
Leichenauer identified quantum chemistry, drug and materials discovery, as the one area with genuine near term value, and dismissed AI-on-quantum-instead-of-GPUs as far future thinking. That’s a useful filter: if a vendor pitch isn’t about molecular simulation or cryptography, treat it with real skepticism.
What CTOs and CISOs Should Actually Do in 2026
Strip away the noise and there are really two actions that matter this year, not five.
1. Start post quantum cryptography migration planning now
NIST’s post quantum cryptography standards are already published. You don’t need a working quantum computer to start this work, you need an inventory of where long-lived sensitive data lives and a migration roadmap, the same kind of project Google has already committed to completing by 2029. Pair this with internal linking to your existing compliance coverage, our breakdown of the GDPR AI fines and EU AI Act situation covers the regulatory side of data protection that overlaps directly with this risk.
2. If you’re in pharma, materials, chemicals, or finance, pilot through the cloud, don’t buy hardware
Since 72% of enterprise quantum activity already happens through cloud access rather than owned hardware, via AWS Braket, Azure Quantum, or IBM Quantum, that’s the lower risk entry point. It also avoids the talent trap: you don’t need to hire scarce quantum error correction specialists to run a bounded pilot. For the infrastructure side of this decision, our piece on the AWS and Azure shared responsibility model is relevant background reading.
What not to do
Don’t chase quantum for generic optimization, AI training, or anything pitched as a “quantum CRM.” That’s square hype, and Leichenauer’s quote above is the cleanest possible rebuttal to it. If a sector peer just raised a quantum startup round, that’s a venture capital story, not necessarily a signal your company needs to follow, our 2026 venture capital trends coverage has more context on where that $12.6 billion actually went.
The Critical Perspective: Is the Tipping Point Real?
Not everyone buys the “commercial tipping point” framing, including critics of McKinsey’s own numbers. An analysis published at postquantum.com argues that comparing 2035 quantum capability against 2026 classical capability misleads readers, and that the widely cited $1 billion revenue figure mostly reflects research contracts and development partnerships rather than production deployments generating real ROI. Even McKinsey’s report concedes most current applications remain experimental or hybrid.
There’s also a structural bottleneck the optimistic headlines tend to skip: programming a quantum computer requires fundamentally different skills than classical software engineering, unitary transformations, constraints from the no-cloning theorem, concepts most software teams have never touched. A sudden hardware breakthrough wouldn’t translate into immediate enterprise value, because there simply aren’t enough people who know how to write the algorithms yet.
Our read: the cybersecurity case for action is more solid and more urgent right now than the optimization or AI commercial case, and most coverage blurs the two together in a way that does readers a disservice. The encryption-breaking timeline has compressed faster than the general commercial timeline. Treat them as two separate decisions with two separate clocks.
Worth remembering too: this is at least the third “quantum is finally arriving” wave in a decade, following IBM’s early cloud access push and Google’s 2019 quantum supremacy claim. “Five years away” has been a recurring prediction for over a decade. If error correction engineering stalls again, as it has before, the $1.3 trillion to $2.7 trillion 2035 projections won’t hit on schedule, and companies that over-invested in dedicated quantum teams in 2026 will be sitting on sunk costs with no near term return.
Frequently Asked Questions
Is quantum computing faster than classical computing?
Not in general. Quantum computers use superposition and entanglement to explore certain large solution spaces differently, which only creates an advantage on narrow problem types: molecular simulation, specific optimization problems, and integer factoring. For everyday computing, they offer no benefit over classical machines.
Can quantum computers break RSA encryption?
Theoretically, yes, using Shor’s algorithm on a fault tolerant quantum computer. Google researcher Craig Gidney’s 2025 estimate puts the requirement at under 1 million physical qubits, down sharply from 20 million in 2019. Today’s largest systems hold only thousands of noisy qubits, well short of that.
What is “harvest now, decrypt later”?
It’s the practice of adversaries collecting encrypted data today with the intent of decrypting it once powerful enough quantum hardware exists. It’s a real present-day risk for any organization whose data needs to stay confidential into the 2030s.
What industries benefit most from quantum computing today?
Drug discovery, materials science, and chemistry lead because molecular simulation scales exponentially for classical computers. Finance (portfolio optimization, fraud detection), logistics, and post quantum cybersecurity planning follow as earlier stage but emerging use cases.
How big is the quantum computing market?
McKinsey projects quantum computing could generate $1.3 trillion to $2.7 trillion in global economic value by 2035, with the core hardware, software, and services market reaching $43 billion to $71 billion by the same year.
Where This Leaves Us
The headline most readers expected, “quantum computers are about to replace classical ones,” was never accurate, and it still isn’t in 2026. What’s actually true is narrower and arguably more urgent: the cryptography that protects long lived enterprise data is on a compressed timeline, the federal government just formalized that concern with an executive order, and the field’s most credible skeptic stopped being skeptical about the 2029 estimate.
Watch three things over the next 6 to 18 months: whether NIST’s post quantum standards see faster enterprise adoption following Google’s 2029 deadline announcement, whether the qubit-count estimates for breaking encryption keep shrinking the way they have for the past two years, and whether any of the 300+ companies McKinsey tracked move from pilot programs to genuine production deployment. That last one is the real tipping point. We’re not there yet.
Want this kind of analysis before it hits the rest of the industry? Subscribe to The Neural Loop at neuralwired.com/newsletter.
IBM’s Quantum Roadmap Gives Enterprises a 4-Year Window to Act on Post-Quantum Migration
By NeuralWired Editorial | June 29, 2026 | 12 min read
Your organization’s most sensitive encrypted data, customer records, financial transactions, intellectual property, could already be sitting in an adversary’s archive. It was captured yesterday. It will be decrypted in 2029, or 2031, or 2033. The exact date is uncertain. What is not uncertain is that the migration away from today’s encryption standards takes 42 to 54 months once an organization actually starts. And fewer than 5% of enterprises have started.
IBM’s quantum computing roadmap, Google’s dramatic security warning published March 25, 2026, and a new research paper that cut prior qubit estimates by a factor of 20 have together shifted this conversation from theoretical risk management to operational urgency. This article breaks down exactly what has changed, what the NIST post-quantum cryptography standards require, and what a CISO or CTO at an enterprise organization needs to do before the end of 2026.
The Real Threat Is Not the Qubit Count
When IBM announced Condor, its 1,121-superconducting-qubit processor, in December 2023, it made headlines. The 1,000-qubit barrier was crossed. But fixating on that number misses the actual story of 2026, which is about timelines, compliance clocks, and a harvest-now-decrypt-later threat that is already happening.
Qubit counts alone do not break encryption. What matters is logical qubits, fault-tolerant gates, and error correction at scale. IBM’s own engineers recognize this: after Condor, the company shifted its focus from raw qubit counts toward error resistance. State-of-the-art error correction currently requires roughly 1,000 physical qubits per logical qubit, which explains why the cryptographically relevant threshold is still years away from Condor’s 1,121 physical qubits.
Key Distinction
A 1,000-qubit quantum computer does not break RSA-2048 today. Breaking RSA-2048 likely requires around one million physical qubits running for approximately a week, based on Google’s latest research estimates. The urgency is about migration timelines, not imminent decryption.
The actual story of 2026 is that organizations which have not started post-quantum cryptography migration will mathematically fail to meet regulatory deadlines. That is the operational reality driving this article.
What IBM’s Quantum Roadmap Actually Says
IBM has published a detailed hardware roadmap that provides the clearest public signal of where quantum capability is heading and on what schedule.
Year
IBM Milestone
Key Capability
2023
Condor (1,121 qubits)
First processor crossing 1,000 physical qubits
2026
Kookaburra (1,386 qubits, multi-chip)
Three chips linked via IBM Quantum System Two, yielding a 4,158-qubit combined system
2028-2029
IBM Quantum Starling
Fault-tolerant system with roughly 200 logical qubits from approximately 10,000 physical qubits; 100 million gate operations
2029
Near-term quantum advantage tools
IBM targets delivery of tools for near-term quantum advantage by end of 2026, first large-scale fault-tolerant machine by 2029
The Kookaburra milestone in 2026 is significant not for its qubit count alone but for the multi-chip architecture. Linking processors is how IBM intends to scale toward the hundreds of logical qubits needed for cryptographically relevant computation. Every step on this roadmap narrows the gap between current machines and the systems that security teams are building their migration timelines around.
Our read IBM’s pivot from qubit maximalism to error-correction depth signals something important: the people closest to the hardware believe the engineering path to fault tolerance is now a matter of execution, not discovery. That is a different kind of confidence than the field had three years ago.
Google’s 2029 Alarm and What It Means for You
On March 25, 2026, Google’s security leadership published a formal announcement setting 2029 as the company’s internal deadline to secure its systems against quantum threats using post-quantum cryptography. The post was authored by Heather Adkins, VP of Security Engineering, and Sophie Schmieg, Senior Staff Cryptography Engineer. This is a full year ahead of NIST’s 2030 deprecation date and six years ahead of the 2035 final federal deadline under NSM-10.
Five days later, on March 30, 2026, Google Quantum AI released a 57-page paper with researchers from the Ethereum Foundation and Stanford University. The finding that drew immediate industry reaction: breaking 256-bit elliptic curve cryptography, the algorithm protecting Bitcoin and Ethereum, would require fewer than 500,000 physical qubits. That is nearly a 20-fold reduction from prior best estimates.
“It’s a real shock. We’ll need to speed up our efforts considerably.”
Bas Westerbaan, Applied Cryptography Lead, Cloudflare — TIME magazine, April 2026
Cloudflare accelerated its own post-quantum deadline to 2029 within days of the paper’s release. Westerbaan’s reaction is worth sitting with. Cloudflare processes a significant share of global internet traffic. When its cryptography lead describes a research paper as “a real shock,” that is not public relations language. That is a practitioner recalibrating a production timeline based on new data.
Google also announced that Android 17 is integrating post-quantum cryptography digital signature protection using ML-DSA, building on existing Chrome support. Our read this signals that PQC is no longer a future feature on Google’s roadmap. It is shipping code.
The Compliance Deadline Ladder: 2027 to 2035
The regulatory framework for post-quantum cryptography migration in the United States is built on NSM-10, the NSA’s CNSA 2.0 suite, and Executive Order 14144. Enterprises serving federal clients, contractors, and financial institutions with ties to regulated sectors need to treat this schedule as binding, not aspirational.
Deadline
Requirement
Who It Affects
Jan 1, 2027
All new National Security System acquisitions must support CNSA 2.0
Government contractors, defense suppliers, NSS vendors
Dec 31, 2030
Equipment unable to support CNSA 2.0 must be phased out; NIST deprecates RSA/ECC
All federal agencies, regulated critical infrastructure
Dec 31, 2031
CNSA 2.0 becomes mandatory across all National Security Systems (except exemptions)
NSS operators, contractors
2033
OS, cloud services, and custom applications must reach exclusive CNSA 2.0 use
Full quantum resistance required across all National Security Systems per NSM-10
Entire US national security supply chain
The January 2027 deadline for new NSS acquisitions is the one that commercial enterprises should pay attention to first, even if they are not themselves defense contractors. When government procurement requirements shift, vendor product roadmaps shift with them. Any software company, hardware manufacturer, or cloud provider that wants to remain in the government supply chain will need CNSA 2.0 support in new products by January 2027. That cascades into commercial product decisions within 12 to 18 months of announcement.
Procurement Action
CTOs should begin requiring CNSA 2.0 and post-quantum cryptography readiness clauses in vendor contracts now. The January 2027 government deadline will reshape commercial vendor roadmaps whether or not your organization is regulated. Get ahead of it in your next contract renewal cycle.
The Enterprise Readiness Gap Is Alarming
The data on enterprise preparedness is consistently grim across every survey and research source published in the past 12 months. The gap between awareness and action is wide enough to be a material risk that boards and audit committees should be asking about.
<5%
of enterprises have a formal quantum-transition plan (arXiv, September 2025)
69%
believe quantum will break current encryption within 5 years (DigiCert/Propeller Insights survey, 1,042 senior security managers)
41%
of organizations do not plan to address quantum computing at this time (ISACA 2025)
The DigiCert survey finding is particularly striking. Sixty-nine percent of senior cybersecurity managers believe quantum computers will break current encryption within five years. Only 19.2% describe themselves as “extremely prepared.” The gap between what people believe is coming and what they are doing about it is not a knowledge problem. It is an organizational inertia problem.
Scott Aaronson, Schlumberger Centennial Chair of Computer Science at the University of Texas at Austin and a newly elected member of the US National Academy of Sciences, offered the sharpest framing of this inertia in a PYMNTS interview in February 2026:
“The time to start thinking about migrating to quantum-resistant methods of encryption is now. Even optimistic estimates place practical quantum attacks five to ten years out, but the migration itself, not the threat, is the actual bottleneck for large institutions.”
Scott Aaronson, Schlumberger Centennial Chair of Computer Science, University of Texas at Austin — PYMNTS, February 20, 2026
Aaronson matters here for a specific reason. He has spent more than a decade as quantum computing’s most prominent skeptic, the researcher other researchers cite when they want to explain why hype outruns reality in this field. His May 1, 2026 blog post, titled “Will You Heed My Warnings?”, noted that some of the most reputable people in quantum hardware and error correction now believe a fault-tolerant, cryptographically relevant quantum computer “ought to be possible by around 2029.” His words, not a breathless press release.
Banking and telecom lead enterprise sectors in preparedness, with 45 to 47% of respondents in those sectors having budgeted and planned for near-term post-quantum cryptography transition. Every other sector is significantly behind.
The CTO Action Plan: What to Do in the Next 90 Days
The migration timeline math is straightforward and unforgiving. Enterprise PQC migrations realistically take 42 to 54 months from the moment an organization is properly resourced and underway. An organization that has not started a cryptographic inventory by the end of 2026 will struggle to hit NIST’s 2030 deprecation date. An organization that has not started by mid-2026 has already put Google’s 2029 internal deadline out of reach.
Step One: Cryptographic Asset Inventory
Every major guidance document from NIST, Capgemini, and Fortinet identifies this as the step that enterprises consistently skip or underestimate. You cannot migrate what you have not mapped. This means cataloguing every certificate, SSH key, code-signing key, embedded cryptographic algorithm in firmware and IoT devices, and any third-party library that handles encryption. For most large enterprises, this inventory alone takes three to six months.
This is the present-tense risk that gets underweighted because its consequences are future-tense. Nation-state adversaries are capturing encrypted traffic now and storing it for future decryption. Any data with a confidentiality shelf-life beyond approximately seven to eight years is already exposed if it is encrypted with RSA or ECC today. That includes healthcare records, defense contracts, M&A negotiations, and anything classified at the top end of most organizations’ data hierarchies. Prioritize migration of those data classes first.
Step Three: Pilot NIST-Standardized Algorithms Now
NIST finalized its first three post-quantum cryptography standards in August 2024: FIPS 203, FIPS 204, and FIPS 205. These are not draft standards. They are ready for implementation. IBM’s z16 mainframe already includes hardware acceleration for post-quantum algorithms. Microsoft has published a detailed migration roadmap targeting full PQC transition by 2033, with core infrastructure migration beginning in 2026. Use these as benchmarks and start pilot deployments in lower-risk environments this quarter.
Step Four: Update Procurement Requirements
Begin requiring CNSA 2.0 and PQC readiness clauses in vendor contracts on renewal. Build a vendor questionnaire that asks suppliers to disclose their own PQC migration plans, target dates, and which NIST-standardized algorithms their products will support and when. The January 2027 government procurement deadline will accelerate commercial vendor timelines regardless; getting this into your contracts now creates leverage and accountability.
Complete cryptographic asset inventory across all systems, firmware, and third-party libraries
Identify all data with confidentiality requirements beyond 7 years and prioritize for immediate migration planning
Pilot FIPS 203, 204, or 205 in at least one production-adjacent environment before Q4 2026
Add PQC readiness requirements to vendor contract renewals starting this quarter
Establish a crypto-agility architecture so algorithm replacement does not require full system rebuilds
Present quantum readiness status to the board or audit committee with a formal risk register entry
The Skeptic’s Case: Why 2029 Might Be Too Early
Any responsible analysis of this topic needs to include the genuine scientific minority view, and not as a dismissal of urgency but as a calibration of certainty.
Gil Kalai, a mathematician at Hebrew University of Jerusalem and one of quantum computing’s most technically rigorous skeptics, has published conjectures arguing that fundamental noise correlations in highly entangled quantum systems may make fault-tolerant quantum computing impossible, not merely difficult. His argument is not that the engineering is hard. It is that correlated errors in large quantum systems may violate assumptions that fault-tolerance proofs rely on. This is an unresolved scientific dispute, not a fringe view.
RAND Corporation’s institutional assessment places cryptanalytically relevant quantum computers in “at least the 2030s,” and RAND explicitly warns policymakers against messaging that suggests such computers could already secretly exist. A hostile actor running a cryptographically relevant quantum computer against unsuspecting victims undetected for years is, in RAND’s assessment, highly unlikely.
Even Craig Gidney, the Google researcher whose work contributed to the March 2026 ECC paper, has described the probability of a cryptographically relevant quantum computer by 2030 at roughly 10%, characterizing that level as “unacceptably high” rather than likely. Google’s 2029 internal deadline is a risk management decision at 10% probability, not a forecast that Q-Day happens in 2029.
Calibration Note
The correct framing is not “quantum computers will break encryption by 2029.” It is “the risk is high enough by 2029 that Google, Cloudflare, and Scott Aaronson now treat 2029 as the responsible deadline for completing migration, regardless of whether Q-Day arrives that early.” That is a different claim, and it supports the same action.
The practical upshot: whether Q-Day lands in 2029, 2032, or 2037, the migration timeline of 42 to 54 months means the decision about when to start is already overdue for most enterprises. The uncertainty about the threat date does not reduce urgency. It increases it, because organizations betting on the later end of the range are taking on risk they cannot adequately price.
FAQ: Post-Quantum Cryptography Migration
When will quantum computers break encryption?
Expert consensus places Q-Day, the point at which quantum computers can break RSA and ECC encryption, in the early-to-mid 2030s. However, Google and Scott Aaronson have identified 2029 as an accelerated risk window based on recent hardware progress and revised qubit estimates. This is not a prediction of Q-Day in 2029; it is a risk-management threshold that justifies completing migration before that year.
What is harvest now, decrypt later?
It is an adversarial strategy where encrypted data is intercepted and stored today with the intent to decrypt it once a sufficiently powerful quantum computer exists. Any organization whose data carries confidentiality requirements beyond seven to eight years should treat this as a current-tense risk, not a future one. Nation-state actors with long planning horizons are the primary concern.
What is CNSA 2.0 and when does it apply?
CNSA 2.0 is the NSA’s Commercial National Security Algorithm Suite, the successor to CNSA 1.0. It mandates quantum-resistant algorithms for federal national security systems. New NSS acquisitions must support CNSA 2.0 from January 1, 2027. CNSA 2.0 becomes mandatory across all National Security Systems by December 31, 2031, with full quantum resistance required by 2035 under NSM-10.
Which NIST post-quantum cryptography standards should enterprises implement?
NIST finalized three standards in August 2024: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a stateless hash-based signature scheme). These are production-ready and should be piloted in enterprise environments now, with deployment priority given to systems handling long-shelf-life confidential data first.
How many enterprises have a quantum readiness plan?
Fewer than 5% of enterprises currently have a formal quantum-transition plan, according to a peer-reviewed arXiv survey published in September 2025. Separately, ISACA’s 2025 poll found that 41% of organizations do not plan to address quantum computing at this time, and 37% have not discussed it internally at all.
How long does post-quantum cryptography migration take for a large enterprise?
Realistically, 42 to 54 months from the moment an organization is properly resourced and underway. The cryptographic asset inventory phase alone typically takes three to six months. An organization that has not started by the end of 2026 faces serious risk of failing to meet the NIST 2030 deprecation deadline, even if it begins in January 2027.
What You Know Now That Most Organizations Don’t
IBM’s quantum hardware roadmap, Google’s accelerated 2029 internal deadline, and a research paper that cut the qubit threshold for breaking elliptic curve cryptography by a factor of 20 have together changed the calculus of this field in the first half of 2026. The story is not that a quantum computer has broken encryption. It is that the organizations responsible for the internet’s security infrastructure are treating 2029 as the prudent completion date for post-quantum migration, and fewer than 5% of enterprises have a plan.
In the next 6 to 18 months, expect three things. First, government contractor compliance pressure from the January 2027 CNSA 2.0 acquisition deadline will cascade into commercial vendor roadmaps, making PQC readiness a de facto procurement requirement across more of the market than current regulations technically require. Second, more industry practitioners will follow Cloudflare and Google in publicly accelerating their timelines, creating reputational and audit risk for organizations that have not started. Third, cyber insurance underwriters and financial regulators will begin asking formal questions about quantum readiness in the same way they now ask about multi-factor authentication.
Three specific things to watch: the release of IBM’s Quantum Starling technical specs when they arrive in late 2028, NIST’s progress on IR 8547 (which addresses transitioning from currently deployed algorithms), and whether the EU’s regulatory framework develops parallel quantum-resistance mandates timed to the 2025 to 2030 NIS2 implementation period.
The organizations that complete post-quantum cryptography migration before Q-Day is demonstrably close will not win prizes. They will simply avoid the ones that do not.
Stay Ahead of What’s Coming
Get NeuralWired’s weekly briefing on quantum computing, enterprise security, and the technology decisions that matter for CTOs and CISOs.
Subscribe to The Neural Loop
AWS, Azure, and Google Cloud’s Shared Responsibility Gap Caused 61% of Enterprise Breaches in 2024
Cloud Security
AWS, Azure, and Google Cloud’s Shared Responsibility Gap Drove 61% of Enterprise Breaches in 2024
By NeuralWired Cybersecurity Desk | June 28, 2026 | 9 min read
A contract that splits security duties between a cloud provider and its customer sounds sensible in theory. In practice, that contract quietly became the most exploited gap in enterprise security, and 2024 proved it at scale. According to SentinelOne, 61% of organizations reported a major cloud security incident in 2024, up from just 24% in 2023, a 154% year-over-year surge that correlates directly with the operational confusion built into the cloud security shared responsibility model that every hyperscaler uses.
If you’re a CISO, cloud architect, or DevSecOps lead managing workloads across AWS, Azure, or Google Cloud, this article is for you specifically. Not because the model is fraudulent. It isn’t. But because the gap between what the contract says and what your team actually does is where attackers are setting up camp, and the data on dwell times, breach costs, and misconfiguration rates makes that devastatingly clear.
What the Shared Responsibility Model Actually Says
Before naming the problem, it’s worth being precise about what the model is. All three major hyperscalers operate on the same foundational principle: the provider secures “of the cloud,” the customer secures “in the cloud.”
AWS states it plainly: AWS manages security of the cloud, covering physical infrastructure, the host operating system, the virtualization layer, and networking down to the data center level. The customer assumes responsibility for the guest operating system, application software, and security group firewall configuration.
Microsoft Azure documents nearly identical logic but breaks it down further by service model. In IaaS, customers carry full responsibility for deployed applications. In PaaS and SaaS, Microsoft absorbs parts of the stack, but the customer remains responsible for application configuration, code security, and access controls. Crucially, for every deployment model without exception, the customer always owns data and identities.
That last sentence is worth reading twice. Always. Data and identities. That’s not a technicality in the fine print. It’s the front door.
Responsibility Area
AWS / Azure (IaaS)
AWS / Azure (PaaS/SaaS)
Google Cloud (Shared Fate)
Physical infrastructure
Provider
Provider
Provider
Virtualization / hypervisor
Provider
Provider
Provider
Guest OS / patching
Customer
Shared / Provider
Shared (active partnership)
Application configuration
Customer
Customer
Customer (Google advises)
Data encryption and classification
Customer
Customer
Customer
Identity and access management
Customer
Customer
Customer
Network firewall / security groups
Customer
Shared
Customer (Google advises)
The documentation is actually more transparent than critics give it credit for. AWS and Azure spell out the dividing lines with precision. The problem isn’t that providers hide this information. The problem is that most engineering teams never operationalize it, and in a multi-cloud environment where the same DevOps engineer might touch AWS Lambda, Azure App Service, and Google Cloud Run in the same sprint, the responsibility matrix shifts three times with no visible alert.
Google Cloud Breaks Ranks: Shared Fate vs. Shared Responsibility
Here’s the development that most cloud security coverage has underreported. Google has publicly, explicitly rejected the “shared responsibility” framing entirely. Not softened it. Rejected it.
Google’s official documentation describes the traditional model as drawing “a line in the sand,” arguing that this creates an “unhealthy, adversarial dynamic leading to finger-pointing and blame.” Google’s alternative is called “shared fate,” in which the company commits to not being the delineator of where its responsibility ends and the customer’s begins.
“The shared responsibility model [is] where a cloud provider runs the underlying infrastructure and is responsible for the security of that, and then on the other side of that line is what the customer is responsible for. That clearly is contractually and legally correct, but it doesn’t, in our opinion, embody the right philosophical approach for security.”
Phil Venables, CISO, Google Cloud — SDxCentral, March 2024
That’s one hyperscaler’s CISO, on record, saying the model that the other two hyperscalers still use as their official framework is philosophically inadequate for real-world security.
Our read: this is significant not as a marketing position but as a signal. When Google Cloud’s CISO goes on the record calling the shared responsibility model’s dynamics “adversarial,” they’re describing something practitioners have experienced for years. Whether “shared fate” resolves that in practice, or simply rebrands it, is an open question. But the candor itself tells you something about where the industry knows the model is breaking.
The Numbers Behind the Gap
The scale of the shared responsibility gap problem isn’t anecdotal. The data from 2024 and 2025 is specific enough to bring to a board meeting.
61%of organizations suffered a major cloud security incident in 2024, up from 24% in 2023
99%of cloud security failures through 2025 will be the customer’s fault, per Gartner’s forecast
276average days to identify and contain a breach spanning multiple cloud environments
Each of those numbers deserves context. The 61% figure from SentinelOne (measuring 2024 incidents) represents a 154% jump in a single year. That’s not a statistical blip. It tracks directly with the 88% of organizations now running hybrid or multi-cloud environments (Fortinet, 2026), each of which multiplies the responsibility matrix complexity.
Gartner’s “99% customer’s fault” forecast has circulated for nearly a decade and remained stubbornly unchallenged by AWS or Azure, which tells you something about whose interests the liability framing serves. The underlying mechanism is almost always misconfiguration: exposed storage buckets, over-permissive IAM roles, unmonitored API endpoints, and security groups left open “temporarily” until they’re not.
Key Metric for Budget Conversations
Misconfiguration-driven breaches take an average of 186 days to identify and an additional 65 days to contain, at a cost of roughly $3.86 million per incident. That dwell time number alone justifies continuous posture validation tooling in most enterprise environments.
The IBM Cost of a Data Breach Report 2025, conducted by the Ponemon Institute across 600 organizations and 3,470 security leaders in 16 countries, puts the average global breach cost at $4.44 million. For U.S. organizations, that figure climbs to $10.22 million once regulatory fines and detection costs are included. A counterintuitive finding: public cloud breaches average $4.18 million while private cloud breaches average $4.68 million, likely because hyperscalers’ investment in provider-side tooling reduces containment time on the infrastructure layers they do control.
What the providers don’t control, and what those breach costs confirm, is everything in the customer’s column: 70% of cloud breaches in 2024 originated from compromised identities, which sits squarely in customer-owned territory under every version of the shared responsibility model, including Google’s “shared fate.”
The Toyota incident from 2023 remains the cleanest proof point. A misconfiguration, not a provider infrastructure failure, exposed data on approximately 260,000 customers across two separate disclosures. The exposure persisted for over seven years before detection. That’s the real-world illustration of a 276-day dwell time: customer-side gap, customer-owned data, customer’s fault, years of blind spot.
Where the Model Breaks Down in Practice
The documentation is clear. The failure is operational. Here’s specifically where the breakdown happens at the team level.
Multi-cloud multiplies the matrix
88% of enterprises now run hybrid or multi-cloud architectures. That means the same security architect who understands the AWS shared responsibility model for EC2 must mentally context-switch to a different matrix for Azure App Service, and again for Google Cloud Run, often within the same week. Each abstraction level (IaaS to PaaS to serverless) shifts the provider-customer boundary, and there’s no automated notification when it moves.
IAM sprawl is the direct consequence
Identity is always the customer’s responsibility. But in a multi-cloud, multi-team environment, IAM configurations accumulate technical debt faster than any other security control. Over-permissive roles granted for a deployment sprint six months ago become the attack vector next year. The 70% of breaches originating from compromised identities isn’t surprising once you map it to this operational reality.
The “temporary” configuration problem
Security groups opened for testing. S3 buckets left public for a data pipeline handoff. Firewall rules adjusted for a migration and never reverted. These aren’t ignorance failures. They’re process failures, and they occur in teams that know the shared responsibility model perfectly well. Knowing who owns something doesn’t guarantee it gets done.
“The complexity of cloud environments makes it difficult to maintain visibility and control, while reliance on third-party services introduces additional risks.”
Oli Buckley, Professor of Cyber Security, Loughborough University — Infosecurity Europe
Buckley has separately argued that the shared responsibility model is one of the main weaknesses in cloud security, not because CSPs hide their infrastructure security failures, but because the framework gives organizations a false ceiling. Once the boundary is defined, teams often treat their side as something to audit at deployment rather than something to validate continuously.
AI workloads are propagating the gap before the original one closes
Microsoft and Google have both published “AI shared responsibility” addenda, extending the same dividing-line model into AI workloads: prompt injection prevention, model integrity, and training data governance. The customer-side obligations here are even less understood than the original cloud model, and most organizations don’t have the governance tooling to enforce them. IBM’s Cost of a Data Breach Report 2025 found that 61% of organizations lack AI governance technologies altogether, and only 34% of those with policies conduct regular audits for unsanctioned AI usage.
The Critical View: “Shared” Is Doing Too Much Work
The sharpest critique of the shared responsibility model isn’t that it’s wrong. It’s that the word “shared” is misleading about the nature of the arrangement.
“Shared responsibility models are absolutely part of the answer, but also part of the problem. Clearly defining who is responsible for what is complex. A shared responsibility model might suggest you can negotiate the terms and decide where each responsibility lies, but this is misleading. Hyperscalers generally just describe where their own responsibility lies.”
Sander Nieuwenhuis, GRC Advisory Global Lead, Nordcloud
Nieuwenhuis’s framing is the most structurally honest critique available. What gets called a “shared” model is actually a unilateral declaration by the provider about what they will and won’t cover. Customers don’t negotiate the boundaries. They inherit them. And because the boundaries shift by service type, by deployment model, and by abstraction level, the practical effect is that organizations are responsible for a moving line they didn’t draw.
Google’s “shared fate” rebranding addresses the adversarial tone of the original. But Nordcloud’s critique applies there too: “shared fate” could set the wrong expectation in the opposite direction, implying that you should trust the other party to do the right thing, when what regulated industries actually need is documented governance that goes far beyond fate. In healthcare, finance, and critical infrastructure, “we’ll figure it out together” is not a compliance posture.
There’s also a commercial incentive layered into this debate that practitioners should keep in mind. The lion’s share of “shared responsibility gap” literature is produced by security vendors selling CSPM, CNAPP, and IaC scanning tools. The Wiz reports, the CrowdStrike state-of-the-cloud documents, the SentinelOne statistics roundups: these are directionally accurate, but they’re not neutral. Treat the direction as real and the precision with appropriate skepticism.
What CISOs Should Actually Do Now
The shared responsibility model isn’t going away. AWS and Azure’s documentation is unusually precise, and the underlying logic of splitting infrastructure from configuration ownership is sound. What has to change is operationalization.
Build per-service responsibility documentation
For every cloud service in your environment, document the boundary explicitly: what the provider owns, what your team owns, and who on your team owns it. This is tedious and non-automated. It’s also the only way to prevent “I thought they handled that” from becoming your breach postmortem’s opening line.
Treat IAM as a continuous control, not a deployment-time check
70% of cloud breaches start with compromised identities. If your IAM review cadence is quarterly or annual, you’re validating a configuration that may have drifted significantly since the last audit. Continuous CIEM tooling, with alerting on privilege escalation and dormant high-permission accounts, is the direct operational response to the data.
Price the dwell time into your tooling budget
Misconfiguration-driven breaches average 186 days to detect and cost $3.86 million. That’s the number to put in front of a CFO when requesting CSPM tooling budget. The math on continuous posture validation versus one breach contained 50 days earlier is not close.
Watch Google’s “shared fate” model carefully
Google’s explicit break from the “shared responsibility” framing is the first time a major hyperscaler has publicly acknowledged the model’s philosophical inadequacy. Whether AWS and Azure follow, whether through language or through actual shifts in default configurations and tooling, will define the next evolution of cloud security architecture. CISOs evaluating multi-cloud strategy should treat Google’s position as a genuine industry signal, not as a sales pitch.
What is the shared responsibility model in cloud security?
It’s the framework dividing security duties between cloud provider and customer. The provider secures “of the cloud,” meaning physical infrastructure, hardware, and virtualization. The customer secures “in the cloud,” meaning data, identities, applications, and configuration. AWS, Azure, and Google Cloud each publish their own version, with boundaries that shift depending on whether you’re using IaaS, PaaS, or SaaS services.
Who is responsible for security in AWS, Azure, or Google Cloud?
All three split responsibility by service type. In IaaS, customers manage significantly more, including the OS, patching, and network rules. In PaaS and SaaS, the provider absorbs more of the stack. One boundary remains constant across all three and all service models: the customer always owns data and identity. Google Cloud alone rejects the “line in the sand” framing, calling its alternative model “shared fate.”
Why do most cloud breaches happen if providers secure the infrastructure?
Because the infrastructure is not where most breaches occur. Gartner projected that through 2025, 99% of cloud security failures would be the customer’s fault, driven primarily by misconfiguration, weak IAM, and unmonitored access controls rather than provider-side infrastructure compromise. The 61% breach rate surge in 2024 reflects customer-side execution failures, not provider failures.
What is Google Cloud’s “shared fate” model?
Google’s alternative to the traditional shared responsibility model, in which Google commits not to act as a hard delineator between its security obligations and the customer’s. Instead, it partners more actively on secure-by-default configurations and customer security outcomes. Google Cloud CISO Phil Venables has called the traditional shared responsibility model contractually correct but philosophically inadequate for real-world security partnerships.
What is the average cost of a cloud security breach in 2025?
The IBM Cost of a Data Breach Report 2025, covering 600 organizations across 16 countries, puts the global average at $4.44 million. U.S. organizations average $10.22 million when regulatory fines and extended detection costs are included. Misconfiguration-driven breaches specifically average $3.86 million and take 186 days to identify plus 65 more to contain.
How can organizations close the shared responsibility gap?
The most effective starting points are per-service responsibility documentation, continuous IAM review rather than periodic audits, and cloud security posture management tooling to detect misconfigurations before they become dwell-time events. The core shift is treating the shared responsibility boundary as a live, continuously validated control rather than a contractual fact you read once during onboarding.
Where This Goes in the Next 12 to 18 Months
Three things to watch closely.
First, the AI shared responsibility extension. Microsoft and Google have already published AI-specific addenda to their shared responsibility models, covering prompt injection, model integrity, and training data governance. These are areas where customer-side obligations are even less understood than the original cloud model, and the governance tooling to enforce them barely exists at enterprise scale. The 61% of organizations lacking AI governance technologies will become a breach statistic inside the next 18 months.
Second, whether AWS and Azure adopt any of Google’s “shared fate” language, or more importantly, whether they back it with default-secure configurations that reduce the operational burden on customers. The philosophical debate is secondary to whether providers start shipping services that are misconfiguration-resistant by default rather than misconfiguration-prone by default.
Third, the regulatory response. As cloud breaches continue to accelerate, the 45% of all data breaches now occurring in cloud environments will draw regulatory attention to the shared responsibility model itself. Whether GDPR enforcement actions, SEC cybersecurity disclosure requirements, or sector-specific rules start holding customers accountable for model misunderstanding versus willful negligence will shape how enterprises document and audit their responsibility boundaries.
The shared responsibility model is not a broken concept. It’s an under-operationalized one. The gap isn’t in the contract. It’s in the space between what the contract says and what your team does on a Tuesday afternoon during a production incident. That gap is where 61% of 2024’s cloud breaches lived. Closing it doesn’t require a new model. It requires treating the existing one as a living operational document rather than a one-time compliance checkbox.
