An employee signs in and sees only their company's orders. The demonstration looks reassuring, but did it establish an access boundary or simply show a screen with selected data? When accepting a SaaS platform serving multiple organizations, request evidence connecting each resource to its permitted tenant, beyond successful sign-in.
Two test organizations expose the question
Imagine a photography-equipment booking platform used by two independent organizations. Each has an order and file with a different synthetic marker, plus an employee and manager. A platform support operator also has a defined exceptional permission. This is a fictional planning example, involving no real platform assessment or customer data.
The employee should access their organization's resources according to their role, while the other organization's resources remain outside their access. A manager might legitimately work across both organizations, but that requires an explicit membership and permission decision. Similar usernames or an “administrator” label do not identify the tenant in which someone is currently operating.
Identity, role and tenant boundary
AWS explains that authentication and general authorization alone do not establish tenant isolation; tenant context must control available resources. Isolation can use dedicated or pooled resources. Do not impose a separate database per customer as the only acceptable evidence, or assume shared infrastructure necessarily means shared access.
Discuss three separate questions: who is the user, which actions does their role permit, and to which organization's data do those permissions apply? Answering one does not automatically answer the others. Hiding an order from a list also does not establish what other in-scope access channels allow.
A resource-boundary card you can review
Use the following card for important resources, asking a specialist to perform authorized checks in an appropriate environment. This is a proposed acceptance tool rather than attack instructions or comprehensive security coverage. Agree expected outcomes before the demonstration and retain the application version and environment reference.
| Field | Example entry | Requested evidence |
|---|---|---|
| Identity and context | Organization one's employee currently operating there | The tenant and role used for the check are explicit |
| Resource and owner | An order and file marked for organization two | Expected denial without disclosing unauthorized content |
| Included channels | Display, search, report and file | A separate result for each channel, beyond one screen |
| Support exception | Limited access for a specified purpose | Authorization, boundaries and a reviewable record |
Add the observed result, evidence reference and person responsible for explaining discrepancies. If the test environment lacks report access, record it as untested rather than passed. Where test data or configuration differs from production, request an explanation of how that limits the conclusion.
Include work outside a user's session
Reports and files might be prepared by background jobs, while another service connects without the user's interface. Microsoft discusses these workload identities and their tenant scope. Request coverage of important outputs instead of assuming an employee-account check covers every automated operation.
In the equipment example, a manager requests their organization's booking report. Specify which tenant the report should use during generation, where it is stored and who can open it. If membership changes before completion, ask the provider to explain and verify the agreed behavior instead of letting execution timing determine it accidentally.
Support and multiple memberships need explanations
Microsoft distinguishes role-based and resource-based authorization and considers users accessing several tenants. Translate this into business questions: how does the manager recognize the current context, who grants or revokes membership, and what may support access under which authorization? A customer's password should not be requested to demonstrate support functionality.
Review permitted access alongside denied access: blocking an authorized user from their resource can disrupt work too. Ask for explanations of support exceptions so undefined broad access is not presented as an unquestionable technical necessity. Evidence should describe the agreed behavior and its limitations.
This card complements the broader penetration-test procurement brief and the post-pilot expansion decision. Attach it when discussing SaaS development with Nextwave so customer-data boundaries enter acceptance scope. Passing a sample does not guarantee the absence of every isolation risk.
Sources for the distinction
The AWS page on tenant isolation and Microsoft sections on identity in multitenant solutions were read on 4 November 2026. This article represents no implemented design, security assessment or certification. Prepared with AI assistance and information and translation review.
