All posts by Kari Wilson

Why Your Computer Backup Strategy Determines Whether You Pay the Ransom

2026-10-07 Kari Wilson

Post Syndicated from Kari Wilson original https://www.backblaze.com/blog/why-your-computer-backup-strategy-determines-whether-you-pay-the-ransom/

An illustration of a laptop connected to a cloud and a datacenter stack.

Most IT teams feel ready for a ransomware attack. Almost none of them actually are.

A Veeam survey of more than 900 senior IT, security, and risk leaders found that 90% are confident they can recover from a cyber incident. But among organizations hit by ransomware that affected their operations or data, only 28% fully recovered it, and 44% got back less than three-quarters.

That gap is really a gap in backup architecture, not incident response. Ransomware recovery doesn’t come down to how good your plan looks on paper. It comes down to whether your computer backup was built to survive the attack in the first place, and that’s a question worth asking about your endpoints specifically, not just your servers or your cloud storage.

Ransomware goes after your backup before it goes after you

Attackers know backups are the way out, so they target them directly. Veeam’s own data protection research puts the number at 96% of ransomware attacks specifically going after backup repositories, and most of those attempts succeed. A backup that anyone, including an attacker with stolen credentials, can delete or shorten the retention on isn’t a recovery plan. It’s a second target.

This is why deleted file retention and restore permissions matter more than almost anything else here. If a device gets wiped, or an attacker with admin-level access tries to clear out backup history, that data needs to stay recoverable regardless. Backblaze Computer Backup keeps a full year of version history and deleted file retention, and restore and deletion permissions sit with IT centrally, not open at the device level for anyone to touch.

Plenty of legacy endpoint backup tools technically support long retention windows too. The gap can show up at restore time, with heavier clients and more complicated restores. A feature on a spec sheet and a restore that works under pressure are two different things.

If you don’t know who can delete backup history or shorten retention on your current setup, find that out now. Not during an incident.

How far back does your version history actually go?

Ransomware doesn’t always announce itself right away. Some strains sit quietly on a network for weeks, copying and encrypting slowly, before anyone notices. By the time you catch it, your “recent” backup might already be infected.

This is where version history does the real work. If your backup only keeps a few days of history, and the infection has been running for two weeks, you don’t have a clean version to restore to. You have a slightly newer copy of the same problem. This is a common gap with the cloud sync tools plenty of businesses lean on instead of real backup: sync tools keep limited version history that varies by plan, which is fine for undoing an accidental edit and not much else.

One IT director put it plainly when comparing what he had before to what he has now: a full year of version history against a prior vendor’s three-day maximum. His point was simple. The extra retention is what actually lets you go back far enough to find a version worth restoring.

Short retention windows often get sold as a way to keep storage costs down. In practice, they’re one of the more common reasons recovery fails. You don’t find out your version history was too short until you need a version that isn’t there anymore.

Why legal hold has to be part of this conversation

A ransomware incident often triggers more than a technical response. Insurance claims, regulatory questions, sometimes litigation. All of that requires you to preserve data exactly as it was, separate from your normal backup retention rules.

That’s what legal hold is for (available with Computer Backup with Enterprise Controls). It preserves a device’s backed up data beyond your standard retention window. It’s a different function from version history. Version history lets you go back in time. Legal hold freezes a specific point and keeps it there.

The mistake we see most often: IT and legal never talked about this until the middle of an actual incident. By then, you’re improvising a process that should’ve been decided in advance. Decide in advance when a hold would be triggered, and who in IT and legal makes that call.

Endpoints are where recovery actually happens

Company-wide backup policy is one thing. Restoring 40, 100, or 300 individual laptops without your entire IT team dropping everything else is a different problem.

This is where a lot of recovery plans fall apart. They’re written at the policy level and never tested at the device level, and a heavier, more complex client makes that worse under pressure. A few things worth knowing before you’re in the middle of it:

Can you restore a single file without pulling down an entire device image?
Can you restore an entire device to a new machine if the original is unusable?
Who has permission to approve and run a restore, and is that list accurate right now?
For a mass-restore situation across dozens of devices, does your vendor offer any option beyond restoring one machine at a time, like a physical drive shipped with the data preloaded?

These aren’t edge cases. They’re the actual mechanics of recovery, and they’re worth walking through before an attack, not during one.

What recovery looks like at different scales

Here’s roughly what recovery timelines look like in practice, depending on scope:

A single file or folder: depends on whether your version history goes back far enough to find a clean copy.
A single device: depends on the size of the data, your bandwidth, and whether restore access is already sorted out.
A full fleet, dozens to hundreds of devices: this is where things slow down. Restoring machine by machine can take days. Some vendors, including Backblaze, can ship a physical drive preloaded with your data to cut that down significantly.

Only 9% of IT teams describe restoring from backup as “very easy,” according to Backblaze’s State of the Backup Report. Most people find out how hard restoring actually is right when they need it to work.

If you don’t know how you’d handle each of these, that’s worth working out before an incident.

How to pressure test your recovery plan

Everything above is a checklist. Here’s the part that separates a real recovery plan from a hopeful one: walk through a restore on paper, from start to finish, for one real laptop.

Name the device, the person who approves the restore, the person who runs it, and where the data goes. Write down each step and where it could stall.

A vendor’s feature list can tell you whether version history, deleted file retention, legal hold, and endpoint-level restore are technically available. It can’t tell you whether your team knows how to use them under pressure. Walking through the steps, and testing with your vendor’s team in a proof of concept, is how you find the gaps.

Where this leaves your computer backup strategy

Paying a ransom was never a guaranteed fix, and the odds haven’t gotten better. What has changed is how much control you actually have over the outcome, and that control lives almost entirely in your backup architecture, not your incident response plan.

This is also where a lot of endpoint backup tools quietly stop being enough. Some keep only a short version history, like many sync tools. Others price by storage, so a ransomware-driven spike in data or a slow migration off a legacy tool turns into an unplanned bill on top of an already bad week. And a fair number were built for Windows first and adapted for Mac later, which shows up as friction the moment you’re deploying or restoring across a Mac-heavy fleet.

Backblaze Computer Backup with Enterprise Control is built around the specific gaps this post walks through: a full year of version history and deleted file retention, Legal Hold to preserve data beyond standard retention, and restores managed by IT from the admin console. It’s native to Mac and Windows and deploys through Jamf, Iru (formerly Kandji), and Addigy. Pricing is flat per device with no per-GB surprises. None of it replaces good security practices. But it goes a long way toward deciding whether ransomware turns into a bad week or a bad year.

If you haven’t walked through your restore process recently, start there. Pick one machine and map it out this week.

Want to go through it with us? Talk to our team.

The post Why Your Computer Backup Strategy Determines Whether You Pay the Ransom appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

What IT Teams Get Wrong About Immutable Backups and Object Lock

2026-09-22 Kari Wilson

Post Syndicated from Kari Wilson original https://www.backblaze.com/blog/what-it-teams-get-wrong-about-immutable-backups-and-object-lock/

An illustration of laptops and security badges

If you’ve spent any time configuring immutable backups, you’ve probably hit at least one of these moments: you thought the data was protected, something went wrong, and the protection wasn’t quite what you expected. Object lock is one of the most misunderstood features in cloud storage, and the gap between “I enabled it” and “it’s actually working correctly” is where most mistakes live.

This is a collection of the real issues that come up in technical conversations with IT administrators and system architects, the kind of problems that surface after the documentation has been read but before the configuration is fully trusted.

Join Zach Lewis—CIO/CISO at the University of Health Sciences & Pharmacy and author of Locked Up—for a candid fireside chat on what really happens during a modern ransomware attack.

Watch the webinar

The Difference Between Immutability and Encryption

These two features often get lumped together as “data security,” but they protect against completely different threats.

Encryption protects people from seeing your data. Object lock protects people from deleting it. An encrypted backup that an attacker can wipe is not a recovery option. An immutable backup that an attacker can read in plaintext is still a usable recovery point.

Both matter. They serve different functions. Treating them as interchangeable is how organizations end up with gaps in one direction or the other.

Immutable Does Not Mean Inaccessible

This one causes real hesitation when IT teams are evaluating immutability for production backup workflows. The concern is that locking data will make it unavailable for restores.

It won’t.

Immutable data is fully readable and downloadable throughout the immutability period. You can restore from it, access individual files, and upload new versions alongside the protected ones. The only thing object lock prevents is modification and deletion before the immutability period expires. That’s the whole point.

The Bucket Creation Problem

With Backblaze B2, object lock can be enabled at bucket creation or added to an existing bucket later. Once enabled, it cannot be turned off, so the change is permanent in that direction.

That said, enabling object lock on an existing bucket does not retroactively protect the files already in it. Only files uploaded or copied into the bucket after object lock is enabled are eligible to be locked. Files that were there before are unaffected.

The practical implication: if you’re adding object lock to a bucket with existing backups, don’t assume those older files are now protected. They aren’t. New backups written after the change will be, but anything already sitting in the bucket requires individual lock settings to be applied manually.

Who Actually Configures the Retention Period

There’s a common assumption that immutability is configured at the bucket level. For many backup applications, that’s only half the picture.

When you’re using Veeam or similar enterprise tools, the backup application manages object lock on a per-file basis. The bucket needs to have object lock enabled as a capability, but the application controls which files get locked and for how long. Think of the bucket setting as opening the door; the backup software decides what walks through it.

This means both sides need to be configured. Object lock enabled on the bucket, and immutability enabled within the backup application. One without the other does nothing.

Retention Period vs. Immutability Period

These are separate settings that operate independently.

A four-year retention policy means your backup application keeps the data for four years. A 14-day immutability period means files cannot be deleted or modified for 14 days after they’re written. Once the 14 days expire, the object lock is released. The file is still there, governed by your retention policy, but it’s no longer immutable.

The two settings don’t need to match. A typical setup runs a long retention policy with a shorter immutability window. The immutability window covers the period when ransomware or a malicious actor is most likely to attempt deletion. Once that window passes, normal retention rules apply.

How Long Should the Immutability Period Be?

The most common recommendation is 7 to 14 days, with 14 days being a reasonable default for most environments.

The logic is straightforward: if ransomware or an attack hits your environment, you’re going to know within hours, maybe a couple of days. The immutability period doesn’t need to cover months of potential compromise. It needs to cover the window between when an attack occurs and when you detect and respond to it.

For most organizations, 14 days is more than sufficient. Security teams that have tested their incident response workflows often find 7 days works fine. The point is aligning the period with your detection capability, not maximizing it arbitrarily.

There’s also a cost angle that’s easy to miss. Every time backup software writes or renews an object lock, it makes a PUT-class API call to update the retention metadata on that object. On AWS S3, those calls are billed as standard PUT requests at $0.005 per 1,000. In large environments with frequent backup jobs, those transaction fees accumulate. Backblaze B2 doesn’t charge for PUT requests, so lock writes and renewals are included with your storage. In practice, this means shorter immutability windows don’t carry a cost penalty on B2, and there’s no incentive to minimize lock renewals to reduce your API bill.

Veeam Quietly Extends Your Immutability Period

If you configure a 7-day immutability period in Veeam and then check the actual lock expiration dates in your bucket, don’t be surprised to see files locked through day 10, 14, or even 17. Veeam adds extra days to the immutability period beyond whatever you configure.

This is intentional behavior. Veeam is protecting against the scenario where a file is written late in a backup job, and a retention cleanup operation would otherwise try to delete it before the immutability period has fully elapsed. The extra days create buffer.

The practical implication is storage capacity planning. If you’re budgeting for 7 days of immutable storage, you may actually need to account for closer to 14 days of data that can’t be deleted at any given time. Plan for that variance.

Don’t Set Bucket Lifecycle Rules When Using Backup Software

Bucket-level lifecycle rules that automatically delete data based on age or other criteria will conflict with how backup applications manage their own data lifecycle.

When you let Veeam or another application handle your backup chain, that application tracks which files are active, which are expired, and when each should be removed. If you set a bucket lifecycle rule that deletes files after 30 days, and your backup application is still referencing a file that’s 32 days old, you’ve broken the chain.

The right approach is to leave bucket lifecycle rules alone and let the backup software handle all data management. If your backup application is working correctly, there’s no need for bucket-level deletion rules. If something isn’t working correctly, a lifecycle rule will compound the problem.

Not All Backup Software Supports Object Lock

Consumer sync tools and basic file backup applications generally don’t support immutable backups. When they encounter an immutable object, the write operation to delete or modify it will fail, which breaks the backup job.

Enterprise backup applications like Veeam and Commvault have native support for object lock. They know how to write immutability flags, manage retention periods, and handle the S3 API calls correctly.

If your current backup tool isn’t on the enterprise list, check the documentation before assuming immutability will work. A backup chain that fails silently because of incompatible object lock handling isn’t protecting anything.

Can You Change the Immutability Period After Setting It?

You can extend it. You cannot shorten it.

Once an object is locked with a specific expiration date, that date can only move forward. This is a deliberate design constraint: the whole value of immutability is that it can’t be weakened retroactively. If a compromised account or a bad actor could shorten or remove the lock, the protection would be meaningless.

The same principle applies to governance mode versus compliance mode configurations. Compliance mode makes data deletion impossible even for account administrators during the retention period. Governance mode allows certain privileged users to modify the lock. For serious ransomware protection, compliance mode is generally the stronger choice.

What Happens If Someone Deletes the Account?

This is the limit of what object lock protects against, and it’s worth understanding clearly.

Object lock prevents any individual from deleting immutable objects within your account. Even an administrator with full permissions cannot delete a locked object before its retention period expires.

However, if someone with account-level access deletes the entire account, that protection doesn’t save the data. This applies to every cloud storage provider, not just Backblaze. It’s not a gap in object lock, it’s a different attack surface entirely.

The mitigation here is account security: two-factor authentication, limited administrative privileges, and monitoring for unusual account activity. Object lock and account security work together. Neither one makes the other redundant.

Does Immutability Cost Extra?

With Backblaze B2, no. Immutability is included as part of the standard storage subscription.

This is worth noting because some storage providers charge separately for object lock API calls, including the PUT requests that renew or write lock metadata. Those transaction fees can add up significantly in environments with high file counts or frequent lock renewals. With B2, you pay for the storage you use, including any additional storage consumed by data that can’t be deleted during its immutability period. The feature itself has no surcharge.

Versioning and Storage Costs

If you enable versioning alongside immutability, all versions of a file count toward your storage usage, not just the current one. If a file has been modified 50 times and you’re storing 50 versions, you’re paying for all 50 regardless of how many of them are currently immutable.

This is consistent across cloud storage providers and is the tradeoff for having granular recovery options. The right versioning configuration depends on your recovery objectives and your budget. Keeping every version indefinitely is rarely necessary. Most backup applications give you control over how many versions to retain, and that setting directly affects your storage costs.

What to Do Before You Deploy

A few things worth confirming before putting object lock into production:

First, verify that your backup application has native object lock support and that you’ve enabled immutability within the application settings, not just at the bucket level.
Second, create your bucket with object lock enabled even if you’re not planning to use it on day one. You can’t go back and enable it later.
Third, skip bucket lifecycle rules if your backup software is managing the data lifecycle. Let the application do its job.
Fourth, account for Veeam’s extra days when planning storage capacity. The actual locked window will be longer than what you configure.
Fifth, review your immutability period in the context of your incident detection capability. A 30-day immutability window isn’t more secure than a 14-day window if your security team can detect an incident within 48 hours.

Object lock is one of the more reliable tools available for protecting backup data against ransomware. It does what it claims. The configurations above are where implementations go wrong, and most of them are easy to get right once you know where to look.

The post What IT Teams Get Wrong About Immutable Backups and Object Lock appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Zero-Touch or It Doesn’t Scale: The New Standard for Mac Fleet Backup

2026-09-17 Kari Wilson

Post Syndicated from Kari Wilson original https://www.backblaze.com/blog/zero-touch-or-it-doesnt-scale-the-new-standard-for-mac-fleet-backup/

A decorative image showing a server, a NAS, and a computer.

Ask any IT director managing a Mac fleet above 50 devices what they need from a backup tool and you’ll hear the same answer before you finish the question. Silent install. Jamf deployment. No prompts. No user interaction. The requirement has been on every evaluation checklist for years, but something has shifted: IT teams have stopped treating it as a preference and started treating it as a filter. Either a tool deploys cleanly through their MDM or it doesn’t make the shortlist. Full stop.

This isn’t pickiness. It’s the only logical position for teams managing hundreds of machines with two or three people.

The Adaptation Problem

Most backup software was built for Windows. The Mac client came later, ported and adapted to work. That history shows up in ways that don’t matter much in a consumer context but matter enormously in a managed fleet.

Mac IT teams running Jamf Pro, Kandji, or Addigy have built their entire operating model around scripted automation. They don’t log into machines. A new hire’s laptop is enrolled, configured, and production-ready before the person sits down. Software appears on machines through policy, not support tickets.

When backup software was designed for a world where someone clicks through an installer, it fights that model at every step. Permission dialogs surface on end user screens. Enrollment fails to register under the provisioned account. The agent installs but doesn’t actually start backing up. Each of these is a support ticket at minimum and an unprotected machine at worst. The IT team ends up owning a third-party deployment problem indefinitely, patching around a script that should have worked out of the box. That’s where Windows-first adaptation gets you.

The Mac backup market has also thinned out in ways that matter. Several vendors that once had credible Mac products have wound down, been acquired, or shifted focus to enterprise platforms where Mac support is a checkbox rather than a priority. Teams that built workflows around those products are now evaluating replacements, often under time pressure, and finding that the field of tools that actually understand Mac MDM is narrower than it looks.

What Silent Actually Means

“Silent install” appears in the marketing materials of practically every backup vendor. It means different things to different people.

For most Mac admins, truly silent means the agent installs, configures itself, handles all required system permissions through MDM profiles, registers under the correct provisioned user, and starts backing up, without a single prompt appearing on the end user’s screen and without any post-install action required from IT. Nobody knows it happened. Nobody has to do anything.

The gap between that definition and what some vendors deliver is where fleet coverage breaks down. Full disk access approvals that surface as user-facing dialogs. Kernel extension prompts that require user confirmation. Background item notifications that confuse employees and generate help desk calls. Each of these seems minor in isolation. Across a 300-machine fleet during a busy onboarding week, they add up to a coverage gap you won’t discover until someone needs a restore.

When it works correctly, employees never know it’s there. Nobody files a ticket about it. Nobody asks IT what the new icon is. That’s the bar.

Backblaze Computer Backup deploys silently through Jamf Pro, Kandji, Addigy, and other MDM platforms via CLI scripts. Pre-built deployment scripts are available on GitHub. Full disk access and system permissions are configured through MDM profiles pushed alongside the agent, with no end user interaction required and no post-install steps for IT. For most Jamf environments, the pre-built script requires nothing more than editing a few variables before it’s ready to push.

There’s also a pricing angle here that doesn’t come up enough: backup tools that require manual or user-assisted enrollment tend to leave machines uncovered. Machines that aren’t backed up still cost money in the per-seat model. You’re paying for protection that isn’t running. With flat per-device pricing and no storage-based overages, there’s no financial incentive to under-enroll, but the only way to ensure complete enrollment is deployment that doesn’t depend on human action.

When Coverage Gaps Cost Real Money

The efficiency argument for zero-touch deployment is intuitive. The cost argument is less obvious until something goes wrong.

A firmware bug bricks five machines. A designer spills coffee on their laptop two days before a pitch. A ransomware event starts encrypting files on devices that weren’t fully enrolled because someone skipped the setup step during a chaotic onboarding month. In every case, the recovery outcome depends on one thing: whether that specific machine was actually backed up.

Professional data recovery for a single device can run anywhere from $1,500 to $5,000 for physical damage scenarios, and that’s before factoring in downtime. For an organization that hits two or three incidents in a year, that’s real budget, often more than the cost of backing up the entire fleet. The backup subscription would have cost a fraction of that, but only if the machines were enrolled. That’s the variable zero-touch controls.

It’s also worth noting what happens to data when employees leave. Organizations with any compliance exposure, and that’s most of them, need endpoint data preserved at offboarding, not just when hardware fails. A deployment model that requires user action to complete enrollment is also a model where departing employees can have gaps in their backup history, exactly when you need it most. Legal Hold is part of the picture here: knowing you can freeze and preserve a former employee’s data only matters if their machine was backed up in the first place.

From unreliable jobsite Wi-Fi to laptops damaged by bulldozers, Torcon’s IT team faces some unusual backup challenges. See how Backblaze Computer Backup protects employees across 20–40 active construction sites—and has supported more than 100 successful recoveries.

Read how Torcon did it

A single-office organization can paper over a bad deployment model with physical presence. Somebody can walk the floor during an onboarding week and catch machines that didn’t enroll. Distributed teams don’t have that option.

If a new hire in Buenos Aires starts on Monday, nobody from IT is walking to their desk on Tuesday to finish a backup enrollment. The same is true for remote employees across time zones, contractors working from client sites, or a newly acquired office that runs through a separate MDM instance. The tool has to work identically everywhere without requiring a different procedure for each location.

This is where the single-account, multi-group model matters. Backblaze Computer Backup lets distributed organizations manage devices across regions under one account, with separate groups reflecting different offices, compliance zones, or MDM environments. Data residency requirements, increasingly common for organizations with EU presence, can be addressed by running region-specific accounts while maintaining unified admin visibility. The deployment script doesn’t change based on geography. The admin experience doesn’t change based on which MDM platform enrolled the device.

The Evaluation Question Nobody Asks First

Most backup evaluations start with features or pricing. That’s backwards for Mac fleets.

The right first question is: show me the deployment documentation. Ask whether the install is truly silent or requires any user-facing steps. Ask what happens when the script runs on a machine that’s already enrolled. Ask whether the same approach works across different MDM platforms. Ask for a reference from a customer running a comparable fleet size.

If a vendor built their product for Mac fleet management, those answers come quickly and confidently. If they built for Windows and adapted, the answers tend to involve workarounds, known issues, or a suggestion to open a support ticket.

Zero-touch Mac backup deployment isn’t a differentiator anymore. It’s the entrance fee. Any tool that can’t clear that bar is asking you to manage a backup system on top of managing your fleet, and that’s not a trade-off a lean IT team can afford.

Get started with Backblaze Computer Backup →

Backblaze Computer Backup with Enterprise Control supports silent deployment through Jamf Pro, Kandji, Addigy, Microsoft Intune, and other MDM platforms via CLI scripts. Pre-built deployment scripts are available on GitHub.

The post Zero-Touch or It Doesn’t Scale: The New Standard for Mac Fleet Backup appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Code42 Is Shutting Down. Is CrashPlan the Safe Choice, or Just the Convenient One?

2026-09-01 Kari Wilson

Post Syndicated from Kari Wilson original https://www.backblaze.com/blog/code42-is-shutting-down-is-crashplan-the-safe-choice-or-just-the-convenient-one/

A gradient with logos for Code42 and Crashplan

Your Code42 renewal notice showed up with different news this year. New sales stopped at the end of 2025. Support ends at the end of 2026. After that, your backup archives get deleted.

So you start looking for a replacement, and the first name that comes up is CrashPlan.

Makes sense. Same lineage. Familiar interface. Probably assumes it’s the safe, low-effort choice, since it’s basically still Code42, right?

Not quite. And that assumption is worth slowing down on before it makes the decision for you.

CrashPlan and Code42 stopped being the same company in 2022

Code42 didn’t rebrand into CrashPlan. It sold it.

In 2022, Code42 spun off its backup business to Mill Point Capital, a private equity firm, and kept the name Code42 for what remained: Incydr, its insider risk and data loss prevention product. The backup product you knew went with the spinoff and became CrashPlan Group, a separate company under separate ownership with its own board, its own P&L, and its own reasons for making decisions.

Code42 itself was later acquired by Mimecast, which is why the backup add-on still bundled with Incydr is now the thing getting discontinued.

Two different companies. Two different endings. One of them just happens to still have “Code42” written all over your IT team’s institutional memory.

Why that matters more than it sounds like it should

If CrashPlan were still part of Code42, you could reasonably treat this as an internal product transition. A new plan, maybe a new UI, but the same company standing behind the decision.

It isn’t that. CrashPlan is a separate company that stands to gain from every Code42 customer who defaults to them without comparing alternatives. That’s not a knock on CrashPlan. It’s just how the incentive is built. A company selling you the “next step” isn’t the same thing as a neutral party recommending your best option.

Which is exactly why CrashPlan has built migration tooling specifically aimed at capturing displaced Code42 customers. It’s a smart move on their part. It’s also a reason to look closer, not a reason to skip the evaluation.

The 5TB cap nobody’s mentioning

Here’s something worth checking before you assume CrashPlan is a like-for-like replacement: some of its plans now cap storage at 5TB.

If you were on Code42 for straightforward, unlimited endpoint backup, that’s a meaningful change, not a rounding error. Plenty of IT teams don’t find out about a storage ceiling until they hit it, usually mid-migration, usually at the worst possible time to discover a gap.

Ask directly. Get the number in writing. Don’t assume “backup” means the same thing across two different companies just because one of them used to own the other.

“Enterprise data resilience” is not the same pitch as “backup”

CrashPlan has also been repositioning its messaging, moving from straightforward backup language toward broader “enterprise data resilience” positioning.

That’s not necessarily bad. It might be exactly what some organizations need. But it’s a different product story than the one you signed up for with Code42, and different stories tend to come with different pricing, different complexity, and different things bundled in whether you asked for them or not.

If what you actually need is dependable endpoint backup, a platform that’s busy becoming something bigger isn’t automatically the simpler choice. Sometimes it’s the more expensive one wearing a more ambitious name.

The question worth asking before you default to anything

Not just about CrashPlan. About whatever you’re evaluating next.

Who owns this company, and what are they optimizing for? What happens to my data and my pricing if this company gets acquired, repositioned, or sunset the way Code42’s backup product just was? Is this the vendor I’m choosing on the merits, or the one I’m choosing because switching again sounds exhausting?

That last one is real, and nobody should pretend it isn’t. Migration fatigue is a legitimate reason people make worse decisions than they would otherwise. It’s also exactly the moment worth a second look, not a shortcut.

What we’d suggest instead

Compare CrashPlan against your actual requirements, not against the assumption that it’s the default successor. Ask about storage limits in writing. Ask what “enterprise data resilience” costs versus what plain backup used to cost. And give yourself enough runway to compare more than one option, because a rushed decision made under a vendor’s deadline is usually the vendor’s deadline working exactly as intended.

If you want a second option in that comparison, we put together a migration guide that walks through what a Code42 replacement looks like on Backblaze specifically, including a realistic week-by-week timeline that doesn’t leave you without protected data at any point in the switch. Backblaze Computer Backup runs a lightweight native client and deploys silently through the MDM tools most IT teams already use, so the evaluation itself is quick even if the decision takes longer. It’s not the only option out there. It’s just one worth putting next to the others before you pick anything.

Migrating off Code42 and want to see how the timeline actually works? Talk to our team about what it would take to move your environment to Backblaze.

The post Code42 Is Shutting Down. Is CrashPlan the Safe Choice, or Just the Convenient One? appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Jamf Administrators: Your Backup Deployment Just Got Simpler

2026-08-19 Kari Wilson

Post Syndicated from Kari Wilson original https://www.backblaze.com/blog/jamf-administrators-your-backup-deployment-just-got-simpler/

A decorative image showing computer and user icons.

If you’re running a Mac fleet, Jamf is often where everything starts. It handles provisioning, policies, app installs——the orchestration that keeps your fleet sane. But backup is the thing that doesn’t fit. Jamf gives you control over every Mac, but it doesn’t protect the data on them. Backblaze closes that gap without changing how your team works.

Join Solution Engineers from Jamf and Backblaze for a practical discussion on building a complete Mac protection strategy.

The device ownership problem

Either you know who owns every device upfront (rare), or you don’t (common). Most teams end up doing some mix: devices that came pre-assigned, devices still waiting for user mapping, devices that migrated between teams. You write a script to fix it, then another to catch the next variation. Three months later, you’re not sure if every device is actually backed up or just supposed to be.

The new solution: Two ways to match devices to users. Pick the one that matches your reality.

This update solves the core friction: you don’t have to choose one deployment model anymore.

Method 1: Fixed email (for controlled environments) If you already know who owns each device at install time, for example, if you have clean HR data synced to Jamf, you can pass the user email directly during deployment. The installer uses it to set up the account automatically. No guessing, no drift.

Method 2: Dynamic user detection (for real-world environments) If you don’t have clean data upfront (e.g. when new devices arrive, get imaged, and wait for assignment) the installer waits until a user logs in. Once a user signs in, Backblaze can automatically associate the device with the appropriate user account based on the deployment configuration and identity information available on the device. This reduces the need for manual user assignment and helps prevent devices from being left unprotected.

Or mix them: some devices get email, others get dynamic detection. The system can now handle both in the same deployment.

What this means for your workflow

You push the Backblaze installer through a Jamf policy, same as any other app. Set your preferred method (fixed or dynamic) once at the group level, then let it run. Devices show up in the Backblaze console under the right user, with the right backup scope, no extra steps.

When something does need adjustment—a device moved teams, a user credential changed—you handle it the same way you’d handle any other Jamf-managed app. Script it, reconfigure it, whatever your existing process is. Backup can now follow the same deployment and management workflows your team already uses for other Jamf-managed applications.

Fewer things that can go wrong means less time managing edge cases

The friction point used to be this: you’d deploy backup, then spend the next week chasing down why a handful of devices aren’t appearing correctly. Someone’s account didn’t match. A device landed in the wrong group. Now you’re writing workarounds.

With two deployment methods that actually handle different scenarios instead of forcing everything into one model. The new deployment options reduce common onboarding issues that often require follow-up troubleshooting. Fewer edge cases means fewer scripts to maintain, fewer devices to manually fix, fewer things to check on at 3am.

It still runs the same way once it’s installed

Nothing else about Backblaze changes. It backs up user data automatically, without caps or limits. Pricing stays flat per device. Restore works the same way. This update is purely about getting it deployed cleanly—the actual backup part just keeps working.

How to start

Pick a small group of devices. Deploy through Jamf. Watch what happens for a week. You’ll see pretty quickly whether the user-matching is working and whether this fits your environment.

How to install Backblaze silently with Jamf Pro for Mac

Learn more about Backblaze + Jamf

The post Jamf Administrators: Your Backup Deployment Just Got Simpler appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Computer Backup vs. Cloud Storage: Which Do You Need?

2026-08-04 Kari Wilson

Post Syndicated from Kari Wilson original https://www.backblaze.com/blog/computer-backup-vs-cloud-storage-which-do-you-need/

Organizations rarely struggle with a lack of storage options. More often, they struggle with determining which solution best fits the way their data is created, accessed, and protected: backup versus cloud storage.

That’s especially true when evaluating backup and cloud storage solutions.

The terms are often used interchangeably, but backup and cloud storage are designed to solve different problems. Understanding those differences can help you build a more effective data protection strategy—whether you’re protecting a personal laptop, a growing media archive, employee endpoints, or critical business data.

At Backblaze, Computer Backup and B2 Cloud Storage serve distinct purposes. For some customers, one solution is the clear choice. For others, the strongest approach combines both.

Before comparing features, it’s helpful to start with a few foundational questions.

Three questions to ask before choosing a solution

When evaluating Computer Backup and B2 Cloud Storage, consider:

Where does your data live today?
Who—or what—needs access to it?
What event are you trying to recover from?

The answers often reveal whether you’re primarily trying to protect a computer, store data in the cloud, or address both needs at the same time.

When the goal is protecting a computer

For many individuals and businesses, the most important data still lives on laptops, desktops, and attached external drives.

A photographer may keep active projects on a workstation. A consultant may store client files locally. A small business may rely on employee laptops as the primary location where work is created and managed.

In these situations, the primary concern isn’t cloud infrastructure. It’s protecting the device where the work happens.

That’s where Backblaze Computer Backup fits.

Computer Backup is designed to automatically protect data stored on a Mac or Windows computer, including connected external hard drives (but not NAS devices). Once installed, it runs continuously in the background, backing up files without requiring users to manually manage folders, storage allocations, or backup schedules. For organizations looking to protect NAS data, B2 Cloud Storage can serve as a backup destination through a variety of supported third-party backup and sync tools.

The value becomes clear when something goes wrong:

A laptop is stolen.
A hard drive fails.
Files are accidentally deleted.
A ransomware attack impacts local data.
A computer needs to be restored after a hardware issue.

In each case, the goal is recovery.

Computer Backup is often a good fit when:

Your most important data lives on a computer.
You want automatic, continuous protection.
You need to recover from device loss, hardware failure, or accidental deletion.
You want a solution that requires minimal administration.
Your primary concern is protecting endpoints.

For many professionals, families, and small businesses, those requirements align closely with their day-to-day reality.

When the goal is storing and managing data in the cloud

As organizations grow, data often becomes less tied to individual devices.

Files are shared across teams. Backup software protects servers and NAS devices. Applications generate and consume data continuously. Data needs to remain accessible and manageable independent of the original device, whether that’s for long-term retention, team access, application workflows, or infrastructure backups.

At that point, the challenge shifts from protecting a computer to managing data itself.

That’s where Backblaze B2 Cloud Storage comes in.

Unlike endpoint backup, cloud object storage is designed to store data independently of any single device. Data can be uploaded, accessed, managed, shared, and integrated into workflows across users, systems, and applications.

Organizations use B2 Cloud Storage for a wide range of use cases, including:

Media archives
NAS and server backups
Ransomware protection
Application storage
AI and analytics datasets
Business continuity and disaster recovery workflows

In these environments, accessibility, scalability, and integration often matter just as much as protection.

B2 Cloud Storage is often a good fit when:

Data needs to exist independently of a specific computer.
Multiple users or systems require access.
You need API-based access and automation.
You use third-party backup software that requires cloud object storage.
You need centralized storage for growing datasets.
You are building applications or data-driven workflows.

The focus isn’t on protecting a device. It’s on providing a durable, accessible home for data.

Understanding the data lifecycle

One reason organizations often use both backup and cloud storage is that data requirements change over time.

Consider a video production team.

While a project is actively being edited, the files may live on a workstation and several external drives. During that phase, protecting the editing environment is critical.

Once the project is complete, however, the priorities often change. The team may need to retain the content for future revisions, client requests, or compliance purposes. The files are no longer active, but they still need to remain available.

The same pattern appears across industries.

Architectural firms retain project files after construction is complete. Marketing teams archive campaign assets. Businesses preserve records for operational or regulatory reasons.

Not all data serves the same purpose throughout its lifecycle.

Active data often benefits from continuous endpoint protection, particularly when it lives on laptops, workstations, or attached drives. As that data ages, becomes shared across teams, or moves into long-term retention, cloud storage often becomes a more appropriate solution.

This is one reason many organizations use both Computer Backup and B2 Cloud Storage. The two solutions address different stages of the data lifecycle rather than competing for the same role.

When your storage requirements change

A common misconception is that organizations eventually “graduate” from backup to cloud storage. In reality, most environments become more complex over time, adding new requirements rather than replacing existing ones. As data volumes grow, teams collaborate across more systems, and retention needs increase, organizations often find themselves adding cloud storage to support those evolving demands. The shift isn’t typically about moving away from backup—it’s about addressing new use cases that emerge as data becomes more distributed, accessible, and valuable to the business. Common signs that additional cloud storage may make sense include:

Your data is no longer centered around one device

When multiple people need access to the same information, storing everything on a single workstation becomes limiting.

You’re building long-term archives

Completed projects, historical records, and large media libraries often benefit from dedicated cloud storage.

You’re adding automation and integrations

Applications, backup platforms, and workflows frequently require API-accessible storage.

You’re managing more than endpoints

As NAS devices, servers, and infrastructure become part of the environment, storage requirements often extend beyond individual computers.

In these scenarios, cloud storage isn’t replacing endpoint backup. It’s addressing new requirements.

The blind spot many cloud storage users discover

The reverse scenario is also common. An organization adopts cloud storage and establishes a centralized repository for important data, only to discover that important risks still exist at the endpoint level. An employee may accidentally delete a local project folder, lose a laptop, or experience a workstation failure before files have been synchronized elsewhere. Cloud storage protects the data stored in cloud storage, but it does not automatically protect every device where work is created. This is one reason endpoint backup remains an important part of many modern data protection strategies. The risks are different, and each solution is designed to address a different recovery scenario.

Why many organizations use both computer backup and cloud storage

One of the most persistent myths in data protection is that a single tool should solve every challenge. In practice, resilient environments are typically built in layers, with different solutions addressing different risks and recovery scenarios. Employee laptops may be protected with Computer Backup, while a NAS backs up to B2 Cloud Storage. Completed projects may be archived in the cloud while active work remains protected on local devices. Together, these layers create a more comprehensive approach to protecting data throughout its lifecycle.

Example: Creative teams

For creative teams, active projects often live on editing workstations and attached storage where they are constantly being updated. Computer Backup helps protect that work in progress, while completed projects can be moved to B2 Cloud Storage for long-term retention, future revisions, or client requests. This approach allows teams to safeguard current work without keeping every finished project on production systems.

Example: Growing businesses

As businesses grow, their data often becomes distributed across employee devices, shared storage, and business applications. Computer Backup can help protect employee endpoints where work is created, while B2 Cloud Storage provides a centralized location for shared assets, backups, and archives. Together, they support both day-to-day operations and longer-term data retention needs.

Example: IT and infrastructure teams

IT teams frequently manage a mix of endpoints, servers, NAS devices, and other business systems. In these environments, B2 Cloud Storage often serves as a destination for infrastructure backups, while Computer Backup protects employee devices that may not be covered by server or storage backup workflows. Rather than competing with one another, the two solutions often work together as part of a broader data protection strategy.

A quick comparison

Question	Computer Backup	B2 Cloud Storage
Is the primary goal protecting a computer?	Yes	No
Is it designed to protect endpoint data automatically?	Yes	No
Is the data primarily tied to a specific device?	Yes	Not necessarily
Is it designed for shared access across users, systems, or applications?	No	Yes
Is API access a core feature?	No	Yes
Can it serve as a destination for third-party backup tools?	No	Yes
Is the primary goal storing and managing cloud-resident data?	No	Yes

Choosing the right solution

The decision ultimately comes down to what you’re trying to protect and how your data is used.

If your primary concern is recovering files from a lost, stolen, damaged, or compromised computer, Computer Backup is likely the right starting point.

If you need scalable cloud storage for archives, applications, infrastructure backups, or shared datasets, B2 Cloud Storage is likely the better fit.

And if your environment includes both endpoints and cloud-resident data—as many organizations do—you may benefit from using both.

The most effective data protection strategies rarely rely on a single layer. They account for where data is created, where it lives, and how it needs to be recovered.

Understanding those requirements is often the first step toward choosing the right solution.

The post Computer Backup vs. Cloud Storage: Which Do You Need? appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Cloud Vendors Make It Easy to Get In. They’re Counting on It Being Hard to Leave.

2026-07-22 Kari Wilson

Post Syndicated from Kari Wilson original https://www.backblaze.com/blog/cloud-vendors-make-it-easy-to-get-in-theyre-counting-on-it-being-hard-to-leave/

A decorative image showing different columns with a dollar sign indicator.

You’ve done the storage evaluation. The per-terabyte price is right. The durability numbers check out. Compliance boxes are ticked. And still, the cloud migration project hasn’t been approved.

That’s not a coincidence.

The cloud storage industry has spent years competing on what happens after you’re already locked in: performance, redundancy, features. Almost nobody competes on what it costs to get there—or what it costs to leave.

Migration friction isn’t an oversight. For most hyperscalers, it’s a business model.

Why cloud migration projects stall before they start

The business case for cloud storage usually looks solid on paper. Lower per-terabyte costs. Less hardware to maintain. A path off aging tape libraries and overloaded NAS environments.

Then someone runs the actual migration math.

Egress fees from the current provider. Data transfer charges. Migration software licenses. Professional services. Tape digitization. Internal engineering hours. Project coordination overhead. For a large dataset, those costs can erase years of projected storage savings before a single byte moves.

Teams spend months building an approval-ready business case, only to find the upfront migration cost makes the model unworkable. The project stalls. Infrastructure the organization already knows is unsustainable stays in place. Modernization gets pushed to next quarter.

This is where most cloud vendors win. The storage decision becomes moot if the organization can never afford to move.

How egress fees trap organizations with their current provider

By the time most IT teams discover what cloud egress fees actually cost, they’re already mid-negotiation with a new provider.

The pricing model is deliberately asymmetric: getting data in is cheap, often free. Moving it out is where providers charge—and for multi-petabyte environments, those charges can run to hundreds of thousands of dollars before a migration has even started. Technically, the organization owns its data. Financially, moving it is a different question.

This reframes the evaluation in a way that favors incumbents. The question stops being which platform best fits long-term needs and becomes whether the organization can afford to leave at all. Once you’re in a major cloud platform with a large archive, exit costs are a structural retention mechanism.

Ask any prospective provider, early: what does it cost to leave? If they’re vague, that’s the answer.

How long does a cloud data migration actually take?

Cost gets scrutinized. Time usually doesn’t—until a migration is already underway and slipping.

A large-scale migration means inventorying data and metadata, evaluating and procuring tooling, coordinating across vendors, monitoring transfer jobs, validating integrity at the destination, and troubleshooting the inevitable edge cases. For multi-petabyte environments, self-managed projects routinely stretch from months into years.

Every quarter that drags on is a quarter the organization is paying to maintain infrastructure it’s already committed to replacing, while its engineering team runs a file-moving operation instead of working on anything strategic. The total cost of a slow migration almost always exceeds the initial estimate—and almost nobody builds that into the business case upfront.

What actually goes wrong during cloud data migration

Migration risk tends to be underestimated until something breaks.

The core questions—will files transfer without corruption, will metadata survive intact, will dependent applications keep working—are harder to answer than they look for LTO tape archives that haven’t been accessed in years, NAS and SAN environments with proprietary metadata structures, media archives with irreplaceable assets, regulated content with chain-of-custody requirements, and datasets large enough that verification at scale is its own engineering problem.

The cost of getting this wrong isn’t just the migration itself. Data loss, integrity gaps, or application failures discovered post-migration can be significantly more expensive than any egress fee. Validation and verification need to be designed into the plan before transfers start, not bolted on after something fails.

Why most cloud providers leave migration to you

Infrastructure teams evaluating cloud storage aren’t looking for a transfer tool. They want infrastructure modernized without burning their engineering team on a multi-year internal project. Predictable costs. A path to cloud that doesn’t require standing up a program management office just to move data.

The standard provider response is documentation and an onboarding checklist. After that, you’re largely on your own.

This isn’t an accident. Selling storage is straightforward. Owning migration means taking on cost, risk, and operational complexity that most providers would rather leave with the customer. The economics of the business favor making entry easy and exit expensive, with as little friction to growth as possible in between.

Providers that treat migration as their problem to solve are a different category. They’re betting that making it genuinely easier to get to their platform is worth more than one-time migration revenue—because a customer who gets there successfully tends to stay.

How Backblaze Universal Data Migration works

We built Universal Data Migration because we kept seeing the same thing: organizations that had already decided to move to Backblaze B2 getting stuck on the migration itself. The technology decision was made. The budget was approved. The project just couldn’t get started.

The program moves data from virtually any source—AWS S3, Microsoft Azure Blob, Google Cloud Storage, Wasabi, NAS and SAN, file servers, LTO tape across all generations, physical hard drives, legacy archives—with Backblaze managing the process rather than handing the customer a tool and a runbook.

The migration cost doesn’t have to be a reason the project stalls. That’s the point.

Before you sign a cloud storage contract, ask these two questions

The storage evaluation isn’t complete until you know what it costs to get there and what it costs to leave.

Most providers make the second number hard to find. If you have to dig for egress pricing, or if a sales rep answers the exit question with “we’d work with you on that,” build the worst-case number into your model before signing anything.

The right provider won’t make you ask. They’ll make migration part of the conversation from the start—because they’re confident enough in their platform to compete on the full picture, not just the monthly storage line.

Have a migration project that keeps getting pushed? Talk to our team about what it would actually take to move your environment to B2.

The post Cloud Vendors Make It Easy to Get In. They’re Counting on It Being Hard to Leave. appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

AI Can Now Execute 73% of Expert-Level Cyberattacks. Here’s What IT Leaders Need to Do.

2026-07-07 Kari Wilson

Post Syndicated from Kari Wilson original https://www.backblaze.com/blog/ai-can-now-execute-73-of-expert-level-cyberattacks-heres-what-it-leaders-need-to-do-now/

An illustration of a laptop screen and a lock.

On April 7, 2026, Anthropic announced a model so capable they refused to release it publicly. Claude Mythos, their most advanced frontier AI, was deemed too dangerous for open access because of one thing: it can hack.

Not in the vague, theoretical sense that security researchers worry about. In the “completed 73% of expert-level capture-the-flag challenges that no AI could touch before April 2025” sense. In the “autonomously identified a 17-year-old remote code execution vulnerability in FreeBSD from scratch, without a human involved after the initial prompt” sense. In the “found thousands of critical zero-days across every major operating system and web browser in a matter of weeks” sense.

Anthropic locked Claude Mythos behind Project Glasswing, a vetted partner program initially restricted to roughly 50 organizations—AWS, Microsoft, Google, Apple, Cisco, CrowdStrike, and others—to use the model for defensive work before adversaries could develop equivalent capability. By June, that program had expanded to more than 200 organizations across 15 countries, including operators of power grids, water systems, hospitals, and telecommunications infrastructure.

Then, on June 9, Anthropic released Fable 5—the first public version of a Mythos-class model—equipped with safeguards that reroute higher-risk queries to less-capable models. The same day, it released Claude Mythos 5 directly to vetted Glasswing partners. Later in June, after a brief US government export review, the Commerce Department confirmed that “appropriate safeguards are in place” and permitted Anthropic to redeploy Mythos 5 to trusted cyber defenders.

But here’s the part that should be on every IT leader’s radar: Anthropic itself now projects that other AI companies will have Mythos-class models within six to 12 months, and those companies may not ship with equivalent safeguards.

GPT-5.5, released three weeks later, didn’t wait. OpenAI shipped it with expanded cybersecurity capabilities and its own controlled-access program—also designed for defense, also eventually available to people with different intentions.

The AI arms race in cybersecurity isn’t coming. It’s here.

Ransomware 5.0 Doesn’t Need a Skilled Operator

For most of its history, ransomware required a human being at the keyboard: someone doing reconnaissance, identifying targets, crafting phishing lures, moving laterally through a network. Skilled attackers commanded significant ransoms. Amateur operators made rookie mistakes.

That dynamic is collapsing.

Ransomware now appears in 48% of all breach chains, according to the Verizon 2026 Data Breach Investigations Report—up from 44% the year prior. Active ransomware groups jumped 49% year over year. Over 250 new operators entered the market in just the last six months, many of them low-skill actors using generative AI to craft personalized phishing campaigns 60% faster than was possible before. AI-assisted lateral movement was present in over 65% of recent cases.

The Verizon 2026 DBIR also marks a shift in how attackers get in the door: for the first time, exploiting unpatched software vulnerabilities has overtaken stolen credentials as the number one initial access vector, now responsible for 31% of breaches. That’s not a coincidence in a world where AI can scan codebases for exploitable flaws at machine speed.

IBM’s 2026 X-Force Threat Index confirmed that “collapsing barriers to entry” are letting even low-volume operators run campaigns that overwhelm defenders. The average cost of a data breach in the US hit $10.22 million—an all-time record.

Trend Micro’s 2026 security predictions describe what they call “Ransomware 5.0”: a model where AI handles reconnaissance, vulnerability scanning, lateral movement, and even ransom negotiation autonomously, without a human operator directing any of it.

If you’re still designing your security posture around slowing down a skilled human attacker, you’re fighting the last war.

The Thing Nobody Wants to Say Out Loud

Here’s where I’m going to say something a little uncomfortable: the cybersecurity industry has been selling you detection for years when what you actually needed was recovery.

Detection is important. Don’t get me wrong. But detection-centric security assumes you catch the attack before it fully executes. In an era where AI compresses the attack timeline, exploit chains run at machine speed, and hundreds of new ransomware groups just showed up with AI-powered toolkits, detection alone isn’t a resilience strategy. It’s a bet.

The UK Government’s AI Security Institute tested Claude Mythos extensively and confirmed it cannot reliably execute attacks against organizations with well-hardened defenses. That’s genuinely good news. But it raises an obvious follow-up question: how many organizations actually have well-hardened defenses? A 2025 report found that over 45% of discovered security vulnerabilities in large organizations go unpatched after 12 months. Many critical infrastructure operators still run end-of-life software.

The honest answer is: most organizations are not that hardened. And even the ones that are will face a more capable threat next year than they face today.

This is why immutable backups aren’t just a box to check; they’re the safeguard that functions even when everything else fails. If an attacker encrypts your production environment before detection fires, the question isn’t “how did that happen?” It’s “how fast can you recover?”

What Claude Mythos Actually Changes (And What It Doesn’t)

It’s worth separating signal from noise here, because the coverage of Claude Mythos has ranged from measured to apocalyptic.

What Mythos changes: the technical barrier for sophisticated attacks. Vulnerabilities that previously required elite researchers to discover and weaponize can now be found and chained faster. Anthropic’s own red team found that Mythos could identify and exploit a previously unknown FreeBSD remote code execution vulnerability—fully autonomously, no human involved after the initial prompt. Across all Project Glasswing partners, Mythos has now surfaced more than 10,000 high- or critical-severity security flaws in production codebases. That means the window between vulnerability disclosure and active exploitation, already dangerously short, gets shorter. It also means less-skilled threat actors get access to capabilities that used to require significant expertise.

What Mythos doesn’t change: the fundamental anatomy of a ransomware attack. Attackers still need initial access. The Verizon 2026 DBIR confirms they’re still relying on unpatched software, stolen credentials, and phishing as entry points just finding and exploiting them faster. Once inside, they still need to move laterally, identify high-value data, and execute the encryption sequence. The Centre for Emerging Technology and Security at the Alan Turing Institute made this point clearly: more sophisticated ransomware attacks that rely on stolen credentials, social engineering, or already-compromised accounts are “far less likely to be affected” by Mythos-class models on either side.

That matters for how you defend. Hardening access controls, enforcing MFA, patching aggressively, segmenting your environment, and maintaining clean, immutable backups are not glamorous. They are not AI-powered. But they address the attack anatomy that AI tools, offensive or defensive, haven’t fundamentally changed.

The Recovery Imperative

Strengthening cyber fundamentals, in practice, means one thing above all else: knowing that when something gets through, you can recover without paying a ransom.

That requires three things from your backup and recovery posture:

Immutability. Backups that can’t be encrypted or deleted by ransomware, even by a compromised admin credential. This isn’t optional anymore. If your backups live in the same environment as your production data and share the same access credentials, they aren’t backups; they’re part of your blast radius. Backblaze B2 Object Lock is S3-compatible, so if your team is already running Veeam, Commvault, MSP360, or Nutanix, you’re not replacing your backup stack. You’re giving it an immutable target that ransomware can’t touch.
Air-gap or off-site isolation. Object Lock, WORM storage, and geographically separate backup targets all put meaningful distance between your recovery point and an active attack. When AI tools can chain dozens of steps in a corporate network attack simulation autonomously, “isolated backups” means genuinely isolated, not just a separate folder. Version history matters here too: the ability to roll back to a known pre-attack state, not just the most recent snapshot, is what separates a clean recovery from discovering your restore point was already compromised.
Recovery time that matches the threat. AI-accelerated attacks mean recovery has to be fast. A backup strategy built around 72-hour RTOs made sense in a different threat environment. In 2026, breach costs approaching $10.22 million in the US, the question your leadership should be asking is: how long does it actually take us to restore from a clean state? Cold storage tiers that require hours of retrieval before a restore can even begin are a liability when the clock is running. Backblaze B2 is hot storage: your data is available immediately after detection, with no retrieval queue to wait on.

A Practical Checklist for IT Leaders Right Now

The Claude Mythos announcement, the Fable 5 public release, and GPT-5.5’s expanded cybersecurity capabilities are a forcing function. Not because Mythos-class capability is in attackers’ hands today, but because the direction of travel is confirmed, the timeline is compressed, and the question is no longer whether equivalent offensive tools will proliferate, only when.

A few things worth doing before that happens:

Audit your backup environment’s blast radius. Can ransomware that has compromised your production environment also reach your backups? If yes, fix that first.
Test your recovery time. Not just that backups exist, but how long an actual restore takes from your most recent clean snapshot. If you don’t know the number, you don’t have a recovery plan. You have a filing system. Backblaze gives you 3x your stored data in free egress each month, which removes the cost barrier that causes most teams to skip DR testing entirely. Run the restore. Know the number.
Pressure-test your identity controls. Credential abuse and phishing remain the dominant entry vectors. MFA, compromised credential monitoring, and least-privilege access aren’t new ideas, but they’re still the fastest path to closing the doors AI-powered attacks walk through.
Patch faster. The Verizon 2026 DBIR found exploited vulnerabilities are now the leading breach entry point. The median time organizations take to fix a known flaw is 55 days. AI-assisted attackers don’t wait 55 days.
Layer your defenses, but anchor to recovery. Perimeter protection, endpoint detection, vulnerability scanning: these all matter. But they’re all designed to catch something before it executes. Immutable backups are what you rely on when something executes anyway.
Revisit your RTO and RPO against today’s breach costs. The math has changed. A $10.22 million average US breach cost changes the calculus on what it’s worth spending on faster, more resilient recovery infrastructure.

The Last Thing

Anthropic made a decision that deserves credit: they looked at what Claude Mythos could do and chose not to hand it to the world on day one. Project Glasswing is a serious attempt to use the model’s capabilities on the right side of this fight, and the coordinated disclosure of thousands of vulnerabilities to the organizations responsible for patching them is meaningful defensive work.

But the history of powerful technology is not “we invented it and kept it safe.” It’s “we invented it, others reproduced it, and everyone had to adapt.” The 6-to-12-month window for equivalent capability to reach adversarial hands isn’t fearmongering; it’s Anthropic’s own forecast. Other AI companies are building toward the same capability threshold right now, and not all of them will ship with the same safeguards.

The organizations that come through this transition will be the ones that took recovery seriously before they needed it. Not because detection failed, but because recovery is the one safeguard that works regardless of what the attacker is running.

Backblaze B2 with Object Lock puts immutable, air-gapped backup storage within reach of organizations that can’t afford hyperscaler pricing (which, as it turns out, is most of them). Start a free trial or talk to our team about building a ransomware-resilient backup architecture before the threat landscape shifts again.

The post AI Can Now Execute 73% of Expert-Level Cyberattacks. Here’s What IT Leaders Need to Do. appeared first on Backblaze Blog | Cloud Storage & Cloud Backup