Why Object First is Best for Veeam

My name is Anthony Cusimano. I am the director of solutions marketing at Object First, and I'm excited to talk with all of you about what Object First is. But before we get into that, I feel like it's always good to start with a why Object First is best for Veeam.

So let's go ahead and get into it. For those of you that don't know, we were founded by the same two founders of Veeam, Ratmir Timashev, Andrey Baranov. They founded us a little over four years ago.

And basically, as an operation to think about how we could change the storage space, specifically for immutable backup storage for Veeam backup and replication. Figuring out how we could do a truly, absolutely immutable storage target for backup, which you might think was already on the market, but I will actually explain to you why that was not the case and how we went about doing this. Their vision was essentially to create something that is effectively ransomware-proof.

And my goal for you all is to explain both why that was necessary and how we do it. And since January of 2026, it is important to note we were acquired by Veeam. So this is late-breaking news, but I guess we did a good enough job that Veeam decided they wanted us as part of their portfolio.

So let's get into it. Obviously, ransomware is not going anywhere. It's still quite a threat in the market.

When we started our business four years ago, one of the things we noticed was in every case of a Veeam ransomware attack, the storage is always the failing point, right? Veeam was fine. You were able to use your Veeam Backup and Replication platform to recover with ease, but the storage was the weak point.

And that was because they did not have the right level of security, immutability, and hardened nature to it to ensure recovery. And then also when you were actually able to recover, we found with some of our research, 50% of the time you couldn't recover within a week. Which is not an acceptable window for any business to continue to operate in, especially in the case of an attack.

So we've looked at, I think the data speaks for itself. There's lots of incidents and attacks that are happening. We know, we've even seen this happen with some of our customers, and I'll talk to you about that.

They're not slowing down. They're getting smarter, and they're getting better. And the one consistent thing we continue to see is bad actors will always go for the backup storage 96% of the time.

So majority of case, bad actor, whether it's AI-led, it's nation state-led, just 14-year-old who got his hands on some cool software, they're going after the backup data simply because they know if they take out the backup or take out the storage, there's no way you can recover. Greatly increases the chance of paying a ransom. So we've seen 50% can recover within a week, 25% or less recover with less than half their business data, which is not good.

But there's also a human impact to this, which we see behind the scenes. And this is really what led us to start creating what we did. 84% of the folks that we interviewed found that they were uncomfortable, stressed over IT security risks.

74% feared the security incident would be blamed on them, depending on the situation. It's not good mentally to be in this state, especially if you're a backup or IT admin. So we start with what's causing the issue.

I think it's important we get into how we fix it. Right? So I'm sure most of you are familiar with the concept of zero-trust.

It's been beaten to death over the last few years at RSA, and importantly so. I think it's a great concept to understand. But three of the key principles are assume breach and segment access, verify explicitly that you are who you say you are, and then use least privilege access for every device, every user, every service and application.

We think this is really good and this works great for production data and production environments, but where we see room for improvement is in the backup and data protection space. So, alongside Veeam, we've come up with this concept, which is called zero-trust data resilience. And the idea behind this is what if we took zero-trust concepts and applied it to data protection?

So it's not just segmentation of individual services or networks. It's segmenting backup software from backup storage because we know if they reside in the same environment, if they're in the same ESX host, if they're in the same cloud environment, if one is taken out, all is taken out. Right?

So if you can segment those things, you've created at least one level of separation between backup software, backup storage. Now take that a step further, you create multiple resilience zones. We're familiar with 3-2-1 or 3-2-1-1-0.

The idea again being that if you create multiple copies of backups, potentially either air-gapped or immutable, you're just further minimizing the blast radius of attack. Paired with segmentation, you've got a pretty good set of recovery options. But the third, and the most important one we're going to talk about the most is immutable backup storage.

And immutability is a term that gets thrown around a lot. A lot of people say they offer it. A lot of it is just a checkbox.

If it can't be disabled, it's not immutable, and I'll talk about that in just a second. But we do believe that in conjunction, these three things make for a very strong environment. " We truly believe that every single backup storage vendor and backup storage-- Backup vendor and backup storage vendor should be following these principles to ensure recoverability for their customers.

So to give you an idea of what an environment looks like, we've got our production, backup software, backup storage. It's pretty obvious. We're splitting these things.

We're creating resilience zones, and you'll notice here in the middle, we're using S3. And we'll get more into that in a minute and why that's so important. But the idea being, we are creating a logical separation for each slice of infrastructure.

And again, minimizing attack surface so when ransomware hits, we are able to ensure that there's always a point to get back to. So let's talk about immutability. This is where I get passionate because, like I said, you see a lot of storage vendors today, they will offer immutability.

Immutability isLike zero trust has become a bit of a marketing term that you can checkbox and put on your website. That is not the way it should be. Right?

The definition of immutable means it cannot be changed, altered, updated, or deleted. And if an admin could come in and using their administrative privilege disable immutability, then it's not immutable. That's every bad actor's first approach, is how do I get in there?

How do I dwell? How do I get the secrets? How do I escalate my privilege?

And then how do I disable immutability? So we believe that there should be a new term. The same way as zero trust, we escalated to zero trust data resilience for backup.

Immutability is just too markety. We need absolute immutability. And what that means is we utilize three core principles to ensure that data cannot be changed to storage once it is written.

The first principle is to utilize S3 object storage. Now S3, created by Amazon, 15 something years ago, really great sort of evolution to how we read and write storage to a file system. Right?

They conceptualized objects. They conceptualized the metadata layer. But they also came up with a little feature called Object Lock, and because this is all an open standard, it gives us a really good ability to understand how it works, and it also makes it great for us to implement it at the software and storage layer.

S3 Object Lock simply means that once it is enabled in conjunction with versioning and compliance mode, it cannot be disabled as long as it's within a time period set by the end user. So the idea here is if I say I want seven days of immutability and I have Object Lock enabled and compliance mode is on, there's no one on the planet that can disable that. Unless, of course, they have access to a man-in-the-middle attack or the hardware layer.

Which is why we get into pillar number two, zero time to immutability. Lot of vendors today will try to optimize data movement by ingesting data as it is received in some kind of cache or buffer. Right?

I'm going to land on high-speed flash cache. I'm going to go to the immutable storage afterwards. This is going to up my ingest, but what it doesn't do is it doesn't protect that data.

And we have seen time and time and again that bad actors will look to basically exfiltrate and get in and disrupt any kind of data movement. So utilizing S3 object storage with technology like Veeam's SOS API, landing on our own proprietary storage, which Jeff will inform you about in a little bit, we're able to short cycle this. So the second the data is captured and then written and received, it should be immutable, that entire step of the journey.

And lastly, third pillar, having a physical target storage appliance. And this is important because we see a lot of folks today that are relying on cloud storage. They're relying on either virtualized or hypervisor-type storage.

" If someone's able to escalate privilege into that VMware layer or the AWS IAM layer, what they're doing is they're basically offering a level of compromise that can then flow downward and disable that storage. Even Amazon, who created the S3 service, offers two modes for their object storage. There's governance mode, compliance mode.

Governance mode is exactly what you think it is. It gives a governor. Someone can come in, disable the thing if they have enough escalator privilege.

" You put all three of these things together, and you get what we call absolute immutability, which means no amount of escalation, privilege, or even vendor privilege will allow you to compromise the data once it is written to our box. So that leads us to us, Object First. We saw a gap in the market, which was specifically that Veeam customers needed secure, simple, and powerful storage.

And everything out there today, I'm not saying they're bad, but they all offer some kind of sacrifice. There's no other storage vendor that when we started was specifically focused on the ingestion of backup data from Veeam. So that made us unique day one.

We focused on a single vendor. We focused on delivering absolute immutability, and we see the potential to be zero trust data resilient in that environment. So just going to give you a walkthrough.

Lot of vendors are using direct attached storage. That's fine. It's cheap.

It's powerful. It works, but you're always going to compromise security because anytime you have a DIY solution, you have a single point of failure, which is the person that made the setup. You got DDAP appliances, which are phenomenal by the way.

Great for long-term data compression or retention. Not great for quick ingest or ensuring absolutely immutable data. The security is a sacrifice there every time.

DIY hard repositories, you've got your pick of the litter when it comes to sort of secure build it yourself solutions, but again, as long as there's that administrative privilege that can be escalated and taken advantage of, it's not zero trust, it's not absolutely immutable. And that's where we fit in, is it's object storage. We have built object storage utilizing S3 immutability that delivers on the absolutely immutable principles that we set forward.

So what Object First offers is backup storage with absolute immutability. Our hardware appliance is secure, simple, and powerful. It is secure because we follow a zero trust architecture.

It uses S3 native object storage. We offer zero access to perform any destructive actions to our box. And I should mention that applies to us as well.

So if there is a support issue with our device and our customers call in, we do what's called eight eyes validation, where two individuals on the customer side and two individuals on the Object First side have to validate they are who they say they are because we understand that everyone can fall victim to these kind of compromises. And lastly, everything we do is third-party penetration tested and validated, and we publish these reports so everyone can see. Any one of you can go to our website and check out our third-party security testsWe'll talk a little bit more about that in a minute, but we believe that public security, not security through obscurity, is the answer, because then there's no surprises.

You know exactly what you're getting when you get our box. Now, all of this is to say it kind of sounds complicated. It's really not.

It's very simple. Our box takes less than 15 minutes to set up. It was built with the idea that the less the end user has to do, the more secure it is.

The less privilege we give them, the less ability we give them, by nature, the more we're able to secure it by default. And everything is managed directly through us. When it comes to updates, firmware, software, hardware, we take care of all of that so they don't have to.

And on the power side, I made that flash analogy earlier, writing quickly to data. It's great. We have come up with a way to basically optimize for both use cases.

And I'll talk more about this when we get into the hardware side. But we have made it so we are able to quickly ingest data from the Veeam Smart Object Storage API directly to our box and also quickly recover and support functions like Veeam Instant Recovery. And when it comes to our actual storage sizes, we scale linearly.

So for every box you buy, you're doubling in power, you're doubling in capacity. We offer many different node sizes throughout our systems. So this is why we exist.

Any questions I can answer for you all so far? I love a good stump the chump, so please try me. What about are there anything that customers can't do compared to the DIY S3 setups?

I love that question because yes, we limit our customer functionality for that reason. The S3 example's perfect because when you set up an S3 bucket in AWS, you have the options of compliance governance. There's no option.

When you create a bucket in an object-first device, it is immutable by default. We check that box for them. If they want, they can do a test dev bucket, but they have to disable that, and that bucket cannot be changed or deleted once that's set.

We limit the privilege simply because we realize it's not a matter of not trusting them. We don't trust that they won't be hacked, so the less we give them, the better. The reason it takes 15 minutes to set up is because legitimately, you rack and stack the box, you turn it on, you plug it into your network, you create an S3 key and an S3 bucket, and you've effectively done everything you can do with object first within the actual backup configuration side.

You're then in Veeam land, and you're writing everything through Veeam. Limitation of privilege is great, especially in a zero trust environment.