Cross-Tenant Access Risks

In 2023, a vulnerability in a widely used cloud-based file transfer platform allowed attackers to move laterally across customer environments , not by breaking into each tenant individually, but by exploiting weaknesses in the platform's architecture that connected them. Thousands of organizations were affected. They had nothing in common except that they all trusted the same vendor. None of them had assessed whether that vendor's multi-tenant architecture provided adequate isolation between customers. None of them had asked whether a compromise affecting another customer on the same platform could reach their data. The question had never come up , because most organizations do not think about the other tenants sharing their vendor's infrastructure. Until they have to.

What are Cross-Tenant Access Risks, Really?

Cross-tenant access risk is the possibility that one customer's data, workload, or environment within a multi-tenant cloud platform can be accessed, affected, or compromised as a result of another customer's presence on the same platform , or as a result of weaknesses in the platform's shared components that serve all tenants simultaneously. It is a risk category that is structurally invisible in most vendor assessments because it does not arise from the vendor's relationship with you specifically. It arises from the vendor's architecture and from the fact that you share that architecture with everyone else they serve.

Multi-tenancy is the foundational economic model of cloud-based software. A SaaS vendor does not build a separate instance of their platform for every customer , they build one platform and partition it so that each customer sees only their own data and configuration. That partitioning can be implemented at many levels: logical separation within a shared database, separate database schemas per tenant, separate databases on shared infrastructure, or fully isolated infrastructure per tenant. The security implications of each approach are dramatically different, and most customers have no idea which model their vendors use.

The risk is not theoretical. Logical separation , the most common and economical model , relies entirely on application-layer access controls to prevent one tenant from seeing another's data. If those controls contain a bug, a misconfiguration, or a design flaw, the separation fails. A researcher querying the wrong customer ID in a poorly validated API endpoint, a support tool that aggregates data across tenants without adequate scoping, or a background job that processes records without enforcing tenant boundaries , any of these can result in cross-tenant data exposure without any attacker involved. When an actual attacker is involved and deliberately probing for these weaknesses, the exposure is far more likely to be discovered and exploited.

Cross-tenant risk surfaces across several distinct attack and failure patterns:

• Insecure direct object references , APIs that accept tenant or resource identifiers without validating that the requesting user belongs to that tenant, allowing one customer to query another's data
• Shared infrastructure vulnerabilities , flaws in components shared across all tenants (authentication services, logging pipelines, background processors) that affect every customer simultaneously when exploited
• Privilege escalation across tenants , compromising a low-privilege account on the platform and using that foothold to escalate access to other tenants through shared administrative interfaces or support tooling
• Noisy neighbor effects , one tenant's activity consuming shared resources in ways that degrade availability or create timing-based side channels for other tenants
• Support and administrative access , vendor staff with the ability to access any tenant's environment for support purposes, creating a shared access layer that bypasses individual tenant security controls

Why this matters

Cross-tenant risk is one of the most underassessed dimensions of third-party cloud risk precisely because it is invisible in the standard assessment model. A vendor questionnaire asks about the vendor's security practices , their encryption, their access controls, their incident response capabilities. It does not ask about the other customers sharing the vendor's infrastructure, or about how a compromise of one of those customers might create a pathway to your data. Yet in a multi-tenant architecture, every other customer on the platform is an indirect part of your threat model.

The blast radius calculation for a cross-tenant incident is fundamentally different from a targeted vendor breach. When a vendor is breached through a vulnerability in their shared platform, every customer on that platform is potentially affected simultaneously , regardless of their individual security posture, their due diligence at onboarding, or the controls they have implemented on their own side. There is nothing a customer can do within their own tenant to prevent a cross-tenant vulnerability from being exploited. The protection is entirely in the vendor's architecture and implementation, which the customer has no direct control over.

This creates a specific due diligence obligation that goes beyond standard vendor assessment: evaluating the vendor's multi-tenant architecture and isolation mechanisms as a risk factor in their own right. A vendor that processes data for highly targeted organizations , financial institutions, healthcare providers, government contractors , alongside less security-conscious customers is a different risk proposition than a vendor with a more homogeneous customer base. The sophistication of attackers targeting one customer on the platform can affect every other customer if the isolation is insufficient.

Where most teams get this wrong

The most common failure is equating account-level separation with security isolation. Most customers understand that they have their own account, their own login, and their own data space within a vendor platform. They interpret this as meaning their data is isolated from other customers. What they have actually confirmed is that the application's user interface shows them only their own data in normal operation , not that the underlying architecture prevents cross-tenant access under adversarial conditions. These are meaningfully different claims, and most organizations have never asked a vendor to demonstrate the latter.

The second failure is not accounting for vendor support access as a cross-tenant risk factor. Virtually every SaaS vendor maintains the ability for support staff to access customer tenants , to investigate issues, respond to support tickets, or perform administrative operations. That support access layer is a shared capability that exists across all tenants simultaneously. If the vendor's internal access controls for that support tooling are inadequate, or if a support staff account is compromised, the exposure is not limited to one tenant. It potentially spans the entire customer base.

• Accepting 'our customers' data is logically separated' as evidence of adequate isolation without understanding what that means architecturally
• No assessment of the vendor's tenant isolation model , logical, schema-level, database-level, or infrastructure-level , and the security implications of each
• Failing to ask about vendor support access to your specific tenant , who can access it, under what conditions, and with what logging
• Not considering the customer composition of the vendor's platform as a risk factor , a platform serving highly targeted customers carries different cross-tenant risk than one serving low-risk SMBs
• Treating cross-tenant risk as a cloud provider concern rather than a vendor architecture concern

What good looks like

Organizations with mature cross-tenant risk assessment treat tenant isolation as a first-class question in vendor due diligence , not an afterthought. They understand that the vendor's architecture is as relevant to their security posture as the vendor's policies, and they ask questions designed to surface how isolation is actually implemented, not just whether it exists.

• Tenant isolation model documented in vendor assessment records , logical separation, schema-level, database-level, or dedicated infrastructure, with an understanding of what each implies
• Vendor support access controls assessed , who at the vendor can access your tenant, under what authorization process, and what is logged when they do
• Cross-tenant incident history reviewed , has the vendor ever experienced a cross-tenant data exposure, and if so, what was their response and what architectural changes followed
• Penetration testing scope confirmed , does the vendor's security testing include cross-tenant attack scenarios, and are the results available to customers
• Data residency and isolation contractually defined , the contract specifies how tenant isolation is implemented and what remedies exist if it fails

Tooling

Cross-tenant risk assessment is primarily an architectural and governance evaluation rather than a tooling problem. However, several tools support the customer-side due diligence and monitoring obligations it creates.

SaaS Security Posture Management , AppOmni, Obsidian Security, Valence Security

SSPM tools provide visibility into how SaaS platforms are configured and used within a customer's tenant. They surface overprivileged integrations, excessive data access grants, and anomalous usage patterns that may indicate cross-tenant exposure. For TPRM practitioners, they also provide evidence of active monitoring of the customer-owned layer within SaaS platforms , demonstrating that the organization is not passively trusting vendor isolation claims.

Cloud Access Security Brokers , Netskope, Microsoft Defender for Cloud Apps, Zscaler

CASBs provide visibility and control over data moving to and from SaaS platforms, including anomaly detection on data access patterns. In a cross-tenant incident, a CASB may detect unusual data access volumes or patterns before the vendor identifies the issue , providing early warning and evidence for incident response.

Vendor Security Assessment Platforms , OneTrust, ProcessUnity, Vanta

These platforms support structured vendor risk assessments that can be configured to include cross-tenant specific questions. The key is ensuring that the assessment template goes beyond standard security questionnaire content to include architecture-specific questions about tenant isolation, support access controls, and cross-tenant incident history.

Bug Bounty and Vulnerability Disclosure Programs , HackerOne, Bugcrowd

A vendor with an active bug bounty program that includes cross-tenant attack scenarios in scope has made a meaningful public commitment to identifying these vulnerabilities. The existence of such a program , and the vendor's track record of responding to and remediating cross-tenant findings , is a tangible signal of architectural security maturity that goes beyond policy attestation.

Governance challenges

The governance challenge with cross-tenant risk is that it falls outside the standard vendor risk assessment model. Most TPRM programs assess the vendor's security controls as they apply to the customer's data and relationship. Cross-tenant risk requires assessing the vendor's architecture as it applies to the entire customer population , a broader and less familiar evaluation that most assessment frameworks are not designed to perform.

The practical answer is to build cross-tenant assessment into vendor tiering and due diligence as a specific risk dimension, weighted by the sensitivity of the data being processed and the likely composition of the vendor's customer base. A vendor processing highly sensitive regulated data alongside many other customers warrants deeper architectural due diligence than one handling low-sensitivity operational data in a dedicated deployment.

• Add tenant isolation to your standard vendor questionnaire as a mandatory section for any cloud-based vendor processing sensitive data
• Request the vendor's penetration testing reports with specific attention to whether cross-tenant attack scenarios were included in scope
• Review the vendor's historical incident disclosures for any cross-tenant data exposure events , these are often understated in questionnaire responses
• Contractually require notification within a defined timeframe if the vendor becomes aware of any cross-tenant vulnerability or incident that may have affected your data
• Consider dedicated tenancy for highest-risk vendor relationships , some vendors offer infrastructure-level isolation at a premium that eliminates shared-component risk entirely

If you are a small team

Start by identifying which of your SaaS vendors process your most sensitive data in a shared multi-tenant environment. For those vendors, add three questions to your next assessment conversation: how is tenant isolation implemented at the architecture level, who at the vendor can access your specific tenant and under what conditions, and has the vendor ever experienced a cross-tenant data exposure. The answers will tell you whether the risk is being managed or simply assumed away.

• Review your vendor contracts for data isolation language , vague references to 'logical separation' without architectural specifics are a gap worth addressing
• Ask your highest-sensitivity SaaS vendors whether dedicated tenancy is available and at what cost , it is worth evaluating for your most critical relationships
• Enable whatever audit logging your SaaS platforms provide for your own tenant , it will not prevent cross-tenant incidents but will help you detect and respond to them
• Check whether your critical SaaS vendors have active bug bounty programs and whether cross-tenant vulnerabilities are in scope

What to require

Ask directly:

"How is tenant isolation implemented in your platform architecture , is it logical separation within a shared database, schema-level separation, separate databases, or dedicated infrastructure per customer?"

"Under what conditions can your support or engineering staff access our specific tenant, what authorization is required, and what is logged when they do?"

"Has your platform ever experienced a cross-tenant data exposure or vulnerability? If so, what was the impact, what was your response, and what architectural changes did you make?"

Expect as evidence

• A clear architectural description of tenant isolation , not a marketing statement, a technical explanation
• Documentation of support access controls including authorization requirements and audit logging
• Penetration testing reports or executive summaries confirming cross-tenant scenarios were tested
• Contractual data isolation commitments with defined remedies if isolation fails

A vendor who responds to the isolation question with 'your data is completely secure in your account' has described the user experience, not the architecture. Press for the technical answer.

How to evidence it

Cross-tenant risk is increasingly recognized in regulatory frameworks as a dimension of cloud vendor due diligence. Demonstrating that your organization has assessed this risk , not just accepted vendor assurances , requires documented evidence of architectural evaluation, not just questionnaire completion.

• Vendor assessment records documenting the tenant isolation model for each SaaS platform processing sensitive data
• Evidence of cross-tenant incident history review as part of vendor due diligence
• Contractual clauses specifying tenant isolation commitments and breach notification obligations
• Records of penetration testing scope review confirming cross-tenant scenarios were included
• Decision documentation for any cases where dedicated tenancy was evaluated and either adopted or declined with documented rationale

Key Takeaway

Every vendor you use in a multi-tenant cloud environment connects you , indirectly but meaningfully , to every other customer on that platform. Your security posture within your own tenant is irrelevant if the architecture separating you from other tenants is inadequate. You cannot patch your way out of a cross-tenant vulnerability, you cannot configure your way around it, and you cannot assess your way to safety without specifically asking how isolation works and whether it has ever failed. Cross-tenant risk is not exotic , it is a structural feature of every multi-tenant platform you depend on. The only question is whether you have evaluated it.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations