5 Multi-Tenant SaaS Security Warranties to Demand
Multi-tenancy is what makes SaaS economics work, and the architectural choice that security teams trust least. The same shared clusters, kernels, identity planes that make a platform profitable through economies of scale could turn one customer's breach into everyone's problem.
Whether you believe standard vendor questionnaires are security theater or not: vendor promises on segmentation of tenants, network separation, are all self-attested in vague language, and rarely backed by a SOC2 or tested independently. That's why gaps keep surfacing.
Here are five warranties worth getting in writing instead. Every answer is easy to give in ambiguously worded responses to questionnaires. The real test is whether a vendor puts it as a warranty in writing, dated, and checkable later.
Tenant Isolation at Every Layer: What to Demand (Warranty 1)
It's not enough to ask if tenants are appropriately segmented and hardened. They need an architecture that shows what stops a breach in one tenant's workload from reaching the kernel, what happens if it does anyway, whether the same holds on shared GPUs, and whether the data layer can leak across tenants even when isolation of the compute holds.
A Workload Escape Should Stop At The Hypervisor, Not Another Tenant's Kernel
Containers share a kernel; namespaces and cgroups don't stop a kernel exploit. In 2021, a researcher escaped a container inside Azure Container Instances and reached the Kubernetes API server. This incident was enough to take over roughly 100 pods across 120 nodes.
Edera's answer is a dedicated kernel per workload, each in its own lightweight VM, so an escape hits a hypervisor boundary instead of another tenant. This is the sort of guarantee worth asking for in writing. Vendors that can't yet make that promise can still adopt Edera's model atop existing Kubernetes and OCI tooling.
Blast Radius Stays Contained, Proven By CVE History And Pentests
In 2024, Snyk disclosed four runc vulnerabilities, grouped as Leaky Vessels. The vulnerabilities let a malicious actor escape to the host filesystem — notable because runc underlies nearly every container platform. The proof worth asking for is a CVE history for the isolation layer, together with independent pentest results that specifically targeted cross-tenant escape.
GPU Memory Is Wiped Between Tenants By Default
GPU drivers are firmware-bound and rarely audited like CPU kernels. In 2024, Trail of Bits found LeftoverLocals, whereby one process on a shared GPU could read another's uncleared memory, including live output from someone else's LLM session. Partitioning should be hardware-enforced too, like NVIDIA's MIG, not a scheduler's promise. Vendors whose drivers don't do this by default can still get there: Edera runs GPU drivers in dedicated zones and clears memory between tenants at that layer.
One Tenant's Data Never Returns In Another Tenant's Query
The leak can also happen one layer up: in 2023, a Redis client bug took ChatGPT offline for hours and leaked some users' chat and billing data to other accounts — just a race condition. The real test is whether that boundary holds in cache entries and backup restores, not just in live queries, and whether something harder than app logic enforces it: separate schemas, per-tenant encryption keys, or database-level row security.
Phishing-Resistant MFA and Zero Standing Privilege (Warranty 2)
It's not enough to ask if MFA is enabled and admin access follows least privilege. You need controls to know whether MFA is actually phishing-resistant, whether new admin and service accounts start with zero standing privilege, and whether that same rigor holds at the help desk, not just at login. In 2024, ShinyHunters compromised roughly 165 Snowflake customers, including Ticketmaster and AT&T, primarily MFA had never been turned on. Ask for a written commitment to zero standing privilege for admin and service accounts, and mandatory phishing-resistant MFA on the admin console and high-impact actions.
Most MFA still relies on something a user can be tricked into handing over: an SMS or app-based one-time code captured on a proxied login page, or a push notification approved without a second thought out of fatigue (the technique behind Uber's 2022 breach and repeated Scattered Spider intrusions since). Phishing-resistant MFA closes both gaps by binding the credential to the origin it was issued for: FIDO2/WebAuthn security keys and passkeys use public-key cryptography that simply won't authenticate to a spoofed domain, and certificate-based methods work the same way.
MFA alone isn't enough if it can be talked away, either: Scattered Spider has repeatedly called company help desks, impersonated privileged employees, and talked agents into resetting MFA straight into Super Admin access. and help-desk identity verification as rigorous as login. Every warranty should extend to the vendor's own supply chain.
Supply Chain Security: Accountability for Subprocessors (Warranty 3)
It's not enough to ask if a vendor manages its subprocessors responsibly. You need to know which outsourced providers touch your environment and whether they meet the same bar. In 2023, malware on one CircleCI engineer's laptop stole an already-authenticated session, and CircleCI told every customer to rotate every secret it could no longer vouch for any of them. This is the kind of admission that belongs in a standing written commitment, not just an incident postmortem.
Workload Identity and Access That Expires When the Task Ends (Warranty 4)
It's not enough to ask if access is revoked when it's no longer needed. They need an architecture that shows how a workload proves its identity, whether a stolen token or copied secret still works, whether an AI agent's access expires when its task ends, and how fast a person's account is disabled after they leave.
Workloads Authenticate Cryptographically, No Static Secrets
Okta's October 2023 breach showed the failure mode: a leaked static service-account credential exposed customer support files, several containing live session tokens good enough to hijack other vendors' accounts.
The IT-ISAC's 2026 Modern SaaS Security paper generalizes the fix: bind credentials cryptographically, by device, or by network, so a stolen one goes dead.
Edera takes the cryptographic one layer down, built on the open SPIFFE/SPIRE standard, giving every workload an identity rather than a static secret. The same logic applies to AI agents, which raise the stakes further: in 2026, one of OpenAI's own pre-release models found a zero-day in its sandbox's egress point and moved laterally for days on exposed credentials before anyone noticed.
Agent Sessions Are Short-Lived And Cryptographically Attested
The same logic applies to AI agents, which raise the stakes further: in 2026, one of OpenAI's own pre-release models found a zero-day in its sandbox's egress point and moved laterally for days on exposed credentials before anyone noticed. Agent sessions should be short-lived and cryptographically attested, expiring when the task ends rather than staying open for as long as an agent keeps finding doors.
Offboarding Happens Automatically, Not By Memory
The same IT-ISAC paper's fix is automated, SCIM-based deprovisioning: access revoked the moment HR or IT flags someone as gone, not whenever someone remembers by hand. A Cisco engineer's AWS credentials outlived his 2018 resignation by five months; he used them to delete 456 virtual machines, taking 16,000 accounts offline and costing $2.4 million. Automated, SCIM-based deprovisioning is simple automation most vendors still handle by hand, making it an easy commitment to get in writing.
Tamper-Evident, API-Accessible Audit Logs (Warranty 5)
It's not enough to ask if a vendor keeps audit logs. You need to know whether those logs can be tampered with, and whether you can get API access to them quickly. Okta's 2023 breach ran about three weeks, and Okta only learned of it after BeyondTrust flagged it, not from its own logging.
Logs only prove anything if they can't quietly be edited afterward, and Super Admin access is the exact prize Scattered Spider continues to target. Tamper-evident logging closes the gap since each log file is cryptographically hashed and chained to the one before it, as with AWS CloudTrail's own integrity validation, so modification, deletion, or forgery becomes detectable even to an attacker holding admin credentials. It doesn't prevent tampering (nothing does) but it makes tampering visible, and that's what matters.
The IT-ISAC paper goes further with programmatic, API-based access, not a dashboard, so logs reach your SIEM before the vendor can touch them. Demand both in writing: cryptographic tamper-evidence, and API access within a defined timeframe — the difference between reconstructing an incident in hours versus waiting weeks to start.
It’s Time to Act
Any vendor can give these answers verbally. The real test is whether they'll put them in writing, dated and checkable — and whether CISOs act on this collectively rather than one vendor at a time. That urgency is harder to defer as AI-enabled attacks accelerate faster than any single vendor's roadmap.
Start now: raise it at your next QBR or vendor risk council, or fold it into your next renewal conversation. It doesn't matter how you start, only that you start. Why not send this blog to the CISOs you know at other SaaS companies. One CISO asking alone is easy to defer; a hundred asking together isn't. "We take security seriously" is not the warranty you deserve.
.png)
-3.avif)