These Questions Matter
If you’re evaluating identity infrastructure—or reconsidering an existing provider—several questions deserve direct answers:
- What happens to your applications when your identity provider has a multi-tenant outage?
- How does your blast radius compare to an isolated deployment model?
- What are the actual total costs when you factor in growth, required features, and risk?
- And where does your data live, who has access, and what happens when regulations change?
These aren’t questions with simple answers. They depend on your specific regulatory environment, risk tolerance, and architectural requirements.
Going Deeper
This article will cover the basics. But if you want to go deeper, we’re hosting a webinar on February 24th that digs into these questions with the technical depth they deserve. We’ll walk through the anatomy of blast radius incidents, compare isolated versus multi-tenant models with real numbers, and share case studies from enterprises that made the transition.
If you’re responsible for identity infrastructure in financial services or healthcare—or any high-stakes environment where authentication failures translate directly to business impact—this session will give you the framework for evaluating your options.
Identity sits at the front door of every application, every user session, and every revenue-generating transaction. When it works, nobody notices. When it fails, everything else fails too. This failure isn’t theoretical. It’s an existential risk that’s hiding in plain sight.
The SaaS Blast Radius
Software-as–a-Service (SaaS) has overtaken almost every application category, and for good reason. SaaS eliminated the capital spend of on-prem software, the patching cycles, the version fragmentation. Teams get automatic updates, predictable costs, and someone else handling infrastructure at 3 AM.
But some things should never be SaaS. At least not in the traditional, multi-tenant sense.
Most SaaS identity providers run on shared architectures. Your authentication data sits beside thousands of other customers on the same hardware. The economics make sense for the vendors. They spread costs across a massive customer base and make promises about passing those savings along.
But those economics come with some trade-offs that rarely appear in the sales deck. Namely, you inherit every other customer’s risk, and they choose how much they’ll charge you when you grow.
When you rely on a shared auth provider, their breach is your breach. A regional outage doesn’t just hit them, it takes you dark, too. You are tethering your security and uptime to a vendor’s infrastructure choices instead of your own.
This is the “blast radius” problem. A single incident at your identity provider can cascade across your entire application ecosystem. Not because of anything you did, but because architectural decisions that were made long before you signed the contract.
What Does Blast Radius Look Like?
Imagine it’s 9:00 AM on a Tuesday. A major managed Auth provider misconfigures a global load balancer. Because you share their identity core with 10,000 other companies, the failure doesn’t care that your AWS region is healthy.
- The Experience: Your status page is green, your servers are idling at 2%, but your login button is a brick.
- The Dev Reality: You are refreshing a vendor’s Twitter feed for updates. You can’t roll back code to fix it. You can’t reroute traffic. You have effectively outsourced your “Delete Key” to a third party.
That damage extends beyond the immediate downtime. Compliance teams scramble to document the incident for regulators. Security teams lose visibility into whether the outage masked something worse. Your business continuity plans that you carefully designed around systems that you control? Worthless because of failures in systems that you don’t.
For organizations like fintech and healthcare, the regulatory implications can dwarf the operational costs.
The Alternative? Isolation By Design
We believe authentication and authorization are too critical to live in a multi-tenant “neighborhood.” They require an isolated deployment, which is a fundamentally different approach that firewalls your data, configuration, and blast radius from thousands of other organizations.
In a shared environment, you are tethered to a vendor’s global risk profile. If they misconfigure a routing table for one customer, the cascade can still reach you. With isolated infrastructure, that “shared fate” disappears. Your security posture and uptime reflect your own architectural decisions, not the mistakes of a neighbor you’ve never met.
Many multi-tenant providers acknowledge this risk by offering “dedicated hosting” or “private instances,” but these are often treated as enterprise-tier upsells with massive, unexpected price tags. We view this differently: Isolation should be the default, not a premium add-on. By choosing a methodology that prioritizes isolated deployments from day one, you gain the resilience of a private cloud without the “enterprise tax” typically required to escape the multi-tenant blast radius.
The Real Cost of SaaS
Multi-tenant providers often lead with lower sticker prices. But that comparison misses several factors that engineering teams eventually discover.
There’s the growth tax. That cheap pricing escalates unpredictably as your user count climbs. There are hidden variables that only surface after you’ve committed. Expect to be charged for features that seemed to be included, to see premium tiers as a requirement for compliance capabilities, and support escalation paths that cost extra.
And then there’s the cost that you can’t quantify until it happens: the breach that came through shared infrastructure, the outage that took your revenue-generating applications offline, the compliance finding that required a multi-month remediation project.
Isolated deployment changes this equation. You pay for what you use, with pricing that scales predictably. You get the features that your compliance team needs without surprise upgrade requirements. And you eliminate the inherited risk that makes some ROI calculators so unreliable.
Deployment Flexibility is a Strategic Asset
Regulatory requirements don’t stand still. Data sovereignty laws proliferate. Compliance frameworks evolve. And your infrastructure choices today constrain your options tomorrow.
Multi-tenant SaaS providers typically offer one deployment model: their cloud, their region, their terms. When regulations change or business requirements shift, you adapt to their timeline.
Isolated deployment opens different possibilities. Cloud, VPC, on-premises, air-gapped—the same identity platform works across deployment models. Your infrastructure choices remain yours to make, based on your compliance requirements and business strategy rather than your vendor’s architecture.
