One Breach, Every Customer: The Hidden Danger of Multi-Tenant Identity

Brad McCarty — 00:05–19:21

Alrighty. Let me get all the things set here. Oh yeah, the camera angle's a little weird — hang on. There we go. Love when it cuts off the top of my head like that.

A couple quick housekeeping notes: you'll see over on the right side that there is a chat and message box. Feel free to drop questions in there as you have them — I'll try to keep an eye on that and get those questions answered as quickly as possible. We'll also have some time at the end for Q&A. But really, a lot of this is not anything that you either haven't already heard the argument about — and we're just going to try to go a little bit deeper down that rabbit hole — or it's probably something you're already considering and you're kind of just hoping to get a piece of information out of this webinar. Regardless of your reason for attending today, thanks for taking the time. We really appreciate it.

I am Brad. I run product marketing here at FusionAuth. Generally speaking, I know nobody wants to hear from the marketer, but because I know that, I promise you I'm not just here to try to sell you a bunch of crap. I would prefer to run marketing from a perspective of first being helpful, answering questions, and giving you something useful to go away with to help you make an informed decision. Today's discussion isn't really talking about the features of authentication — like MFA and passkeys. Those are the whats of identity. Today we really want to talk about the where and the how of identity.

Identity is the new perimeter. Yet for most organizations, it remains their most dangerous single point of failure. Here at FusionAuth, we firmly believe that identity shouldn't just work — it should be resilient by design. We're going to look at how to move away from shared risk and toward a total architectural model of control.

So here we go. Before we dive into architecture, we need to speak the same language. In the world of site reliability engineering, they talk about tier zero — it's not just important software, it's the stuff that is critical to your business. It's the bedrock. If your tier one app — like your storefront or your API — is the house, then identity is the foundation for that house. If the foundation cracks, the house falls.

We're going to talk about blast radius here as well. In a shared SaaS model, you're not really on an island — you're part of a continuous forest. One lightning strike at the provider level can burn the whole forest down. Our goal today is to show you how to move toward what we'd like to call sovereign identity: where you draw a hard line around where your infrastructure ends, and you get to manage the risk because it is yours alone.

We often hear identity described as "the plumbing," and I think that understates the risk we see pretty frequently these days. In a modern stack, identity is tier zero infrastructure — it's the hierarchy of resilience. Tier one is your application. But if tier one is your application, tier zero is the foundational service, like DNS or networking. At those levels, if those services go down, your application requires them to function, so you kind of disappear — or in an even worst-case scenario, you look like you're available, but people can't use your service because they can't log in.

So if your database goes down, you've got a warm standby. If your CDN goes down, you can fail over. If your identity provider goes down, your product isn't really accessible to frustrated users who are staring at it on the screen.

Engineering orgs oftentimes inherit their identity stack. It was the thing bundled with an early cloud provider, or it was the easiest API to plug in during an MVP. But easy at the start can lead to fragile at scale. We need to stop treating identity as a commodity and start treating it as the critical infrastructure that it is.

In a multi-tenant model, we have to look at blast radius and how it actually functions. It's not just total provider blackout — it's resource contention. You're sharing a database and CPU with thousands of neighbors you've never met before. If one of those strangers runs into a massive unoptimized report or faces a sudden traffic surge, your login speeds could be fighting for those same IOPS. That's a performance risk you didn't create, but you definitely own it.

Then there's platform risk. When the provider makes a global configuration error or suffers a breach of their management layer, it's not going to hit just one account — it boards up the front door for every single customer all at once. You could have the most secure application ever built, but if your shared identity foundation is failing, your users are locked out. Here at FusionAuth, one of the things we believe really strongly is that your security performance shouldn't be a communal experience — that should be something you own all by yourself.

I want to be clear: I come from a background of working with multi-tenant SaaS, and I still think it's a really great answer for a lot of things. If you're building a prototype or an internal tool where a four-hour outage is an annoyance rather than a disaster, a shared model is often the right move — nobody's going to argue about that. But as you scale into tier one application status, or as you start signing those enterprise B2B clients with six-figure associated losses for downtime, that shared risk becomes an existential threat to your business.

When we talk to customers and potential customers, we hear frequently that CFOs love predictability — and identity pricing is rarely predictable. When we look at a three-year total cost of ownership, it's more than just the license cost; we're looking at the cost of downtime. When an incident occurs, do you own the response? Can you roll back a version? Can you move to a different region? In an isolated model — the sort of identity infrastructure you own every element of — you aren't going to be immune to incidents. We can't make any global promises of that. But what we can say is that you own the response. You aren't stuck in a support queue with 10,000 other people. You have the control and the operational flexibility to restore your service on your timeline, not your vendor's.

One of the things I've been really amazed by here at FusionAuth — I've been with the company now for about three years — is when people talk to our support team. If you are a FusionAuth customer or have been through that process at all, you've probably met who we lovingly refer to as the Joshes. The Joshes are a pair of guys named Josh who are our tier one support people. When you come into FusionAuth with an issue, they're probably the people you're going to talk to. They are developers — they know every element of this. There's no support queue where someone asks if you've rebooted yet; you're going to talk to the people who develop the product. That is something I love about this company, and something a lot of our customers say is a defining characteristic for them and why they chose to go with FusionAuth.

So let's talk about the FusionAuth cloud option. When most people hear "cloud," they think multi-tenant. But when FusionAuth hosts it for you, it's still a dedicated deployment. You aren't in a row of shared databases — you have your own CPU, your own RAM, your own database instance.

We've architected it so that data is separated at the infrastructure level. The reason behind that is pretty obvious, but let's talk about the noisy neighbor problem: somebody creates a problem for shared infrastructure — that's not your problem, because you don't share that infrastructure with them. It ensures that a vulnerability in any one tenant's configuration cannot be used to hop into yours. You get the convenience of managed services — we handle all of that for you — but then you decide: do you want to upgrade now, or wait for the next version? Do you need to roll back because something changed that you don't like? You are in complete control within a single-tenant architecture that we host for you.

This is really where the context of identity sovereignty lands. We don't care where you run FusionAuth as long as it meets your needs — whether you're running it on bare metal, an orchestration tool like Kubernetes, or just spinning up a local instance on a Mac for dev work, FusionAuth is built for it. In fact, we are an incredibly lightweight piece of downloadable software. Anecdotally, I love hearing from customers who had an old Mac mini sitting in a closet, and that's their identity server because it meets all of their needs. I don't recommend running FusionAuth on an old Mac mini, but you can, and it works just fine.

Most SaaS providers are cloud-only, so you have to trust their infrastructure. We take a completely opposite approach. If you're a defense contractor or a bank needing air-gapped environments, we support that. You own the stack, the data, the keys — that's true sovereignty.

When we talk to engineering teams and engineering leaders, a number of conversations come up frequently. One is always the "should we build or should we buy?" question — and we have a calculator that proves that in most instances, buying is almost always more efficient than building. There is a second, more critical question, though: how are you buying? Traditional SaaS identity models are built on a variable tax — MAU tokens, additional fees for IDPs, feature gates that make your three-year TCO a moving target and a lot harder to predict year over year. When you move to an isolated model, you're not just buying software — you're buying budget predictability. And that's a big deal not only for engineering teams but for the CFO, the person signing the check. They need to know what this is going to cost next year. With us, you absolutely can know — you'll know your infrastructure cost, you'll know your licensing fee, and most importantly, you know your team isn't going to be pulled off a revenue-generating sprint to fix a breaking change forced by your multi-tenant provider.

I like to talk in real-world terms. For us, these are not just technical experiments — they're mission-critical systems. And when we talk to customers and potential customers, we love to hear their stories about how we're solving a problem for them.

You're probably familiar with Bilt, Bilt Rewards — they let people pay rent with a credit card and earn rewards. They're a massive fintech player serving millions and millions of users every month. They chose FusionAuth because they needed fintech-level authentication and couldn't afford noisy neighbor performance hits or systemic risks with shared SaaS providers — they needed to run on a dedicated isolated instance. They get their functionality without needing to compromise on the performance their rewards and payment platform demands.

Another favorite: a European travel agency moved away from Auth0 specifically because they needed a more flexible, cost-effective model that guaranteed data residency for GDPR compliance. You'll find that story on our blog.

And then there's Promptfoo. They deal with AI prompting; they're an AI security company, and they used our isolated model to ship authentication that met strict security requirements their Fortune 500 customers had to have — and they spun it up in seven days. It's stunning to look back at these and see the actual stories: massive scale, guaranteed compliance, enterprise speed.

Let me check my questions here. Okay, thank you. And again, feel free — stop me, throw a chat message in, throw something in the Q&A. I'm happy to talk about it with you. You'll also get a recording of this, so you can pass it on to people on your team who need to see it if you don't want to try to remember all the fine-point details.

So what does it look like when identity just works? This is the "after" scenario. Imagine a sprint planning meeting where auth never comes up as your blocker. You're improving security because you have the control to implement the policies your specific business needs. When identity stops being a project you have to think about, your team can ship more. You get to focus on your core competencies. You don't have to become an identity and authentication expert — we've already handled that for you.

So if you woke up tomorrow and saw a headline on The New Stack or Hacker News similar to the Okta support breach from back in 2023 — a single vulnerability in one vendor exposed every customer's session tokens — what's your plan B? If you're on a shared multi-tenant platform, you're essentially waiting for a vendor to tell you if you've been hit. When you have an isolated deployment, that risk is completely off the table.

If you want to see exactly how an isolated deployment fits into your VPC or your air-gapped environment, we've got solutions engineers ready to jump on a call with you. You can also use the TCO calculator to see the baseline savings of moving away from homegrown auth.

I want to talk about that TCO calculator for a second, because it would have been really easy to go in there and fill it with numbers that always point in our direction. What you'll find, if you click around in the right ways, is that we will actually tell you, "Oh, no — actually, in this case, SaaS authentication probably makes sense for you." But there are caveats to every one of those scenarios. So go play with it. It's at fusionauth.io/buildvsbuy.

It's what I like to think of as the most honest, most transparent calculator I've seen — because that's how I designed it. I didn't want to hide behind opaque pricing. I literally tell you the logic built behind every section. So go play with it, see what those savings could be for you if you're considering homegrown auth or you're already in that scenario, and we can discuss how an isolated model adds that extra layer of fiscal and technical control.

If you've got deep questions, we would love to hear them. Give us a call or drop us an email — it's not going to be a high-pressure sales environment, we don't do that. We would prefer that you make an educated decision and that you're ready to go back to the rest of the decision makers on your team and have that discussion with them.

That's what I've got for you today. Thanks so much — I appreciate all of your time. Told you it was going to be quick and easy. If you've got questions, drop us an email through the contact form on the website, or you can email me directly and I can get you to the right person. I've been here long enough that I'm one of the few people with a first-name email at FusionAuth, so I'm just brad@fusionauth.io. Thank you so much for your time — we'll talk to you soon.